验收检查：AI 写的代码怎么检查再上线
先给答案：AI 代码审查不是逐行啃代码，而是走一遍四步清单——看 diff、跑检查、过安全红线、讲得清。 走完这四步，「看着没问题」才变成「检查过了」。
为什么必须有这一步？回看 Karpathy 那条广为流传的推文里描述的做法：「I "Accept All" always, I don't read the diffs anymore」——我总是全盘接受，不再看 diff 了。他还承认：「The code grows beyond my usual comprehension」——代码已经超出了他通常的理解力。工程师 Simon Willison 给 vibe coding 下的定义也很直接：「building software with an LLM without reviewing the code it writes」——用 LLM 写代码但不审查它写的代码。
所以「审不审查」就是 vibe coding 和正经软件开发的分界线：周末自娱自乐的小玩具，可以不看 diff；要上线的东西，审查是必选项。这一课就是 工作流导读 立的第四条纪律「上线前验收」——跑一遍能过/不过的检查，能讲清代码做了什么。
四款工具（Claude Code、Codex、OpenCode、WorkBuddy）通用，零基础 10 分钟走完。
学完你能做什么
- 用一份四步验收清单检查 AI 交付的代码：看 diff、跑检查要证据、过安全红线、讲得清，把「看着没问题」变成「检查过了」
- 说得出 AI 代码审查重点查什么：量化研究指出的逻辑错误、配置错误、安全漏洞高发区，逐项对号入座
- 用工具自带的审查功能让「没写过这段代码的 AI」帮你把关：Claude Code 的
/code-review和/security-review、Codex 的专门审查、OpenCode 的 review-diff 命令 - 分清什么时候可以走「不看 diff」的原版玩法、什么时候必须验收——给别人用的东西，发布前找有经验的人把把关
你现在的困境
- AI 说「已完成，所有功能正常运行」，你点开一看页面确实能跑——但它顺手改了三个你没让它碰的文件，你根本不知道
- 听说 AI 写的代码安全漏洞比人写的多 2.74 倍，想查但无从下手：代码看不懂，AI 代码审查到底查什么、按什么顺序查？
- 东西马上要给别人用了（朋友、客户、上架商店），心里没底：万一里面藏着洞，第一个发现它的是用户还是攻击者？
什么时候用这一招
当你需要：
- 把「AI 说做完了」升级成「检查过了，可以上线」
- 给别人用的东西，发布前把风险拦在自己手里
- 一份不懂代码也能执行的 AI 代码检查清单
而且不想：
- 逐行啃完 AI 生成的每一行代码（这一课不要求你全读懂）
- 上线后靠用户报错来发现漏洞
- 把周末玩具的「Accept All」玩法直接搬到正经产品上
🎒 开始前的准备
- 读完 报错循环：把错误信息原样喂回去——验收查出来的问题，最后都要接回那一课的修复循环
- 装好并用过至少一款工具：Claude Code、Codex、OpenCode 或 WorkBuddy
- 手头有一个 AI 刚交付的「能跑」的小项目——拿真交付物练手，比看例子记得牢
- 10 分钟和一杯水 ☕
核心思路
验收检查的本质：把「看起来做完了」变成「检查证明做完了」。 Claude Code 官方最佳实践把这话说得很明白：没有可跑的检查时，AI 收工的唯一依据是「看起来做完了」——实际上你成了它的测试套件，每个问题都要等你亲自运行那一刻才暴露。
那为什么不能只靠「跑起来看看」？因为量化研究把 AI 代码的质量问题摆到了台面上：
| 研究 | 发现 | 对验收意味着什么 |
|---|---|---|
| CodeRabbit（2025-12，分析 GitHub 上 470 个开源 PR） | AI 参与的代码比人写的多约 1.7 倍「重大」问题；配置错误多 75%；安全漏洞多 2.74 倍 | 不能只看功能跑没跑通，要按高发区抽查 |
| Veracode（2025-10，三年追踪） | 模型生成可运行代码的能力显著进步，但生成代码的安全性整体没有提升 | 「模型更新了应该更安全」不成立，每批代码都要查 |
| Lovable 事件（2025-05） | 1,645 个由 AI 应用平台 Lovable 创建的 web 应用里，170 个存在「任何人都能访问用户资料」的安全缺陷 | 不验收就上线，洞是成批出现的 |
这些数字的完整来龙去脉，在 Vibe Coding 靠谱吗：风险、争议与真实案例 里详聊。这一课只取一件事：AI 代码质量的问题不是随机的，它有高发区——逻辑错误、配置错误、安全漏洞。验收清单就是照着高发区设计的。
四步清单先睹为快，每一步拦一种坑：
| 步骤 | 动作 | 拦住什么 |
|---|---|---|
| 1. 看 diff | 逐处过目 AI 的改动 | 它改了你没让它改的东西 |
| 2. 跑检查 | 能过/不过的检查 + 命令和输出当证据 | 「看起来做完了」的假完成 |
| 3. 过红线 | 密钥、权限、配置、逻辑逐项对号 | 安全漏洞和配置错误高发区 |
| 4. 讲得清 | 能向别人解释代码做什么，必要时找人把关 | 你自己都没理解的代码上了线 |
一句话记住这一课：diff 要看、检查要跑、红线要过、讲得清才上线。
跟我做
（拿你手头那个 AI 刚交付的项目当素材，四步走完：从看清它改了什么，到拿得出上线底气。查出来的任何问题，都贴回报错循环修。）
第 1 步：看 diff——AI 代码审查从「它改了什么」开始
为什么：AI 做出来的东西和你想的不一样，是官方最佳实践列出的头号常见坑——它没法从你的脑子里读需求，只能猜。而「Accept All 不看 diff」恰恰把发现猜错的机会全放走了。所以 AI 代码审查的第一步不是读代码，是看改动清单：先知道它动了哪些文件，再谈检查。
各款工具看改动的入口：
| 工具 | 怎么看 diff |
|---|---|
| Claude Code | 会话里跑 /diff，查看工作区改动，包括 AI 目前为止的所有编辑 |
| Codex | 改动出现时当场检查命令和 diff（官方定位：Steer the active turn, inspect commands and diffs as they appear） |
| OpenCode | 终端跑 git diff --stat 看改动文件列表，git diff 看具体内容 |
| WorkBuddy | 交付物以「可检查的结果」形式交回，代码开发场景本身包含 review，在任务对话里逐项核对它做了什么 |
项目在 Git 仓库里的话，git status 和 git diff 四款工具通用——这是最底层的保底入口。
看的时候只问三个问题：
- 改的文件是不是都是我让它改的？
- 有没有多出来的文件、多出来的依赖？
- 删掉的行里，有没有看着不像「重构」的？
来路不明的改动，直接问它（本页第一个魔法模板）：
这次交付你改动了哪些文件？逐个说明每处改动是干什么的、
对应我哪条需求。有没有我明确要求之外但你顺手改的地方？💡 让 AI 自己标风险
官方工作流里有一条现成做法：提交前让 AI 标出潜在风险和需要留意的地方（Review Claude's generated PR before submitting and ask Claude to highlight potential risks or considerations）。它的自评不能代替你的检查，但能给你指路——它标的地方，就是你重点看的地方。
你应该看到：一份改动清单 + AI 对每处改动的说明。出现你没让它动的文件，它的解释你要认可；解释不了的改动，要么让它改回去，要么标记为待查。
- 小检查：我看过改动文件列表，没有来路不明的改动；有的话，AI 的解释我认可
第 2 步：跑一遍能过/不过的检查，要证据不要「做完了」
为什么：「页面能打开」不等于「做完了」。报错循环那一课把「能过/不过的检查」用在修 bug 上；验收时它是最后一道闸：交付物必须真的跑过检查，而且你得亲眼看到证据。官方原话：「"All tests pass" 单独一句说明不了什么」——要的是它跑过的命令和完整输出。
检查可以是这些里的任何一个（官方清单，项目里有什么用什么）：
| 检查 | 例子 |
|---|---|
| 测试 | 项目里的测试命令，全部通过 |
| 构建 | 构建/编译命令的退出码为 0 |
| Lint | 代码检查工具无报错 |
| 对比脚本 | 输出和预期文件逐行比对一致 |
| 页面截图 | 浏览器里跑起来的实际样子，和你要的样子对比 |
验收提示词直接抄（本页第二个魔法模板）：
交付验收：请把你跑过的检查命令和完整输出贴给我，
包括：<测试命令>、<构建命令>。
任何一项没通过，说明原因和修复计划，别只说「已完成」。用 Claude Code 的话，多一道杀手锏：它说做完后，跑 /verify——这个官方技能会让它构建并运行你的应用、亲自看运行结果，专抓测试和类型检查抓不住的问题（页面白屏、按钮点不动这类「测试全绿但东西不能用」的坑）。
你应该看到：AI 贴回它跑过的命令和完整输出；你自己挑其中一条重跑，结果一致。对不上，就是没跑或者跑了别的——接回报错循环。
- 小检查：「做完了」三个字后面跟着命令和输出，我自己重跑过至少一条
第 3 步：过一遍安全红线——AI 代码质量的高发区逐项对号
为什么：CodeRabbit 的研究给出了 AI 参与代码的问题分布——逻辑错误（错误依赖、控制流缺陷）比例更高，配置错误多 75%，安全漏洞多 2.74 倍。AI 代码审查不能平均用力，要按高发区逐项排查。四条红线，每条都有明确的查法：
| 红线 | 查什么 | 为什么是高发区 |
|---|---|---|
| 1. 密钥 | API key、密码、token 有没有被硬编码进代码、提交进仓库 | Willison 安全清单第 2 条：代码一旦涉及密钥，就必须看懂，否则容易泄露 |
| 2. 权限 | 「谁能访问什么」的门槛还在不在：登录、授权、数据可见范围 | Lovable 事件：170/1,645 个应用任何人都能翻用户资料——权限洞是成批出现的 |
| 3. 配置 | 配置项的值对不对，生产/测试环境有没有弄混 | CodeRabbit：AI 参与的代码配置错误多 75% |
| 4. 逻辑 | 核心流程的控制流对不对：条件、边界、异常处理 | CodeRabbit：逻辑错误（错误依赖、控制流缺陷）比例更高 |
不懂代码也能查前两条：密钥红线，在项目里全局搜 key、secret、token、password 这类词，命中了让 AI 解释那是什么、会不会跟着代码公开；权限红线，用「别人的账号」或未登录状态访问一遍，看到不该看的就说明有洞。后两条靠工具审查兜底：
| 工具 | 审查命令 |
|---|---|
| Claude Code | /code-review 检查当前 diff 的正确性 bug（别名 /review，加 --fix 可直接应用修复）；/security-review 专查安全漏洞——注入、认证问题、数据暴露 |
| Codex | 专门审查：对未提交改动、某个 commit 或基准分支跑审查，报告按优先级排列的问题，且不动你的工作区 |
| OpenCode | 官方示例命令 review-diff：把 git diff --stat && git diff 的输出自动塞进审查提示词（见下方进阶技巧） |
⚠️ 工具审查报告不是圣旨
官方专门提醒过：被要求找问题的审查者，总能找出点什么。如果审查报告列了十几条，别全部照单全修——修多了的代价是多出一堆用不上的抽象层和永远不会发生的场景测试。按「影响正确性和安全」排优先级：红线相关的必须处理，风格类的放过。
你应该看到：四条红线逐项有答案；工具审查跑完，没有密钥泄露、权限缺失、高危漏洞这类硬伤。查出来的问题原样贴回报错循环修——报错原文、检查命令、要证据，那一课的整套打法照搬。
- 小检查：密钥、权限、配置、逻辑四条红线我都过了一遍，查出的问题已贴回报错循环
第 4 步：讲得清才算过——给别人用的东西找人把关
为什么：Willison 的黄金法则：「My golden rule for production-quality AI-assisted programming is that I won't commit any code to my repository if I couldn't explain exactly what it does to somebody else」——没法向别人准确解释一段代码做什么，就不把它提交进仓库。他还给了分界判据：代码是 LLM 写的，但你审查过、彻底测试过、能向别人解释它怎么工作——那就不是 vibe coding，是正经的软件开发。
操作分两层，按项目去向选：
第一层：讲给自己听（所有项目）。 把 diff 或关键文件喂回给 AI，让它解释给你听（本页第三个魔法模板）：
用人话给我解释这次改动的核心逻辑：这个项目现在从头到尾
做了什么？数据从哪来、到哪去？哪几处改动最关键、为什么？
就当我完全不懂代码。你听不懂的地方，就是风险点——要么追问到懂，要么标记出来重点查。能用自己的话把项目讲清楚，这一步才算过。
第二层：独立把关（要给别人用的项目）。 Willison 安全清单第 6 条原话：「If you're going to vibe code anything that might be used by other people, I recommend checking in with someone more experienced for a vibe check」——要 vibe code 任何可能被别人使用的东西，找更有经验的人看一眼。人找不到，至少让「没参与写这段代码的 AI」当独立审查员：
- Claude Code 的
/code-review就是这个原理——它开一个全新的子代理来审 diff，从没看过你们的对话，不会被写代码时的推理带偏 - 没有这个命令的工具，开第二个会话干同样的事：一个会话写代码，另一个会话对着文件审，把发现贴回第一个会话修
你应该看到：你能用两三句大白话讲清「这个项目做什么、怎么做的」；给别人用的项目，有经验的人或独立审查员看过一轮。
- 小检查：我能向朋友讲清这段代码做什么；给别人用的项目，我安排了人或独立审查把关
检查点 ✅
- 我看过 AI 的改动清单（diff），没有来路不明的改动
- 「做完了」有证据：检查命令 + 完整输出，我自己重跑过至少一条
- 密钥、权限、配置、逻辑四条安全红线逐项过了
- 我能用自己的话讲清代码做什么，讲不清的地方处理了
- 给别人用的东西，我找有经验的人看过，或用独立审查（
/code-review、第二会话）把过关
踩坑提醒
❌ 「页面能打开，验收通过」
页面能打开只证明主路径没断，证明不了别的。官方最佳实践的原话：没有可跑的检查时，AI 收工的依据就是「看起来做完了」——你成了它的测试套件，每个问题都躺到你亲自运行才炸，而攻击者不会只走主路径。正确做法：第 2 步的能过/不过检查跑一遍，要命令和输出当证据；用 Claude Code 再加一道 /verify，让它自己把应用跑起来看结果。
❌ 把「AI 说所有测试通过了」当证据
「"All tests pass" 单独一句说明不了什么」——这句是官方原话。AI 转述的检查结果可能是跑过的、可能是猜的、可能跑的是旧版本代码。正确做法：要它贴出跑过的命令和完整输出，你再挑一条重跑对结果。证据对不上，接回报错循环。
❌ 审查报告列了 15 条，我熬夜全修了
被要求找问题的审查者，总能找出点什么——官方专门警告过这一条。全修的代价是多出一堆用不上的抽象层和永远不会发生的场景测试，代码反而更难讲清。正确做法：按「影响正确性和安全」排优先级——密钥、权限、配置、逻辑相关的必修，风格类的放过；修的时候一次只修硬伤，修完重跑检查。
❌ 周末玩具的玩法，直接搬到给别人用的产品
Karpathy 自己划过界：这套「Accept All 不看 diff」的玩法，用在 throwaway weekend project（周末一次性小项目）上还不错。给别人用的东西照搬这套，等于把 2.74 倍的安全漏洞系数直接带给用户——Lovable 平台上 170 个「任何人都能访问用户资料」的应用就是这么来的。正确做法：按「给谁用」定验收强度：自己玩的，跑通+顺手扫一眼密钥；给别人用的，四步全走，再找有经验的人把关。
进阶技巧（可选）
把验收标准写进项目说明书。 官方最佳实践说：项目里已经有检查的话，CLAUDE.md 里最有用的一行就是跑它的命令。把「交付前必须跑什么检查、证据怎么交」写进 AGENTS.md / CLAUDE.md，每个新会话自动带上验收标准——写法详见 AGENTS.md 与 CLAUDE.md：给 AI 留一份项目说明书。
OpenCode 用户的 review-diff 命令。 官方文档给了一个现成的自定义命令示例：在项目里建 .opencode/commands/review-diff.md，内容两行——Review this diff: 加 !`git diff --stat && git diff`。之后每次 /review-diff，它会自动把改动塞进审查提示词。
让检查自动拦截。 Claude Code 支持 Stop hook：Claude 想收工时先跑你的检查脚本（比如类型检查），没过就把它打回去继续修——验收从「人盯着」变成「机制拦」。进阶玩法，感兴趣看官方 best-practices 文档的 Enforce the check 小节。
走小程序或插件上架路线的读者：平台审核是最后一道外部验收——微信小程序提审前有官方自查清单（名称合规、核心功能、内容安全），见 提交审核与发布：微信审核规则避坑指南；Chrome 商店审核与灰度发布见 商店审核与发布策略。
本课小结
✅ AI 代码审查的完整链条你走通了：看 diff（改动清单逐处过目）→ 跑检查（能过/不过 + 命令输出当证据）→ 过红线（密钥、权限、配置、逻辑四条高发区）→ 讲得清（能解释给别人听，给别人用的再找人把关）。
✅ 你知道了为什么验收不能省：CodeRabbit 的量化研究说 AI 参与的代码安全漏洞比人写的多 2.74 倍、配置错误多 75%；Veracode 三年追踪说模型能力在涨、安全性没涨。问题有高发区，清单就是照着高发区设计的。
✅ 你分清了两种玩法的使用边界：Karpathy 的原版「不看 diff」留给周末玩具；要上线的东西，审查就是 vibe coding 和软件开发的分界线——Willison 说得干脆：审查过、测试过、讲得清，就不是 vibe coding，是软件开发。
关键概念回顾：
| 概念 | 一句话 | 在哪深入 |
|---|---|---|
| 看 diff | 验收第一步：先知道 AI 改了什么 | 本页第 1 步 |
| 要证据 | 命令 + 输出，不是「做完了」三个字 | 本页第 2 步 |
| 安全红线 | 密钥、权限、配置、逻辑——AI 代码的高发区 | 本页第 3 步 |
| 讲得清 | 解释不了就不提交——黄金法则 | 本页第 4 步 |
| 把关 | 给别人用的东西，找有经验的人或独立审查看一眼 | 本页第 4 步 |
下一课预告
验收清单走完，代码可以放心上线了——但等等，这一课的红线只查了「密钥有没有写进代码」，还没管「密钥本身怎么保管」。下一课：成本与安全：密钥、账单和沙箱三道防线。
你会学到：
- API 密钥怎么保管：这一课查泄露，下一课给你完整的看管方案
- 计费上限怎么设：无计费上限的 API 被 vibe coding 出数千美元账单的惨案，怎么防
- 沙箱怎么用：给 AI 划一个活动边界，新手的安全从沙箱开始
- 数据隐私怎么把关：确认你的数据会不会离开你的机器