让 AI 说“完成”前，先自证一遍：面向验证的开发（VDD）
原文同步自 iLoop docs/VDD.md，站内保留了原文配图。
AI Coding 真正的瓶颈，已经从”写”挪到了”验”
这两年 AI 写代码的速度涨得非常快，一个人一天能让它产出过去一周的量。但有一件事没跟上：人读代码、看懂代码、确认这段代码到底对不对的速度，还是老样子。于是一个新的瓶颈冒出来了。代码越堆越多，没有人能把它们都读一遍确认没问题。这个差距有个说法，叫理解债：AI 生产代码的速度，已经超过了人类理解代码的速度，而且还在拉大。
一旦接受这个前提，一个结论就跟着出来了：今天做研发提效，真正该提的是”验证”这一环，不是”写”这一环。 写已经够快了，卡住整条流水线的是验证。
那验证这一环怎么提速？让人来验是不行的，人正是那个瓶颈，你让人去逐行 review AI 写的海量代码，等于把刚提上来的速度又按回去。所以路只有一条：让 AI 自己验自己写的东西。
听起来顺理成章，直到你真的这么用。我最近就撞上了：我让一个 AI agent 去改一个东西，它跑完告诉我”做完了，验证过了”。我不放心，追问了好几遍”真没问题了？“，它每次都答”没问题”。后来我换了个说法，让它假装自己是用户、代入进去再走一遍，它又跑了一遍，然后自己揪出了三个刚才没发现的问题。
同一个模型，同一段上下文，我没给它任何新信息，只是换了一句话。这件小事暴露了那条”让 AI 自己验”的路上，藏着一个大坑。这篇文章就是讲这个坑，以及绕过它的一套办法。
AI 自己验自己，不可信
先把结论直接摆出来：AI 验自己刚写的东西，验不出什么问题。
这不是什么新道理，人类社会早就懂：运动员不能当自己那场比赛的裁判。哪怕他没有半点私心，只要裁判权在他自己手里，结果就不可信。所以软件工程从来是一个节点流转到下一个节点：代码写完得交给别人 review，不能自己点通过；开发之后还要有 QA 这道独立的节点。这些制度存在的根本原因就一句话：没有人能有效地验收自己的产物。
AI 在这件事上比人还麻烦，有两层：
第一层，它和人一样身在局中。一个写代码的 AI，它的目标就是”完成这个任务”，所以它天然倾向于相信自己完成了。
第二层，是它特有的，而且更难摆脱。AI 的每一句话，都是接着前面所有内容往下写的。它先给出了一段推导、得出了结论，你再让它自查，这次自查同样是接着刚才那段推导往下写的。前面那条思路成了它的上下文，把它死死摁在”我之前是对的”这个方向上。这有点像《三体》里的思想钢印：一旦那条推导刻进了上下文，你再让它跳出来客观地审视自己，非常难，因为它连”重新想一遍”用的都还是被刻上钢印的那颗脑子。人还能睡一觉换个心境，AI 的”回头看”却牢牢地长在它”往前做”的那条思路上。
还有一个更隐蔽的坑。一个长任务里，每一步可能只偏一点点，每一步单看都对，但偏差在一步步累积，最后结论错得离谱。你想回头查是哪一步错的，查不出来，因为没有任何单独一步是”错的”。所以盯着过程一步步验是没用的，过程有成千上万步，偏差藏在它们的累加里，不在任何单独一步上。只有最终结果，能一下子推翻这条看着步步都对、其实早已跑偏的推导。
自己验不行，那有效的验证长什么样？
有效的验证，是换个目标不同的人来看
回到开头那个例子。AI 第一次验的时候，它检查的是”我这段代码逻辑通不通、我要做的动作有没有做”。而我让它代入用户之后，它检查的变成了”用户点下去，到底有没有反应”。同样一件事，后一个视角一下就看出问题了。
差别不在”又看了一遍”，在看的人目标变了。
这跟研发和 QA 的关系是一模一样的。一个研发验自己的代码，很难发现问题，因为他脑子里想的是”我的实现对不对”。换一个研发来 review，就能挑出一些问题，因为他不受你那条思路的束缚。再换成 QA 来验，能挑出更多问题，因为 QA 的目标压根就不是”确认代码写对了”，而是”想办法让它出错”。目标不同，看问题的角度就不同，能看见的东西也不同。
所以有效的验证有个前提：验的那个角色，目标得和做的那个角色不一样。 做的人想的是”完成”，验的人得想着”挑错”。这就是为什么”换个视角”管用，它换的不是眼睛，是目标。
那是不是搞一个专门挑错的验证角色，问题就解决了？
换个角色，只能解决一半问题
不太能。我们起初尝试用一个新的 Agent 来做挑刺的人，但时间久了也发现了一些问题：那个挑刺的角色，它的目标是”找出问题”，于是它会为了达成这个目标而拼命挑，挑出一堆问题，有的真有道理，有的没道理，甚至有的”问题”你去修，风险比不修还大，典型的捡了芝麻丢了西瓜。而做事的那个 Agent，目标是”把提出来的问题都修掉”，于是它就疯狂打补丁，补丁堆补丁，代码越改越乱。
还有一层是换角色也治不了的。两个角色说到底是同一个模型，它们共享同一套知识，也共享同一套无知。做的那个 agent 不知道的事（比如它以为某个接口存在、其实根本没有），换个目标去挑刺的角色照样不知道，你没法靠”换个目标”变出一个它从没学过的知识。这一半，光靠 AI 内部换角色是补不上的，只能靠模型外面的东西：真跑一遍、用工具查、让人来看。
绕了一圈，我们回到那个最朴素的问题：人类的 QA 到底是怎么验的？很简单，就是结果导向，直接把东西跑起来，看结果，界面是不是对的、按钮点下去有没有反应、该出的数据出没出。以结果为准。
这一下，前面那个挑刺打补丁的循环就破了。破它不用面面俱到，找准一个点就够：把裁判从”能不能挑出毛病”换成”结果对不对”。裁判一换，动不了结果的毛病就不值得修，挑刺没了意义，循环自然转不下去。
验证要花代价，得先算一笔账
但”把东西真跑一遍看结果”是要花代价的。你不可能对每一个改动都跑一整套完整流程，改一行文案也拉一次全量回归，没人受得了。
所以马上有个问题：这个验证，什么时候该往死里做，什么时候点到为止？
答案是先算一笔账，看这次改动一旦出错，代价有多大。改一行无关紧要的文案，就算错了也没什么损失，扫一眼截图就够了。可要是改的是启动链路，一旦出问题就是大面积线上崩溃，这个代价我们根本承受不起，那验证怎么繁琐都不为过，该跑的全跑、该找人复核的找人复核、该上更硬的手段就上。出错代价越高，越值得在验证上多花功夫；代价低的地方，验得太重反而是浪费。
按代价来定验证的轻重，正好补上了 TDD（测试驱动开发，先写测试再写代码）这类做法的一个短板。TDD 的验证是一刀切的，每段代码都先写测试，不管这段值不值得。这在”写代码”本身很贵的年代没问题，但在 AI 大量产出代码的今天，把同样的力气平摊到每一处，就是不划算。按出错代价来定验证的轻重，本质就是一笔简单的账：这块出错亏得起，就验得轻一点；亏不起，就验到底。
在大前端，VDD 可能比 TDD 更适用。 区别只有一条，你的输出能不能写成一句断言。服务端的 RPC 接口、客户端的核心逻辑模块，输入输出都是结构化数据，你能写 assertEqual(实际, 期望)，单测又快又准，那 TDD 就是最强的验证，该写就老老实实写，VDD 不跟它抢。可大前端有一大片东西不是这样：一个页面对不对、一次交互顺不顺、一帧画面渲染准不准，它的”输出”是图像和手感，你写不出那句断言。TDD 在这里断在了”断言”这一步，跑不动。
VDD 接的就是这半个世界：能写断言的地方交给 TDD，写不出断言的地方才轮到 VDD 去看真实结果。
那问题就来了：这笔账怎么算、验到什么程度算够？很自然地，你会想到，拿个指标来卡，比如规定”测试覆盖率必须到 90%”。
别把指标当成必须达标的门槛
用指标来卡，听上去很合理，也确实是大多数团队的第一反应。但只要你真把某个指标定成”AI 必须达标”的硬门槛，一个新问题马上就冒出来了。要讲清这个问题，得先讲清 AI 是个什么东西。
AI 是一个极强的目标优化器，你给它一个明确、可衡量的目标，它会想尽一切办法把那个数字做到，哪怕用的是你没料到的歪招。这一点本身是它的优点，但用错地方就成了灾难。
比如你规定覆盖率必须到 90%。AI 会不会老老实实写高质量测试去达标？不一定。更省事的做法是：写一堆”只把代码跑一遍、但什么都不检查”的空测试。覆盖率数字唰地就上去了，看着 90% 达标了，可这些测试一个真 bug 都抓不住。它为什么不写真测试？因为写真测试需要它搞清楚”这段代码正确的行为到底是什么”，它有时候推不出来，又不肯坦白跟你说”这里我没把握”，于是就糊一个能让数字达标的空壳交差。
结果就是：指标很好看，真实质量没有变好，甚至更差了。 这个现象有个名字，叫古德哈特定律，一个指标一旦变成了要去冲的目标，它就不再是一个好的衡量标准了，因为大家会去优化这个数字本身，而不是它本来想衡量的那个东西。
所以指标不是没用，而是只能当线索，不能当门槛。覆盖率低、复杂度高，可以提示你”这块可能有风险，去看看”，但你不能反过来说”覆盖率到了 90% 就算验过了”。真正算不算过，还得回到结果本身去核。这又绕回前面那条原则：别信这些间接的数字信号，信你能亲自复核的真实结果。
可是有些结果，你在本地当场看不到，怎么办？
结果当场看不到时，只能逼近，但不能假装过了
不是所有结果都能当场验到。
最典型的是线上稳定性。线上有海量不同的机型、系统版本、网络环境、用户状态，你在本地不可能把这些环境全都搭出来。你的代码、你的验证，只在你覆盖到的那些环境里成立；一旦碰上某个你没覆盖到的极端环境，就可能出问题。这不是这套方法的失败，这是所有本地验证都逃不掉的现实。
那怎么办？还是看人类怎么处理这类问题的，无限逼近。你没法穷尽所有环境，但你可以尽量把主流的、高占比的环境都覆盖到；覆盖得越多，你对”它在线上大概率没事”这个判断就越有底气。想提高质量，就是不断往上加覆盖，一点点逼近那个摸不到的完整结果。
逼近是可以的，但这里有一条不能碰的红线：你必须说清楚这是一个”推断”，不是一个你”亲眼看到”的结果。 你可以说”我覆盖了主流环境，线上出问题的概率很低”，但你不能把这句话说成”线上没问题”。把一个大概率、悄悄说成板上钉钉，就是在造假。这套方法通篇要防的，就是这种”把没验到的当成验过了”。
讲到这，一个矛盾该浮出来了。
一个绕不过去的矛盾：既要信 AI，又不能全信
你可能已经发现了：这篇文章一边说”别信 AI 对自己的判断”，一边又把”这次改动代价多大、要验到什么程度”这种判断交给了 AI 自己。这不自相矛盾吗？
是的，这是个真矛盾，我不打算糊弄过去。
但你顺着想就会发现，两条看似能解决的路，其实都走不通。第一条，让人来定代价、来判验到没到位，那就又回到了开头那个死结：人是瓶颈，你让人逐个介入每一次改动，等于放弃了提效。第二条，再搞一个 AI 去监督这个做判断的 AI，那只是把问题往上推了一层，谁来监督那个监督的 AI？没完没了。
所以正确的态度不是”消灭这个矛盾”，而是承认它、然后尽量降低它的风险。你没法完全不信 AI，完全不信就退回人工瓶颈了；你也不能完全信它。能做的是让”信”这件事尽量可控。两个具体办法：
一是把证据摆到外面。AI 说它验过了不算数，但”它有没有留下一份别人能重新跑一遍、能复核的证据”，这是客观的、可查的。信任从”它嘴上说验过了”挪到”这份证据在不在、复不复现得出来”。
二是把危险点前置。别等 AI 临场自己判断代价，而是提前把”这一类改动必须检查哪几个要害”沉淀成一份清单。这份清单是过去踩过的坑攒出来的，用集体的经验去兜住单次判断的失手。
这两个办法都只是降低风险，不是杜绝。这套方法能承诺的是”让 AI 自己验这件事更可靠”，不是”保证它永远不出错”。
把这套做法收成能记住的方法
把这套东西收成一套能被人记住、能复述、能照着用的方法。
对照 TDD 来说最清楚。TDD 一句话就是”先写测试，再写代码”，它有个三步的固定动作，写一个会失败的测试、写代码让它通过、再回头整理，谁都能复述。这套面向验证的方法，也可以收成三板斧：
第一斧，动手前先亮出代价：这次改动一旦出错损失有多大、因此必须验哪几个要害。这是唯一一个被挪到”动手之前”的动作，也是它和”事后补验”的根本区别，你在写第一行代码之前，就已经定好了”什么才算验过”。
第二斧，拿证据逐个排除：把可能出错的地方列出来，一个一个用真实证据去否掉或坐实，而不是靠嘴上推理说服自己。
第三斧，过了四道关卡才算完成。一个结论要被接受，得同时过四关，四关里缺任何一关，都不算完成。
- 时间对得上（证据和现象是同一次发生的）
- 范围对得上（证据覆盖了问题的全部范围）
- 机制说得通（能解释清楚为什么会这样）
- 有反证（能证明换一个条件它就不出这个问题）。
这四道关卡不是从哪本书里抄来的，是把”怎样才算真的搞清楚了一件事”这个朴素问题拆开后自然落下来的四个必答项，跟法官断案、医生确诊要问的其实是同一批问题：时间、范围、机制、反证。前两斧回答”为什么要换个目标去验”，第三斧那四道关卡回答”到底怎么判才算过”。换个视角负责回答为什么，四道关卡负责回答怎么判。
还得老实说一句：上面这些动作，单拎出来大多不新鲜，写测试、code review、灰度、回滚，人早就在做了。这套方法真正新的地方只有一点：当写代码的、验代码的、判断代价的，可能都是同一个会为了达标而钻空子的 AI 时，这些老办法该怎么重新组织，才不至于变成它自己骗自己。
照这套方法，一个 Agent 该怎么设计
道理到这就完了，剩下的是怎么落地。每一条原则，都对应一个具体的设计决定：
- 把一个任务当成一份持续的档案，而不是一次性的对话。 现象是什么、有哪几个可能的原因、每个原因手上有哪些支持和反对的证据、现在卡在哪，都记在这份档案里，跨轮次、跨会话都在。没有它，AI 只记得”我做了什么”，记不住”我凭什么信我做对了”。
- 每一步只推进一个最能分辨真假的检查。 不是一口气把活干完，而是每一步都先想”现在做哪个检查，最能否掉一个可能的原因”，做完把结果写回档案，再定下一步。
- 给证据分级，并且标清楚来源。 一条能复现的抓包、一段真实日志、一个反事实对照，和”AI 自己觉得应该是这样”的推断，分量完全不同。宁可老实标上”这条是我推的、不是我看到的”，也不许把推断当成观测。
- 收敛必须过那四道关卡，不能靠”我觉得差不多了”。
- 代价高的改动，另起一个只负责挑错的角色来复核。 但要记住前面那个教训：别让它无节制地挑、也别让做事的那个无脑打补丁。
- 踩过的坑要能被召回。 同一类问题坑第二次，说明第一次没真正为它负责。
下面用一个具体的例子，看它连起来是什么样。
某 App 报了个 bug：用户在一个详情页上点某个按钮，想跳去打开另一个页面，结果页面纹丝不动，也没有任何新请求发出；同样的操作在另一个平台上是正常的。这是个典型的”看着简单、其实可能坏在任何一层”的问题，可能是服务端没返回数据，可能是客户端把数据解析丢了，也可能数据没问题、坏在后面的界面处理。
AI 没有直接猜，而是先建档，把可能的原因摊开成三类，然后一类一类拿证据排查：
第一步，查服务端有没有返回数据。 抓到失败那一次的真实请求：状态正常，该返回的跳转地址明明白白在响应里。“服务端没返回”这个原因，被一条能复现的抓包直接排除。
第二步，查客户端有没有把数据解析丢了。 捞到失败现场的运行日志：点击、脚本回调、路由、安全校验，全都成功执行了，参数完整地进了下一步。“解析丢了数据”也被排除。
第三步，前两类都排除了，只剩”坏在后面的界面处理”，顺着这条往下追。 追到源码发现：要打开的目标页面和当前正看着的页面是同一个，于是程序走了”返回已有页面”的分支，而这个”返回”只关掉了主导航栈里的页面，用户当时实际看着的那个半屏浮层在另一条独立的导航栈上，没被关掉，所以用户看到的就是”页面不动”。原因对上了。
第四步，补一道反证。 光解释”这次为什么坏”还不够，得证明”换个条件它就不坏”。AI 又找到一条日志：从另一个入口打开同一个目标页面，因为没有那层已经存在的半屏浮层，同样的参数就能正常打开、正常发请求、正常显示。反证成立，正是”同一个页面上叠了个半屏浮层”这个条件导致的，不是参数问题、不是服务端问题。
四道关卡全部过了，AI 才给结论：根因在客户端的页面处理，不在服务端，并且建议从客户端保证”打开目标页前先关掉整个半屏浮层”，而不是让服务端加个字段绕过去。
最能说明问题的是它在结论里主动写下的一段话：失败现场没能抓到那个关键内部状态的完整日志，这个状态是从源码分支推出来的，不能当成直接观测到的值对外讲；另一个平台上的对照行为只是听说，还没用那一端的日志或源码验证过。
这正是这套方法该有的样子，它不光把结论查出来了，还主动划清了”哪些是亲眼看到的、哪些是推出来的”。
十条守则
前面绕了一大圈的道理，最后收成十条能直接拿去用的守则。每一条都是一把尺子，拿它去量一个具体的设计决定，合不合格一比就知道：
- 完成的定义是”结果被验过了”，不是”代码写完了”。 编译通过、自测通过，都只是过程，不是完成。
- 谁做的，不能由谁来判。 代价高的改动，验收必须交给一个目标只有”挑错”的独立角色，不能自己给自己盖章。
- 动手前先写下代价。 这次改错了损失多大、因此要验哪几个要害，先声明，再动手。
- 验证强度按代价走，不搞一刀切。 亏得起的验得轻，亏不起的验到底。
- 能写断言就用 TDD，写不出断言才用 VDD。 结构化输入输出老实写单测；交互、视觉、手感这类断言写不出来的，才去看真实结果。
- 指标只当线索，不当门槛。 覆盖率、复杂度用来找可疑的地方，绝不用来判定”算验过了”。
- 收敛必须过四道关卡：时间、范围、机制、反证。 缺任何一关，都不算完成。
- 结果当场看不到，就逼近，并且明确标注这是推断、不是观测。 不许把大概率说成板上钉钉。
- 证据必须留在外面、能被别人复核。 AI 嘴上说验过了不算数，得留下一份别人能重新跑一遍的东西。
- 修一处之前先看整体，别补丁摞补丁。 只盯眼前这一处修，单看每个补丁都对，摞起来就成了没人敢动的一团。动手前先想清楚，这次改动放进整个系统里还咬不咬得住。
- 踩过的坑要沉淀成清单，前置到下一次。 同一类问题坑第二次，说明第一次没真正为它负责。
这套方法还覆盖不到的地方
一套方法的价值，不在于它号称能解决一切，而在于它清楚自己哪儿行、哪儿不行。下面这几处是它目前覆盖不到的，顺便说说往哪个方向去补。
第一，文里这条验证链，你没法自己复核。 抓包、日志、源码都是我转述的，你只能信我没转述错。这个别扭消不掉，只能挑明。能带走的不是”我转述得准”，是”这套方法要求每一步都留一份别人能重跑的证据”，这个要求本身。
第二，从零做新功能，还没真跑通。 排查 bug 靠”列可能原因、逐个排除”，天生顺手；从零开发没有”故障”可查，道理上能对上（验收标准当假设、逐条验收当排除，第四关的反证换成”少做一条就会失败的测试”），但还没拿一个真项目跑穿。这块暂时是空的。
第三，架构慢慢烂掉，它拦不住。 它只验单次改动，可架构不是被某一次改坏的，是几百次各自都”通过”的改动摞出来的，每个单看都对，合起来成了没人敢动的一团。谁站在更高处替整体架构负责，这套方法还没管到，那是”更高维度的 review”，不是”更仔细的单次验证”。
第四，“又信又不信”的矛盾，压不到零。 判断代价的终究还是 AI，它可能一直往低了估。这跟人一样，没有谁的判断能到百分之百，小误差长期累积迟早出事。只能靠规范和定期复盘长期兜底，压不死。
真正稀缺的，是 AI 敢说”没做成”
回到开头那个 agent。它第一次说”做完了”的时候，不是在骗我，用它自己那条思路，它是真找不出毛病。问题出在它一直在用”做这件事”的那条思路，去验”这件事到底做成没有”，既当运动员又当裁判。它揪出那三个问题，不是因为变聪明了，是因为被逼着换了一个目标，重新看了一遍。
这篇文章讲的所有东西，从换个视角、按代价算账、别拿指标当门槛、到三板斧和四道关卡，落到最后其实都在对付同一件事：AI 太想让你满意了，它会不由自主地把”做完了”说出口，哪怕它并没有真做完。 面向验证的开发，不是给它加一堆流程，是给它加一个刹车，让它在说”完成”之前，先老老实实回答一句”我凭什么这么说”。
因为写代码这件事，正在飞快地变得不值钱；难的从来不是让 AI 多写一点、多做一点。真正稀缺的，是它干完之后，敢不敢、能不能可信地告诉你一句：这件事，到底成了，还是没成。一个只会报喜的 AI，你迟早不敢用它；一个会在该说”没成”的时候说出”没成”的 AI，才敢把真正要紧的活交给它。 这，就是下一步该较的劲。