CCClaude Code中文喂饭教程

Code Review 中如何识别 AI 生成代码风险

团队 Code Review 教程：识别 AI 生成代码中的越界修改、幻觉 API、漏测、过度抽象、安全隐患和业务语义错误。

AI 生成代码最大的风险，不是语法错。

真正危险的是：代码看起来合理，但业务语义错了；测试没覆盖，但总结写得很自信；改动范围变大了，但开发者没意识到。

所以 Code Review 要有一套专门识别 AI 风险的检查方法。

AI 生成代码常见风险

风险表现
越界修改顺手改了无关文件、格式化大面积代码。
幻觉 API调用了项目里不存在或语义不对的方法。
业务误解代码能跑，但不符合真实业务规则。
漏掉异常分支只处理 happy path。
过度抽象为小需求造大工具、大封装。
安全遗漏忽略权限、密钥、输入校验。
测试假覆盖测试写了，但没覆盖真实风险。

Review 第一问：它改多了吗

先看文件范围：

请审查本次 diff 是否有越界修改。

重点：
1. 是否改了任务无关文件。
2. 是否大面积格式化。
3. 是否顺手重构。
4. 是否新增依赖。
5. 是否修改配置、权限、脚本。

AI 很容易“顺手优化”。Review 要先把范围收回来。

先按文件类型判断风险

Review 不要平均用力。不同文件风险完全不同：

文件类型Review 重点
样式、文案是否影响响应式、视觉层级和可访问性
业务组件状态、边界、异常分支、用户操作链路
接口和服务层参数校验、错误处理、兼容性、幂等
权限和认证是否绕过校验、是否扩大访问范围
数据库和迁移是否可回滚、是否影响已有数据
构建和部署脚本是否影响 CI、生产环境和回滚
依赖文件是否引入未知包、锁文件是否异常变大

可以让 CC 先给 Review 优先级：

请根据本次 diff 的文件类型，给出 Code Review 优先级。

要求：
1. 哪些文件必须重点人工审查。
2. 哪些文件可以快速检查。
3. 哪些改动可能影响生产或安全。
4. 不要只按文件数量判断风险。

Review 第二问：它理解业务了吗

语法没错不代表业务正确。

检查：

可以让 CC 反向审查：

请以业务审查视角检查本次改动。

要求：
1. 不要只看代码是否能运行。
2. 判断业务规则是否被误解。
3. 列出需要产品或后端确认的问题。
4. 标出没有证据支持的假设。

Review 第三问：它验证了吗

AI 总结里的“已完成”不能当证据。

必须看：

如果没有验证，就让它补：

请为本次改动补一份验证清单。

要求：
1. 正常路径。
2. 空数据。
3. 错误状态。
4. 权限不足。
5. 边界输入。
6. 回归风险。

验证清单要对应改动，不要生成一份万能清单。比如只改了登录错误提示，就重点看登录失败、成功、空输入、接口异常；不要突然要求跑全站性能测试。

Review 第四问：有没有安全问题

重点看：

企业项目中，安全问题优先级高于功能完成。

Review 第五问：有没有过度设计

AI 生成代码经常会把小任务做成大抽象。

常见表现：

可以这样审：

请检查本次改动是否存在过度抽象。

重点看：
1. 新增的抽象是否真的被多处使用。
2. 是否为小需求引入过重结构。
3. 是否增加后续维护成本。
4. 是否可以用更直接的小改动完成。

Review 时要记住：能交付、可读、可验收，比“显得高级”更重要。

AI 代码 Review 清单

请按 AI 生成代码风险清单审查本次 diff。

检查项：
1. 是否越界修改。
2. 是否存在幻觉 API 或不存在的配置。
3. 是否误解业务语义。
4. 是否漏掉异常分支。
5. 是否过度抽象或引入不必要复杂度。
6. 是否存在权限、安全、敏感信息问题。
7. 测试和验收是否覆盖真实风险。

输出：
- 必须修复
- 建议修复
- 需要人工确认
- 可以接受

PR 描述应该怎么写

AI 参与的 PR，不要只写“完成需求”。建议写：

## 改动目标
【本次要解决的问题】

## Claude Code 参与范围
- 只读分析：
- 生成计划：
- 修改代码：
- 辅助审查：

## 人工确认
- 我确认了哪些业务规则：
- 我检查了哪些 diff：
- 我运行了哪些验证：

## 风险
- 可能影响：
- 需要 Reviewer 重点看：

这样 Reviewer 知道该看哪里，也知道哪些结论不是 AI 单方面给出的。

Review 结论怎么分级

不要所有问题都写成“建议优化”。可以分四级：

级别含义
必须修复会导致功能错误、安全风险、数据风险、构建失败
需要确认业务规则、产品预期、接口兼容还不确定
建议改进可读性、维护性、体验可以更好
可以接受有小瑕疵但不影响本次交付

这种分级能避免 Review 变成无重点的挑刺。

团队 Review 规范建议

团队可以规定：

验收结果

学完后，应该能做到：

上一篇：企业任务边界下一篇：团队 CLAUDE.md 治理