跨国深谈← 返回←AI 写代码太快的时代，验证才是新瓶颈

AI 写代码太快的时代，验证才是新瓶颈

关联

人物 Gabriel Spencer-Harper

公司 Meticulous

概念 验证 · 基于断言的测试 · 代码覆盖率 · 确定性 · pull request

这一集是 Meticulous 的联合创始人兼 CEO Gabe 的现场演示演讲，主题只有一个：怎么验证 AI 写出来的代码。

他的开场判断很直接——如果你有穷尽式的验证，就能以智能体写代码的速度发布代码；如果没有，那组织里某个地方的人就得花时间验证，这成了新瓶颈，你被迫在发布速度和 bug、用户体验之间做取舍。而现实是：AI 写代码的速度已经比人类审查的速度快，审查和验证成了新的瓶颈。更麻烦的是，仅靠基于断言的测试(就是提前写好「预期行为应该是什么」的测试)根本不够——不管人还是智能体多努力地事先在断言里定义软件的正确行为，可能的回归空间都太庞大，无法穷尽覆盖。

他给了一个很好的自查问题：如果组织里一名工程师用 AI 生成了一个 pull request,你会放心点「合并并发布」吗？在大多数组织里，答案是不会——你还得去检查所有 feature flag、角色、权限、设置、配置和各种边缘情况，才能理解这次变更的完整影响。

现状带来的三个后果

第一个是逃不掉的 bug 和回归，直接影响业务。第二个是工程组织要花两位数百分比的时间维护端到端测试套件——手动验证、审查、调试 flake(时而随机失败的测试)、更新维护测试，全都在烧时间。第三个更微妙：如果真能拿到穷尽式验证，编程方式本身会变——突然之间你可以升级所有依赖、做大规模重构、满怀信心地接受任何 AI 生成的变更。

演示：它到底怎么工作

Meticulous 的做法：给非生产环境(本地、QA、dev、staging)注入一行 JavaScript。这段脚本对浏览器插桩，记录成千上万条用户工作流——点登录按钮、点设置面板、点分析面板等等。当你在 CI 上打开一个 pull request、启动 web 应用后，Meticulous 取这些录制工作流的一个子集，逐条回放每个事件，并在整个时间线的每个原子时刻截图——于是每条工作流都有变更前、变更后两个截图序列，再把两个序列做 diff,在合并代码之前告诉你：应用会有什么不同。

演示里有个例子：一次变更里有人改了名字，同时在某个下拉菜单里引入了一个错误。Meticulous 几分钟内就在 PR 上发评论，列出各处 diff——浅色模式下的名称变更、深色模式下的名称变更，以及那个逻辑错误的表现。

关键的产品哲学在差异本身：Meticulous 不会告诉你有没有 bug。传统断言测试要求你预先用业务判断固化「正确行为」；而 Meticulous 只展示有什么不同，你在审查时运用判断——或者由智能体来判。

支撑它的三项关键技术

一，所有外部依赖全被 mock 掉。 录制时记录所有网络请求和响应，回放时 stub 进去。两个原因：让测试幂等——连跑一千次结果都一样；且每个测试彼此隔离，消除竞态条件，能水平并行，几分钟出结果。

二，flake 少几个数量级。 相比 Cypress 或 Playwright 这类测试工具，Meticulous 的 flake 极少，原因是从调度引擎层开始增强浏览器使其完全确定性——浏览器当初设计时根本没把确定性当目标，动画 spinner 会依赖 CPU 时钟速度、setTimeout 和 setInterval 的交错，全是随机性来源，他们把这些全部处理掉。

三，最核心的：代码覆盖率最大化算法。 要穷尽，就得覆盖每个 feature flag 组合、每个权限、每个角色、每条分支路径。他们的做法是：每条录制的会话先对 main 分支回放一次，监控哪些代码行被执行，建立「工作流 → 执行代码行」的索引，然后选出最大化全应用代码覆盖率的子集。

有意思的是他对代码覆盖率这个指标的态度：按他带立场的说法，覆盖率对世界上除 Meticulous 之外的每一个工具都是糟糕的指标——你可以写一个覆盖 100% 代码库但只做一次断言的测试，覆盖率不等于被测试过的代码。但在 Meticulous 这两者近似相等，因为他们做了件极不寻常的事：整个流程每个可能的时刻都截图。一个 412 步的流程里哪怕出现单个像素的 diff 也会被标出来。

三项技术是层层咬合的

他最后点明了整个系统为什么能成立:你之所以能获得穷尽验证，是因为代码覆盖率算法；那个算法真正有效，又是因为每个时刻都在截图——这意味着几千万到上亿张截图，按传统方式你会被噪声和 flakiness 淹没；所以必须从根源解决 flakiness,这正是增强浏览器那一步做的事。三层缺一不可。

本集带走

• 验证已成为 AI 编码时代的新瓶颈：AI 写码速度超过人类审查速度，不解决验证，就必须在速度和 bug 之间取舍——先问自己「AI 生成的 PR 你敢直接合并吗」。
• 「展示差异」替代「预定义正确」：与其在断言里预先固化正确行为(覆盖不全)，不如在合并前展示变更前后应用的一切差异，把判断留给审查者或智能体。
• 确定性是规模化的前提：要让「每个时刻截图」可行，必须先从浏览器调度引擎层消除随机性，否则上亿张截图只会带来海量误报。
• 覆盖率算法决定穷尽程度：录制真实用户工作流、映射到代码执行行、挑出覆盖率最大化的子集——这才是「穷尽」的真正来源。
• 外部依赖全 mock:让测试幂等且互相隔离，才能并行跑到分钟级出结果。

如果你有穷尽式的验证，你就能以你的智能体写代码的速度发布代码。
if you have exhaustive verification, then you can ship code at the speed that your agents write it.
—— Gabriel Spencer-Harper · [00:45]

审查和验证现在成了新的瓶颈。
And review and verification is now the new bottleneck.
—— Gabriel Spencer-Harper · [01:57]

所以无论人类或智能体多么努力地事先在断言里预先定义软件的正确行为，可能的回归空间都太庞大，无法穷尽覆盖。
So no matter how hard a human or an agent tries to define the correct behavior of software a priori upfront in assertions, the space of possible regressions is too vast to exhaustively cover.
—— Gabriel Spencer-Harper · [02:09]

通常，按我们带立场的观点来说，代码覆盖率对世界上除 Meticulous 之外的每一个工具来说都是一个糟糕的指标。
Typically, I would say that code coverage in our opinionated view is a terrible metric for every tool in the world apart from meticulous.
—— Gabriel Spencer-Harper · [09:26]

但在 Meticulous,这两者实际上近似相等，因为我们做了一件非常不寻常、非常激进的事：我们在整个流程中每一个可能的时刻都截取一张截图。
But with meticulous, it actually is approximately the same because we do this really unusual and radical thing, which is we’re taking a screenshot at every possible moment throughout a flow.
—— Gabriel Spencer-Harper · [09:48]