CCClaude Code中文喂饭教程

实战：让 CC 审查 PR

PR 审查要优先找风险，不是让 CC 夸改动。要按严重程度排序，重点检查越界修改、漏测、兼容性和安全风险。

审查模板

PR 审查的目标不是“让 CC 夸写得不错”，而是让它帮你提前发现合并风险。输入越具体，审查越有价值。

/code-review

请审查这个 PR 或本次 diff。

优先级：
1. 可能导致线上 Bug 的问题。
2. 安全、权限、密钥、隐私风险。
3. 测试和验收遗漏。
4. 越界修改或无关重构。
5. 可读性和维护性建议。

请按严重程度输出，不要把风格建议放在最前面。

审查前给什么信息

请审查这个 PR。

PR 目标：
【写清楚这次 PR 要解决什么】

本次主要改动：
【列出模块或文件】

已做验收：
【列出测试、构建、截图、人工验证】

我最担心：
【权限 / 数据 / 兼容 / 性能 / UI / 其他】

限制：
1. 只审查本次 diff。
2. 不要把历史问题当成本次阻塞项。
3. 高风险问题放前面。
4. 每条问题都给依据。

好审查结果应该有

好的 PR 审查要像风险清单，不像读后感：

内容合格表现
位置能定位到文件或具体改动
依据说明为什么从 diff 能看出问题
后果说明不修会影响什么
级别阻塞、建议修复、可选建议
处理给出最小修复方向

问题应该怎么分级

分级时要避免两个极端：一是把所有问题都说成阻塞，导致 Review 没重点；二是把真正的权限、数据、兼容问题写成“建议优化”，导致风险被低估。

可以让 CC 复核分级：

请重新检查刚才的 PR 审查分级。

要求：
1. 阻塞项必须说明不修会造成什么具体风险。
2. 建议项必须说明为什么不阻塞合并。
3. 可选建议不能影响本次交付判断。
4. 如果分级过重或过轻，请调整。

不同 PR 的审查重点

PR 类型重点
前端页面响应式、交互、可访问性、截图验收
后端接口兼容性、错误码、权限、调用方
数据库迁移、回滚、性能、数据兼容
配置部署环境变量、密钥、回滚、影响范围
文档链接、导航、学习路线、SEO
重构行为不变、测试覆盖、diff 范围

PR 审查不要做什么

不要让 PR 审查变成二次需求开发：

如果发现审查跑偏，可以这样收回来：

请收窄到本次 PR 的合并风险。
历史问题、风格偏好和无关重构先不要展开。

如果 CC 给了一堆泛泛建议

这些建议太泛泛了，请重新审查。

要求：
1. 只保留能对应到具体 diff 的问题。
2. 每条都说明为什么影响本次 PR。
3. 删除没有证据的建议。
4. 按“阻塞合并 / 建议修复 / 可选建议”分类。
5. 如果没有阻塞问题，请明确说明。

如果要让 CC 修 PR 问题

不要让它一次修所有建议，先修阻塞项。

请只处理审查中的阻塞合并问题。

限制：
1. 不要处理可选建议。
2. 不要重构无关代码。
3. 每个修复都说明对应哪条审查问题。
4. 修复后重新 /verify。
5. 最后输出还剩哪些建议未处理。

修完 PR 问题后复审

请复审刚才修复后的 PR。

要求：
1. 原阻塞问题是否已解决。
2. 修复是否引入新风险。
3. 是否需要重新跑测试或 /verify。
4. 是否还有阻塞合并的问题。
5. 不要重新扩大到可选建议。

合并前最终确认

请做 PR 合并前确认。

请输出：
1. PR 目标是否完成。
2. 阻塞问题是否清零。
3. 已经做过哪些验证。
4. 还有哪些未验证风险。
5. 是否建议合并。
6. 如果不建议合并，必须先处理什么。

适合发给 Reviewer 的总结

最后可以让 CC 帮忙整理一段给 Reviewer 看的摘要：

请把本次 PR 审查结果整理成 Reviewer 摘要。

要求：
1. 先写是否建议合并。
2. 只保留最重要的风险。
3. 标出需要 Reviewer 人工确认的文件或逻辑。
4. 不要写冗长过程。
5. 不要把可选建议放在摘要最前面。

这个摘要适合放进 PR 评论，帮助团队快速抓重点。

PR 审查收尾

请输出 PR 审查最终结论。

格式：
1. 是否建议合并：是 / 否 / 需要补充验证。
2. 阻塞项：
3. 建议修复项：
4. 可选建议：
5. 已验证内容：
6. 未验证风险：

验收结果

下一篇：发布前检查