1. 当AI开始写代码审查这件事到底该怎么摆前阵子跟几个做后端的朋友吃饭聊到一个挺扎心的话题现在用 Claude Code、Codex 这类工具一个中等复杂度的模块描述清楚需求之后几分钟就能吐出一两百行能跑的代码。以前写一天的东西现在可能半小时就搞定了。但问题紧接着就来了——代码是写完了可你敢不敢直接合并到主分支我自己的答案是不敢但也不会像以前那样逐行去抠。这个转变其实挺微妙的。过去我们做代码审查默认前提是“代码是人写的”所以审查的核心目标是找逻辑漏洞、边界条件、命名规范、潜在的并发问题。但现在代码是 AI 生成的它的“犯错模式”跟人完全不一样。人写代码容易犯的错是粗心、遗漏、对业务理解不到位AI 写代码容易犯的错是“看起来特别合理但实际跑不通”、过度设计、以及在一些隐蔽的地方引入微妙的语义偏差。所以这篇文章想聊的不是“要不要审查 AI 写的代码”这种是非题而是怎么审查才划算。我会结合自己在实际项目里用 Claude Code、agent 工具链的经验拆解一套适合 AI 编程时代的代码审查方法论。不管你是刚接触 AI 编程的新手还是已经在团队里推行 AI 辅助开发的老手应该都能从里面找到能直接抄作业的东西。2. AI 生成代码的“犯错地图”先搞清楚敌人在哪2.1 为什么逐行审查在 AI 时代反而低效先说一个反直觉的结论逐行审查 AI 代码性价比极低。原因很简单。AI 生成的代码在“表面质量”上通常非常高——命名规范、缩进整齐、注释该有的都有甚至比你团队里某些人写得还漂亮。你逐行看下去很容易产生一种“这代码没问题”的错觉。但真正的坑往往不在单行代码里而在几个函数之间的协作逻辑、在边界条件的处理、在对业务语义的理解上。我踩过的一个典型坑让 Claude Code 写一个订单金额计算的函数它写得漂漂亮亮单元测试也过了。但上线之后发现当订单包含优惠券和积分抵扣同时存在时计算顺序反了导致最终金额比预期少了几块钱。这个问题逐行看代码根本看不出来因为每一行单独看都是对的错的是业务逻辑的组合方式。所以逐行审查的问题在于你把注意力放在了“这一行写得对不对”但 AI 的代码在单行层面几乎不会出错。真正需要你花时间的地方是跨行、跨函数、跨模块的语义一致性。2.2 AI 代码的四类高频问题根据我自己和身边朋友的实际经验AI 生成的代码问题大致可以归为四类严重程度从高到低排列问题类型典型表现危险程度审查难度业务语义偏差逻辑看起来对但跟实际业务规则不符极高高边界条件遗漏空值、超长输入、并发场景没处理高中过度设计与抽象简单需求被写成三层架构中低依赖与版本问题用了不存在的 API 或过时的写法中低第一类“业务语义偏差”是最要命的也是最需要人来把关的。因为 AI 不知道你的业务规则它只能根据你的描述去推断。你描述得越模糊它推断得越离谱。第二类边界条件问题AI 其实有一定概率能处理好但它不会主动告诉你“我在这里做了边界处理”所以你需要专门去验证。第三类和第四类问题相对好办前者靠代码审查时的“简化直觉”就能发现后者靠编译和测试就能暴露。2.3 审查重心的转移从“看代码”到“看意图”基于上面的分析我的核心观点是AI 编程时代的代码审查重心应该从“审查代码实现”转移到“审查代码意图”。什么意思以前你审查代码是在看“这个人怎么实现的实现得对不对”。现在你审查 AI 代码应该先看“这段代码想干什么它干的事情跟我的需求是不是一回事”。实现层面的细节交给测试、类型系统、静态分析工具去兜底。这个转变带来的直接好处是你的审查时间可以从“逐行看 200 行代码”压缩到“花 5 分钟确认意图 花 10 分钟跑验证”。剩下的时间你可以去做更有价值的事情比如设计更好的 prompt、搭建更完善的自动化验证流程。3. 一套可落地的 AI 代码审查流程3.1 审查前的准备让 AI 自己先交代清楚我现在用 Claude Code 或者类似工具的时候会在 prompt 里加一条硬性要求生成的代码必须附带一段“实现说明”包括它做了什么假设、哪些地方它不确定、哪些边界条件它处理了。这个技巧看起来简单但效果非常好。因为 AI 在生成代码的时候其实“知道”自己做了哪些取舍只是默认不会告诉你。你主动问它就会说。比如它可能会告诉你“我假设输入的手机号一定是 11 位如果不符合会直接抛异常。”——这种信息你逐行看代码可能要花好几分钟才能推断出来但它一句话就说明白了。具体可以在 prompt 里这样写请生成 XXX 功能的代码。要求 1. 代码写完后用一段话说明你的实现思路 2. 列出你在实现过程中做的所有假设 3. 列出你不确定的地方以及你认为需要人工确认的点 4. 列出你处理了哪些边界条件哪些没有处理这四条要求加上去之后AI 输出的代码可审查性会大幅提升。你拿到代码的第一件事不是看代码而是看它自己写的“交代材料”。如果交代材料里有关键假设跟你的业务不符直接打回去重写连代码都不用看。3.2 第一层审查意图对齐检查拿到 AI 的代码和说明之后第一层审查只做一件事确认代码意图跟需求是否一致。这一步不需要你看任何实现细节只需要对照你的需求文档或者口头描述逐条确认需求里说的“计算总价”代码是不是真的在算总价而不是在算单价乘以数量需求里说的“异步处理”代码是不是真的用了异步而不是同步阻塞需求里说的“失败重试三次”代码是不是真的重试了三次而不是两次或者五次这一步听起来很基础但我实测下来大概有 20% 到 30% 的 AI 代码问题在这一步就能被发现。因为 AI 有时候会“自作主张”地理解你的需求比如你说“用户登录后返回 token”它可能给你返回一个 JWT也可能返回一个 session ID还可能返回一个自定义的加密字符串。如果你不确认后面可能整个认证体系都要返工。提示这一步最好用“反向复述”的方式来做。让 AI 用一句话复述它理解的你的需求然后你确认这句话对不对。如果它复述错了说明它理解错了代码大概率也写错了。3.3 第二层审查关键路径验证意图对齐之后进入第二层审查验证关键路径。什么叫关键路径就是这段代码在实际运行中最核心、最不能出错的那条执行路径。比如一个支付接口关键路径就是“用户发起支付 → 校验余额 → 扣款 → 返回结果”。其他分支比如“用户取消支付”“支付超时”可以稍后再看但关键路径必须第一时间验证。验证的方法不是看代码而是跑测试。我通常会做三件事让 AI 自己生成单元测试然后我审查测试用例是否覆盖了关键路径自己手动构造一两个真实场景的输入跑一遍看输出对不对如果有条件用集成测试或者端到端测试跑一遍完整流程这里有个经验AI 生成的单元测试往往只覆盖“正常情况”不覆盖“异常情况”。所以你在审查测试用例的时候要特别关注有没有空值测试、有没有超长输入测试、有没有并发测试。如果没有让 AI 补上。3.4 第三层审查边界与异常扫描关键路径验证通过之后第三层审查聚焦在边界条件和异常处理上。这一步我通常会用一个“边界清单”来对照检查。清单内容根据业务类型不同会有差异但通用的大致包括输入为空、输入为 null、输入为超长字符串数值为 0、为负数、为超大值并发场景下的竞态条件网络超时、第三方服务不可用数据库连接失败、查询结果为空对照这个清单逐条问 AI“如果出现这种情况你的代码会怎么处理”如果 AI 回答“会抛异常”或者“没有处理”你就需要判断这个异常是否可接受。对于核心业务通常不能接受“没有处理”对于边缘功能可能可以接受。这一步不需要你看代码只需要跟 AI 对话。实测下来这种方式比逐行看代码找边界问题要快得多而且不容易遗漏。3.5 第四层审查代码质量与可维护性最后一层审查才是传统意义上的“看代码”。但这时候你已经确认了意图、验证了关键路径、扫描了边界条件剩下的就是一些“锦上添花”的检查命名是否清晰函数是否过长是否有重复代码是否有明显的性能问题是否符合团队的代码规范这一步我通常会借助工具来完成比如 ESLint、Pylint、SonarQube 之类的静态分析工具。这些工具能自动发现大部分代码质量问题不需要人肉去抠。人只需要关注工具报出来的“警告”和“错误”判断哪些需要修哪些可以忽略。4. 工具链与自动化让机器干机器的活4.1 Claude Code 在审查流程中的定位Claude Code 这类工具很多人只把它当成“代码生成器”但其实它在审查环节也能发挥很大作用。我自己的用法是把 Claude Code 当成一个“审查助手”而不是“审查替代品”。具体来说我会在代码生成之后再开一个 Claude Code 的会话把生成的代码贴进去然后问它几个问题请审查以下代码重点关注 1. 是否有业务逻辑上的潜在问题 2. 是否有未处理的边界条件 3. 是否有性能隐患 4. 是否有安全风险Claude Code 会给出一个审查报告列出它认为有问题的地方。这个报告不能全信但可以作为参考。我通常会把它当成一个“检查清单”逐条确认它提到的问题是否真实存在。这里有个技巧让 Claude Code 用“挑刺”的模式来审查而不是“确认”的模式。如果你问它“这段代码有没有问题”它可能会说“看起来没问题”。但如果你问它“这段代码在哪些情况下会出错”它就会认真去找问题。措辞上的差异会导致输出质量的天壤之别。4.2 自动化验证流水线的搭建人工审查再仔细也难免有遗漏。所以我的原则是能自动化的验证绝不靠人眼。一个典型的自动化验证流水线大概长这样阶段工具检查内容触发时机静态检查ESLint / Pylint代码规范、潜在错误每次提交类型检查TypeScript / mypy类型一致性每次提交单元测试Jest / pytest功能正确性每次提交集成测试Postman / pytest模块间协作每次合并安全扫描Snyk / OWASP依赖漏洞、注入风险每日定时这套流水线搭好之后AI 生成的代码在提交时就会自动跑一遍。如果静态检查或者类型检查报错直接打回去让 AI 修。如果单元测试不过也打回去。只有全部通过之后才进入人工审查环节。这样做的好处是人工审查只需要关注“机器判断不了的事情”比如业务语义、架构合理性、长期可维护性。那些机器能判断的事情全部交给机器。4.3 用 agent 做多轮审查的实践最近我在尝试用 agent 的方式来做多轮审查。具体做法是搭建一个简单的 agent 框架让不同的 agent 扮演不同的角色对同一段代码进行多轮审查。比如Agent A 扮演“业务专家”审查代码是否符合业务规则Agent B 扮演“安全专家”审查代码是否有安全漏洞Agent C 扮演“性能专家”审查代码是否有性能问题Agent D 扮演“测试专家”审查测试用例是否充分每个 agent 独立审查最后汇总结果。这种方式的好处是每个 agent 的注意力更集中不容易遗漏。而且不同 agent 之间可以互相“辩论”比如 Agent A 说“这个逻辑没问题”Agent B 说“这里可能有注入风险”然后它们可以进一步讨论。当然这种方式目前还比较实验性成本也比单轮审查高。但对于核心模块的代码审查我觉得是值得的。5. 团队协作中的审查策略调整5.1 审查责任的重新分配在 AI 编程的背景下团队里的代码审查责任需要重新分配。以前通常是“谁写的谁负责另一个人审查”。现在 AI 写的代码责任归属变得模糊了。我的建议是明确一个“AI 代码负责人”的角色由这个人对 AI 生成的代码负最终责任。这个负责人的职责不是逐行审查代码而是确认 AI 理解的意图是否正确确认关键路径是否验证通过确认边界条件是否处理确认自动化验证流水线是否全部通过换句话说这个人是“质量把关人”而不是“代码检查员”。他不需要看懂每一行代码但需要确保整个验证流程是完整的。5.2 审查清单的标准化为了让审查过程可复制、可传承我建议团队制定一份AI 代码审查清单。清单内容可以根据团队的技术栈和业务特点来定制但核心框架可以参考下面这个## AI 代码审查清单 ### 意图对齐 - [ ] AI 复述的需求理解是否与原始需求一致 - [ ] 代码的核心逻辑是否与需求描述一致 - [ ] 是否有 AI 自行添加的、需求中没有的功能 ### 关键路径 - [ ] 关键路径是否有对应的单元测试 - [ ] 关键路径的测试是否通过 - [ ] 关键路径的输入输出是否符合预期 ### 边界条件 - [ ] 空值输入是否处理 - [ ] 超长输入是否处理 - [ ] 并发场景是否考虑 - [ ] 第三方服务失败是否处理 ### 代码质量 - [ ] 静态检查是否通过 - [ ] 类型检查是否通过 - [ ] 是否有明显的性能问题 - [ ] 是否有安全风险这份清单不需要每次审查都逐条过一遍但对于核心模块的代码建议至少过一遍。时间长了之后审查的直觉会越来越准清单可以逐渐简化。5.3 审查效率的度量与优化最后聊一个比较实际的问题怎么衡量审查效率怎么持续优化。我自己的做法是记录两个指标审查发现问题的数量每次审查发现多少个问题其中多少个是业务语义问题多少个是边界问题多少个是代码质量问题审查花费的时间每次审查从开始到结束花了多少时间记录一段时间之后你会发现一些规律。比如你可能会发现业务语义问题占比最高那说明你的 prompt 需要优化要让 AI 更准确地理解需求。或者你可能会发现边界问题反复出现那说明你的审查清单需要加强边界条件的检查。这种数据驱动的优化方式比凭感觉调整要有效得多。6. 我踩过的坑和总结出的几条硬经验6.1 不要相信“看起来没问题”的代码这是我踩过的最大的坑。AI 生成的代码表面质量太高了高到你会不自觉地放松警惕。我有一次审查一个数据同步的模块代码写得非常漂亮注释齐全命名规范我扫了一遍觉得没问题就合并了。结果上线之后发现它在处理增量同步的时候把“更新时间”和“创建时间”搞混了导致部分数据被重复同步。这个问题逐行看代码根本看不出来因为每一行都是对的。错的是字段的语义理解。从那以后我审查 AI 代码的时候会特别关注“字段语义”和“业务规则”的对应关系而不是代码本身的写法。6.2 让 AI 自己解释比你自己猜要快前面提到过让 AI 在生成代码时附带“实现说明”。这个习惯我坚持了大概半年效果非常明显。以前审查代码遇到不确定的地方我要自己推理“它为什么这么写”。现在直接问 AI它一句话就说明白了。而且这个技巧还有一个额外的好处如果 AI 解释不清楚它为什么这么写那大概率它自己也没想清楚。这种情况下代码出问题的概率很高直接打回去重写就行。6.3 自动化验证是底线不是上限很多人觉得“测试通过了就没问题了”这是一个危险的错觉。测试只能验证你想到的情况验证不了你没想到的情况。AI 生成的代码最危险的地方恰恰在于“它可能在你没想到的地方出错”。所以自动化验证是底线——它保证代码在已知情况下能跑通。但人工审查是上限——它保证代码在未知情况下也不会出大问题。两者缺一不可。6.4 审查的粒度要跟代码的重要性匹配不是所有代码都值得花同样的时间审查。我的做法是把代码分成三档核心业务代码完整走四层审查流程必要时用多 agent 审查一般业务代码走意图对齐 关键路径验证两层边界条件抽查工具类、辅助类代码静态检查 单元测试通过即可人工快速扫一眼这样分配时间才能把有限的审查精力用在刀刃上。6.5 保持对 AI 输出的“合理怀疑”最后一条经验也是最重要的一条永远保持对 AI 输出的合理怀疑。AI 编程工具的能力确实很强强到有时候你会觉得“它比我写得还好”。但它的本质是一个“概率模型”它在生成代码的时候是在“猜”你想要什么而不是在“理解”你想要什么。所以它一定会犯错而且犯的错往往很隐蔽。合理的怀疑不是不信任而是在信任的基础上保持验证。你信任它能写出高质量的代码但你也知道它可能会在某个地方理解错你的意图。所以你会去验证会去确认会去跑测试。这种态度才是 AI 编程时代最需要的。说到底AI 替你写代码省下的是“敲键盘”的时间不是“思考”的时间。审查这件事该花的时间还是得花只是花的方式要变。从逐行抠代码变成确认意图、验证关键路径、扫描边界条件、依赖自动化工具。这套方法我用了大半年整体效率比之前纯人工审查提升了至少一倍而且漏掉的问题反而更少了。如果你也在用 AI 编程工具不妨试试这套流程。一开始可能会觉得麻烦但用顺了之后你会发现审查这件事其实可以很轻松。
