开发者不再读代码，验证AI生成软件的能力成为关键

很多人已经不再阅读代码了。Agent 已经发展到这样一个阶段：你可以把软件当作一个黑盒来构建，它或许能做到你想要它做的事。然后你戳一戳它，发现它没有做到你想要它做的某件事，于是你让 agent 把它做出来，现在它也能做那件事了，而你从头到尾都没看过代码。

在具体情况下这是不是个好主意，取决于一大堆因素！但这是人们越来越多在做的事，而且在一次性脚本和关键基础设施之间的光谱上，我想我们都能同意，如今确实有一部分代码可以盲写了。

但“盲”是什么意思？我们仍然会看它的行为，即使我们看不到代码。我们仍然会看那个脚本的输出是否看起来合理，仍然会看界面是否对、是否似乎做到了我们想要的事。我们仍然会以某种方式验证 AI 产出的东西大致符合意图，即使我们不是通过阅读代码来验证。

我们通常是在测试、类型系统或形式化证明的语境下听到“验证”这个词。这些东西也是这场讨论的一部分。但即使我们不用它们，验证也始终存在。无论如何，我们总会以某种方式检查我们产出的东西是不是我们想要的。

让 AI 为自己的代码写测试很常见。这没什么问题——测试和代码一样，承载着编写和维护的负担，而自动写出的测试也确实有价值。但它们的价值是不同的，取决于我们是否、甚至是否能够阅读它们。

谁来验证验证者？就像我们的其他代码一样，我们怎么知道测试在做我们想要的事？如果我们把测试也当作黑盒，它们实际上并没有解决验证问题，只是把它挪了个地方。

我们或许可以把测试看作两类：

第一类有价值，但第二类仍然不可或缺。而第二类只有在其利益相关者能够亲自验证测试本身时才成立。即使测试不是他们写的，测试也是他们意图的表达；除非被阅读和理解，否则它们作为验证手段毫无用处。一套你从未读过的、全部通过的单元测试，也许（也许不）能在内部帮助 agent 完成工作，但作为局外人，它们对你关于软件状态的判断什么也没说。

验证软件有很多方式——人工 QA、单元测试或集成测试、静态类型、形式化验证，甚至对抗性 AI 审查（对照某些规格或需求清单）。每种方式在维护负担、敏捷性、严谨性、人力投入以及对特定问题领域的适用性上都有不同的取舍。

重要的是，总要有某种“布丁里的证据”是人类大脑能理解的。而且永远都会有。即使（在极端情况下）“这东西在生产环境里出问题了吗？”也是一种验证，尽管我们真的很想在那之前就发现。

所以，对于任何你不打算阅读的代码，想一想：我将如何、何时发现它是否做到了我想要的事？也许时不时手动测一下就够了。也许只需目视检查，或者跑一次看起来没问题的测试。也许你的风险承受能力允许你直接把它发布给用户并记录日志。又或者你需要一份形式化证明。

不管是什么，记住：AI 替你做不了这件事。你必须自己消化它、思考它，即使这是你仍然需要思考的最后一件事。