CCClaude Code中文喂饭教程

让 Claude Code 写提交说明

提交说明不是随便让 CC 编一句。要先确认 diff、验证结果和风险，再让 CC 生成不夸大、不遗漏、能被团队理解的提交信息。

Claude Code 很适合帮忙写提交说明，但前提是：它必须基于真实 diff 和验证结果，而不是凭聊天记忆编总结。

提交说明的目标不是好看，而是让团队知道这次改了什么、为什么改、有没有风险。

写提交说明前先确认三件事

不要一改完就让 CC 写 commit message。先确认：

可以这样开场：

请先不要生成提交说明。

请先检查：
1. 当前 diff 是否只包含本次任务相关内容。
2. 是否有无关文件或临时文件。
3. 是否有密钥、Token、账号、内部地址。
4. 已经执行了哪些验证。
5. 是否还有不适合提交的风险。

这一步通过后，再写提交说明。

提交说明不要夸大

CC 很容易把提交说明写得过满，比如：

这些说法通常不适合真实提交。提交说明应该具体、克制、可追溯。

更好的表达：

可以这样要求：

请生成提交说明，但不要夸大。

要求：
1. 只描述本次 diff 真实包含的内容。
2. 不要写“全面”“所有”“彻底”等夸张词。
3. 不要包含没有验证过的结论。
4. 如果有未验证风险，放到备注里。

推荐格式

简单项目可以用一句话：

docs: add Claude Code diff review guide

中文项目可以用：

docs: 新增 Claude Code diff 审查教程

复杂一点的任务，可以让 CC 生成：

docs: 新增 Claude Code diff 审查教程

- 补充文件范围、越界修改、删除内容的审查方法
- 增加按风险等级审查 diff 的模板
- 更新学习路线和导航入口

重点是：标题说清主要改动，正文列出关键点。

让 CC 先给多个版本

不要只要一个结果。可以让 CC 给三个版本：

请基于当前 diff 生成 3 个提交说明版本：

1. 简短版：一行，适合个人项目。
2. 团队版：标题 + 3 条 bullet。
3. 保守版：只描述最确定的改动。

要求全部基于真实 diff，不要编造。

然后选择最适合的一版。

提交说明要和任务类型匹配

任务类型推荐前缀示例
文档docsdocs: 更新快速学习路线
修 Bugfixfix: 修复移动端按钮溢出
新功能featfeat: 新增站内搜索入口
样式stylestyle: 调整文档页右侧卡片展示
重构refactorrefactor: 拆分模型配置说明
测试testtest: 补充接口边界测试
构建buildbuild: 更新静态站生成脚本

如果团队没有规范，就用简单清楚的中文也可以。关键是准确。

不确定时写风险备注

如果本次任务没有跑完整检查，不要假装没风险。

请生成提交说明，并在备注里说明未验证项。

格式：
标题：
正文：
验证：
未验证风险：

这样比写一句“完成优化”可靠得多。

提交前最后一次自查

提交说明写好后，继续让 CC 做最后检查：

请检查这条提交说明是否准确。

请对照当前 diff 判断：
1. 有没有夸大。
2. 有没有遗漏关键改动。
3. 有没有提到不存在的内容。
4. 有没有把未验证内容写成已完成。
5. 是否适合给团队成员阅读。

提交说明也是交付的一部分，不能随便糊弄。

多个任务不要硬塞进一次提交

如果一次 diff 里混了多个目标，提交说明会很难写清楚。这通常说明任务应该拆开。

可以让 CC 判断是否需要拆提交：

请判断当前改动是否适合一次提交。

请输出：
1. 本次 diff 里是否包含多个独立目标。
2. 如果适合拆提交，建议怎么拆。
3. 每个提交应该包含哪些文件。
4. 每个提交对应的提交说明。
5. 是否有文件暂时不适合提交。

文档、样式、业务逻辑、配置、数据库改动混在一起时，尤其要小心。拆开提交不是形式主义，而是让以后排查问题更容易。

团队协作里的提交说明

团队项目里，提交说明要给别人看，不是只给自己看。

更适合团队的写法：

可以让 CC 生成团队版：

请生成适合团队协作的提交说明。

要求：
1. 标题控制在一行。
2. 正文列出 2 到 4 个关键改动。
3. 单独写验证结果。
4. 单独写未验证风险。
5. 不要写营销式描述。

这样的提交说明，后续做 Code Review、回滚和问题追踪都会更清楚。

常见错误

遇到这些情况，先回到提交前检查。

验收结果

上一篇：提交前检查相关：任务交接说明