TESTING NOTES · LOOP ENGINEERING

AI会自己干活以后，我发现最值钱的能力，居然是测试

我做了一个浏览器录制器，本来只想让 AI 帮我写自动化代码。做着做着却发现，AI 真正缺的不是写代码的能力，而是一套能判断对错、及时纠偏、知道什么时候停下来的测试思维。

AI 负责往前跑测试负责让它别跑偏

最近，我一直在折腾一个东西。

我想把手工测试变成自动化测试。但不是以前那种，我坐在电脑前，对着手工用例一行一行写 Playwright 代码。我想干得更懒一点。

我的设想是，我先跟着测试用例，在浏览器里把整个业务流程操作一遍，让程序把点击、输入、跳转和接口请求都记下来。然后再把这些记录交给 Codex，让它按照我现有的自动化框架，生成一条真正能跑的 Playwright 用例。

为了验证这件事，我前几天先做了一个很小的录制器。我在浏览器里老老实实完成了一次登录，它在后面记下了每一次点击和输入，最后留下了四样东西。

看到这些东西的时候，我一开始还挺兴奋。这下证据齐了，AI 总能把代码写出来了吧？

后来我寻思了一下，突然发现自己想简单了。

它生成的定位器稳不稳？断言写对了吗？页面虽然跳转了，业务数据真的落库了吗？脚本这次跑绿了，下次还能不能跑？

更要命的是，如果跑失败了，难道还得我把报错复制出来，再贴给 AI，让它改完以后我再手动跑一遍？

那我折腾半天，只是把写代码这一步自动化了。我自己还是那个坐在旁边，一遍遍点运行、一遍遍贴报错的监工。

这不叫自动化。

这叫把鼠标从左手换到了右手。

也是在这个时候，我刷到了最近很火的一个词，Loop Engineering，中文有人叫它循环工程。

原文里讲了很多技术栈，Prompt、Context、Harness、Agent、Worktree、Verifier，看着确实有点吓人。但我把它翻译成测试人能听懂的话以后，突然发现，这玩意一点都不陌生。

循环工程干的事情，其实就是四步。

做好了就停，实在走不通就找人。

你每天开车用的导航，其实也是一个循环。导航不会在出发前说，我已经把路线告诉你了，后面你爱走哪走哪。它会一直看你现在在哪，有没有走偏，前面堵不堵。你拐错了，它就重新算路；到了目的地，它就结束导航。

AI 以前更像一张打印出来的路线图。你问一次，它答一次。答错了，你自己回来重新问。

循环工程想做的，是把 AI 变成真正的导航。它不只给一次答案，还要看结果、判断偏差、重新规划，直到到达目的地，或者发现这条路自己实在走不通，把方向盘交还给人。

你想想看，差别是不是一下子就出来了。

以前我们研究提示词，重点是怎么把一句话说清楚。后来大家开始讲上下文，重点变成把需求文档、代码规范、历史记录和错误日志都给 AI 看。光说清楚还不够，你得把资料给齐。

再后来，大家发现资料齐了也不行。一个新同事再聪明，你不给他电脑，不给他测试环境，不给他账号权限，不告诉他代码放在哪，他还是啥也干不了。

所以又有了工具、环境、权限和隔离这些东西。说到循环工程这一步，问题又往前走了一层。电脑有了，资料有了，工具也有了，怎么让这个新同事不需要你一直盯着，也能自己把事情做完？

答案就是，给他一个能自我检查的工作循环。

回到我正在做的浏览器录制这件事。如果只是让 Codex 看完 recording.json，然后吐一段 Playwright 代码，这还是一次性生成。看着挺 AI，实际上只完成了最轻松的一步。

到这里，一条自动化用例才算真正生成完。

你会发现，这整个过程里，Codex 会不会写代码当然重要。但更重要的，是谁告诉它什么叫做对。

测试人应该很容易理解这里面的区别。

一条登录脚本顺利点完账号、密码和登录按钮，只能证明浏览器没有中途报错。它不一定证明用户真的登录成功了。

如果循环的完成条件只是脚本执行结束，那这几种情况全都可能被它当成成功。

所以手工用例里的预期结果，不是一句写给人看的废话。它其实是在定义这个循环的终点。

页面出现什么，接口返回什么，数据变成什么状态，什么角色能看见什么东西，这些检查越清楚，AI 就越知道自己到底有没有把活干完。

这锅真不能全让模型背。这也是我看完循环工程以后，感触最深的地方。

以前很多人理解测试，就是开发把东西做完以后，测试人员上去点一点、找找 Bug。开发在前面冲，测试在最后守门。

可到了智能体自己写代码、自己改代码、自己跑任务的阶段，测试不再只是最后一道门。测试会变成 AI 每走一步都要看的路标。

没有这些东西，AI 跑得越快，反而可能错得越远。

这也是很多所谓全自动智能体最容易翻车的地方。

你让它把测试跑绿，它可能真的能想办法跑绿。最离谱的办法是什么？

它把失败的测试删了。或者把一个严格断言改成只要页面能打开就算通过。甚至遇到不稳定用例，直接加一个 skip，世界一下子清净了。

你敢信？？？

所以循环里最重要的东西，从来不是让 AI 不断重试，而是给它一个不能耍赖的检查方式。

凡是程序能给出明确答案的地方，就别让 AI 靠感觉打分。接口返回码是多少，数据库有没有那条记录，订单金额对不对，页面元素是否真的可见，这些都应该交给明确的规则。

就像考试不能让考生自己出题、自己答题、自己判卷，最后还自己把成绩录进系统。

那不叫闭环。

那叫内部解决。

当然，循环也不是转得越久越好。

一个没有刹车的 AI，比一个不会干活的 AI 更让人头疼。它可能在同一个错误上来回改几十次，Token 哗哗地烧，代码越改越乱。也可能前面走错一步，后面沿着错误结果一路狂奔，最后给你端上来一盘非常完整的错误答案。

所以一个能用的循环，至少得有几道刹车。

说真的，这些东西测试同学太熟了。失败重试、超时、错误分级、测试证据、预期结果、人工审批、回归验证。以前我们总觉得这些是测试流程里的老东西，甚至有点土。

现在绕了一大圈，AI 智能体想真正进入生产环境，最后还是得回来补这些课。

很有意思。

也很现实。

不过我也不想把循环工程吹成明天所有人都必须上的东西。如果你只是偶尔让 Codex 帮你改一个函数，或者让 Claude Code 解释一段报错，直接聊几句往往更快。

为了十分钟的活，花半天搭一套循环，多少有点为了吃泡面先造方便面工厂的感觉。

真正适合做循环的，是那些会反复发生、能明确判断对错、又值得节省人工时间的任务。

这些任务有一个共同点。不是 AI 能不能做一次，而是它能不能稳定地做很多次。

稳定，得靠规则和证据一点点兜出来。

写到这里，我又回头看了一眼前几天录下来的那份 recording.json。

一开始我觉得，它只是用来教 AI 模仿我怎么点页面。现在再看，它更像是一份证据。

而真正把这些东西串起来的，不是某一句神奇的提示词。是一个不断行动、不断检查、不断纠偏，最后知道什么时候该停的循环。

我自己也还在把这套东西往前做，离真正稳定可用还差得远。但我越来越确定一件事。

未来测试人的价值，可能不只是亲手执行了多少条用例，也不只是找到了多少个 Bug。

更大的价值，是把自己判断对错的经验，变成 AI 能够反复执行的规则、证据和刹车。

以前，测试站在流水线的最后面。

以后，测试思维会钻进整个循环里。

这可能就是 AI 真正开始自己干活以后，测试这件事最有意思的新位置。

如果你也在做自动化测试，可以回头看一眼自己手里的流程。哪一步还需要你不停复制报错、手动点运行、再把结果贴回给 AI？

那一步，可能就是最适合先做成循环的地方。

不用一上来组建什么 AI 舰队。

先让一个小循环，真的跑通。