第 24 章：场景五：Code Review

经过前几个场景的实战，你应该已经能熟练地用 Claude Code 理解项目、搭建功能、进行重构和调试了。这一章，我们进入一个不同的角色——Reviewer。Code Review 是软件工程中保障代码质量的核心环节，但它也往往是最消耗时间精力的环节之一。Claude Code 在这个场景下能发挥什么作用？

本章通过两个真实场景来回答这个问题：场景 A——你写完了支付模块，提交前想让 Claude 帮你自查一遍；场景 B——同事提交了一个涉及 8 个文件的 PR，你需要高效地完成 Review。

本章目标：掌握使用 Claude Code 进行代码审查的完整工作流，包括提交前自审和 PR Review 两种场景，学会生成结构化的 Review 报告，理解 AI Code Review 的优势与局限。

24.1 场景描述

以下是本章要覆盖的两个典型 Code Review 场景：

场景 A：提交前自审

你花了两天时间完成了一个支付模块的开发，涉及订单创建、支付回调处理、退款逻辑等 5 个文件。代码已经能跑通了，但你总觉得哪里不踏实——是不是有边界条件没覆盖？有没有安全漏洞？性能有没有问题？在 git commit 之前，你决定让 Claude Code 帮你做一次全面审查。

场景 B：Review 别人的 PR

同事小李提交了一个 PR，标题是"优化用户查询接口并增加缓存层"。这个 PR 涉及 8 个文件的改动：新增了一个 Redis 缓存服务、修改了查询接口、调整了数据库访问层、更新了相关测试。你是 Reviewer，需要在半小时内完成 Review 并给出反馈。

两个场景的核心区别在于：场景 A 中你是代码的作者，需要 Claude 帮你发现自己可能忽略的问题；场景 B 中你是第三方的审查者，需要 Claude 帮你理解他人的代码并发现问题。

flowchart TB subgraph A["场景 A：提交前自审"] A1["完成功能开发"] --> A2["git diff 查看变更"] A2 --> A3["Claude 审查代码质量"] A3 --> A4["发现并修复问题"] A4 --> A5["再次审查确认"] A5 --> A6["提交代码"] end subgraph B["场景 B：PR Review"] B1["收到 PR 审查请求"] --> B2["Claude 读取 PR diff"] B2 --> B3["逐项检查评估"] B3 --> B4["生成 Review 报告"] B4 --> B5["逐条评审，决定采纳"] B5 --> B6["提交 Review 意见"] end style A fill:#e3f2fd style B fill:#e8f5e9

24.2 场景 A：提交前自审

24.2.1 启动审查

场景 A 的起点很简单：你在支付模块的开发分支上完成了所有改动，现在想在做 commit 之前让 Claude 帮你检查一遍。最简单的启动方式就是一句直白的话：

帮我审查一下这次的改动

Claude Code 收到这个请求后，会自动运行 git diff 来获取当前所有未提交的变更：

开发者：帮我审查一下这次的改动

Claude：好的，让我先查看当前的所有改动。

[运行 git diff]

我看到了以下改动（共涉及 5 个文件）：

1. src/services/payment.service.ts（新增 120 行）
   - createOrder()：创建支付订单
   - handleCallback()：处理支付回调
   - processRefund()：处理退款

2. src/controllers/order.controller.ts（修改 45 行）
   - 新增 POST /api/orders 路由
   - 新增 POST /api/orders/callback 路由

3. src/utils/validator.ts（新增 30 行）
   - 支付参数验证逻辑

4. src/models/order.model.ts（修改 15 行）
   - 新增 refund_status 字段

5. src/config/payment.config.ts（新增 10 行）
   - 支付渠道配置

现在开始逐文件审查...

24.2.2 检查维度

Claude Code 在审查代码时，会从以下几个维度系统性地检查你的代码：

维度	关注点	典型问题示例
代码质量	逻辑正确性、错误处理、边界条件	条件判断反了、未处理的 Promise、死代码
安全问题	敏感信息暴露、注入风险、权限控制	SQL 注入、密码明文日志、缺少鉴权中间件
性能问题	不必要的计算、数据库查询、内存使用	N+1 查询、循环中的重复操作、内存泄漏
一致性	命名规范、代码风格、错误处理模式	同一概念用了不同名称、错误格式不统一
可维护性	函数复杂度、代码重复、模块耦合	单函数超过 100 行、重复逻辑未抽取

24.2.3 实际审查过程

以下是一个典型的审查交互过程。Claude 会在同一个回复中给出完整的问题列表：

=== Code Review Report ===

🔴 Critical（必须修复）
────────────────────────────
1. [安全] 缺少输入验证
   文件：src/controllers/order.controller.ts:32
   
   app.post('/api/orders', async (req, res) => {
     const order = await paymentService.createOrder(req.body);
     // ↑ req.body 直接传入服务层，没有任何验证
   });

   问题：用户传入的金额、商品 ID、回调 URL 等参数没有经过任何验证。
   恶意用户可能传入负数金额、注入脚本或发起 SSRF 攻击。

   建议：在 controller 层或使用中间件对输入做严格校验：

const schema = z.object({ amount: z.number().positive().max(999999), productId: z.string().uuid(), callbackUrl: z.string().url().startsWith('https://'), }); const validated = schema.parse(req.body);

2. [安全] 密码/密钥日志泄露
文件：src/config/payment.config.ts:8

console.log('Payment config loaded:', config);
// ↑ 这会在生产日志中输出包含 API 密钥的完整配置对象

问题：API 密钥和签名密钥会被写入日志，一旦日志系统被入侵，
整个支付通道就暴露了。

建议：仅记录配置加载成功，不输出内容；或使用序列化函数过滤敏感字段。

🟡 Major（建议修复）
────────────────────────────
3. [性能] 退款回调中的 N+1 查询
文件：src/services/payment.service.ts:85-95

for (const item of order.items) {
  const product = await db.products.findById(item.productId);
  // 循环内逐条查询 —— N+1 问题
  await inventoryService.restore(product.sku, item.quantity);
}

建议：批量查询所有商品信息：

const productIds = order.items.map(i => i.productId); const products = await db.products.findByIds(productIds); const productMap = new Map(products.map(p => [p.id, p]));

4. [代码质量] 缺少支付超时处理
文件：src/services/payment.service.ts:30-50

createOrder() 创建订单后直接返回，没有设置超时取消机制。
如果用户 30 分钟内不支付，订单会永远处于 pending 状态。

建议：添加定时任务或使用消息队列的延迟消息，
超时后自动取消订单并释放库存。

🔵 Minor（可选优化）
────────────────────────────
5. [一致性] 错误码格式不统一
有的地方返回 { error: '...' }，有的返回 { code: '...', message: '...' }。
建议统一错误响应格式。

6. [代码风格] createOrder() 函数 80+ 行
建议拆分为 validateParams()、calculateAmount()、saveOrder() 等子函数。

📊 总结
────────
- 5 个文件，共 220 行新增代码
- 🔴 2 个必须修复的问题
- 🟡 2 个建议修复的问题
- 🔵 2 个可选优化建议

24.2.4 逐条修复与再次审查

收到 Review 报告后，你是最终的决策者——不是每条建议都必须采纳。对于 Critical 级别的问题，基本上应该全部修复；对于 Major 和 Minor，结合上下文判断。

修复过程可以直接交给 Claude：

开发者：请帮我修复上面列出的问题 1、2、3。

Claude：[逐一修复，生成 diff]
问题 1：在 controller 层添加了 zod 验证 schema
问题 2：移除了配置对象的完整日志输出
问题 3：将循环查询改为批量查询

开发者：帮我再次审查一下，确认问题已经修复。

Claude：[重新运行 git diff，对比上次审查结果]
✅ 问题 1（输入验证）：已添加 zod schema，覆盖了 amount、productId、callbackUrl
✅ 问题 2（日志泄露）：已移除敏感信息输出
✅ 问题 3（N+1 查询）：已改为批量查询

修复完成后，你就可以放心地提交代码了。这个工作流的核心价值在于：Claude 帮你覆盖了那些容易被作者忽略的细节——安全漏洞、边界条件、代码一致性。

24.3 场景 B：Review 别人的 PR

24.3.1 启动 PR Review

场景 B 的启动同样简单。当同事的 PR 提交后，你可以用以下几种方式让 Claude 来 Review：

方式一：直接指定 PR 编号（如果使用 GitHub CLI 集成）

Review 一下这个 PR #342

方式二：提供 PR 的 diff 内容 将 PR 的 diff 内容粘贴给 Claude，然后说：

帮我 Review 一下上面这个 PR 的改动

方式三：使用专用的 Review 命令（如果项目配置了）

/review

Claude Code 接到请求后会首先读取 PR 的完整 diff，然后生成结构化的 Review 报告。对于涉及 8 个文件的大型 PR，Claude 会先给出全局概览，再进行逐文件分析。

24.3.2 审查检查清单

在 Review PR 时，Claude 会围绕以下检查清单展开：

flowchart TB START["开始 PR Review"] --> C1["✅ 功能正确性"] START --> C2["✅ 边界条件与错误处理"] START --> C3["✅ 编码规范与一致性"] START --> C4["✅ 安全隐患"] START --> C5["✅ 测试覆盖"] START --> C6["✅ 性能影响"] C1 --> D1["逻辑是否与 PR 描述一致？<br>是否有遗漏的场景？"] C2 --> D2["空值、超时、并发、<br>大数据量情况是否处理？"] C3 --> D3["命名、注释、<br>错误处理模式是否一致？"] C4 --> D4["是否有注入风险？<br>是否有敏感信息暴露？"] C5 --> D5["新增和修改的代码<br>是否有对应的测试？"] C6 --> D6["对现有功能的影响？<br>查询效率如何？"] D1 & D2 & D3 & D4 & D5 & D6 --> REPORT["生成 Review 报告<br>（分级标注严重程度）"] style START fill:#e3f2fd style REPORT fill:#fff9c4

24.3.3 逐项审查流程

以"优化用户查询接口并增加缓存层"这个 PR 为例，Claude 的审查过程如下：

第一步：全局概览

Claude：我已经读取了 PR #342 的完整 diff。这个 PR 涉及以下改动：

文件变更概览：
📁 src/services/user-query.service.ts    (+45, -12)  修改查询逻辑
📁 src/services/cache.service.ts          (+80, 新文件) 新增 Redis 缓存服务
📁 src/models/user.model.ts               (+15, -3)   新增缓存过期字段
📁 src/config/redis.config.ts             (+25, 新文件) Redis 连接配置
📁 src/controllers/user.controller.ts     (+30, -8)   查询接口适配缓存
📁 src/tests/user-query.test.ts           (+60, 新文件) 查询单元测试
📁 src/tests/cache.test.ts                (+50, 新文件) 缓存单元测试
📁 src/middleware/auth.ts                 (+5, -1)    权限中间件微调

总共：+310 行，-24 行

开始详细审查...

第二步：逐文件审查

Claude 会按文件逐一分析，核心关注点包括功能正确性、边界条件、编码规范、安全隐患和性能影响：

=== PR Review Report — PR #342 ===

🔴 Critical（必须修复后才能合并）
────────────────────────────────────

1. [安全] 缓存键设计存在碰撞风险
   文件：src/services/cache.service.ts:25

   async getUserById(id: string) {
     const cacheKey = `user:${id}`;
     // ↑ 如果系统中有不同类型的 ID（用户ID、组织ID），
     // 这种键名可能与其他缓存模块冲突

   建议：增加命名空间前缀，如 `user:profile:${id}` 或
   使用哈希函数确保唯一性。

2. [功能] 缓存与数据库不一致风险
   文件：src/services/user-query.service.ts:68

   async updateUser(id: string, data: UpdateUserDto) {
     await db.users.update(id, data);     // 先更新数据库
     await cache.set(`user:${id}`, data); // 再更新缓存
     // ↑ 如果缓存更新失败，数据库已写入但缓存还是旧数据
   }

   建议：采用 Cache-Aside 模式（更新数据库后删除缓存）
   或使用事务/回滚机制保证一致性。

🟡 Major（强烈建议修复）
────────────────────────────────────

3. [性能] 缓存穿透未处理
   文件：src/services/cache.service.ts:35

   当查询不存在的用户 ID 时，每次都会穿透缓存直接查询数据库。
   如果恶意用户用大量不存在的 ID 发起请求，会导致缓存形同虚设。

   建议：对查询结果为 null 的情况也设置短时缓存（如缓存空值 60 秒）：

if (user === null) { await cache.set(user:${id}, NULL_PLACEHOLDER, { ttl: 60 }); }

4. [测试] 缺少缓存失效的测试用例
文件：src/tests/cache.test.ts

测试覆盖了缓存写入和读取的基本场景，但没有覆盖：
- 缓存过期后的行为
- 缓存服务不可用时的降级行为
- 并发场景下的缓存一致性

建议：补充以上场景的测试用例。

🔵 Minor（可选优化）
────────────────────────────────────

5. [代码风格] 魔法数字问题
文件：src/services/cache.service.ts:10
const DEFAULT_TTL = 3600; // 建议提取到配置中，并为不同缓存类型设置不同的 TTL

6. [可维护性] 缺少错误日志上下文
文件：src/services/cache.service.ts:55
console.error('Cache error:', err); 
// 错误日志缺少请求上下文（哪个 key、什么操作），排查问题时信息不足

💚 Suggestion（值得参考）
────────────────────────────────────

7. [架构] 考虑使用缓存装饰器简化代码
当前每个方法都手动写缓存逻辑，可以考虑用装饰器模式：

@cached({ ttl: 300, keyPrefix: 'user:profile' }) async getUserById(id: string)

减少样板代码，降低遗漏缓存操作的风险。

📊 审查总结
────────────
- PR 总体方向正确，缓存层的引入合理
- 🔴 2 个必须修复的问题
- 🟡 2 个强烈建议修复的问题
- 🔵 2 个可选优化建议
- 💚 1 个架构层面的参考建议

建议：在 Critical 问题修复后可以合并，Major 问题可跟进 Issue 在下个 PR 解决。

24.3.4 逐条评审与决策

收到 Claude 的 Review 报告后，作为 Reviewer，你需要逐条判断：

1. Critical 问题：要求开发者必须修复，并在修复后重新 Request Review。
2. Major 问题：强烈建议修复，但可以根据项目优先级决定是本次修复还是建 Issue 跟进。
3. Minor 和 Suggestion：作为参考，可以接受开发者的自主判断。

一个实用技巧：把 Claude 的 Review 报告中你最认可的几条单独拿出来，加上你自己的判断，形成最终的 Review 意见。AI 做初筛，你做终判。

开发者（你的 Review 意见）：

总体来说 PR 设计合理，有几个问题需要处理：

1. （来自 Claude 的建议）缓存键需要加命名空间前缀，避免跨模块碰撞
2. （来自 Claude 的建议）updateUser 需要改为 Cache-Aside 模式
3. （我的补充）auth 中间件的修改范围比预期大，请说明为什么需要微调
4. （我的判断）缓存穿透问题可以先建 Issue 跟进，本次先解决 Critical 问题

请修复第 1、2 和第 3 点后重新 Request Review。

24.4 代码质量问题识别

通过上面两个场景，你已经看到了 Claude Code 在 Code Review 中能发现的问题类型。本节系统性地梳理 Claude 能够识别的常见代码质量问题，以及它的发现机制。

24.4.1 问题类型总览

问题类型	识别方式	Claude 的优势	典型示例
逻辑错误	静态分析 + 模式识别	能发现反直觉的条件判断、循环边界错误	if (status === 'paid' && status !== 'pending') — 永不成立的判断
安全问题	安全知识库 + 模式匹配	常见安全漏洞的记忆和模式识别	SQL 注入、XSS、硬编码密钥、敏感信息日志泄露
性能问题	代码模式分析	识别经典反模式（N+1、无界循环）	循环中逐条查询、缺少索引感知的查询
代码风格	规则匹配	一致性检查比人工更彻底	命名不统一、魔法数字、函数过长
测试缺失	覆盖率分析	系统性地列出所有分支覆盖	错误路径、边界值、异常场景缺少测试
可维护性	复杂度评估	大代码量面前保持一致的判断标准	重复代码、过高耦合、职责不清

24.4.2 逻辑错误的发现

Claude 在发现逻辑错误方面有一个独特的优势：它不会像人类一样被"预期行为"欺骗。

举个例子：当代码作者写了一个条件判断 if (order.status === 'cancelled' && order.status === 'refunded') 时，人类 Reviewer 可能会因为经验而"视而不见"——大脑自动补全了"正确"的逻辑。而 Claude 会指出：这两个条件不可能同时为真，这里应该用 ||。

常见的逻辑错误类型：

// ❌ 条件判断反了
if (user.isLoggedIn) {
  redirectToLogin();  // 已登录的反而跳转到登录页
}

// ❌ 循环边界错误
for (let i = 0; i <= items.length; i++) {
  process(items[i]);  // items[items.length] 是 undefined
}

// ❌ 异步处理不当
const result = fetchUserData();  // 忘记 await，result 是 Promise
console.log(result.name);        // undefined，不会报错但行为错误

Claude 能识别这些模式，因为它对编程语言的语义有深度理解，而不是简单的正则匹配。

24.4.3 安全问题的发现

这是一个 Claude 特别擅长的领域。模型在训练过程中接触了大量安全漏洞案例和修复方案，能有效识别常见的代码安全问题。

SQL 注入检测：

// ❌ 字符串拼接导致 SQL 注入风险
const query = `SELECT * FROM users WHERE name = '${userName}'`;

// ✅ 参数化查询
const query = 'SELECT * FROM users WHERE name = ?';
db.execute(query, [userName]);

Claude 不仅能指出 SQL 注入的存在，还能判断上下文——如果 userName 是来自请求体而非内部调用，它会标注为 Critical 级别。

敏感信息泄露检测：

// ❌ 日志中包含敏感数据
logger.info('User login', { email, password });  // password 在日志中明文记录

// ❌ 错误信息暴露内部结构
res.status(500).json({ error: err.stack });  // 暴露了服务器路径和依赖信息

// ❌ 硬编码密钥
const API_KEY = 'sk-proj-abc123def456';  // 密钥硬编码在源码中

24.4.4 性能问题的发现

Claude 对性能模式有良好的识别能力，特别是以下几类经典问题：

N+1 查询问题：

// ❌ N+1 查询：先查所有订单（1次），再循环查每个订单的明细（N次）
const orders = await db.orders.findAll();
for (const order of orders) {
  order.items = await db.items.findByOrderId(order.id);
}

// ✅ 批量查询
const orders = await db.orders.findAll();
const orderIds = orders.map(o => o.id);
const allItems = await db.items.findByOrderIds(orderIds);
const itemsMap = groupBy(allItems, 'orderId');

不必要的重复计算：

// ❌ 每次渲染都重新计算结果
function UserList({ users }) {
  const activeUsers = users.filter(u => u.active);  // 每次渲染都执行
  return <List data={activeUsers} />;
}

// ✅ 使用 useMemo 缓存计算结果
function UserList({ users }) {
  const activeUsers = useMemo(
    () => users.filter(u => u.active),
    [users]
  );
  return <List data={activeUsers} />;
}

内存泄漏：

// ❌ 事件监听器未清理
useEffect(() => {
  window.addEventListener('scroll', handleScroll);
  // 组件卸载时未移除监听器
}, []);

// ✅ 返回清理函数
useEffect(() => {
  window.addEventListener('scroll', handleScroll);
  return () => window.removeEventListener('scroll', handleScroll);
}, []);

Claude 的优势在于：它能跨文件追踪变量和函数的引用关系，发现那些人工 Review 容易遗漏的全局副作用。

24.5 安全隐患扫描

24.5.1 使用 security-review Skill

除了常规 Code Review，Claude Code 生态中还有一个专门用于安全审查的 Skill：security-review。当你需要对当前分支的变更进行深入的安全审查时，可以使用它：

/security-review

与普通 Code Review 不同，安全审查聚焦于可被利用的安全漏洞，检查维度更窄但更深入：

检查维度	具体内容
输入验证	所有外部输入（请求参数、URL 路径、Header、Cookie）是否经过严格验证？
认证与授权	敏感接口是否有正确的鉴权中间件？是否存在垂直/水平越权路径？
数据保护	敏感数据（密码、Token、个人隐私）是否在传输和存储中妥善保护？
注入防御	是否存在 SQL 注入、命令注入、LDAP 注入、XSS 等漏洞？
依赖安全	新增的第三方依赖是否有已知漏洞？
配置安全	密钥、证书是否通过环境变量注入？是否有调试接口暴露到生产环境？
错误处理	错误信息是否泄露了系统内部结构？

24.5.2 安全审查 vs 常规 Code Review

很多开发者会混淆安全审查和 Code Review，它们其实是互补关系：

维度	常规 Code Review	安全审查 (security-review)
关注点	代码质量、逻辑、性能、风格、安全	仅关注安全漏洞
深度	广度优先，覆盖多个维度	深度优先，一条漏洞追到底
输出	分级报告（Critical/Major/Minor）	安全漏洞清单 + 修复建议
触发时机	每次提交 / 每个 PR	涉及支付/认证/敏感数据的改动
典型场景	日常开发流程	上线前审查 / 安全审计

24.5.3 Claude 安全审查 vs 专业安全工具

这是一个经常被问到的问题：Claude Code 的安全审查能替代专业安全工具吗？

答案是明确的：不能替代，是互补关系。

flowchart LR subgraph AI["AI 安全审查（Claude Code）"] A1["语义理解<br>理解业务逻辑中的安全风险"] A2["上下文感知<br>跨文件追踪数据流"] A3["业务逻辑漏洞<br>如权限绕过、逻辑缺陷"] end subgraph TOOL["专业安全工具（SAST/DAST）"] T1["规则库驱动<br>基于 CVE/CWE 知识库"] T2["确定性<br>零误报（规则明确）"] T3["已知漏洞<br>如依赖漏洞、配置缺陷"] end subgraph BOTH["两者结合"] R["AI 发现逻辑层面的安全问题<br>+ 工具扫描已知漏洞<br>= 最完整的安全防护"] end A1 & A2 & A3 --> BOTH T1 & T2 & T3 --> BOTH style AI fill:#e3f2fd style TOOL fill:#e8f5e9 style BOTH fill:#fff9c4 style R fill:#ffcc80

Claude Code 擅长的安全审查场景：

• 业务逻辑层面的安全漏洞（如权限绕过、数据越权）
• 上下文相关的安全风险（如特定业务流程中的认证缺陷）
• 动态分析需求（理解代码意图，而非仅匹配模式）

专业工具擅长的安全场景：

• 依赖库的已知漏洞（CVE 扫描）
• 配置文件的硬性安全规则（如 CSP 头配置）
• 大规模代码库的自动化扫描（速度快、覆盖全）

最佳实践：在 CI/CD 流水线中同时运行 SAST 工具（如 SonarQube、Snyk）和 Claude Code 的安全审查，前者抓已知漏洞，后者抓业务逻辑安全问题。

24.6 生成 Review 报告

24.6.1 Review 报告的推荐格式

经过多个项目的实践，我们总结了一套高效的 Review 报告格式。你可以要求 Claude 按这个格式生成：

请按以下格式生成 Review 报告：

1. 总体评估（一段话概述 PR 的整体情况）
2. 分级问题清单：
   - 🔴 Critical：必须修复（功能错误、安全漏洞、数据丢失风险）
   - 🟡 Major：强烈建议修复（性能问题、可维护性问题、测试缺失）
   - 🔵 Minor：可选优化（代码风格、命名建议）
   - 💚 Suggestion：值得参考的架构/设计方案建议
3. 逐条详述：每条问题包含
   - 严重级别
   - 影响文件及行号
   - 问题描述
   - 代码片段（当前代码和修复建议）
4. 审查总结和合并建议

Claude 生成的 Review 报告可以作为你 Review 意见的初稿。你最终发布的 Review 意见应该是：关键问题的简洁陈述 + 你的专业判断 + 具体的修复方向。

24.6.2 如何与人工 Review 配合

AI Review 和人工 Review 不是二选一的关系，而是分层协作的关系。以下是我们推荐的配合策略：

flowchart TB PR["PR 提交"] --> AI["AI 初审<br>（自动化）"] AI --> REPORT["结构化 Review 报告<br>（Critical / Major / Minor）"] REPORT --> HUMAN["人工复审<br>（约 10-15 分钟）"] HUMAN --> DECISION{"决策"} DECISION -->|"同意（约 80%）"| D1["采纳 AI 建议<br>直接提出"] DECISION -->|"存疑（约 15%）"| D2["标记为讨论点<br>发起对话"] DECISION -->|"不同意（约 5%）"| D3["拒绝，附理由<br>（说明为什么误报）"] D1 & D2 & D3 --> FINAL["提交最终 Review 意见"] style AI fill:#e3f2fd style HUMAN fill:#c8e6c9 style FINAL fill:#fff9c4

AI 初审处理的是机械性、模式化的检查——这些问题 AI 比人做得快、做得全。当 AI 帮你把所有这些问题筛出来后，人工复审只需要关注：

1. AI 标注的 Critical/Major 问题是否属实（判断误报）
2. 这个问题在业务上是否真的重要（判断优先级）
3. 有没有 AI 没发现的设计层面的问题（补全缺失的视角）
4. 代码的整体架构是否合理（AI 当前判断力不足的领域）

这种分层协作模式能让 Review 的效率提升 3-5 倍，同时保证审查质量不会下降。

24.6.3 不能完全依赖 AI Review 的场景

尽管 Claude Code 在 Code Review 方面表现出色，但以下场景不能完全依赖 AI 的审查结果：

场景	原因	正确的做法
核心支付/资金相关代码	逻辑正确性要求极高，误判后果严重	AI 初审 + 资深工程师逐行复审
涉及复杂业务规则	AI 不理解领域特定的业务逻辑	业务专家主导审查，AI 辅助发现技术问题
架构层面的决策	AI 关注局部代码而非全局架构	架构师评审，AI 做实现层面的检查
合规性审查	涉及法律和行业标准（如 GDPR、HIPAA）	专业的合规审查流程，AI 作为辅助
安全关键系统	安全漏洞的后果不可接受（如医疗、航空）	专业安全审计 + 形式化验证

一个实用的判断标准：如果这个代码的错误可能导致用户资金损失、数据泄露或人身安全风险，就不要只依赖 AI Review。

24.7 复盘与技巧总结

24.7.1 AI Code Review 的优势与局限

优势

速度快：一个涉及 8 个文件、300+ 行改动的 PR，Claude 可以在 30 秒内给出初步审查报告。对于常见的代码质量问题、安全漏洞、性能模式，Claude 的反应速度远超人类 Reviewer。

不遗漏常见问题：人类 Review 容易因为疲劳、对代码的"熟悉感"而忽略一些常见但隐蔽的问题。Claude 不会疲劳——第 1 个文件和第 50 个文件的审查标准完全一致。

无情绪偏见：人类 Reviewer 可能受到代码作者印象、代码风格偏好、甚至当天心情的影响。Claude 给出的每一条意见都基于代码本身。

知识面广：Claude 能识别多种编程语言和框架中的反模式、安全漏洞。一个精通后端的人类 Reviewer 可能对前端 React 的性能问题不够敏感，但 Claude 对两种语言的分析能力是均衡的。

局限

不理解业务逻辑：这是 AI Review 最大的局限。Claude 能告诉你 if (balance < amount) 这个条件在语法上没问题，但它不知道"余额不足时是否应该允许透支"——这是业务规则，只有熟悉领域的开发者才能判断。

可能误报（False Positive）：Claude 偶尔会把一些刻意为之的设计标注为"问题"。比如某些性能优化可能故意牺牲了可读性，Claude 可能会建议"优化代码可读性"而忽略了性能意图。

缺少项目上下文：Claude 不知道为什么当初要这样设计、有什么历史包袱。它基于当前代码的"最佳实践"来审查，但这些"最佳实践"未必适合你的项目现状。

对新颖模式可能误判：如果一个 PR 引入了一种创新的设计模式或非常规的解决方案，Claude 可能因为"没见过"而给出不准确的判断。

24.7.2 最佳实践

基于以上分析，以下是使用 Claude Code 进行 Code Review 的最佳实践总结：

实践	说明
AI 初审 + 人工复审	AI 做第一轮筛查，人做第二轮的判断和决策。这应该成为默认工作流。
审查范围先清晰	告诉 Claude 你关注什么：是安全？是性能？还是整体质量？审查目标不同，关注点就不同。
要求分级输出	要求 Claude 按 Critical / Major / Minor 分级，这样你可以优先处理真正重要的问题。
结合 git diff 上下文	不要只给 Claude 看代码片段，让它自己 git diff，看到完整的改动上下文。
不要盲从	每一条 AI 的建议都经过你的判断再决定是否采纳。AI 是顾问，不是决策者。
积累误报经验	当 Claude 给出误报时，告诉它为什么误报。虽然当前不能持久化修改 Claude 的判断逻辑，但这有助于在该轮对话中提升后续审查的准确性。
关键代码双重审查	涉及核心支付、认证、数据安全的代码，AI Review + 资深工程师的人工 Review 缺一不可。

24.7.3 关键命令速查

命令 / 用法	用途	使用场景
帮我审查一下这次的改动	当前分支未提交变更的审查	提交前自审
Review 一下这个 PR	审查指定的 PR	团队代码审查
/review	调用 review 命令审查当前变更	快速启动审查
/security-review	调用安全审查 Skill	涉及敏感数据的改动
审查这个文件的代码质量	单文件审查	审查特定模块
帮我检查这个问题是否还有遗漏	修复后复查	确认问题已修复
请按分级格式生成 Review 报告	生成结构化报告	正式 Review 流程

本章小结

本章通过两个完整场景——提交前自审和 PR Review——展示了 Claude Code 在代码审查中的实际应用。核心要点：

1. 双场景覆盖：Claude Code 既能在提交前帮你自查代码，也能作为 Reviewer 的工具帮助你审查他人的 PR。

2. 多维度检查：从代码质量、安全问题、性能、一致性和可维护性五个维度系统性地审查代码，几乎不会遗漏常见的模式性问题。

3. 分级输出：Critical / Major / Minor / Suggestion 的四级分类让你能区分"必须修"和"可以考虑修"，高效分配精力。

4. AI 与人的正确关系：AI 做初审——快速、全面、不知疲倦；人做终判——理解业务、判断优先级、把握架构。这是一个高效的分层协作模式。

5. 懂得局限才更可靠：Claude Code 不理解你的业务逻辑，可能在特定场景下误报，也无法替代资深工程师对架构设计的判断。知道它不擅长什么，反而更能用好它擅长的那部分。

Code Review 是保障代码质量的重要防线，而 Claude Code 让这条防线的效率提升了数倍。不要用它替代人的判断——用它替代那些机械的、模式化的、容易被疲劳忽略的检查工作。

下一章，我们将进入下一个实战场景：测试编写——看看 Claude Code 如何帮你为现有代码补充测试、提升项目质量。