CCClaude Code中文喂饭教程

/code-review：提交前审查

代码审查不是让 CC 再写一遍，而是让它站在审查者角度找风险、越界和遗漏。/code-review 应该发生在修改和 /verify 之后，提交前之前。

审查阶段的原则：先找问题，再决定是否修；不要把审查变成新需求开发。

什么时候做代码审查

直接复制

/code-review

请审查本次未提交改动。

重点看：
1. 是否有明显 Bug。
2. 是否有安全风险。
3. 是否有越界修改或无关重构。
4. 是否遗漏测试或验收。
5. 是否包含 API Key、Token、密码或隐私信息。
6. 是否建议继续修改，还是可以进入提交前检查。

更严格的审查模板

/code-review

请只审查本次未提交改动，不要直接修改文件。

审查重点按严重程度排序：
1. 会导致功能错误、数据错误或安全问题的 Bug。
2. 越权、密钥、隐私、权限、危险命令相关风险。
3. 超出任务范围的修改。
4. 缺少必要验收或测试。
5. 可维护性问题。
6. 命名、格式、风格建议。

每个问题请包含：
- 严重程度：高 / 中 / 低
- 相关文件：
- 问题说明：
- 判断依据：
- 建议处理方式：

如果没有发现必须修的问题，也请明确说“未发现阻塞提交的问题”。

审查结果怎么看

审查结果不是越多越好。好的审查应该具体、可定位、可判断；差的审查会堆很多“建议优化”“可以考虑”。

审查结果可信度
引用具体文件、改动和风险高
能说明触发条件和后果高
只说“建议优化代码结构”低
没看 diff 就泛泛谈最佳实践低
把新需求当成审查问题需要降级处理

问题分级

让 CC 按提交风险审查

如果这次改动要上线或合并，可以更严格一点：

/code-review

请按“提交是否安全”的角度审查本次改动。

重点判断：
1. 有没有会阻塞提交的问题。
2. 有没有必须本次修的问题。
3. 有没有可以单独开任务的问题。
4. 有没有只是风格偏好的建议。
5. 有没有需要重新 /verify 的地方。

请不要提出和本次需求无关的新功能建议。

如果审查指出问题

先不要直接修改。

请把审查问题分成三类：
1. 必须在本次任务修复的问题。
2. 可以单独开新任务的问题。
3. 只是风格建议的问题。

对必须修的问题，请给出最小修复方案。
在我确认前不要修改文件。

如果它指出的问题看起来不确定，先追问依据：

请先不要修。

请解释这个审查问题的依据：
1. 具体是哪段改动导致风险。
2. 什么输入或场景会触发问题。
3. 如果不修，最坏后果是什么。
4. 这个问题是本次引入，还是原来就存在。
5. 你有多大把握，请说明不确定点。

只有当问题能说清“触发条件 + 后果 + 文件位置”，才值得进入修复。

如果审查结果太泛泛

这个审查结果太泛泛。

请重新审查，并做到：
1. 每个问题都必须引用具体文件或改动。
2. 不要输出没有依据的泛泛建议。
3. 把高风险问题放在最前面。
4. 如果没有具体问题，请明确说没有发现阻塞项。
5. 不要为了显得有内容而编造问题。

修完审查问题后要复审

审查发现问题并修复后，不要直接提交。需要让 CC 复查“修复是否又引入新问题”：

刚才已经按审查意见做了修复。

请复审这次新增改动：
1. 原审查问题是否已经解决。
2. 修复是否只影响必要文件。
3. 是否引入新的行为变化。
4. 是否需要重新运行验收。
5. 是否仍有阻塞提交的问题。

审查后收尾

请基于刚才的审查结果给出收尾建议。

请输出：
1. 必须修的问题。
2. 可以暂缓的问题。
3. 是否需要重新 /verify。
4. 是否可以进入提交前检查。
5. 建议的提交说明。

审查常见误区

误区正确做法
审查一出建议就全部照做先分级，只有阻塞问题必须处理
把风格建议当成 Bug风格建议可以暂缓或单独处理
审查阶段继续加功能回到新任务，不要混进本次提交
不看未提交文件范围先确认 diff，避免提交无关文件
没有复审修完审查问题后再看一遍

提交前最终确认

请做提交前最终确认。

请输出：
1. 本次任务目标是否完成。
2. /verify 是否通过。
3. /code-review 是否还有阻塞问题。
4. 是否存在密钥、账号、隐私或无关文件变化。
5. 建议的提交信息。
6. 如果不建议提交，请说明必须先处理什么。

验收结果

下一篇：CLAUDE.md 与项目记忆