让 AI 整理发布说明：把代码改动写成用户真正会遇到的变化
“重构导出模块、修复边界情况、优化交互”写进发布说明后，用户仍不知道自己会看到什么。AI 可以把技术材料转成可读内容，但它不应从几个提交标题推测功能已经上线。先确认本次交付范围，再描述实际变化，发布说明才有使用价值。
AI生成概念配图
先做一份经过确认的变更底稿
Keep a Changelog 的官方说明把变更日志定位为按版本整理的重要变化，并区分它与代码提交记录。本文借用这一原则设计 AI 写作流程：输入不只包括提交标题，还要有面向用户的行为、适用范围、发布状态与可核对的工单或验收结果。
虚构的“纸舟资料夹”准备发布二点四版。底稿有四项：网页端新增按文件夹导出；修复含逗号标题的导出问题；内部拆分导出模块；移动端批量导出尚未开放。每项再补充是否已部署、适用账号以及是否需要用户操作，不能把“代码已合并”直接改写为“现在即可使用”。
底稿还要注明材料的截止时间。若某项功能先合并又被撤回，模型读到早期工单后仍可能把它列入本次更新。把发布负责人确认的最终范围作为筛选条件，遇到提交记录与发布清单冲突时进入待核实，不按文本出现次数或描述详细程度决定哪份有效。
先分组，再翻译成使用场景
让 AI 把同一功能的实现、修复和测试记录归到同一个主题，避免一个新入口被写成三项功能。内部模块拆分若没有已验证的用户影响，可以留在技术记录中；不能凭“重构”推断导出更快，更不能编造提升百分比。已知限制应和对应功能放在一起。
例子的用户说明可以写：“网页端现在可以导出当前文件夹中的资料，从文件夹菜单选择导出；该入口仅向已开通导出权限的账号提供。”另一条写“修复标题含逗号时导出内容被错误拆列的问题”。移动端未开放应明确标注，读者就不会拿着新说明到另一端反复寻找。
用模板约束状态、效果与操作
可复用模板：请依据以下已核实变更写发布说明，读者是现有普通用户。每条说明变化前后、适用范围、用户需要做什么，并附来源编号。合并同一功能的多条实现记录。没有证据的性能、稳定性或兼容性效果不要写；未上线项放入待发布清单，不混入本次说明。列出需要负责人确认的问题。
如果旧入口将在以后移除，应分别写清本次是否仍可用、替代路径和已确认的移除时间。日期缺失就提问，不能为了段落完整填一个“下月”。若用户暂时无需操作，也要以验收资料为依据，而不是因为底稿没写迁移步骤就默认升级毫无影响。
用目标账号逐条对照再发布
审核时把每条说明映射回变更编号，检查有没有把计划、实验或灰度状态写成普遍可用。用对应平台和权限的测试账号走一遍入口，核对按钮名称、默认行为与限制。说明中提到的帮助链接也要实际打开，确认读者能访问，而不是只存在于团队内部文档。
最终保存版本、日期、发布范围与审核记录。AI 负责整理表达，发布负责人负责确认事实；两者合起来才能减少遗漏。若上线后发现范围描述不准确，更新说明并留下修订原因，不要只在新版本里补一句，让旧版本读者继续依赖过期信息。
