AI 写完代码之后：vibe 项目的代码审查实战流程

用 AI 写代码的人都经历过这个时刻：Agent 唰唰唰吐出 500 行代码，测试一跑，全绿。你长舒一口气，点了合并。三天后生产环境炸了——某个边界条件没处理，某个密钥被写进了日志。

问题不在 AI 写得慢，而在你审得太草率。vibe coding 把写代码的成本打到了零，但代码审查的成本没有跟着降，反而变高了：代码量是以前的 5 倍，里面还掺着你一行都没读过的逻辑。这篇文章给的是一套实战流程，核心就一句话：分层审查——Diff 看逻辑、运行看行为、AI 做初筛、人做最终裁决。每一层都有具体的动作清单，照着做就行。

为什么必须审：Agent 的三类经典翻车

先统一认知：审查不是不信任 AI，而是 AI 的犯错模式和人类不一样。人类会犯粗心错，AI 会犯「自信的错」——代码看起来头头是道，实则暗藏玄机。最常见的有三类。

第一类：逻辑似对实错。这是最难抓的。代码能跑，测试能过，但某个边界条件是错的。比如分页逻辑里 offset = page * size 应该是 (page - 1) * size；时区没统一，UTC 和本地时间混用；并发场景下两个请求同时扣库存，没有加锁。AI 特别擅长写出「看起来对」的代码——变量名规范、注释详尽、结构清晰，你的眼睛会不自觉地滑过去。审查时对这类代码要反直觉：越漂亮的代码，越要逐行看分支条件。

第二类：隐藏的安全洞。AI 为了让你「跑起来」，会走捷径：把 API key 写进代码、SQL 用字符串拼接、用户输入直接拼进 shell 命令、认证中间件「稍后再加」然后忘了。更隐蔽的是依赖投毒——AI 可能引入一个你没听过的 npm 包，里面藏着恶意代码。这类问题靠肉眼 Diff 很难全覆盖，所以后面我们会用自动化扫描先过一遍。

第三类：过度工程。你让 AI「加个用户反馈表单」，它给你搭了一套插件化、可扩展、支持 10 种后端的表单引擎，附带 3 层抽象。代码没 bug，但维护成本翻了三倍。审查时要敢删：问自己「这个抽象未来三个月真的会被用到吗」，答不上来就让它简化。

记住这三类，后面的清单都是围绕它们设计的。

先让代码变得可审查：小步提交、一 PR 一件事

审查的第一步不是看代码，而是让代码「值得看」。Agent 默认的工作方式是审查的噩梦：一次吐 2000 行，混着功能、重构、修 bug 三件事，commit message 写着「update」。这种 Diff 神仙也审不动，所以要在 Agent 动手之前立规矩。

三条铁律，直接写进你的 prompt 或 AGENTS.md：

• 小步提交。每完成一个独立功能点就提交一次，一个 commit 只做一件事。一个 PR 的 Diff 理想情况下不超过 400 行——超过这个规模，人的审查质量会断崖式下跌。
• 一 PR 一件事。功能、重构、修 bug 分开提。混在一起的 PR 直接打回，让 Agent 拆开重提，不要心软。
• 附带变更说明。每个 PR 必须说清楚：改了什么、为什么改、怎么验证的。让 Agent 自己写这段说明——写不清楚的，说明它自己也没想清楚。

可以给 Agent 的指令模板长这样：「完成功能后，按功能点拆分成多个小 commit，每个 commit 只做一件事；然后为每个功能点单独开 PR，PR 描述里写清变更内容、原因和验证方法；单个 PR 的 Diff 不要超过 400 行，超了就拆。」把这段话固定下来，你后续的审查工作量至少减半。

还有一个习惯：让 Agent 在 PR 里标注「我不确定的地方」。AI 其实知道自己哪里在猜——比如某个 API 的行为是凭记忆写的、某个边界条件没把握。你明确要求它标出来，审查时就可以直奔这些点，效率最高。

Diff 级审查清单：先扫全量，再死磕高危区

Diff 审查分两遍。第一遍通读，抓逻辑问题；第二遍只看高危区，抓安全问题。不要混在一起看，人的注意力一次只能干一件事。

第一遍的通用清单，逐条过：

• 边界条件：空数组、null、0、负数、超长字符串、第一页和最后一页——AI 最爱在这里翻车。
• 错误处理：每个外部调用（API、数据库、文件）都有 catch/finally 吗？错误信息会不会把敏感信息打进日志？有没有吞掉异常的空 catch？
• 并发：共享状态有没有竞态？两个请求同时写同一行数据会怎样？需要锁、事务或幂等键吗？
• 资源释放：文件句柄、数据库连接、定时器、事件监听，有没有泄漏？尤其看 AI 写的长生命周期对象。
• 命名与注释：注释说的是「为什么」而不是「是什么」吗？注释和代码对得上吗？AI 的注释经常描述的是它「以为」的逻辑，而不是实际逻辑——注释和代码不一致时，信代码，改注释。

第二遍只看五个高危区，AI 在这里的犯错率最高，值得逐行死磕：

• 认证与授权：每个路由都有鉴权吗？有没有「先放行、TODO 后面加」的？权限校验是在服务端做的吗（前端校验等于没有）？
• 支付：金额用最小单位（分）计算吗？有没有幂等处理防止重复扣款？价格是后端说了算，还是前端传啥是啥？
• SQL：全部参数化了吗？搜一搜字符串拼接 SQL 的痕迹，一个都不能留。
• 加密：有没有自己发明加密算法？密钥和 IV 是怎么管理的？密码是哈希存储（bcrypt/argon2）而不是可逆加密吗？
• 密钥与配置：代码里有没有硬编码的 key、token、密码？配置文件有没有被提交进仓库？

实操技巧：审查时开着搜索，全仓库搜 TODO、FIXME、sk-、api_key、password 这些关键词。AI 留下的 TODO 经常藏着没做完的事，搜一遍只要 30 秒。

运行级验证：先让机器替你看一遍

人眼看 Diff 之前，先让机器跑完它能跑的。顺序很重要：自动化门禁全绿了，人再看；没绿，人不用看。

1. 类型检查 + lint 全绿。TypeScript 项目跑 tsc --noEmit，Python 跑 mypy 或至少 ruff。AI 写的代码经常有「any 大法」——类型检查能逼出很多隐藏的 null 问题。
2. 测试全绿。让 Agent 为新功能写测试，并且测试真的跑过。重点看：测试断言的是行为而不是实现细节；边界条件的测试有没有。
3. 依赖安全扫描。npm audit 或 pip audit 跑一遍，高危漏洞直接升级或换包。AI 引入的陌生依赖，逐个看一眼它的周下载量和最近更新时间——三天前刚发布、下载量两位数的包，直接换掉。
4. 密钥扫描。用 gitleaks 或类似工具扫一遍，顺手搜一下 -----BEGIN（私钥）、sk-、xoxb- 这类前缀。密钥一旦进了 git 历史，rotate（轮换）比删除更重要。
5. 跑起来点一遍。最后一步永远是人肉：把功能跑起来，按正常用户和「捣乱用户」两种姿势各点一遍。AI 的 happy path 通常没问题，魔鬼在异常路径里。

把这五步做成 CI，每次 PR 自动跑。vibe 项目最容易犯的错误就是「CI 以后再说」——以拖待变的结果就是永远没有 CI。花一个下午搭好，之后每个 PR 省半小时。

借 AI 审 AI：第二个模型做初筛

代码量大的时候，人逐行看 Diff 既不现实也没必要。这时可以用第二个 AI 来做初筛——注意，是「第二个」，最好是不同厂商、不同架构的模型。让写代码的模型自己审自己的代码，等于让考生自己批卷子，盲区是重合的。

给审查 Agent 的 prompt 要具体，不能只说「review 一下」。一个可用的模板：

你是代码审查员。审查下面这个 PR 的 Diff，输出三类问题：1）逻辑 bug：边界条件、并发、错误处理方面的具体问题，指出文件和行号；2）安全问题：认证、SQL 注入、密钥硬编码、敏感信息泄露；3）过度设计：可以删掉的抽象和依赖。每类问题按严重程度排序，只说你有把握的问题，不要猜测。不确定的标注「需人工确认」。

流程是：审查 Agent 先输出报告，你只看它标红（高严重）的地方，加上你自己 Diff 第二遍的高危区。AI 的报告里 80% 是正确的，15% 是误报，5% 是它没看出来的——你的工作就是处理那 20%。统计下来，一个 400 行的 PR，人工需要细看的部分通常不到 50 行。

但有一条红线：AI 永远不做最终合并决定。审查 Agent 可以标问题、可以建议改法，但点 merge 按钮的手必须是人的。这不是情怀，是责任归属——出了事，你没法跟用户说「是 AI 让我合并的」。把这条写进团队规范，也写进你自己的习惯。

合并门禁：PR 模板、main 保护、回滚预案

审查流程要靠机制兜底，不能靠自觉。三道门禁，缺一不可。

第一道：PR 模板。在仓库里放一个 .github/pull_request_template.md，强制每个 PR 回答四个问题：改了什么、为什么改、怎么验证的、有没有不确定的地方。Agent 建 PR 时会自动套用这个模板，空着的地方一眼就能看见。

第二道：main 分支保护。打开分支保护规则：CI 全绿才能合、至少一次人工 approve 才能合、不能直接 push 到 main。这三条在 GitHub/GitLab 里都是点几下的事，但能拦住 90% 的「手滑合并」。vibe 项目里 Agent 有 push 权限是常态，分支保护就是最后一道物理隔离。

第三道：回滚预案。合并之前先想好：如果这版有问题，怎么在 5 分钟内回滚？git revert 是最基本的；数据库 migration 必须可逆（每个 up 都有 down）；大功能用 feature flag 包起来，出问题先关开关再修代码。让 Agent 在 PR 描述里写一句回滚方案——写不出来的 PR，说明变更太大，先拆小。

把它变成习惯：复盘、记录、反哺

流程的最后一环是复利。每周花 20 分钟做三件事，三个月后你的 Agent 会少犯一半错误。

第一，review 旧代码。挑一个两周前合并的 PR，重新看一遍 Diff，问自己：当时漏掉了什么？很多问题在当时看不出来，回头看一眼就有数。把漏掉的问题记下来，这是你审查清单的升级来源。

第二，记录 Agent 的犯错模式。AI 犯错是有模式的，而且很稳定：有的 Agent 永远忘记处理时区，有的永远吞掉异常，有的一写 SQL 就字符串拼接。建一个文档（就叫 AGENTS.md 或 review-notes.md），每发现一个重复出现的错误模式就记一条，附上例子。

第三，反哺 prompt 规范。记录不是目的，目的是让错误不再发生。把高频错误模式翻译成 prompt 规则，写进 Agent 的系统指令：「所有时间统一用 UTC 存储、展示时转本地」「禁止字符串拼接 SQL，一律参数化」「catch 块不允许为空」。下次 Agent 写代码时，这些坑它会自己绕开——你亲手调教的审查清单，变成了它的写作规范。

这套流程跑顺之后，你会得到一个正循环：审得越细，记录的模式越多；模式反哺成规范，Agent 写出的代码越干净；代码越干净，审查越快。vibe coding 的终极形态不是「AI 写、人不看」，而是「AI 写、人定标准、AI 按标准写」。审查流程，就是你定标准的方式。