浏览 AI 知识库

AI 写 Git commit message：用真实 diff 和测试生成提交说明

提交说明应该让审查者快速看懂真实改动、原因和验证结果。它必须来自 diff 与测试，而不是把一个文案修改包装成“全面优化”。

需要哪一项，就直接查到哪一段

把表格、命令、清单或规则作为工作中的查询工具，不要求从头顺序阅读。

这张表什么时候有用

提交说明写“优化系统性能并修复多项问题”，真实 diff 只是给搜索空状态加一句文案。夸大的说明让审查者误判风险。

字段参考

要记录的内容	怎么填写	检查点
收窄提交范围	检查暂存文件和 diff，排除凭证、临时文件、无关格式化和用户未授权改动。	提交内容
写变更原因	说明用户或系统问题、旧行为和期望，不用“优化代码”代替。	Why
概括实现	按行为或模块描述实际差异，引用关键文件，但不逐文件复述。	What
列验证证据	写实际运行的测试、构建、截图或手工步骤和结果，未运行项明确说明。	How tested
说明风险与回滚	列数据迁移、兼容性、配置、部署和回滚要求。	Review focus

PR 说明实例

示例描述必须与当前 diff 和真实测试结果一致。

本例材料

需要确认	本例内容
现有材料	本次 diff 为组件文案、一个测试和一张截图；定向测试通过，全量测试未运行。
不能越过的边界	说明只基于真实 diff 和测试；未运行项与风险明确；不宣称性能、上线或用户效果。
要交付的结果	基于 diff 和测试的提交/PR 说明

最终输出

commit message 为 `fix(search): clarify empty result guidance`；PR 摘要列两个改动文件、测试命令、桌面/手机截图和“未运行全量套件”。没有写无证据的业务收益。

常见失败

验收方式

标题能由 diff 直接支持测试命令和结果真实风险与未验证项没有隐藏提交范围不含凭证、临时文件和无关格式化Why 对应真实问题和旧行为What 能定位到关键文件/行为测试、构建、截图和未运行项如实列出风险与回滚要求明确

进一步核对

查看、提交、合并和冲突处理必须建立在实际工作区与历史上。

PR 描述、审查和合并策略按仓库规则与平台当前功能核对。