用途：把“团队做了什么”翻译成“读者会有什么不同”。提交列表只是事实，更新日志要说明对读者的意义。
主要能力：按影响分组输出更新日志（⚠ 需行动/破坏性变更 → ✨ 新增与改进 → 🔧 修复 → 内部改动一行带过）；把每条改动翻译成 so-what（如“更快的搜索”→“大工作区中搜索结果现在一秒内返回”）；破坏性变更块包含受影响人群、什么会失效、编号迁移步骤及截止时间；受众利益不同时拆分用户版与开发者/API 版。
必要输入：原始改动（提交、PR 标题、团队清单，以及每项对用户可见的实际影响；影响不明时需询问，猜测会制造谎言）；读者是谁（终端用户、管理员、API 使用者）；读者必须执行的事项（迁移、重新认证、更新配置）及其截止时间；发布渠道（应用内提示、邮件、文档页，深度不同）。
翻译规则：每条要么给出读者可感知的不同，要么归入内部改动一行；破坏性变更必须先讲，并带编号步骤与日期；用第二人称现在时（“你现在可以……”）；声明带数字与限制（如“大文件约快 40%”“移动端暂不支持”）；完整版写一次，再按渠道压缩，但任何深度都保留破坏性变更块。
输出格式：产品 — 版本/日期；⚠ 需要行动；✨ 新增与改进；🔧 修复；另含内部改进；附各渠道删减版本。
限制与反模式：不要把提交列表加个标题就发布；不要把需行动事项埋在功能介绍下；不要夸大改进；不要用模糊措辞隐藏已修复的缺陷；不要用一份日志服务利益不同的两类受众。触发短语如“写发布说明”“把提交列表变成更新日志”“向用户宣布这次更新”。