Claude Code 进入团队后，代码 Review 流程会面临一个新问题：当 60% 的代码是 AI 生成的，review 的重心应该在哪里？
不变的原则：
代码 review 的目的从来不是"找 bug"，而是： 1. 知识共享（让团队都了解这段代码） 2. 系统一致性（代码符合整体架构） 3. 错误预防（人眼看到 AI 看不到的业务问题）
这些目标在 AI 时代变得更重要，不是更次要。
Review 重心的转移：
之前的重心：
- 语法和格式（AI 已经很好了，不值得花时间）
- 标准库用法（AI 比你更熟悉，不值得花时间）
- 测试覆盖（AI 能生成，关键是验证测的对不对）
新的重心：
- 业务逻辑正确性（AI 不了解你的产品规则）
- 系统边界的决策（这个功能是否该在这层实现？）
- 性能和扩展性（AI 倾向于正确但不是最优）
- 安全敏感的代码（不能信任，必须人工验证）
给 reviewer 的建议：
# 在 review 前先让 Claude 做一遍
claude "这是 PR diff（$(git diff main)）。
作为一个审慎的 reviewer：
1. 找出可能有业务逻辑错误的地方
2. 找出并发安全问题
3. 找出缺少测试的关键分支
4. 找出与我们代码规范不一致的地方
把真正需要人工决策的问题排在前面。"
然后 review 时重点关注 Claude 标记的问题，而不是从头读一遍。
给 PR 作者的建议：
在 PR description 里说明：
1. 这段代码是 AI 辅助生成的（如果是）
2. 你验证了哪些关键行为
3. 哪些部分你自己不确定，想要特别关注
不要让 reviewer 猜"这段是 AI 写的吗"。
不要用 AI 做的 review：
- 最终的"可以 merge"决策
- 关于架构是否正确的判断
- 评估测试是否真的覆盖了重要场景
这些需要人的判断，因为需要了解团队背景、产品方向、历史债务。
防止"盖章文化"：
"Claude review 过了，没问题" — 这是 review 最危险的滑坡。
Claude 做的是快速的技术检查，不是业务正确性的保障。每个 reviewer 仍然需要负责任地判断每行代码。
用 Claude 减少低价值的 review 工作，把节省的时间用在高价值的判断上，而不是减少总 review 时间。