先确定这份日志给谁看
使用 Claude 写更新日志时，先说明读者是开发同事还是产品用户。内部提交信息可能描述实现，用户更关心操作和行为变化。不要直接把提交数量当作功能数量，多个提交可能只解决同一个问题。
准备已核实的改动清单
给每项改动附编号、状态和证据。已合并、已部署、已向所有用户开放是不同状态。模型不能因为看到代码合并记录，就写成用户现在已能使用。本文例子仅用于方法练习，不代表本站发布了对应功能。
虚构案例：三个状态
材料：“R1：新增导出说明，已部署；R2：修复空值提示，已验证；R3：批量处理仍在开发”。正式日志可以说明R1和R2，R3应放计划或不在本次列出，不能写成新增批量处理。
把实现变化译成可理解行为
如果记录写“修正空值分支”，需要知道用户此前看到什么、现在看到什么；信息不足先问，不编造报错文本。说明解决的具体场景，避免“全面提升稳定性”这样没有范围的表述。
区分新增、修复与限制
新增指用户多了什么明确能力；修复指已有行为按预期工作；限制是当前条件或已知问题。一个条目可以附适用范围，但不能将所有内容包装成新功能。保留版本号与发布日期，前提是材料实际提供。
变更涉及迁移时单列
如果用户需要更新设置、重新登录或转换文件，明确行动和影响。没有证据就不写“无需任何操作”。接口变化需要让负责人确认兼容要求，不能从一条提交标题推断所有旧调用都继续可用。
发布前逐条回溯
对照原记录检查状态、版本、功能名称、链接和限制。删除未验证的性能数字，确认已知问题没有遗漏。若只完成编辑，不要标为已正式发布或已通知用户，对外发布属于另一项实际动作。
常见问题：写得太技术怎么办
要求用用户能观察到的行为解释，保留必要术语但不堆实现细节。每条一句变化加一句适用条件即可；不为了简短省略限制。版本比对可参考《Claude 文档对比教程：核对版本差异与新增条件》。