让 AI 写提交信息和 PR 说明，要提供哪些真实变更证据

提交和 PR 说明只能从真实 diff 与测试生成

不要让 AI 根据任务标题猜完成内容。先确定提交范围、查看差异和运行验证，再写为什么改、实际改了什么、如何验证和剩余风险。

收窄提交范围

检查暂存文件和 diff，排除凭证、临时文件、无关格式化和用户未授权改动。

通过标准：提交内容

把涉及的文件、目录、版本、命令和实际输出写进记录；代码变化同时保留 diff 与测试结果。

写变更原因

说明用户或系统问题、旧行为和期望，不用“优化代码”代替。

通过标准：Why

确认“写变更原因”已经有可回查结果，再进入“概括实现”；依据仍然来自猜测时，把缺口单列并停在当前步骤。

概括实现

按行为或模块描述实际差异，引用关键文件，但不逐文件复述。

通过标准：What

确认“概括实现”已经有可回查结果，再进入“列验证证据”；依据仍然来自猜测时，把缺口单列并停在当前步骤。

列验证证据

写实际运行的测试、构建、截图或手工步骤和结果，未运行项明确说明。

通过标准：How tested

确认“列验证证据”已经有可回查结果，再进入“说明风险与回滚”；依据仍然来自猜测时，把缺口单列并停在当前步骤。

说明风险与回滚

列数据迁移、兼容性、配置、部署和回滚要求。

通过标准：Review focus

需要修改时先限定文件和行为范围，无法说明回滚方式或影响面的动作先不执行。 完成后把证据归入“基于 diff 和测试的提交/PR 说明”。

让审查者不打开全部文件也能定位重点

提交信息保持单一意图；PR 说明关联 issue、截图和测试。描述与 diff 不一致时修描述或拆提交，不美化完成状态。