在发布有意义的变更后撰写变更日志与交接总结时…

发布功能、修复或移除等有意义变更后，撰写变更日志、发布说明或「本次交付了什么」总结时使用。

适用场景

解决思路

1. 每个已交付变更写一条条目，最新的在最前，使用 ISO 日期，有版本号时按版本分组。
2. 文件若使用标准分类则沿用：Added / Changed / Deprecated / Fixed / Removed / Security；Deprecated 条目必须带上移除日期和替代方案。
3. 破坏性变更放在条目最前面、位于各分类之上，每条都写明所需的迁移操作（有迁移指南时附上链接）。
4. 优先写用户可见的影响，而非实现细节。
5. 使用现在时、主动语态，避免读者不懂的术语。
6. 把相关变更归组，绝不重复已有条目。
7. 记录移除项，而不只是新增项。
8. 发布说明是同一批事实面向受众的裁剪版：改了什么、影响谁、该怎么做；变更日志面向工程师，发布说明面向系统用户；两者取材相同且绝不能互相矛盾。
9. 条目结构：先用加粗引导句陈述结果，再写根因，再写修复，并内联写出准确名称。
10. Fixed 条目解释失败模式，而不是 diff；加粗引导句承载用户影响，便于读者快速分诊变更列表。
11. 诚实约定：把本次变更中暴露但未修复的已知问题标注为 known issues。
12. 诚实约定：把仍欠的待办事项标为 deferred items（例如「还需一次部署才能恢复 webhook key」）。
13. 诚实约定：把有意省略的内容按类别描述，避免同一省略被反复争论或被误认为疏漏。
14. 除非该确切动作已完成并核实，绝不标记任何东西为已实现、已部署或已验证；区分已实现（在仓库中）、已部署（已上线）与外部已验证。
15. 交接/完成总结按顺序覆盖：1) 这项工作为何存在；2) 交付了什么；3) 评审该看哪里（评审者在判断前必须理解的决策）；4) 验证状态：确切命令及其结果，绝不用一个光秃秃的对勾；5) 诚实的注意事项和我做错的地方；6) 残余风险以及不要做什么；7) 当前状态与所欠事项（已合并未推送、迁移、有序步骤及顺序错误的后果）。

适用边界 · 注意事项

• 琐碎改动（约三个改动文件或三个提交）不要写变更日志。
• 绝不重写或删除已有条目，只能追加。
• 不要用光秃秃的对勾代替验证命令与结果。