编程开发 编辑复核
Git 提交说明与变更边界
根据真实 diff 生成清晰、可追溯的提交说明，突出行为变化、测试和未包含的事项。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名代码变更记录编辑。请只依据 diff 和测试证据写提交说明，不把未来计划或未实现的效果写成已完成内容。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 用一句话概括用户或系统行为变化
2. 列出关键文件、接口、数据和兼容性影响
3. 记录已运行、未运行和需要人工验收的测试
4. 写明不包含的重构、风险和回滚提示
输入变量：
- 代码 diff（{{diff}}）：提供与本次提交直接相关的 diff。
- 原始需求（{{requirement}}）：提供用户可观察的需求。
- 测试结果（{{tests}}）：列出已运行的命令和结果。
- 兼容性（{{compatibility}}）：说明需保持的 URL、字段和行为。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 提交前检查工作区是否混入无关文件。
- PR 描述链接真实构建和浏览器验收证据，不要只贴提交标题。
WHEN IT FITS
适用判断
适合这些情况
- 一次改动涉及多个文件，需要说清楚变更边界。
- 团队有提交格式约定，需要保持一致。
- 想在提交信息里留下为什么这么改，方便日后追溯。
换个做法更好
- 你要写的是 PR 描述：用《Pull Request 说明生成器》，篇幅和读者不同。
- 改动是单文件的一行修复：一句话就够。
- 你没法提供 diff：模型只能按文件名猜，写出来的信息没有价值。
FAILURE MODES
常见翻车与修正
- 提交信息把 diff 复述了一遍，没说为什么改。
要求正文回答「为什么需要这个改动」和「为什么用这个做法」，改了什么看 diff 就知道。
- 一条提交信息描述了三件不相关的事。
这说明提交本身该拆。要求指出改动中彼此独立的部分，并建议拆分方式。
- 标题超长或不符合团队的格式约定。
把团队约定和几条现有提交粘进输入，要求格式对齐并控制标题长度。
ACCEPTANCE
怎么判断输出合格
- 正文说明了改动原因和方案取舍，不是 diff 复述。
- 一条提交只描述一件事，混杂的建议了拆分。
- 格式符合团队约定，标题长度合适。
- 涉及的关联信息（issue 编号、影响范围）都带上了。
SAFETY BOUNDARY
使用边界
- 提交信息会永久留在历史里，不要写入客户名称、内部工单细节和安全问题的具体描述。
- 模型总结的变更范围可能有遗漏，涉及破坏性改动的标注要自己确认。