生成很便宜，验证很昂贵

过去几个月里，我在使用 Coding Agents 工作时越来越明显地感受到一个现象：代码本身，出人意料地经常已经不再是问题所在。

过去我可能会为一个实现预留半天时间，而今天在条件合适时，几分钟内就能得到结果。Agent 会分析相关代码范围，修改多个文件，补上 Unit Tests，运行 Build 和 Lint，最后交付一个从技术上看颇为合理的 Patch。

这依然令人印象深刻。但工作并不会因此自动结束。

我仍然必须理解到底改了什么。我必须判断业务需求是否真的被满足。我必须检查这个方案是否仍然符合现有的架构模型，是延续了已有概念，还是悄无声息地又造出了第二套。对于另一些改动，我还会关心 Security、Contracts、Migration、运行时行为或 Performance。

于是出现了一种很奇怪的不对称：如果实现只需要五分钟，而一次严肃的 Review 仍然需要二十、三十甚至六十分钟的注意力，会发生什么？

当多个 Agents 并行工作时，这种效应就更加明显。

这还不是成本核算。下一篇文章我才会讨论那一层问题。这里我更关心另一个问题：

当代码生成变得又便宜又快时，“验证”到底意味着什么？

随着吞吐量上升，变化的不只是我们生产软件的方式。真正困难的部分也在移动。

生成扩展得比信任更快。

一个 Patch 是一项主张

本系列第 6 篇已经讨论过一个相关问题：看起来合理，并不等于真实。模型完全可能非常有说服力地犯错。这里我不想重复那层讨论，而是再往前走一步。

当 Coding Agent 生成一个 Patch 时，这个 Patch 实际上隐含着一项范围很广的主张：

这项改动满足需求，适配现有系统，不违反相关 Constraints，也不会引入不可接受的副作用。

Patch 本身并没有证明这件事。它只是提出了这项主张。

验证必须提供足够的证据，让我们愿意接受这项主张。

这听起来比日常工程更抽象，但实际上并不是。我们早就在使用各种各样的证据渠道。真正的问题，是不要把这些渠道各自能说明什么混在一起。

信号	它实际回答的问题
Build	在给定条件下，被检查的代码能否成功构建？
Typecheck	类型系统能够捕获的静态假设是否一致？
Lint	这项改动是否遵守了显式编码进去的规则？
Unit Test	一个被限定的单元，在描述过的场景中是否按预期行为？
Integration Test	多个参与部分在被测试的场景中能否协同工作？
E2E / Acceptance Test	一个具体 Flow 能否跨越多个系统边界正常工作？
Architecture Rule	一个被显式建模的结构边界是否得到遵守？
Human Review	在当前业务与技术上下文中，这个方案是否合理？
Architecture Review	Responsibility、概念与依赖是否仍然符合系统模型？

这些检查没有任何一个是没价值的。恰恰相反：好的软件工程，很大程度上依赖于把尽可能多的重要属性变成可机械验证的东西。只是它们各自能证明的范围有限。

Build 全绿不能证明业务正确。Unit Test 不能证明一条 Business Rule 放在了正确的 Layer。E2E Test 可以保护一条完整的用户 Flow，却依然可能完全看不见：为了这条 Flow，我们已经在现有机制旁边悄悄引入了第二套 State 概念。

一个绿色信号，只能证明我们实际提出的那个问题。

于是，验证的核心问题发生了变化。不是：我们有没有 Tests？而是：

对于这项具体改动，我们到底需要什么证据？

Verification Surface

为此，我使用一个工程模型里的概念：Verification Surface（验证面）。

一项改动的 Verification Surface，描述的是这项改动所触及、因此值得验证的业务、技术、结构与运行层面的相关属性集合。

关键在于：这个“面”并不等于 Diff 的大小。

一次机械式改动可能会涉及 500 行代码。也许只是按照现有模式调整 Mapper，移动文件，或者修改清晰定义过的 DTO 转换。Patch 很大，但真正有意义的自由度很小。Compiler、Tests 再加上少量针对性检查，就可能覆盖大部分相关错误类别。

而十行代码的改动，可能完全不同。

Diff 很小。

Verification Surface 却很大。

中央 State 机制、权限判断、Schema 变更，或者 Public Contract 上的微小修改，都可能出现同样的情况。

代码量和 Verification Surface 不是一回事。

当代码生产越来越便宜时，写了多少行代码会进一步失去解释力。更有意思的问题变成：这项改动可能在哪些层面出错？

这个视角也能避免另一种误区：Review 深度不应该条件反射式地随着 Diff 大小增长。一个小的文本修正不需要 Architecture Review。一个小小的 Authorization Rule 改动，也许就需要。

局部正确，系统性错误

最近一次经历，让我非常直观地看到了这两个概念的区别。

在一个系统里，+state 中已经存在一个常规的 Signal Store。它的角色是有意设计过的。相关 Business State 放在那里，Reactive Derivations 在那里产生，数据流与 State 变化也遵循一套既定模型。

后来，一个 Agent 在 application Layer 中又创建了一个自己手写的 Store。

对我来说，两个 Store 并不会自动构成架构错误。一个 Source Store 加一个独立的 ViewModel Store，完全可能拥有合理的不同 Responsibilities。如果两者承担不同任务，而且这种分离是有意识建模出来的，那甚至可能是更好的架构。

但这里不是这种情况。

第二个 Store 没有独立的业务 Responsibility。它拿已有的 Derivations 再次转换，并开始重复 State Responsibility。同时，这个实现还把 computed、effect 这样的 Reactive 机制与明显更 Imperative 的风格混在了一起。

于是出现了两种不同的 Drift。

第一种是 Responsibility Drift（职责漂移）：Responsibility 被移动或复制了，却没有新的业务概念来支撑这种变化。

第二种是 Paradigm Drift（范式漂移）：在同一个 Problem Space 中，开始出现第二套编程与 State 模型。

从局部看，这段代码并不荒谬。它可以工作。Tests 也可以是绿色的。

而这恰恰是这次改动最值得注意的地方。在此前大约十个任务里，这个 Agent 一直工作得非常干净。于是我的注意力也自然下降了。有一次我没有再看得那么深——系统里突然就多出了第二套 State 概念。

一项改动可以在局部是正确的，却在系统层面是错误的。

Architecture Drift 往往并不是来自一个显然错误的决定，而是一连串局部上都合理的决定，慢慢把系统带向了另一个方向。

可靠的历史会改变注意力

这个例子里还有第二个机制，对我同样重要。

如果一个 Agent 连续十次都工作得很可靠，我会从中学习。这是合理的。信任本来就是通过经验形成的。我们和人协作时也是如此：一个多年来始终交付高质量结果的人，和一个经常提交基础性问题的人，Review 的方式自然不同。

但信任也有副作用。成功的历史会改变我的注意力深度。

这并不是说人会因此变懒或变得粗心。它只是说明：我们的注意力是有限的，而我们会根据概率去分配它。一个长期表现稳定的系统，看上去就不那么需要深度检查。

在自动化生成场景中，这会变成一个特别的问题，因为生产速率同时还在上升。

可靠的历史，并不能证明下一个 Patch。

好的历史记录，是关于某个 Workflow 预期可靠性的证据。它不能替代对某项具体改动的验证。

也正是在这里，开始出现一种之后还会继续讨论的债务：Verification Debt（验证债务）。

Architecture Review 本质上是在验证 Responsibility

我的架构会有意识地让各层保持“无聊”。这一点对 application 尤其如此。

通常情况下，我不希望在那里看到令人意外的 Business Logic。这一层聚合相关 Store Properties 或 Use Cases，并向 Presentation 暴露一个清晰的 Contract。如果某条 Business Rule 已经属于 State Responsibility，我不希望它再在 application 中重新出现一次。

同样的原则也适用于其他方向。Business Rules 不应该因为某个 Event 恰好在 Presentation 中到达，就被塞进 Presentation。UI Responsibility 不应该因为某个 Signal 在 Store 中很方便，就迁移进 Store。Infrastructure Mapping 不属于 State。新的 State Abstraction 也应该拥有可识别的 Responsibility，而不是仅仅因为技术上“可以做”就存在。

因此，Architecture Review 回答的问题，和 Behavior Test 不一样。

Test 可以验证行为。Architecture Review 验证 Responsibility 是否仍然待在正确的位置。

这也是为什么我不会把 Architecture Review 简化成 Pattern Matching。

Patterns 有帮助。Layering Rules 有帮助。Import Constraints 特别适合自动化。比如，它们可以阻止 presentation 直接访问 infrastructure。

但更难的问题有时是：这个新 Abstraction 为什么会存在？它是否真的拥有独立 Responsibility，还是我们正在第二次建模同一份 Responsibility？

要回答这种问题，Reviewer 需要一个关于整个系统的模型。

今天，这种系统性理解仍然是我认为有经验的开发者特别有价值的地方之一。但我不会因此把它定义成人与机器之间永久不变的边界。Review Models 会继续变强，Context Retrieval 会继续改善，架构知识也越来越能被显式化并提供给模型。

更谨慎的说法是：

今天，系统级 Review 往往比局部 Diff Review 需要更多、也更稳定的 Context。

规则很有帮助——只是它们不知道未来所有偏差

Store 的例子之所以有意思，还因为这个环境绝不是毫无治理的。

我现在会使用 Layering Rules、Agent Files、Skills、专门的 Review Instructions 和机械化 Checks。本系列上一篇文章讨论的正是这一发展：Build、Lint、Tests 和 E2E 越来越成为 Agent Infrastructure 的组成部分，让 Coding Agent 能够自己运行并检查自己的改动。

但第二个 Store Abstraction 依然出现了。

这并不否定上一篇文章。它只是说明：显式规则最擅长解决的是已知的 Drift 类别。

非法 Import 可以被 Architecture Rule 拦截。错误 Dependency 可以被 Constraint 拒绝。缺失的 Tests 可以在 CI 中暴露。Naming Violations 属于 Linting。错误的 Layer Access 可以被机械性限制。

更难的是那些目前还没有规则的 Divergence：第二套竞争概念、新的隐式 Responsibility、不必要的 Abstraction、Paradigm Mix，或者一个技术上能工作的方案，却重新实现了三座 Library 之外已经存在的机制。

Architecture Rule 必须提前知道这个问题，才能精确禁止它。

显式规则能够减少已知的 Drift 类别，却无法预见所有新的、局部合理的 Divergence。

因此，我仍然认为“让更多架构规则可执行”这个方向是对的，但这并不意味着 Architecture Review 会因此变得 trivial。Rule Review 越来越容易自动化。System Review 目前仍然更难。

Reviewer 不应该先被说服

还有一点改变了我使用 Review Agents 的方式：我会尽量避免让 Reviewer 一开始就接收 Implementing Agent 的自我辩护。

原因其实非常“人类”：修辞会形成锚定。

一个口才很好的开发者，可以把一个技术上很可疑的决定解释得极其有说服力。我自己就经历过。很多年前，我和一位学术背景很强、表达能力也非常强的同事讨论 Microservices。聊了很久以后，我几乎真的被他说服了：这个概念从根本上就行不通。

后来有一次骑自行车时，我突然想到：

等等。刚才那套说法其实根本站不住脚。

并不是因为那位同事什么都不懂。恰恰相反。正是因为他的专业能力很强，那套论证才更容易让人信服。

这件事一直留在我的记忆里。一段很好的解释，会在我真正独立检查对象本身之前，就先影响我的判断。

AI 生成的代码也是一样。Coding Agent 完成实现以后，完全可以写出一段非常漂亮的说明，告诉我为什么这个方案优雅、如何延续已有 Pattern、又如何满足所有 Requirements。

这是一条有用的信息。

但它不是证明这件事真实的证据。

看起来合理的理由，不是证据。

因此，我更喜欢给 Review Agent 另一类任务。不是：解释 Coding Agent 的方案是否合理。而更像：

Requirement
+
Constraints
+
相关系统 Context
+
Diff
↓
独立验证

实现理由以后仍然可以有价值。我只是不希望它先决定 Verifier 的观察视角。

Verifier 应该拿方案去对照 Requirements 与 Constraints，而不是拿它去对照 Generator 自己的解释。

Independent Evidence 需要不同的视角

这就引出了另一个概念：Independent Evidence（独立证据）。

我们很容易把“独立性”等同于参与的模型数量。Agent A 实现，Agent B Review，于是看起来好像已经有了两个视角。

但这并不会自动成立。

我见过一个真实 Workflow：Junior 1 在 Agent 支持下实现，Junior 2 也在 Agent 支持下 Review。结果看起来很好。Review Agent 没有发现什么实质问题。

然后，一个有经验的 Reviewer 只问了一个关键问题。

整个方案开始崩塌。

随后，一个被有意识配置得更强的 Review Agent 找出了多个严重问题。

这并不是说 Junior 不应该使用 AI，也不是说第二个模型没有价值。真正值得注意的是另一件事：

仅仅因为有第二个模型参与，Review 并不会自动变成独立验证。

两个模型可能继承同样的假设。它们可能都找不到同一片 Repository 区域，都漏掉同一条 Architecture Rule，都读到同一份不完整的 Requirement Context，也都接受同一个看起来合理的故事。

因此，独立性更多来自验证视角，而不是模型身份本身。

Generator 问的是：我怎么实现这项 Requirement？

Verifier 更应该问：这个 Patch 可能违反了哪条相关 Requirement、Constraint 或 System Assumption？

这仍然不能保证真正独立。但至少两边的任务已经不是同一个。

能够提出反驳本身就是一种 Capability

现在，我会明确期待强模型反驳我。

我不需要 Reviewer 告诉我，我的想法其实挺不错。如果我错了，我希望尽可能早地知道。

在和 Frontier Models 做较长技术讨论时，这已经发生过很多次。我一开始带着相当明确的观点，模型在某一点上反对我，我们把背后的假设一层层拆开——最后我改变了自己原来的看法。

我不觉得这是 Workflow 失败。

这正是 Workflow 本身。

我不需要一个只会确认我的方案“看起来合理”的 Reviewer。我需要一个在有充分理由时敢于反驳我的 Reviewer。

但这并不意味着每次 Review 都要变成最大强度的 Red Teaming。

我也试过那种方式。如果你要求 Agent 无论如何都必须找到风险，它就一定会找到风险。到后来，理论上的 Edge Cases 会被用和真实 Architecture Violations 一样的力度追查。下一轮 Fix 又会增加 Guards、Fallbacks、Abstractions，而这些东西又会成为下一轮 Review 的新攻击面。

这有时会让软件更稳健。

也可能让软件变得过度防御、难以阅读。

所以，对我来说更好的特性不是最大攻击性，而是校准（Calibration）：有充分理由时就反驳；现有证据已经足够时，也应该接受方案。

Verification Diversity

Independent Evidence 还会引出一个相关原则：不同的验证渠道，最好不要只是重复问同一个问题。

我把它叫作 Verification Diversity（验证多样性）。

一个贴近实现的 Unit Test，对错误的敏感性和 E2E Test 不同。Architecture Rule 能看到的问题，和业务 Reviewer 不同。Static Typecheck 会发现和 Security Review 不同的 Defects。Review LLM 可能会发现一个 Tests 从未描述过的 Smell。业务负责人也可能发现：一个技术上完全正确的实现，实际上做错了 Requirement。

目标不是让每个 Patch 都接受尽可能多的检查实例。

更多验证，并不会自动变成更好的验证。关键在于，不同渠道是否能暴露不同且相关的错误类别。

因此，Review 深度也应该由 Verification Surface 决定。一次静态文本修改的 Surface 很小。一个同时触及 Presentation、Application、State、Infrastructure 和 API 的 Feature，Surface 就大得多。此时，我会特别关心 Layering Boundaries、Slicing、Autonomy、既有 Patterns、不必要的新 Dependencies，以及有没有在已有工具之外又引入 Self-Made Solutions。

Diff 大小至多只是多个信号之一。

Verification Surface 更取决于一项改动触碰了哪些边界，而不是它改了多少行。

不同 Test Level 需要不同程度的独立性

对 Independent Evidence 的追求，不应该变成新的教条。

例如，我并不认同一种一刀切的要求：Implementing Agent 绝对不能写自己的 Unit Tests。Unit Tests 本来就经常用于保护某个具体实现。在这种上下文中，离实现很近并不一定是问题。

一个实现业务函数的 Agent，完全可以同时补上直接相关的 Unit Tests，覆盖 Edge Cases，保护 Local Invariants。这些 Tests 成为 Patch 的一部分，并增加针对这个具体实现的证据。

但对于 Acceptance Tests 或 E2E Tests，我通常更希望它们具有更强的独立性。

在那里，我不太关心单个 Method 是否工作，而更关心预期 Flow 是否能跨越相关 Layers 正常工作。为此，我会更倾向让一个专门的 Agent 使用 Requirements 和系统访问能力，从另一个视角验证完整流程。

即便如此，也不能夸大 E2E 的证明力。E2E Test 只能验证我们描述给它的预期行为。而现实中的 Requirements 很少完整。

Tests 只能针对足够明确的 Expectations 做验证。缺失的 Requirements，并不会因为我们增加更多 Testing 就自动变完整。

这是 Verification 本身很重要的一条边界。Evidence 只能拿一项主张去对照已知或能够推导出来的 Expectations。如果没人知道某个特殊场景在业务上到底应该怎么表现，Test 不可能凭空创造那个决定。

好的 Verifier 知道自己权限的边界

因此，对我来说，Verification 还包括另一个问题：谁到底有权做这个决定？

如果业务 Requirement 不清楚，应该由业务侧决定。Architect 或 Developer 可以解释选项、说明技术后果、指出不一致，但这不会自动赋予他发明新 Business Rule 的权力。

反过来，一项 Architecture Decision 也不会因为它来自某个业务 Ticket，就自动变成业务侧的职责。

在我的工作里，这条边界相对清晰：业务侧拥有业务决策权，Engineering / Architecture 拥有技术决策权。

最近在更强的模型上，我越来越常看到一种我非常希望出现的行为：模型发现某个地方不清楚，然后直接说，这个问题必须和业务负责人确认。

这是一个好答案。

第 10 篇文章已经用“停下来，而不是猜测”这一思路讨论过这种态度。放到 Verification 里，它意味着：

好的 Verifier 不需要对每个问题都有答案。它必须知道，什么时候自己没有做决定的权限。

有意识的例外，还是无意识的 Drift？

Architecture Rules 本身也不是自然法则。

有些场景里，偏离规则完全可能是合理的。也许 Legacy Contract 阻止我们采用干净的目标架构。也许某个技术限制让既有 Pattern 变得不现实。也许完整方案做得到，但对当前产品上下文来说经济上并不合理。

但我不会接受一句：“没办法，只能这样。”

如果真的要打破一条规则，那么规则本身就应该重新成为分析对象。它为什么在这里不适用？有哪些替代方案？是否已经有成熟做法？这个偏差能否被限制在局部？长期意味着什么？

有时分析之后，答案确实仍然是：我们接受这个例外。

那我希望这是一个有意识做出的决定。如果现实经济条件迫使我们选择技术上更差的方案，那就是 Tech Debt。关键在于，我们知道自己承担了它。

有意识的例外，是一个决定。没有被察觉的例外，就是 Architecture Drift。

这不是在主张每个小问题都写一份官僚式 ADR。它只是主张：真正重要的偏差，不应该悄无声息地消失在“普通实现细节”里。

Verification Debt

这样就可以更精确地定义前面的概念。

我所说的 Verification Debt，并不只是“Tests 不够”。

当改动产生得比我们为其业务与系统正确性建立可靠证据的速度更快时，就会形成 Verification Debt。

这可能发生在多个 Agents 并行工作时。也可能因为 Implementation Time 大幅下降，而 Review Time 没有同比下降。也可能因为团队已经很好地自动化了 Build、Lint 和 Unit Tests，却只是浅层看待系统性改动。还可能因为 Review Agent 只检查 Local Diff，而相关的竞争性 Abstraction 根本不在它的 Context 中。

这里有一个重要限制：Agentic Work 并不会自动制造 Verification Debt。

如果 Verification 能按比例增长，就不一定产生债务。这正是工程工作真正要解决的问题。

我们不能只扩展 Generation。我们还必须扩展自己检查、解释并可靠接受这些结果的能力。

Generation 更容易并行化

目前，我不断碰到一个非常实际的边界。

我可以同时启动多个 Coding Agents。一个实现 Feature，一个做 Refactoring，第三个补 Tests，第四个写 Documentation。

从计算上看，这种吞吐量几乎可以继续无限扩展。但我的注意力没法以同样方式并行。

如果两个改动属于不同的业务和架构 Context，我不可能在同一时间认真理解两边。我可以来回切换。我可以委托 Reviews。我可以把机械 Checks 自动化。

但 Systemic Judgment 目前仍然是一种有限资源。

因此，我个人现在最常遇到的瓶颈，已经出人意料地不再是写代码。

严肃的 Review，目前才是瓶颈。

这里“目前”两个字非常重要。

Review Models 在进步。Repository Retrieval 在进步。Architecture Rules 会越来越显式。Models 会获得更大、更稳定的工作空间。也许几年之后，我今天自己检查的很大一部分内容，都能被可靠自动化。

所以，更普遍的论点根本不需要建立在人类与 AI 永久对立的边界上：

瓶颈会移动到那些“信任还无法被充分自动化”的地方。

这也为并行化划出了一条边界：

Generation 的扩展速度，不应该超过系统可靠验证其产出的能力。

软件开发真的正在转向 Verification Work 吗？

我自己的这项观察，已经和当前研究中的一部分结果出现了相当明显的呼应。但现有证据还远远不足以把它直接推广成所有软件团队的普遍规律。

Annie Vella 与 Kelly Blincoe 在 2026 年的一项纵向研究尤其值得注意。作者对专业 Software Engineers 做了两轮调查，间隔六个月。第一轮 158 人，第二轮 101 人，其中 95 人有可配对的纵向数据。82% 的参与者表示，自己花在“真正写代码”上的时间减少了。作者描述了一种从 creation 向 verification 的更广泛转移，并提出 supervisory engineering work 这一类别，用来描述对 AI Output 的引导、评估与纠正。同时，主观感受到的 Productivity Improvement 依然很高；但在配对样本中，至少有一个 Developer Experience 维度变差的参与者比例，从 14% 上升到 27%。截至 2026 年 9 月，这项工作仍属于 Preprint 或 Submitted Manuscript，因此需要谨慎解读。

Agnia Sergeyuk、Ilya Zakharov、Ekaterina Koshchenko 与 Maliheh Izadi 的系统性文献综述覆盖范围更广。它综合了 90 项关于开发环境中 Human-AI Experience 的 Empirical Studies。作者既发现了 Productivity Gains，也发现了 Verification Overhead 与 Over-Reliance；在质量维度上，反复出现的风险集中于 Correctness、Maintainability 与 Security。这项工作已经发表于 Empirical Software Engineering，同时也清楚展示出这个研究领域有多么异质，以及我们仍然有多么缺乏更长期、更接近真实环境的评估。

Mohamed、Assi 与 Guizani 的另一项 Systematic Review and Mapping Study 对 39 篇 Peer-Reviewed Studies 得出了同样谨慎的结论：多数研究报告了 Productivity Benefits，尤其是在 Routine Tasks 与 Code Search 上。但对于 Code Quality，并不存在一致效果；结论高度依赖 Task、Measurement Method 与 Context。

因此，研究确实支持“开发者工作内容正在发生迁移”这一判断。但它并不支持一个简单公式：Verification Work 增加，就一定意味着 Productivity 降低。

更多 Output 也可能只是把工作转移到别处

Feiyang Xu 等人在 2025 年的一项研究观察了 GitHub Copilot 引入之后的 Open-Source Projects。作者报告称，较少经验或更 Peripheral 的 Contributors 尤其出现了更高 Productivity，但与此同时 Rework 也增加了。分析中，经验丰富的 Core Developers Review 的代码增加了 6.5%，而他们自己的 Code Productivity 下降了 19%。这项工作应被视为 Conference Contribution 或 Preprint。它是一个有意思的信号，说明局部 Productivity Gain 可能会把工作重新分配到系统内部，但它并不是 AI-Assisted Software Development 的普遍效应值。

Qualitative Data 从另一个角度呈现了相似的摩擦。Sebastian Baltes、Marc Cheong 与 Christoph Treude 在 2026 年的一篇 Preprint 中分析了 1,154 条 Reddit 与 Hacker News 关于所谓 AI Slop 的帖子。他们编码结果中的一个核心主题 Cluster 是 Review Friction：开发者讨论额外的 Reviewer Burden、Trust Loss 与各种 Countermeasures。这类数据描述的是特定 Online Communities 中的感知与讨论，并不是代表性开发团队中的实际 Productivity Measurement。

Fawzy、Tahir 与 Blincoe 另一项 2026 年 Preprint 通过 162 名参与者，比较 Non-Developers、Novices 与 Professional Developers 的 Verification Practices。作者提出 perception-action gap：对于 AI Generated Code 可能有风险这件事，人们的意识其实相当普遍；但真正评估、Debug、Verify 代码的能力，则和 Experience 以及实际 Programming Practice 更强相关。这并不能证明只有有经验的开发者才能 Verification AI Code，但它支持一个更谨慎的观点：Risk Awareness 与 Verification Capability 是两种不同的能力。

反向证据同样重要

如果只挑上面这些研究，我们很容易讲出一个预设好的故事：AI 产生更多代码，有经验的开发者只能不停修，最后所有人都更累。

研究没有这么简单。

Microsoft、Accenture 与另一家 Fortune 100 公司中的 Randomized Field Experiments，总计覆盖 4,867 名开发者。Cui 等人的 Pooled Analysis 报告称，获得 Generative Coding Assistant 使用权的开发者，完成的 Tasks 大约增加了 26%；同时，较少经验开发者的 Adoption 更高，Productivity Gain 也更强。这项工作已于 2026 年发表在 Management Science 上，并清楚说明：在真实企业环境中，AI Assistance 完全可能对被测 Throughput 产生正向总体效果。

著名的 METR 2025 实验则指向另一个方向。16 名有经验的 Open-Source Developers 在自己已经熟悉多年的 Repositories 中完成 246 个真实 Tasks。使用当时可用的 AI Tools 后，他们平均反而慢了 19%。特别有意思的是 Perception Gap：开发者自己认为他们变快了。其中一部分额外时间用于 Prompting 与 Review Generated Output。

但这 19% 也不能被冻结成永恒结论。

METR 在 2026 年 2 月公布了关于更新模型世代的新数据。结果更偏向可能出现 Speedup，但 Selection Effects，以及 Agents 并行工作时难以精确测量时间的问题，使这些数据还不足以给出新的可靠效应值。研究者也因此调整了自己的 Study Design。

对我来说，这才是更有意思的科学结论：Task Type、Experience、Codebase、Model Generation、Tooling、Quality Bar、可用的 Verification Infrastructure 与 Workflow，都会改变最终结果。

目前最合理的总结，反而更加克制：

越来越多证据表明，开发者的一部分工作正在从 Creation 转向 Steering、Review 与 Verification。它最终带来净 Productivity Gain 还是额外负担，高度依赖具体 Context。

为什么今天 System Understanding 仍然有价值

这又把我带回第二个 Store。

一个有经验的 Developer，未必是因为能更快读完十行代码，才更容易看出这项实现的问题。他的优势在另一个地方。

他通常拥有一份 System Model。

他知道已经有一个 Store。他知道这个 Store 的 Responsibility。他能看出新的 Abstraction 并没有建模任何独立业务概念。他也可能意识到：另外三项 Local Changes 单独看都合理，但合在一起却正在建立一种新的 Architecture Paradigm。

这种知识，会改变“经验”的价值所在。

今天，一个真正理解系统的开发者，其价值越来越不在于能更快写完 Patch，而在于能看见很多 Patches 的总和正在如何改变整个系统。

这里“今天”依然很重要。

不存在任何技术定律规定，AI System 永远不可能拥有足够好的 System Model。Review Agents 在拥有优质 Context 时，已经非常强。它们能发现错误 Layer Access、Broken Contracts、Missing Tests、可疑 Error-Handling Paths 与不一致实现。

真正变难的是这种问题：这个 Abstraction 本身可以工作——但这个概念是不是已经存在于另一个 Slice？我们是不是正在长期形成两套竞争 State Models？

为了回答它，Agent 首先要找到可比较的 Existing Mechanism，理解二者的 Semantic Relationship，再判断相似性究竟是有意隔离，还是不必要重复。

这比 Local Diff Review 拥有更大的 Verification Surface。

Review Automation 只能随着“可获取的证据”扩展

即便如此，我也不会得出“AI Review 只能做表层工作”这个结论。

恰恰相反。我现在很喜欢使用专门的 Review Agents，并让它们有意识地对照 Requirements、Architecture Rules 与 Diffs 做检查。尤其面对显式 Constraints，它们可以接管大量机械化 Review Work。

真正关键的是另一点：

Review Automation 能扩展到什么程度，取决于相关 Evidence 与 Context 能否被 Reviewer 获取。

这也把本文重新连接到上一篇关于 AI-Friendly Software 的文章。

上一篇的问题之一是：Agent 能不能自己运行 Build、Lint、Tests 与 E2E？

这一篇的问题是：这些绿色结果到底证明了什么——之后还有哪些 Quality Dimensions 仍然没有答案？

因此，一个可执行的 Workspace 是强 Verification 的重要基础。但它仍然没有定义：对于某项具体改动，什么程度的 Verification 才足够。那取决于 Verification Surface。

“Expensive” 首先意味着注意力

这篇文章的标题是：

Generation is cheap, verification is expensive.

这里的 expensive，我暂时还不是主要指欧元、美元或 Token。

Verification 需要 Attention。需要 Judgment。需要相关 Context。有时需要独立 Model Runs，有时需要真实 Runtime Environments，有时需要 Security Expertise，有时还需要一项不应该由 Agent 单独做出的业务决定。

Generation 可以在几分钟内产出四个看起来合理的方案。但“哪个方案可以接受”这个问题不会因此消失。

也许将来，这种判断本身也会越来越多地被自动化。那会是一个很自然的延续。但只要 Generation 扩展得比可靠 Verification 更快，Bottleneck 就只会继续移动。

对我来说，实际结论相当明确：Coding Agents 的并行化程度，不应该超过 Verification System 能承受的吞吐量。同时，我们至少应该像投资 Coding Agents 一样，有意识地投资 Review Agents、Acceptance Tests、Architecture Rules 和其他 Verification Infrastructure。对于拥有较大系统性 Verification Surface 的改动，我今天仍然会有意识地让真正理解相关系统的人参与进来。

最后这一点是否永远必须由人完成，仍然是开放问题。背后的原则更普遍。

Generation 越便宜，我们越需要认真回答：一项改动要获得接受，到底需要什么证据？

所以，我们不应该只衡量一个 Agent 能生成多少代码。我们应该理解，一个 Generated Patch 是如何变成一个经过验证、可以接受的改动的。

因为从这里马上会出现下一个问题。

如果 Verification 需要 Attention、Model Runs、Tests、E2E、真实 Infrastructure 与 Human Judgment——那么，一项我们能够充分信任的改动，到底成本是多少？

这就是经济层面的视角。

而它属于下一篇文章。

代码会变便宜。信任不会自动变便宜。Bottleneck 会移动到那些“信任还无法被充分自动化”的地方。

来源与研究定位

Annie Vella, Kelly Blincoe — “The Impact of AI Coding Assistants on Software Engineering: A Longitudinal Study”, 2026.
针对专业 Software Developers 的纵向 Mixed-Methods 研究，两次测量间隔六个月。与文中从 Creation 向 Verification 的转移以及 supervisory engineering work 概念相关。截至 2026 年 9 月，应将其视为 Preprint 或 Submitted Manuscript。

Agnia Sergeyuk, Ilya Zakharov, Ekaterina Koshchenko, Maliheh Izadi — “Human-AI experience in integrated development environments: a systematic literature review”.
对 90 项研究的 Systematic Literature Review，发表于 Empirical Software Engineering。与 Productivity Gains、Verification Overhead、Over-Reliance 以及 Correctness、Maintainability、Security 风险相关。该综述同时展示了研究领域的高度异质性，并呼吁更长期、更广泛的评估。

Amr Mohamed, Maram Assi, Mariam Guizani — “The Impact of LLM-Assistants on Software Developer Productivity: A Systematic Review and Mapping Study”.
对 39 项 Peer-Reviewed Studies 的综合。多数研究报告 Productivity Gains，而 Code Quality 的结果仍然相互矛盾，并高度依赖 Context。

Feiyang Xu, Poonacha K. Medappa, Murat M. Tunç, Martijn Vroegindeweij, Jan C. Fransoo — “AI-assisted Programming May Decrease the Productivity of Experienced Developers by Increasing Maintenance Burden” / “GenAI as a coding partner”.
分析 Copilot 引入后的 Open-Source Development；其中报告了 Core Developers 更多的 Review 与 Rework。应视为 Conference Contribution 或 Preprint。结果提示 Work Redistribution 的可能性，但不是普遍 Effect Size。

Sebastian Baltes, Marc Cheong, Christoph Treude — “An Endless Stream of AI Slop: How Developers Discuss the Burden of AI-Assisted Software Development”, 2026.
对 1,154 条 Reddit 与 Hacker News 帖子的 Qualitative Analysis。与感知到的 Review Friction、Trust Loss 与 Maintenance Burden 相关。这些数据反映开发者讨论，不应被当作代表性 Productivity Measurement。

Ahmed Fawzy, Amjed Tahir, Kelly Blincoe — “From Prompting to Verification: How Experience Shapes Vibe Coding Practices”, 2026.
包含 162 名不同经验水平参与者的 Survey Preprint。与文中提到的 perception-action gap 相关：Risk Awareness 与实际 Verification AI-Generated Software 的能力并不是同一件事。

Kevin Zheyuan Cui, Mert Demirer, Sonia Jaffe, Leon Musolff, Sida Peng, Tobias Salz — “The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers”. Management Science，2026 年 2 月 27 日在线发表。出版信息与 DOI。
在 Microsoft、Accenture 与一家 Fortune 100 公司进行的 Randomized Field Experiments，总计 4,867 名开发者。Pooled Analysis 报告明显 Productivity Gain，在本文中作为反对“AI 必然带来更多整体负担”这一简单叙事的重要反向证据。

Joel Becker, Nate Rush, Elizabeth Barnes, David Rein / METR — “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”.
随机实验，涉及 16 名经验丰富的 Open-Source Developers 与 246 个熟悉 Repositories 中的真实 Tasks。Early-2025 Tools 让受试开发者平均慢了 19%。METR 自身明确提醒不要过度泛化；2026 年后续数据提示 Effect 可能正在变化，但还不足以给出新的精确 Effect Size。

本文中的 Verification Surface、Verification Debt 与 Verification Diversity 是作为 Engineering Models 使用的。引用研究并没有建立这套具体术语。它们提供的是与 Verification Overhead、工作内容迁移、Review Burden 以及 Context-Dependent Productivity 相关的实证连接点。