引言

现代生活中充满了黑盒，各类人造物的本质都隐藏在厚厚的外壳之下。你无法从本质上确认这些东西的可靠性。之所以能心安理得的接受，是因为有一套机制确认它是安全的。我相信我吃的药一定经过了严苛的临床试验，走的桥经过了载荷测试，乘坐的飞机通过了适航认证。

我还能这样相信AI吗？

一、测试为什么可信

测试从来不能保证覆盖所有的情况。前文讲到第三层抽象堆叠时说过，系统状态随模块组合指数爆炸，穷举在原则上不可能实现。测试的目标不是把所有情况都跑一遍，而是在超大的状态空间里做有限的采样。为什么稀疏的采样点能承诺整体的可靠性？关键是以下三点：

精准设定的测试点。前三层的造物有明确的设计规范，界定了系统在各类情况下的预期行为，测试点是依照设计规范、再叠加过往一次次真实的教训积累下的经验，专挑历史上反复出问题的位置设定的。测试点的密度不是均匀的，它密集分布在系统最重要和最容易出问题的位置上。稀疏采样之所以够用，因为它是被Specs和历史经验引导过的。

独立性，它是测试产生有效信息的隐藏前提。工程师按自己对设计要求的理解完成实现，测试按照同样的设计要求、结合规范和经验设定测试点对实现进行验证。两条路径分头出发，如果终点一致则为有效信息 —— 两独立方各自沿自己独立路径，在完全相同位置犯完全相同错误的概率很低。

可复现，同样的输入永远给出同样的输出。一个点位一旦测试通过，我们有信心认为它一直能保持这种状态。这种确定性保证了已经验证过的部分不会自己坏掉，让你在大多数情况下只需要关注改动的内容，而非每次调整都把整个系统做一遍完整的回归。它把一次测试的结论，沿时间轴外推到了无数次未来的运行。

那些我们安心依赖的黑盒，本质上都建立在这三点之上。虽然日常接触这些东西的时候我们并不会思考这些，更多的是一种“别人用这个都没事儿我用也不会有事儿”的朴素想法，但这个机制确实是这种信任的深层基础。

二、AI模型的评测

LLM是另一回事。

模型没有Specs，没有传统工程意义上的完整行为规格，无法设定点位校验参数是否符合要求。替代测试的方案是评测(eval) —— 准备考卷让模型来答题，用评分评估模型的能力。古德哈特定律告诉我们，一旦某个分数成为指标，那么它也就不再是一个好指标了。“考高分”成为厂商迭代模型的目标，精准的测试点变成了几张可以被针对性优化的试卷，考卷出题是否合理、能否覆盖足够的空间都可能不确定了。

独立性没了。模型的评测集和数据集应该保证严格独立，让模型推理没见过的题目才有评测意义。但在所有数据基本已经被吃完的情况下，评测数据容易混进训练数据中（有时是有意作弊），考试推理变成了背题。原本相互独立的两条路径合并成了一条，交叉验证失效。

不可复现。模型从原理上说是概率性的，给定同一个输入，输出是从一个分布里采样的。一模一样的两个问题问两次，模型给出的很可能是不严格相同的答案，可能意味着不同的工具调用或流程编排。这次测过对了，不等于它以后会一直对。

所以评测本质上也是统计估计，答题结果能告诉你模型在某个分布上有多大的概率可靠，给你一个置信区间，但保证不了任何具体调用的结果。测试告诉你的是在特定的输入上一定给出特定输出，但评测告诉你的是“这个模型在过去答卷的时候平均分XX”。

三、Vibe Coding的可靠性

编程之所以难，核心在于要把不严谨的自然语言翻译成逻辑严谨的符号语言，把每一种边缘case都处理干净。需求里那些含糊的、想当然的、没说出口的内容在代码里都需要有一个清晰明确的交代，并且要符合架构要求、为以后的迭代维护预留空间，这才是编程真正的成本所在。

Vibe Coding的核心卖点就是替你省掉这层翻译。人用自然语言描述想要什么，模型把需求细化、补全成Specs、写出实现、配上测试。人喝个咖啡刷个手机，等结果出来看一眼，对了就提交。它给人的感觉有点像编程领域的P = NP —— 仿佛简单描述一个想要的效果，和实际实现这个效果，从此一样轻松。

实际上一句简单的需求描述和能落地的实现之间隔着大量缺失的信息。很多时候给AI的指令只能算是一个验收指标，远不是完整的规格。模型要把你没说清楚、没说出来、甚至根本都没想清楚的部分猜出来补上去，而且要猜得一致。如果真的能用自然语言把需求涉及的每一条逻辑都描述清楚，逐一翻译成代码的成本并没有那么高。Vibe Coding没有消除掉“把话说清楚”这个难度，只是在用模型能力补充这些缺失的信息。

当模型自己做所有事时，实现和测试间的独立性就不存在了。模型有时会尝试各种手段绕过而非解决问题，包括但不限于改需求、删测试。表面需求满足了、测试通过了，结果却是错的 —— “用谎言去验证谎言，得到的一定是谎言”

所以人必须留在回路里，逐个环节去review。可人这一侧的独立性也在消失。AI辅助之下，业内已经有不少合并技术职能的案例，研发和测试不再分设，所有人借助AI做全栈。效率也许会更高，但一个人的认知盲区可能会同时体现在代码和测试阶段，自己根本测不出来自己的错误。

两层独立性都被降本增效干没了。模型在代码和测试之间没有独立性，人在代码和测试之间也没有独立性。整条链上，只剩下人和AI之间的独立性。AI是能给使用者补上认知盲区，还是会放大这个盲区呢？或许就看模型能力如何继续进化了。

四、回路里的人

AI还不能完全独立完成任务，人仍留在回路里，做最终的判断和决策。流程整体效率取决于它的瓶颈环节，也就是回路里的人。麻烦在于，这个兜底的人，正同时被两个方向挤压。

一头是不断被要求提效。真正的逐行审核，意味着人要重新理解AI写下的每一段逻辑、每一处边界，这件事的认知成本并不低。同时，各种对AI Coding的吹嘘带来爆棚的不安全感，评估体系重建，所有人对着提效的目标内卷，同样面临古德哈特定律。为了拿到效率结果，审核逐渐退化成盖章。人名义上还在回路里，实际上很多判断已经被默认跳过，许愿系统不要在自己任内崩掉就好。

另一头，涌进回路的东西在变多、变差。Vibe Coding把编程门槛降低到前所未有的水平，似乎会描述需求就能做开发。几轮对话搞出一个能跑的Demo，很容易让人产生“我能替代工程师”的感觉。但Demo不是工程。当人人都觉得自己能借AI做开发，产出会指数级增长，质量并不会等比例提升。如果Vibe Coding的产物要上线，最终仍然需要回路里的人来兜底。结果一样是审核标准退化。

原本的可靠性边界一定会被突破。系统的劣化不会是几次简单的孤立事故，而是整体上一种弥漫的、平均意义上的退化。更大量“反正又不是不能用”的东西被合并、部署，继续堆叠。这种退化短期内可能是不可见的，风险会逐渐积累并后移，直到某个边缘情况被触发的那天。在那天到来之前，一切都那么顺利 —— 效率更高了、人员更少了，积极“拥抱AI”的人拿到好绩效，或晋升或跳槽。业务照常运转，所有指标都告诉你方向是对的，继续往前冲就好。

历史向来如此。

后记

到本篇为止算是把前文提出“为什么我觉得AI不可靠”的问题详细拆解完了。AI模型本身无法被真正测试，AI的产出物也没有被正确地测试。原本那些让我觉得黑盒可靠的机制失效了。这不意味着我不看好AI。人是懒惰的，历史上能替人干活的机器最终都会被大规模采用，这是我们第一次有能替人思考的机器。我想的是接下来是否有新的范式能把AI约束在我们想要的可靠性区间内运行？当人真的逐渐退出回路，又意味着什么结果？