生成不再是瓶颈，验证才是

2026-09-24 Aryee 0

先说清出处，因为这句话被引用时经常归错地方。

「代码生成不再是瓶颈，验证才是」来自 Thoughtworks 的《The Future of Software Engineering》，对应 2026 年 6 月 28 到 30 日在瑞士恩格尔贝格的峰会；中文世界里的主要流传版本是 Tony Bai 2026 年 7 月 31 日的解读。它不属于《Technology Trends》年度报告——那份里并没有这个提法。两者混引的情况已经很多了，写文章时归错源，后面的论证再对也站不住。

这个判断有旁证

单看一份会议报告容易当成观点，但另两条独立线索指向同一处：

DORA 在 2026 年 4 月发布的《The ROI of AI-assisted Software Development》，核心的说法是两条：AI 是放大器——它放大既有的强项，也放大既有的弱项；同时吞吐量上升与部署不稳定性上升是同时发生的。这份报告里还有个更好用的词：验证税（verification tax）。

开发者侧的自陈数据。Sonar 2026 年 1 月发布的调查，样本 1,100 名开发者：AI 代码占比 42%，对 2027 年的预期是 65%；但96% 的人表示不信任 AI 产出的代码，38% 明确抱怨评审负担变重。BairesDev 的另一份调查（样本 705 人）里，67% 说审查 AI 产出花了更多时间。

三份材料统计的定义不一样、方法也不一样，把它们并排放只为了说明一件事：产出的量上去了，确认它对的工作量上去了，而且后者涨得更快。 这就是「瓶颈迁移」的意思——不是质量变差了，是瓶颈从写挪到了验。

验证税在真实改造里长什么样

抽象讲「要加强评审」没用。我按一次系统改造里的实际分层来记这笔账：

层级	验什么	能不能自动化	谁来做
语法与结构	编译、静态检查、格式	完全能	CI
行为正确	单元与契约测试	基本能	CI
边界与异常	空值、超时、并发、部分失败	半自动，用例要人写	作者 + 评审
与既有系统一致	老代码的隐含约定、字段语义	很难	熟悉这块的人
意图对齐	这段代码是不是需求要的那件事	不能	提需求的人和作者

AI 把前三层的成本压到接近零，后三层的成本一分没减。而且有个副作用：前三层太容易通过，容易让人以为「测试都绿了」就等于第四五层也没问题——这是当前最典型事故来源。

第四层尤其值得单独说。老系统里大量约定是没人写下来的：某个字段为空时的处理是靠上游保证的、某个接口返回 200 但 body 里带错误码、某张表逻辑删除靠的是标志位而不是真删。生成出来的代码在这些点上「看起来合理」，跑单元测试也过，一进真实环境就出事。这类知识不在代码库里，在几个人脑子里。 AI 学不到，因为压根没写下来过。

那笔省下来的时间该花在哪

如果生成阶段确实省了时间，账要记回到验证上去，否则只是把风险往后推。我实际会做的三件事：

一、评审看边界，不看结构。 结构层面的问题交给工具，人的注意力集中在「这里超时了怎么办」「这个字段为空谁兜住」。一份 PR 里 AI 生成的代码，我会直接翻到异常分支和外部调用处，其余扫一眼。

二、把隐含约定写成测试或注释。 上面说的第四层，唯一的解法是把知识显性化。每修一个这类问题，顺手补一条能重复执行的断言。这件事的短期性价比很难看——多花了时间——但它是唯一能让第四层逐步自动化的路径。

三、给 AI 产出单独设一道合并门槛。 不是因为它是 AI 写的就歧视，而是因为责任链变了：代码是 AI 生成的，但提交的人要签名。合并前必须回答一个问题：这段代码你读懂了吗？答不上来的，退回自己重写一遍。这条比任何工具都管用，因为它把「验证税」明确交给了签名字的人，而不是留给线上。