AI代码生成的隐形成本：验证债

我已经忘了该怎么写代码，至少我觉得自己忘了。很难确定，毕竟我已经有一阵子没写了。不过转念一想，我上一次把全新的服务器装进机架、再安装 Linux，是什么时候？如果这样的物理操作都能被 Terraform 简化成一行命令，凭什么写代码就必须是不可冒犯的圣域？

无所谓，我仍然看得懂代码。文档也看得懂。计划也一样。动辄数百万 token，有时候我甚至真的会留意它们到底写了什么。大多数时候，我只是负责按下屏幕上那个大大的“由我负责”按钮——至少我想象它写的是这个。“本人 Lars Janssen 特此证明：我至少要求两个 LLM Agent 以代码审查之名，把提交的变更批得体无完肤。”

但偶尔，我还是得深入研究整体结构，调出代码，弄明白不同 bot 派系究竟创造了什么。对于什么才算有品位，我是最终裁决者——尽管网上所有围绕鸡毛蒜皮问题的争论都已经被提炼进了模型，所以它们大概比我更清楚，所谓“好”到底应该是什么样子。

到了这个十年结束时，我们会走到那一步吗？几个月前，那个未来似乎还远得让人安心。然后，某些东西变了。

眼下，狂热者已经上瘾了。如果不先启动至少两个 Agent，让它们在那里埋头思考、听候差遣，他们根本舍不得离开办公桌。上厕所时不烧 token，简直都算不上有生产力。与此同时，怀疑者则在抱怨——而且并非毫无道理——AI 正在拖慢他们的速度，他们自己动手明明能做得更快。

两派说得都对。如今的真实体验是这样的：

你的 Agent 十分钟就产出了一份令人印象深刻的 diff。然后你得花一个小时，确认它没有漏掉什么会在日后狠狠坑你的东西。

上下文会蒸发。20 万 token 听起来相当慷慨，直到 Agent 开始压缩你们的对话，并忘掉十分钟前才达成的共识。

输出冗长得让人麻木。你要求做一个范围明确的改动，得到的却是一篇论文，附带一堆没人要求的注释和毫无必要的重构。

工具集成的效果时好时坏。有些 MCP 非常出色；另一些则像是有人把 API 文档随手写在了信封背面，然后让模型自己琢磨剩下的部分。

可即便如此，某些东西确实已经改变。如今已经没人再争论它到底有没有用，大家争论的是应该怎么用。

从派对把戏走向生产环境

几年前，ChatGPT 横空出世，全世界一度集体失去了理智。我在当时的一篇博客文章里把它称为“盒子里的大脑”——推理能力强大，却完全没有连接能力。想象一下，如果 Apple 发布的 iPhone 没有网络：技术演示令人惊叹，真正工作时却毫无用处。你能做的无非是把代码片段复制进去，再复制出来，仅此而已。

去年，工具在一定程度上追了上来。自动补全开始让位于 Agent 工作流的雏形。但它用起来仍然很笨拙——连接能力有限、可访问性很差，而且只要你把目光移开哪怕一分钟，模型很快就会跑偏，自顾自地做起别的事情。

发生了什么变化？好几件事，而且是同时发生的。

模型真正变得好用了——并不完美，但已经足够好：你可以把一项真实任务交给 Agent，并得到一份条理连贯的结果，哪怕为了通过那些权限提示，你得按五十次“yes”。到了 Opus 4.5 和 GPT-5，曾经对此不屑一顾的人也开始认真关注。

产品也与模型同步成熟起来。原生运行在终端里的 Agent，可以深入庞大而陈旧的代码库，并真正弄明白里面到底发生了什么。使用体验也变得足够顺手，你不再需要和工具搏斗，而是开始与它协作。

而我们也变得更擅长使用它。写 prompt 是一项技能。为 Agent 划定任务范围是一项技能。知道什么时候该相信输出、什么时候该把它扔进垃圾桶，也是一项技能。

这并不是由某一个突破带来的，而是更好的模型、更好的工具和更有经验的用户同时到来之后产生的复合效应。就像早期的互联网：没人记得它究竟在哪一天突然变得有用。它就是……变得有用了。

当工具真正契合时

真正的转变并不在于模型更聪明，而在于把它们接入你的真实系统之后，会发生什么。

当我把 Claude Code 接入我们的 Snowflake 数据仓库时，一个原本只是帮忙写 SQL 的便利工具，变成了一名全能分析师。它开始自行遍历 schema，把它们与代码和 Confluence 页面交叉比对，最后带回了一些连我自己都没想到要去寻找的洞察。

重点不再是“AI 帮我写代码”，而是“AI 可以通过定义清晰的工具，真正对现实世界采取行动”。集成做得好时，Agent 就不再只是高级的自动补全，而会成为真正的协作者：它能调查、交叉验证并提出方案。

集成做得不好时，就像给实习生一张地图，而地图上有一半的街道都是编出来的。

有一件事正在悄然成为所有人的共识：没错，我们写的代码确实变少了，但我们正在用验证工作取代它。

Agent 可以在几分钟内生成一份看起来很合理的 diff。测试通过了。commit message 写得比一半人类写的都好。PR 看起来也干净利落。而陷阱恰恰就在这里——因为“看起来正确”和“实际上正确”不是一回事。

不妨把它称为“验证债务”：我们生成产出的速度与验证产出的速度之间，正在形成一道越来越大的鸿沟。每当你对一份并未完全理解的 diff 点击批准，就等于在向未来举债。与技术债务不同，技术债务通常会通过不断增加的阻力暴露自己——构建越来越慢、依赖关系纠缠不清、每次碰到那个模块时心中都会逐渐升起恐惧；验证债务滋生的却是虚假的信心。代码库看起来很整洁，测试全是绿色。六个月后，你才发现自己构建出来的东西完全符合规格说明——却没有一样是客户真正想要的。

不要再问“我们怎样才能产出更多代码？”，而应该问“我们怎样才能验证更多代码？”这才是 2026 年真正的问题。

眼下，一份合理的验证清单应该包括：

Agent 实现的是正确的逻辑，还是只是在忠实地把一份有缺陷的规格说明写成代码？除非你明确要求，否则它不会质疑你的意图。

Agent 对业务领域做出了哪些假设？

这项变更引入了哪些权限、数据访问或副作用？

你是否愿意以自己的名义担保：它真正满足了用户的需要，而不只是工单上写的要求？

如果最后一个问题的答案是“大概吧”，那你的审查就还没有结束。

有一个令人不安的事实：如果 AI 能让每位工程师的生产力哪怕只提高 50%，组织得到的也不是多出 50% 的成果，而是多出 50% 的 PR、50% 的文档和 50% 的设计提案——而这些东西全都得有人审查。

当少数早期采用者生成更多 PR 时，团队还能消化。当所有人都这么做时，审查就会成为制约因素。瓶颈并没有消失，它只是向上游移动，转移到了工作中那些无法剥离人类参与的部分：决定要构建什么、定义什么叫“完成”、理解业务领域，以及围绕风险与取舍作出判断。

没人愿意审查 AI 制造的垃圾。大家有理由期待，你在提交自己的产出之前，已经先检查过一遍。但我的发件箱里，热情高涨的 Agent 产出的内容正越积越多，增长速度远远超过我费力审阅它们的速度。

软件工程一直都是知识工作——分析信息、共享上下文、建立共同理解。AI 可以帮助你更快找到信息，但你仍然必须真正理解它。

我一天中的大部分时间，都在向 Agent 提问。“问得好！”，它们总是这样回答，哪怕同一个问题我已经问了无数遍。因为既然我们现在都是“10x”开发者，要跟上这么多项目的细节实在太难了。AI 并没有消除认知负担，它只是改变了认知负担的形式。

令人担忧的不只是工作岗位，还在于我们可能会停止思考。我听见办公室里有人半开玩笑地说——我猜是半开玩笑——到今年年底，我们所有人甚至都不会再思考了。

这和 Google 刚出现时人们的恐惧如出一辙：既然可以直接搜索答案，为什么还要根据文档一步步推理？但实际发生的是：我们不再死记硬背 API 签名，转而开始解决更困难的问题。技能发生了转移，但并没有萎缩。AI 遵循的是同一种模式，只不过又向上提升了一个层级。

我对具体细节的判断可能是错的。也许上下文窗口会停滞不前，也许各种集成在未来许多年里仍然不稳定。但细节并不重要，方向已经不可逆转。

Agent 让产出变得廉价，却没有让责任也变得廉价。

明天我依然会坐在办公桌前，启动一堆 Agent，然后按下那个“出事算我的”按钮。