--- title: "跑一下试试，是 AI 时代最贵的验收方式 | 行开心的颠倒世界" description: "AI 生成代码的速度远超你阅读的速度，\"跑一下试试\"只能测到你想到的场景。真正有效的验收需要两层：先前置写验收标准让 AI 生成测试，再让另一个模型以\"接手者视角\"审查技术债——这十分钟能省掉三个月后那个\"测试全过却线上出 bug\"的噩梦。" canonical: "https://xingkaixin.me/posts/ai-code-review-expensive-testing/" language: "zh-CN" --- # 跑一下试试，是 AI 时代最贵的验收方式 AI 生成代码的速度远超你阅读的速度，"跑一下试试"只能测到你想到的场景。真正有效的验收需要两层：先前置写验收标准让 AI 生成测试，再让另一个模型以"接手者视角"审查技术债——这十分钟能省掉三个月后那个"测试全过却线上出 bug"的噩梦。 2026年4月11日·1,590 字·5 分钟 [AI编程](https://xingkaixin.me/tags/AI%E7%BC%96%E7%A8%8B/)[代码审查](https://xingkaixin.me/tags/%E4%BB%A3%E7%A0%81%E5%AE%A1%E6%9F%A5/)[测试](https://xingkaixin.me/tags/%E6%B5%8B%E8%AF%95/)[工程实践](https://xingkaixin.me/tags/%E5%B7%A5%E7%A8%8B%E5%AE%9E%E8%B7%B5/) ![跑一下试试，是 AI 时代最贵的验收方式](https://xingkaixin.me/cover/ai-code-review-expensive-testing.webp) AI 给我写了一个日期格式化函数。测试全过，我扫了一眼，合并了。 三个月后要改日期格式化逻辑，改完上线，数据错乱。排查半天才发现：项目 utils 里本来就有一个功能几乎一样的函数，只是命名不同。AI 当时没复用，自己写了一个新的。我只改了 utils 里那个，AI 写的那个压根没碰，因为我根本不知道它存在。 从合并那天起 bug 就埋下了。测试全过，“跑了一下”什么都没看出来。 * * * ## 速度放大了验收的缺口 ![速度放大了验收的缺口](https://xingkaixin.me/posts/images/ai-code-review-expensive-testing/ai-code-review-expensive-testing-01.webp) 手写代码的时代，“跑一下试试”勉强说得过去——因为你写了什么你心里清楚，你知道哪些地方可能有问题，你的手动测试多少是有针对性的。 但 AI 写代码不一样。生成速度远超你阅读的速度，实现路径不一定是你预想的那条，没有明确说明的地方它会自己做判断。这些判断大多数时候合理，但不一定符合你的业务逻辑。 你”跑一下”测到的，是你想到的场景。你没想到的场景，就是漏洞藏身的地方。 更麻烦的是，Agentic 开发的节奏比手写代码快得多。你可能一个下午让 AI 写了三个模块，每个都”跑了一下”，感觉都没问题。但三个模块拼在一起，在某个你没有走过的路径上，问题才会出现。 速度越快，“跑一下”这个验收方式的漏洞就越大。 * * * ## 先写验收标准，再让 AI 写代码 ![先写验收标准，再让 AI 写代码](https://xingkaixin.me/posts/images/ai-code-review-expensive-testing/ai-code-review-expensive-testing-02.webp) 思路不新：写代码之前，先用人话把”什么算对”描述清楚。比如”用户连续输错密码 5 次，锁定账号 15 分钟”。这句话本身就是验收标准，产品经理能看懂，AI 也能看懂。 这个做法（BDD，行为驱动开发）在手写代码的时代一直推不动，工程师嫌先写行为描述再写实现太麻烦。但 Agentic 开发把成本结构改了：你写行为描述，AI 转成可执行的测试用例，再根据测试写实现，自己跑通验证。你唯一要做的判断是：行为描述写对了没有。 而且有一个反直觉的事实：**让 AI 写测试，比让 AI 写功能代码更可靠。** 测试的正确性比实现的正确性更容易被人判断。你看一眼测试用例，能直接判断它测的是不是你想要的行为；但你看一眼实现代码，很难判断它在所有边界条件下都是对的。 我自己的做法是，让 AI 生成测试之后，先花几分钟过一遍测试用例清单。不需要读测试代码本身，只看每条测试描述的是什么行为，少了哪个边界场景一眼就能看出来。这几分钟的回报率极高：在验收标准层面发现的遗漏，修复成本几乎为零；同样的遗漏等代码写完才发现，可能要推翻整个实现。 把验收标准前置，给 AI 一条有终点线的赛道。这是第一层验收的核心。 * * * ## 测试抓不住的那类问题 功能验收解决了”对不对”的问题，但还有一个没解决：质量。 AI 优化的目标是让当前测试通过，至于三个月后这段代码好不好改，不在它的考虑范围内。项目里明明有一个功能相似的工具函数，它会再写一个新的；错误处理只要不抛异常就算完事；代码风格跟项目其他部分对不对得上，也不是它操心的事。 这些问题单独看都不是大事。但它们累积起来就是技术债。今天不影响运行，六个月后每改一行都如履薄冰。 开头那个日期函数就是这类问题。每个函数单独看都是对的，测试全过。但两个功能重复的函数同时存在，改了一个忘了另一个，bug 就这么埋进去了。靠测试抓不住。 问题在于，质量没有标准答案，也没有一个分数可以打。你没办法跑一个命令，输出”质量：87分”。 但有一件事是可行的：**让另一个模型来读这段代码。** 功能 bug 应该被测试抓住，这里让它做的是另一件事：以”三个月后要接手这个项目的工程师”的视角读代码。哪些地方会让人困惑？哪些地方引入了不必要的复杂度？哪些地方和项目已有代码存在功能重复？ 为什么要换一个模型？写代码的模型对自己的输出有惯性，注意力集中在”能不能工作”上。换一个没有这段代码生成历史的模型来读，更容易看到那些局部合理但整体有问题的地方。 我通常给评审模型的角色设定是：你要接手这个项目，读完这段代码后指出三类问题——和现有代码的重复或不一致、错误处理中被吞掉的异常、以及任何让你需要”想一下才能理解”的地方。这个聚焦的视角比泛泛地说”帮我审一下代码”有效得多，它不会花篇幅告诉你变量命名可以更好。 它发现不了所有问题，但能在技术债还是种子的时候看到它。早发现，修一下就好；晚发现，可能要推翻重来。 * * * ## 十分钟和两周 ![验收的本质是什么](https://xingkaixin.me/posts/images/ai-code-review-expensive-testing/ai-code-review-expensive-testing-03.webp) 回到开头那个日期函数。如果验收标准里写了”复用项目已有的工具函数”，AI 不会另起炉灶写一个新的。就算漏了这条，让另一个模型扫一遍，和现有代码的重复大概率也会被标出来。 两层验收加起来多花十分钟。省掉的，是三个月后排查那个”明明测试全过啊”的 bug。 **写代码变得很容易了。判断什么代码值得存在，才是越来越贵的能力。** ## 版权声明 作者 XingKaiXin 标题 跑一下试试，是 AI 时代最贵的验收方式 发布时间 2026年4月11日 文章链接 [https://xingkaixin.me/posts/ai-code-review-expensive-testing/](https://xingkaixin.me/posts/ai-code-review-expensive-testing/) 本作品采用[CC BY-NC-ND 4.0 DEED](https://creativecommons.org/licenses/by-nc-nd/4.0/deed.zh-hans)许可。 导览 展开导览