用 AI 维护 Changelog 与发布说明：从 git log 到可读文档

发布说明为什么总是拖到最后？

功能合并时大家很兴奋，写 Changelog 时却集体失忆。结果是：要么空着，要么粘贴一串无意义的 commit 标题。AI 很适合承担「初稿生成」，但人必须负责「叙事正确」。

两种受众，两份文案

面向用户

关心：新能力、破坏性变更、是否需要操作、已知问题。少提内部模块名。

面向开发者

关心：API 变更、迁移步骤、环境变量、依赖大版本。

不要让 AI 输出一份「四不像」同时糊弄两边。

推荐输入材料

一次性提供给模型：

• 版本号与日期区间
• git log 或 PR 列表（已筛选 merge）
• 破坏性变更备注（若有）
• 上一版 Changelog 风格样例一段

输入越结构化，初稿越接近可发布。

质量控制要点

• 合并同主题：五个「fix button」应归并为一条「修复若干按钮交互问题」
• 删除噪音：格式化、锁文件、typo 不必逐条展示
• 核实功能名：模型可能把分支名脑补成产品名，必须对照实际 PR
• 标出 Breaking：升级指引单独成节，避免埋在小修复里
• 中英文一致：若站点是中文产品，用户向说明用中文写清

可复用 Skill 骨架

1. 读取用户提供的提交列表

2. 按 Added / Changed / Fixed / Breaking 分类

3. 生成用户向与开发者向两个小节

4. 列出需要人工确认的不确定项（而不是假装确定）

把「不确定项」强制输出，能显著降低一本正经的胡编。

与 RuleHub 站点实践

RuleHub 自身有 更新日志 与洞察专栏。发布内容型功能（例如新文章、新导航）时，Changelog 应写用户可感知的变化，而不是只写「update header」。

行业工具与模型更新可参考 AI 最新消息，但不要把外部新闻误写进自己的产品 Changelog。

发布节奏建议

• 小版本：AI 初稿 + 负责人 10 分钟润色
• 大版本：先人工列「叙事大纲」，再让 AI 填充条目，避免结构跑偏

小结

AI 让 Changelog 从「没人写」变成「有人改」。关键是区分受众、提供结构化输入、强制不确定项清单，并由人做最终署名。

下一步：为最近一个版本生成双受众说明初稿，对照实际功能删改后合入仓库。