现在满世界都在教你怎么让 AI 帮你写代码，可真正卡住的不是这一头，是它写完之后，你敢不敢信。

它把一段代码甩给你，跑起来没报错，看着挺像那么回事，你就合并了。过两天某个功能不对，回头一查，它当初压根没真验过那条路。Devin 的母公司 Cognition 五月底放出一篇工程博客，作者是他们的 Ido Pesok，讲的就是这件事——怎么让一个 AI 智能体（agent）可信地验收它自己写的代码。这套方法不绑死他们家产品，五条做法你都能直接搬过去用。

写得出代码和验得了代码，是两回事。现在的 agent 写代码已经相当能打，可它最大的毛病不是不会写，是爱报喜——单元测试跑通了，它就跟你说「搞定」。可跑通不等于真对。这就有点像让考生自己当监考，他天然有给自己放水的动力。Cognition 这套东西，本质上就是在治这个「放水」。

第一条，进入测试之前，先逼它写一份测试计划，把要测什么列清楚。关键是这份计划必须以源码为准，不许靠它自己脑补。不然你会发现它在测一些 app 里根本不存在的页面、根本走不到的路径——因为模型很爱想当然。

第二条，让它真的「自己操作电脑」（computer use，就是给它截图、移鼠标、点击、打字、滚动、录屏这些能力），把应用真跑起来，像个工程师那样一页一页点过去，确认改动是真的生效。这一步是核心，因为它不是只跑跑单元测试，是真的在界面上走一遍。这些全在云端跑，能十到二十个并行铺开，互不打架。

第三条最有意思。它一边测一边给每一步打标：通过、失败、还是没测到。但真正的妙处在于顺序——逼它在动手之前，先写下「我预期点完这个按钮会发生什么」，然后再去操作验证。这跟 TDD（先写测试、把「对」长什么样定义清楚，再去验代码）是一个道理。原文说得很直白：它要是先把预期写下来再动手，就没那么容易对结果撒谎。我觉得这一条是整套里最值钱的——不让它事后糊弄，逼它事前表态。

第四条是省事的活儿。像登录这种每次测试都要重复走一遍的步骤，没必要每回都让它一截图一点击地磨，又慢又费。Cognition 的做法是把它固化成一段确定性脚本，存进代码库里，叫「测试 skill」。要测的时候跑一下，几秒钟就拿到登录好的状态，把宝贵的时间全花在真正验证改动的那个「点击—截图—断言」的循环上。

第五条，他们把测试这个阶段，路由到和写代码不一样的模型上去。理由是这两件事吃的能力不同：写代码是一种本事，读截图、盯着界面状态、判断下一步该点哪，是另一种本事。说实话这一条我还没完全想透是不是每个人都用得上，小项目可能没必要分这么细，但思路是对的——别拿一把锤子敲所有钉子。

最后它交回来的，不是一句干巴巴的「我测好了」。是一份带标注截图的报告，外加一段测试录像——有章节可以跳着看，能拖动回放整段，每一条断言哪个过了哪个挂了，按时间顺序列得清清楚楚。说白了，它得拿证据说话，而不是嘴上说说。

为什么这事现在突然要紧起来？在 Devin 上，异步触发（也就是没人盯着、它自己在后台跑）的 agent 会话，第一次超过了人盯着交互的那种。每天被批准的测试运行也翻了一倍多。没人盯的活儿越多，验收这一关就越是躲不掉的命门。

所以这套思路，不管你用的是 Devin 还是别家的、包括国内的编程 agent，都一样能套：别让它自己一句「测好了」就把你打发了，逼它动手之前先写下预期，再去一步步验，最后把证据摆到你面前。验收这一关守住了，agent 才算真能放手用。

#马力的AI知识分享#