根据拉取请求撰写版本说明，同时过滤内部信息
让 Beeuni 阅读已连接的 GitHub 仓库、核对版本范围，并根据变更起草面向用户的说明，同时附上相关引用。
Beeuni 团队
Beeuni··阅读时间 3 分钟
标题为“重构导出任务”的拉取请求能告诉审阅者该去哪里查看，却很难让客户了解实际情况。版本说明需要解释产品发生了什么变化、会影响哪些人，以及这些变化是否已在此版本中推出。
确认版本中实际包含哪些内容
通过已配置的 GitHub 连接，授予智能体访问仓库的权限。让它查找上一个和当前标签，对比两者之间的提交，并检查相关拉取请求。如果有多个版本正在推进，请明确提供仓库名称和标签。
Read the connected repository and compare v1.4.0 with v1.5.0.
Draft release notes for users, grouped into features and fixes.
Inspect the linked PRs and diffs rather than relying on titles alone.
Keep a separate list of internal changes, reversions, and uncertain availability.
Save the draft with PR references. Do not publish a release.已合并的 PR 不一定已经部署，同一周内合并的变更也可能属于后续版本。对比标签可以确认包含了哪些代码，但功能标记和发布状态可能仍需团队确认。
让智能体先创建一份内部工作清单，列出来源 PR、行为变更、受影响的用户，以及该变更是否包含在版本中。检查已撤销的变更和仍处于禁用状态的功能。在有人确认之前，不要把存疑的条目放进公开草稿。
从实现细节转为面向用户的变更说明
以下示例展示了几种常见的 PR 说明编辑方式：
| 工作备注 | 版本说明草稿 | 编辑决定 |
|---|---|---|
| 在查询参数中保存所选筛选条件 | 分享链接时，现在会保留筛选条件。 | 描述用户可见的行为 |
| 修复双击造成的重复提交 | 修复了一个问题：双击“提交”可能会创建重复请求。 | 说明触发条件和结果 |
| 整理测试辅助工具 | 不纳入公开说明 | 在内部记录中保留维护类变更 |
| 导出功能的代码已加入，但控制它的开关尚未开启 | 等导出功能可用后再列入 | 发布前确认功能是否可用 |
按读者需要了解的信息分组
如果版本内容适合分组，可使用“新功能”“改进”和“修复”等栏目。没有内容的栏目可以省略。多个 PR 若共同实现一项功能，可合并为一条说明。若多个修复影响不同操作，则应分别列出。
不要把必需的操作藏在笼统的改进列表中。如果 API 字段发生变化，请注明旧形式和新形式，并链接到迁移说明。如果行为变化只影响某些账户或客户端，请说明具体适用对象。请功能负责人确认这些细节。
让草稿内容有据可查
- 在审阅稿中保留 PR 或提交的引用，即使这些引用最终不会出现在公开说明中。
- 确认每项已公布的功能都已包含在所述版本中。
- 移除内部主机名、凭据、客户信息和未公开的问题内容。
- 除非有可引用的测量数据，否则将“速度更快”等说法改为对具体行为的描述。
要求提供两个文件：公开说明草稿，以及列明已纳入、已排除和待确认条目的工作清单。审阅后，如果连接权限允许写入仓库，你可以让智能体更新仓库中的草稿。发布版本则需要单独指示。如果说明称表单问题已修复，网站测试指南介绍了可用于核实这一说法的复现记录。