模型天天换，验收没人干：为什么「会不会验收 AI 写的代码」比「选哪个模型」重要 10 倍
先说结论
这两年我把市面上的 Coding Agent 几乎用了个遍：Claude Code、Codex、Cursor、Gemini CLI、OpenClaw……模型换了一茬又一茬，跑分榜天天刷新。但我越来越确信一件事：真正决定你能不能用好 AI 的，不是你选了哪个模型，而是你有没有一套「验收 AI 写的代码」的本事。 模型负责把代码「生」出来，验收负责把代码「放生」出去。前者 AI 已经做得又快又便宜，后者恰恰成了整个流水线里最卡脖子的环节。本文聊聊这个瓶颈是怎么形成的、AI 代码最常踩的 6 种坑、以及我自己在用的四层验收体系和一张工位清单。
图 1：本文主视觉——AI 像传送带一样 24 小时不间断产出 PR，而人类拿着放大镜一个一个验。自制文章配图。
1. 问题背景：我们都得了「模型选择困难症」
先坦白，我曾经是个重度「模型党」。
每次新模型发布，我比谁都积极：刷榜、看跑分、翻 X 上的测评帖，然后把同样的需求分别丢给三四个 Agent，对比谁的代码更优雅、谁的思路更「像我」。我甚至给不同任务维护了一张「模型-任务匹配表」：重构用 A，写测试用 B，查 bug 用 C，改文案用 D。
听起来很专业对吧？直到有天我复盘一个线上事故，发现一个尴尬的事实：那次出问题的代码，恰恰是我用「当时跑分最高的模型」生成的。 而它出问题的原因，不是模型不够聪明，是我当时看它「写得挺像那么回事」，扫了一眼就合并了。
那一刻我突然意识到：我一直在优化「生产端」，却对「验收端」零投入。这就好比一个餐厅老板，天天研究换更好的炒菜机器人，却从来不管端出去的菜有没有人尝过咸淡。菜炒得再快，试菜员不尝，早晚出事。
2. 问题表现：验收，成了新的拥堵点
当你开始用 Coding Agent，一个微妙的角色转变发生了：你从「写代码的人」变成了「审代码的人」。
以前一天写 200 行，现在 Agent 一小时给你吐 2000 行。生成的环节被压缩到了几分钟，但「看懂这 2000 行到底干了什么、敢不敢合进去」的环节，一点没压缩，反而因为量大而被无限拉长。整个流水线的瓶颈，从「生产」悄悄迁移到了「验收」。
图 2：瓶颈迁移——生成环节被 AI 压缩到几分钟，验收环节却越堆越高。自制示意图。
这不是我一个人的体感。2026 年 6 月，The New Stack 发了一篇标题就很扎心的文章：《How long before we stop reading the code?》（我们离「不再读代码」还有多远）。文章的核心观点是：AI 正在「杀死」传统代码审查，人类的检查点必须从「读代码」上移到「审意图、审规格、审验收标准」。
图 3：The New Stack 文章真实截图。注意副标题——「停止读代码，把人类检查点上移到验收标准」。连业界媒体都在讨论这个瓶颈。
翻译成人话就是：代码太多，人眼不够用了，你不可能再逐行看完 AI 写的所有东西，你必须换一种验收方式。 但问题是——大多数人的验收方式，还停留在「扫一眼，觉得没毛病就合了」的原始阶段。
3. 问题分析：感觉变快了，其实变慢了
你可能会反驳：「我觉得用 AI 明显变快了啊，怎么说瓶颈在验收？」
问得好。这恰恰是整件事里最反直觉、也最值得警惕的地方。我们来看一组硬核数据。
2025 年 7 月，研究机构 METR 做了一项罕见的随机对照试验（RCT，就是医学上验证药效那种最严格的实验方法）：他们找来 16 个经验丰富的开源开发者，让他们在自己非常熟悉的成熟项目（平均 5 年以上维护经验、上百万行代码）上完成 246 个真实任务，随机分成「允许用 AI」和「不许用 AI」两组。
图 4：METR 论文的 arXiv 页面真实截图。51 页、8 张表、22 张图的正经研究，不是自媒体口嗨。
结果出来后，所有人都惊了：
- 实验开始前，开发者们预测 AI 能让自己快 24%；
- 实验结束后，他们依然感觉自己快了 20%；
- 但实际测量的结果是——他们慢了 19%。
图 5：感觉 vs 实测，相差整整 39 个百分点。自制图表，数据来自 METR 论文。
感知和实测差了 39 个百分点，方向完全相反。为什么会这样？METR 的研究员深入分析后发现，开发者用 AI 时，大量时间被三件事吃掉了：反复调试提示词、检查 AI 生成的代码、修复 AI 引入的隐蔽 bug。而且开发者对 AI 建议的采纳率只有 39%——也就是说，超过六成的 AI 产出，被人类看完后果断丢弃了。
你看，省下的时间并没有消失，它只是从「写」转移到了「验」。 而且因为「验」这个动作太琐碎、太分散，你的大脑根本记不住它花了多少时间，于是产生了「我变快了」的错觉。
打个小学生都能懂的比方：这就好比你点外卖，送餐只要 5 分钟（AI 生成），但送到后你要花 40 分钟检查有没有送错菜、有没有少给筷子、汤有没有洒（人工验收），最后还得热一热、补点盐才能吃（修 bug）。你的「做饭」时间是省了，但「检查外卖」的时间把省下的全吃回去了，还倒贴。你以为你点了顿省事的饭，其实你当了 40 分钟免费的质检员。
4. 问题根因：代码正在「劣币驱逐良币」
如果只是「没省时间」，那还好。更要命的是，AI 正在悄悄改变整个代码库的质量结构。
GitClear 是一家专门分析 git 仓库代码质量的公司，他们分析了 2020 到 2024 年间 2.11 亿行代码变更（涵盖 Google、Microsoft、Meta 等企业的仓库），在 2025 年的代码质量报告里发现了几个扎心的趋势：
图 6：移动/重构代码从 25% 跌破 10%，复制粘贴代码一路反超。自制图表，数据来自 GitClear 报告。
- 「移动/重构」代码占比，从 2021 年的约 25%，跌到了 2024 年的不足 10%。 「移动代码」是重构的典型信号——把重复逻辑抽取出来复用。它的暴跌，说明大家越来越不爱「收拾屋子」了。
- 2024 年成为历史上第一次「复制粘贴代码」超过「移动代码」的年份。 重复代码块的数量在 2024 年暴涨了 8 倍。
翻译一下：AI 特别擅长「新写一段」，但特别不擅长「把现有的代码改得更好」。 它宁愿给你复制粘贴出第五份相似的逻辑，也不愿意去重构掉前四份。因为「复制」对它来说成本为零，而「重构」需要理解整个项目的上下文——这恰恰是它最薄弱的地方。
这就是为什么「验收」比「选模型」重要。打个装修比方：AI 是个力气超大、干活超快、但完全不懂户型的装修队。 你让它「加个插座」，它能三分钟给你把整面墙拆了重砌，顺便多砌出三面墙（复制粘贴）。墙砌得又快又直，但你的房子被越改越乱，住着越来越别扭。这时候，决定你家住得舒不舒服的，不是装修队力气多大（模型多强），而是你这个监工，能不能在它砌第三面多余的墙时及时喊停。
连 Simon Willison（Django 联合创造者、AI 编程领域最有影响力的独立观察者之一）都专门造了个词来区分两种用法：他把「不读代码、能跑就行」叫 vibe coding，把「专业工程师对 AI 产出保持高度负责」叫 vibe engineering（后来业界更常叫 agentic engineering）。
图 7：Simon Willison 那篇著名的《Vibe engineering》真实截图。他明确说：用 Agent 写出「我有信心长期维护的生产级代码」，是一种完全不同的工作方式。
这两种方式的分界线，不在于你用了多贵的模型，而在于你对产出物负不负责、验不验收。
5. 如何解决问题：我的四层验收体系
讲了半天问题，该给解法了。这是我踩了无数坑之后，沉淀下来的一套四层验收体系。它的核心思想来自机场安检——层层设卡，每一层拦截一类问题，越往下越严格。
图 8：四层验收体系——像机场安检一样，机器能查的先查，人眼只留给最关键的地方。自制图。
第一层：意图验收 —— 它交的是不是我点的那道菜？
拿到 AI 的产出，第一件事不是读代码，是读「它以为自己干了什么」。看它的总结、看 commit message、看 diff 的文件列表，问一个问题：这堆改动，和我提的需求，是同一回事吗？
AI 最常见的毛病是「过度发挥」——你让它改个分页，它顺手把你的列表组件重写了，还多送了三个你没要的「优化」。意图验收就是要在这个阶段把「夹带私货」揪出来。 这就像收快递先对一下订单号，号不对，里面包得再精美也不用拆。
第二层：自动化验收 —— 机器能查的，绝不人肉查
测试、Lint、类型检查、安全扫描、构建——全部自动化，全部设为合并的硬门槛。这一层的原则是：凡是机器能判断的，一律不消耗人类宝贵的注意力。
但这里有个巨大的坑，后面会专门讲：AI 写的测试可能是假的。所以这一层除了「跑测试」，还要多一步「验测试」。
第三层：关键路径人工验收 —— 把好钢用在刀刃上
人的注意力是最贵的资源，只花在「错不起」的地方。什么是错不起的？涉及钱、涉及数据、涉及权限、涉及安全的代码。这部分代码，哪怕 AI 写得再漂亮，也要逐行亲手过一遍。
这就像机场安检，所有行李都过 X 光机（自动化），但贵重物品和可疑包裹一定要开包手检（人工）。什么都手检会累死，什么都不手检会出事。
第四层：可回滚验收 —— 给自己留条后路
这是最后一道保险，也是最容易被忽略的。无论前面验得多仔细，都要假设「可能漏了」。 所以每次合并都保持小步、独立、可干净回滚。这样哪怕验收漏了个 bug 混进线上，也能 5 分钟内一键撤回，把损失控制在最小。
验收的终极目标不是「永不犯错」，而是「即使犯错，也能快速发现、快速撤回、不伤筋骨」。
6. AI 代码的 6 种坑：验收时的捉虫清单
光有体系还不够，你还得知道「虫」长什么样。我把 AI 写的代码最常出的问题，总结成了 6 种坑。每次验收，就照着这张清单捉虫。
图 9：AI 代码的 6 种常见坑，以及对应的验收口诀。自制图。
- 看似能跑的暗坑：本地能跑，但空数组、并发、时区、整数溢出这些边界条件一碰就碎。就像伞，晴天能撑，下大雨就漏。
- 答非所问跑偏题：需求要 A，它做了 A 还顺手改了 BCD，改动范围严重超标。点碗面，厨师把厨房重装了。
- 安全后门随手开：硬编码密钥、把鉴权「先注释掉方便调试」、关掉参数校验。装修工图省事没给你装门锁。
- 复制粘贴堆重复：同一逻辑抄 5 份，改一处漏四处。这就是 GitClear 报告里那个 8 倍的来源。
- 风格漂移不认亲：命名、分层、错误处理和项目完全是两套，像外来代码空降，格格不入。
- 测试造假走过场：这个最阴险——断言恒为真（
assertTrue(true)）、注释掉失败的用例、为了「全绿」而绿。体温计量不出烧，它直接把体温计敲碎。
7. 一张贴在工位上的验收清单
最后，把整套体系浓缩成一张清单。每次合并 AI 代码前，从上往下打勾，全部 ✅ 才准 merge。
图 10：工位验收清单，建议截图保存。自制图。
特别说两条容易被忽略的：
「测试是真的」这条，怎么验？ 有个狠招：故意把被测代码改错一处，看测试红不红。如果代码都改错了测试还绿着，说明这测试是摆设，是假的。这招叫「变异测试」的朴素版，对付 AI 的假测试特别灵。
「我讲得清」为什么是底线？ 因为签 merge 的人是你，不是 AI。线上出了问题，老板找的是你，不是模型。如果你讲不清这段代码为什么这么写，那本质上你就不是在「验收」，而是在「抽签」。讲不清，就不 merge——你签的名，你负的责。
8. Q&A：几个常被问到的问题
Q1：照你这么说，AI 编程是不是根本没用？
恰恰相反。AI 极其有用，但前提是「生产快、验收严」。METR 那个研究的对象是「在超熟悉的老项目上做精细维护」的资深开发者，这恰恰是 AI 最讨不到便宜、验收成本最高的场景。在写原型、写一次性脚本、探索新领域这些「验收标准宽松」的场景，AI 的提速是实打实的。关键是分场景——别把「能快速生成」和「能放心合并」混为一谈。
Q2：那我是不是不用追新模型了？
不是不追，是降权。模型的代际差异，远小于「有没有验收体系」的差异。一个中等模型 + 严格验收，胜过一个顶级模型 + 闭眼合并。模型从 80 分提到 90 分，你感受到的提升可能不到 10%；但验收从「扫一眼」到「四层体系」，你的线上事故率能降一个数量级。投入产出比完全不在一个层面。
Q3：小团队没人手搞四层验收怎么办？
四层不代表四个人。一个人也能做：意图验收就是「读一遍 AI 的总结再开 diff」，自动化验收就是「把测试和 Lint 接进 CI 并设为必填」，关键路径人工验收就是「涉及钱和权限的地方逼自己逐行读」，可回滚验收就是「别一把梭，拆小提交」。成本很低，收益很大。
Q4：未来模型会不会强到不需要验收？
也许有一天会。但至少在今天，以及可见的几年内，不会。模型越强，我们越敢让它干更重要的事，验收的赌注反而越大。就像汽车安全带——车越好、开得越快，安全带越不能省。验收能力不是 AI 时代的过渡技能，而是这个时代的核心技能。
写在最后
回到标题的问题：为什么「如何验收 AI 写的代码」比「选择哪个模型」更重要？
因为模型是变量，验收是常量。模型会一代代换，今天的第一名明天就会被超越；但「你敢不敢为你合并的每一行代码负责」这件事，永远不会过时。
AI 把「写代码」变成了廉价品，也就同时把「判断力」推上了天价。当所有人都能三分钟生成一千行代码时，真正能拉开差距的，是那个知道这一千行里哪三行会要命的人。
别再只盯着跑分榜了。去练你的验收能力吧——那才是你在 AI 编程时代，真正的、别人拿不走的护城河。