编程开发 编辑复核
从提交记录整理发布说明
把真实提交和变更文件整理成用户能理解的发布说明，区分内部修复、可见变化和仍待验证事项。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名发布工程编辑。请只基于提交记录、变更文件和测试证据写发布说明，不从提交标题推测未实现的业务收益。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 按用户可见功能、修复、性能、安全和内部维护分类
2. 为每项补充影响版本、用户动作和证据链接
3. 指出破坏性变更、迁移、已知问题和未验证部分
4. 输出适合用户、客服和工程团队的三个版本
输入变量：
- 提交记录（{{commits}}）：提供 commit、PR 或变更摘要。
- 测试证据（{{tests}}）：提供通过的测试和未运行的检查。
- 读者（{{audiences}}）：说明需要哪些版本的读者。
- 发布信息（{{release}}）：说明版本、日期和升级方式。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 先核对提交是否真的进入目标分支和镜像，再发布说明。
- 未运行的测试明确写出来，不要用“全面验证”概括。
WHEN IT FITS
适用判断
适合这些情况
- 有一批提交记录需要整理成对外可读的说明。
- 提交信息质量参差，需要归类和改写。
- 要区分哪些改动值得对用户说、哪些是内部细节。
换个做法更好
- 你要写给工程团队看：用《工程发布说明》，措辞和详略不同。
- 只有两三个提交：直接写更快。
- 提交信息全是「fix」「update」：先补充改动说明，否则整理不出内容。
FAILURE MODES
常见翻车与修正
- 模型给提交补充了它推测的用户价值描述。
推测的价值可能完全不对。要求只基于提交内容改写，无法判断用户影响的单独列出让你补充。
- 内部重构和依赖升级被写进了面向用户的说明。
要求先分类：用户可感知的、需要用户行动的、纯内部改动，最后一类不进对外说明。
- 把破坏性变更混在普通改动里，用户看漏了。
补充要求：破坏性变更和需要用户手动操作的项必须单独成段并置顶。
ACCEPTANCE
怎么判断输出合格
- 所有描述都能追溯到具体提交，没有推测的价值主张。
- 内部改动没有混进对外说明。
- 破坏性变更单独置顶，不会被漏看。
- 无法判断影响的提交单独列出待确认，而不是随便归类。
SAFETY BOUNDARY
使用边界
- 提交信息里可能含内部代号和未公开功能，对外版本要逐条筛掉。
- 模型会把提交描述当作事实，实际改动和描述不符的情况很常见，关键项要看 diff 确认。