ARTICLE · 1035808
测试全过≠软件能用:Agent 时代验证该怎么做
如果一张图概括 vibe coding 时代的质量困境，大概就是这张：一辆自行车，两个车轮都是方形的，每个方形轮子上都印着巨大的绿色对勾——All tests passed. 底部一行小字：Still a bad design.
测试全过，产品还是坏的。这不是段子，是 2026 年 AI 大量产出代码之后，越来越多团队撞上的真实处境。
有人在 X 上把这个话题聊透了。@yaogangqiang 连发三条推文聊测试与质量，@yetone（avante.nvim 作者）引用其中一条，总结成一句：大 CI/CD 时代已经来临！
本文转述这条讨论的主线，再结合 2026 年开源社区的实际动作，聊聊验证这件事正在发生什么变化。
一、vibe coding 把代码产量顶上去了，质量没跟上
@yaogangqiang 的第一条推文说的很直白：
随着 vibe coding 产出大量代码，大部分项目质量并没有提高。整个软件研发历史里，写代码一直是最容易的环节，有了 AI 之后，只是让这个环节变得更容易了。
他甚至转述了一个创业公司的声音：因为 bug 太多，有朋友说"我觉得可能人肉写写代码，稍微长期来看，速度更快，因为现在天天修 bug"。
代码越来越便宜，bug 越来越贵——这个剪刀差就是当前 AI 编程落地的核心矛盾。
二、只靠测试不能保证软件质量
二、只靠测试不能保证软件质量
他的第二条推文开头说了句关键的话：
上一条说，只靠测试不能保证软件质量。
注意，这不是"测试没用"的意思。后半句是："这条先聊也应该怎么写测试，因为这是基础。下次聊关键设计，以及 review 应该看什么。"
Test the outcome
Test the outcome
配图是一张更扎心的咖啡机漫画：AI 机器人的测试清单上，Pump ✓、Heater ✓、Button ✓ 全绿，但咖啡机没有出咖啡，端着空杯的用户满脸问号——But where's my coffee?
Test the outcome.
部件都测过了，结果不对，等于白测。测试要写，但更重要的是测对东西：测用户要的"结果"，而不是只测"部件存在、能跑通"。
三、测试写对了，下一个瓶颈是 CI 本身
第三天，他补了一条评论区里被问爆的问题——测试跑得慢、CI 资源消耗大：
我负责的研发团队，一天上线 50 次，一天至少要跑 300 轮测试。在测试写对的基础上，怎么跑得更快、更省，可以尝试从这几个地方处理。
Vibe coding 时代代码产出翻倍，测试轮数跟着涨，"验证"从边缘活儿变成了吞吐瓶颈。这也是为什么 @yetone 会引用这条，说出那句总结：
大 CI/CD 时代已经来临！
四、行业在做什么：给 Agent 的验证闭环
2026 年开源社区对"AI 写代码怎么验证"这件事，已经长出了实打实的工具。两个方向最值得看：
1. 用视觉模型跑端到端验证
Agent Labs 开源了 a-test：让 Agent 在模拟器上"像用户一样"测试 App。核心循环是——截屏 → 发给视觉模型看 → 模型返回要点的坐标 → adb 执行点击/输入 → 循环。
它想解决的是 Espresso 这类传统 UI 测试的盲区：测试按 ID 找到按钮、点了、断言过了，但动画还在播、按钮根本没响应，真实用户早就放弃了。Espresso 看的是元素树，不是用户看到的画面。而视觉模型看渲染后的帧，按钮没响应它看得出来，加载转圈它读得懂，UX 挂了测试才挂。
它还内置了一个"防幻觉"验证步：Agent 循环跑完说 done 不算过，再用一个不带上下文的全新视觉调用确认"用户真的登录进 Dashboard 了吗"，答 no 就 fail。确定性断言（uiautomator dump 出来的 XML 上 grep 关键文案）和 LLM 判断并存，最后把每步截图拼成 GIF 传上 CI，PR 评论里直接看。
2. 把模拟器/真机变成 Agent 的验证工具
Callstack 开源了 agent-device，定位就是 mobile app automation and verification for AI coding agents：给写代码的 Agent 一个"在真机/模拟器上验证自己改动的闭环"。
它让 Agent 读无障碍树（accessibility snapshot）而不是硬猜截图，用 ref/selector 去点、填、滑，每一步留截图/视频当证据。支持 iOS、Android，也包括 HarmonyOS（走 HDC + ArkUI uitest），能接 Claude Code、Codex、Cursor 等，也能在 CI 里用 replay 脚本跑回归，还能连 BrowserStack / AWS Device Farm 这些远程设备云。Shopify、Expensify 的团队已经在用它验证 App。
五、模拟器的发展方向：从"调试玩具"到"验证基础设施"
把这两条线索放在一起，模拟器的角色正在肉眼可见地转变：
以前，模拟器是"开发者手里调试用的玩具"——人看着屏幕点一点，确认效果。
现在和以后，模拟器越来越像 CI 里跑验证的"服务器"——无头启动、命令行驱动、可并行、不进测试就跑 300 轮那种集群。方向大概是四条：
对鸿蒙开发来说这特别值得注意：agent-device 已经支持 HarmonyOS，走的正是 hdc + uitest 这条路。无头模拟器 + Agent 验证闭环，不是设想，是正在发生的事。
个人观察
这场讨论最扎心的地方在于：AI 时代最稀缺的不是写代码的能力，是"判断代码对不对"的能力。
测试帮我们判断"部件对不对"，设计 review 帮我们判断"方向对不对"，CI 帮我们判断"合进来对不对"——每一层都是在给 AI 这匹快马套缰绳。而模拟器从玩具变成基础设施，正是这套缰绳里最关键的一环：让验证能跟上代码的产量。
测试全过，不等于产品能用；Test the outcome，验证要跟上产码的速度。
原文信息
觉得有用？点「在看」让更多同行看到 ↓
📌 关注「和弦代码」，跟踪 AI 开发工具与工程实践的解读