changelog-writing

name	changelog-writing
description	编写或修改 public/changelog/ 下的更新日志时使用。确保日志条目符合项目规范。

更新日志写作规范

适用场景

• 新增 public/changelog/ 下的 .md 更新日志文件
• 修改已有更新日志
• 更新 public/changelog/index.json

条目类型前缀

• feat: — 新功能
• fix: — 修复已有 bug

dev: 类内部改动（构建脚本、配置、CI、提示词等）不面向最终用户，不出现在 changelog 中。

核心规则

1. 只记录用户可感知的变化

changelog 面向最终用户，只记录 feat: 和 fix:。内部重构、工具链调整、changelog 自身更新等一律不出现。

2. 涉及物品/设备时必须使用 i18n 正式名称

日志中涉及物品、设备、配方等概念时，必须到 src/shared/i18n/zh-cn/registry.ts 中查询其真正的中文名称，严禁自行翻译。

3. 修复 bug 时描述终端表现，而非根因

fix: 条目应直接描述用户看到的错误现象，而非内部技术原因。例如：

• ✅ 修复反应池无法选择输出端口物品的问题
• ❌ 修复反应池端口过滤条件不符的问题

4. 多条改动必须全部列出

如果一次提交包含多个独立改动，日志中应逐一列出所有条目，不可只选取主要条目省略其余。

5. 条目格式

每条以 - 开头，简短描述改动内容。不写技术实现细节，只写用户可感知的变化。

6. 区分手动内容与自动生成内容

部分 changelog 由用户手动撰写，AI 只负责追加基于提交日志自动生成的条目。

• 用户手动撰写的部分：只读，不修改。包括用户写的标题、引言、章节、条目等。
• AI 自动生成的内容：统一放在文章末尾的 ## 其他改动 章节下，以列表形式逐条列出。## 其他改动 不是文章最后一个章节——用户可能在该章节之后写结语、未来展望等内容，插入时应识别并放在正确位置。
• 去重：在写入 ## 其他改动 前，必须先通读用户手动撰写的部分。如果某个功能或 bug 修复已经被用户手动提及，则在 ## 其他改动 中不再重复列出。