用 Claude Code 两个月后，大多数人会开始意识到它的边界。识别这些边界不是悲观，而是为了在对的地方发力。
Claude 代码的可靠性分布：
高可靠性（可以直接用）：
- 标准库的用法
- 常见设计模式的实现
- 已有代码的扩展
- 测试用例和 fixture
- 文档和注释
中等可靠性（需要 review）：
- 领域特定逻辑（Claude 不了解你的业务规则）
- 性能敏感代码（需要基准测试验证）
- 并发代码（race condition 需要专业眼光）
- 数据库 query（执行计划需要验证）
低可靠性（需要谨慎）：
- 密码学实现（永远不要自己实现加密）
- 金融计算（精度、取整规则）
- 与特定外部系统的集成（API 可能和训练数据不一致）
- 新版本 API（知识截止日期问题）
必须自己把关的场景：
1. 业务规则
# Claude 无法知道你的业务规则
claude "计算用户的积分"
# 它会给出一个"合理"的计算，但可能和你的产品规则完全不同
Claude 生成的逻辑通常是"合理的"而不是"正确的"。你的业务规则在代码里，不在 Claude 的训练数据里。
2. 状态机和时序逻辑
并发、竞争条件、时序依赖——这些需要人脑的系统性分析，Claude 容易在局部看起来正确但整体有问题。
3. 外部系统集成
claude "接入 Stripe Webhooks"
# Claude 的知识可能基于旧版 API
# 永远用最新的官方文档，不是 Claude 的记忆
4. 性能优化的最后一步
Claude 可以帮你分析 profile、给出优化方向，但"这个改动是否真的更快"需要你跑基准测试来验证。
建立验证习惯：
# 每次 Claude 生成关键代码后
claude "这段代码有没有：
1. 潜在的 race condition？
2. 可能为 nil 的解引用？
3. 不处理的错误返回？
4. 假设了不应该假设的输入范围？"
让 Claude 自己质疑它自己的代码，往往能发现一批问题。
最重要的原则：
你是最终负责人，Claude 是工具。它能加速你 80% 的工作，但剩下的 20%——关键业务逻辑、安全敏感代码、性能关键路径——需要你的专业判断。
不要因为"Claude 生成的"就跳过 code review。