Vibe Coding 从 Diff 生成 Release Notes：机器归集，人工判定用户影响

自动生成发布说明通常从提交标题开始：把 feature 放进 Added，把 fix 放进 Fixed，再让模型润色。这个流程能减少归集工作，却无法判断一次“重构”是否改变超时默认值、数据库迁移是否需要停写、配置重命名是否会让旧部署启动失败。相反，巨大的生成代码 diff 可能完全没有用户可见影响。Diff 是证据入口，不是影响结论。

Keep a Changelog 强调变更记录面向人而不是机器日志，Semantic Versioning 则把公开 API 的兼容意图连接到版本号。Vibe Coding 流程应让机器负责不漏材料，让实际 owner 负责“用户需要知道什么”和“我们是否敢作这个承诺”。

先冻结准确的发布集合

生成任务必须接收 base 与 head 的不可变提交、目标产品、制品摘要和发布渠道。只读“上次 tag 到当前分支”会受移动 tag、补丁挑选、子模块和生成制品影响。合并提交、关联 PR、issue、schema、API 规范、配置、依赖锁、功能开关和迁移目录都进入候选材料，并记录收集器版本。

同一提交可能进入多个产品，不应把整个 monorepo diff 都写给每类用户。先根据构建图和发布清单计算实际包含的组件，再按受众划分：最终用户、API 消费者、管理员、运维者和贡献者。无法确定制品包含关系时标为 UNKNOWN，由 release owner 裁决。

Conventional Commits 或标签可以提供线索，但 feat 不保证对用户有价值，fix 也可能引入破坏性行为。提交标题与 PR 描述属于作者声明；生成器还应查看实际 diff、契约报告、测试结果和批准的决策记录。两者冲突时保留冲突，不能选择更好听的一边。

从变化事实生成候选影响

先抽取事实，不急着写营销语言：新增或删除了哪个公开入口，默认值怎样改变，哪些角色可见，数据是否迁移，旧客户端能否继续，操作员要执行什么，安全边界是否变化。每条事实连接到具体文件、operation、schema 或配置键，生成稳定 change ID。

随后归类为 Added、Changed、Deprecated、Removed、Fixed 或 Security。内部重命名若不改变公开行为可以不进用户说明，但仍保留在构建追踪中；性能优化只有在受控测量支持时才写“更快”，不能根据算法看起来更优就给出百分比。安全修复先走披露策略，AI 不得把漏洞细节自动公开。

生成器尤其要扫描“安静的破坏”：必填环境变量、权限 scope、默认超时、排序、日期格式、错误码、CLI exit code、数据库约束、缓存键和删除行为。API 变化应连接API 文档实现同步，规格范围改变则连接规格变更重新验收。机器发现不了的业务含义必须由 owner 补充，不能留给用户从代码猜。

区分 Changelog 与本次 Release Notes

Changelog 是按版本维护的长期、可扫描历史，保留弃用到删除的连续关系；Release Notes 服务一次发布，可按受众组织升级步骤、风险、已知问题和回退入口。二者共享批准的 change ID，但不是复制同一段文本。前者要稳定，后者可以增加本次 rollout 与迁移上下文。

这也不同于开发者 Changelog 分发归因：后者回答说明发布后经哪些渠道触达并被采用，本篇只负责说明内容是否忠实于实际差分。生成、验收、发布与分发回执应保留不同状态，不能因为邮件已发就倒推内容正确。

每条用户说明采用结果导向表达：谁受到影响，原行为与新行为是什么，是否需要动作，何时生效，如何验证。避免“优化架构”“提升体验”这类无验收条件的句子。破坏项给出旧新示例、迁移前提、失败信号和支持窗口；Deprecated 必须提供替代路径和计划删除版本。

人工验收不是点一次 Approve

至少由代码 owner 核实事实、产品或 API owner 核实用户影响、release owner 核实包含范围与时序。涉及安全、数据和运营动作时加入对应责任人。审阅界面展示 base/head、制品、原始证据、AI 候选和人工修改差分，不能只展示润色后的最终段落。

每个 change ID 只能进入 accepted、excluded、needs-evidence 或 blocked。Excluded 记录理由，例如仅测试重构或未进入目标制品，防止下一次又被当成新变化。Needs-evidence 不能在发布时自动消失；涉及兼容、迁移或性能却没有证明时，应删去未经支持的结论或阻断发布。

版本号由公开契约与发布政策决定，不由提交数量决定。SemVer 的 major、minor、patch 只在项目确实声明并维护公开 API 时有意义；零主版本和多产品仓库仍需书面策略。版本提议与弃用窗口由人批准，AI 可以报告与既有规则冲突。

发布后保持历史可校验

最终包包含 change ID 列表、文本摘要、base/head、制品摘要、版本、审批人、契约与迁移证据、已知问题和发布时间。Changelog、Git release 与站内说明都从这份已批准包渲染，避免多渠道手改出不同事实。GitHub 自动生成 release notes 可以归集合并内容，但官方能力本身不提供上述语义验收。

发布前在候选制品上执行迁移和关键行为验证，并通过编程 Agent 改动验证门。依赖更新的用户影响还应接入依赖升级与锁文件兼容门，不要把 lockfile 噪声隐藏成一句“常规维护”。

发布后若发现遗漏，不静默改写已签发版本。新增带时间和原因的 correction，保持原文与更正关系；若错误会导致危险操作，立即在当前入口突出修正并触发沟通。回滚也发布新的状态，说明哪些能力撤回、数据是否受影响和下一步，而不是删除失败版本的历史。

从 Diff 生成内容的正确分工，是让 AI 覆盖庞大材料、关联证据和提出疑点，让人承担兼容性、受众和措辞责任。这样 Vibe Coding 带来的高变更频率不会变成高噪声提交摘要，用户拿到的是可行动、可追溯且与真实制品一致的发布说明。