代码审查：别让 AI 替你做决定

AI 代码的核心矛盾

Claude Code 写的代码有一个很微妙的特点：它「看起来很对」。语法没问题，结构清晰，注释齐全，甚至变量命名都挺讲究。但「看起来对」和「真的对」之间有一道鸿沟——Claude Code 不知道你的业务规则，不了解用户的实际行为模式，也看不到系统里那些历史遗留的坑。

我有一次让 Claude Code 写一个用户注册接口，代码写得很漂亮。但它默认邮箱是唯一标识，而我们系统其实允许同一个邮箱注册多个账号（历史原因，别问）。这种「看起来合理但实际上不对」的问题，只有了解业务背景的人才能发现。

所以代码审查不是可选项。每一次 AI 产出的代码，你都需要过一遍。好消息是，如果你按照上一课的小步快跑节奏来，每次审查的量不大，两分钟就能搞定。

五类常见问题

用了一段时间之后，我发现 AI 代码的问题基本可以归为五类。了解这些模式之后，审查效率会高很多，因为你知道该重点看什么。

第一类是虚构的 API。Claude Code 有时候会使用不存在的方法，或者用的是某个库旧版本的 API。它对各种库的 API 有一个大致的印象，但不保证百分之百准确。我遇到过它用一个 lodash 方法，参数顺序和实际完全反过来的情况。

第二类是边界遗漏。正常路径通常写得很完美，但空值、并发、超时这些边界情况经常被忽略。这其实和很多初级开发者犯的错一样——happy path 写得很溜，一到异常情况就露馅。

第三类是过度抽象。你要一个简单的工具函数，它给你搞出一个工厂模式加策略模式的组合。AI 似乎天然倾向于「设计完备」的方案，但在很多场景下，简单直接才是正确选择。如果你发现代码里出现了只有一个实现类的接口，或者只被调用一次的抽象层，那大概率是过度设计了。

第四类是安全疏忽。SQL 注入、XSS、敏感信息硬编码——这些 Claude Code 有时候会注意到，有时候不会。特别是当你的 prompt 里没有特别强调安全性的时候，它可能为了代码简洁而省略掉输入校验。

第五类是隐式假设。代码里暗含着「数据一定存在」、「网络一定通畅」、「用户输入一定合法」之类的假设，但没有任何注释或错误处理来应对假设不成立的情况。这类问题最隐蔽，因为代码本身看起来完全没问题，直到某个假设在生产环境被打破。

审查检查清单

知道了常见问题类型之后，审查就可以变得很有针对性。下面这张表是我日常在用的检查清单，不需要每次全部过一遍，但至少前五项应该成为习惯：

检查项	关注什么
导入和依赖	模块/库是否存在？版本匹配？
类型正确性	参数、返回类型与调用方一致？
边界处理	null？空数组？超长字符串？
错误处理	异常被捕获？错误信息有意义？
安全性	输入校验？敏感信息泄露？
风格一致	命名、格式统一？
复杂度	有没有过度设计？

让 AI 帮你做第一轮筛查

一个实用的技巧是让 Claude Code 先做一轮自查。你可以在它写完代码之后说：「审查你刚才写的代码，重点检查边界处理和安全隐患」。它通常能捕捉到一些自己遗漏的问题。

不过，这只是第一层过滤，不能替代你自己的审查。原因很简单：AI 自查的盲区和它写代码时的盲区是一样的。它写代码时忽略的那些隐式假设，自查时大概率也会忽略。真正能发现深层问题的，还是了解业务上下文的你。

我的做法是把 AI 自查当作一个「低成本的预处理步骤」。它能帮你过滤掉一些明显的问题，这样你自己审查的时候就可以把注意力集中在更深层的逻辑和业务相关的问题上。