软件测试这件事，成本一直在涨。

根据 Capgemini 2024 年的报告，全球企业 IT 预算中大约 23% 花在了测试和质量保障上。一个中型互联网团队，10 个开发配 3 到 4 个测试工程师是常态，再加上 QA lead、测试环境维护、自动化脚本更新、回归测试排期——测试占据了软件交付周期中相当大的比重。

这还只是显性成本。隐性成本更难量化：开发提交代码后等待测试反馈的空转时间，bug 单在开发和测试之间来回流转的沟通损耗，以及回归测试覆盖不全导致的线上事故。

自动化测试跑了十几年，痛点在哪

Selenium 2004 年发布，距今二十多年。这期间自动化测试工具层出不穷——从 Selenium、Cypress 到 Playwright，测试框架越来越好用，CI/CD 的普及也让自动化测试跑起来越来越方便。

但一个根本性问题始终存在：脚本写得再快，也跟不上需求变化的速度。

前端改了一个按钮的 class name，十几条 E2E 测试就挂了。后端加了一个字段，Mock 数据得全套更新。更尴尬的是这种维护工作往往没有新增功能优先级高，测试脚本年久失修是普遍现象。

还有一个更深层的问题：传统自动化测试验证的是 DOM 结构和 API 响应，但用户体验是视觉层面的。一个按钮的 API 能正常返回数据，可如果按钮被遮挡了、颜色和背景融为一体看不见了、或者渲染位置偏移了几十个像素——这些视觉层面的 bug，基于选择器的自动化测试根本抓不住。

视觉回归测试：方向对了，但还不够

这几年视觉回归测试开始流行，Applitools、Percy 这些工具通过截图对比来发现 UI 差异。思路是对的——把人眼看到的东西做成可量化的检测。

问题在于截图对比本质上是像素级或区域级的 diff。它能告诉你「这块区域有变化」，但不能理解「这个变化是好是坏」。换个主题色，整个页面截图全部标红，全是 false positive。动态内容（当前时间、随机推荐）更是让对比结果充满噪声。

核心矛盾是：截图对比缺乏语义理解。它看到了像素变化，但不知道用户在这一步期望看到什么。

VLA 模型带来的范式转移

VLA——Vision-Language-Action，视觉-语言-动作模型。这类模型的能力是：看到屏幕截图（Vision），理解当前上下文和任务目标（Language），然后输出下一步该做什么操作（Action）。

当把 VLA 模型用在测试场景里，它做的事情和人类 QA 工程师非常接近：

看到当前界面 → 判断是否符合预期 → 如果需要进一步操作就点击、输入、滚动 → 检查操作结果。

这跟传统自动化测试的区别在于，VLA 模型不需要预先写好定位器和断言。给它一段自然语言的测试指令——比如「点击添加按钮，填入类别名称 Food，选择绿色，保存，检查列表中是否出现」——它能像真人一样操作界面并验证结果。

选择器变了？没关系，模型靠视觉定位元素。布局调整了？没关系，模型理解的是语义而非坐标。这意味着测试脚本的维护成本大幅下降。

一个完整的实践：从代码生成到自动 QA

理论说完了，具体怎么落地？

明略科技开源的 Mano-AFK 项目提供了一个完整的参考实现。它的定位是全自动应用构建管道——从一句自然语言描述开始，走完 PRD 生成、架构设计、代码编写、本地部署、自动测试、缺陷修复的完整流程，全程无需人工介入。

这套流程中最关键的环节是 E2E 测试阶段。在应用部署完成后，系统调用 VLA 视觉模型去「看」这个刚建好的应用——打开浏览器、操作界面、验证功能是否符合 PRD 中定义的验收条件。

流程拆开来看：

第一步：需求到验收标准。 PRD 自动生成时就包含了结构化的验收标准（Given-When-Then 格式），每条测试用例都能追溯到具体需求。这解决了一个常见问题——代码能跑但不符合需求意图。

第二步：多层测试覆盖。 Lint 检查语法，API 测试检查接口，E2E 测试检查真实用户体验。三层递进，最后一层是最接近真实使用场景的验证。

第三步：VLA 驱动的视觉验证。 这是整条链路的核心差异点。测试命令长这样：

mano-afk run "Click Add Category, fill in 'Food', pick green, click Save" \
  --url "http://localhost:3000" \
  --expect "A category called Food with green color appears in the list"

模型实际执行的操作：截取当前屏幕 → 理解指令 → 定位「Add Category」按钮并点击 → 在输入框填入 Food → 选择绿色 → 点击保存 → 截取结果屏幕 → 判断列表中是否出现了绿色标记的 Food 条目。全程基于视觉感知，不依赖 CSS 选择器。

第四步：对抗性审查。 这里有个设计值得注意——系统里有一个独立的 Adversary Agent。它的职责是从 PRD 和源码出发，独立找出 Build Agent 可能遗漏的问题。让构建者和审查者分离，避免自测试的盲区。

第五步：自动修复循环。 测试失败后不是简单地生成报告等人来修。系统会自动读取失败日志，定位问题代码，生成修复方案，重新部署，再跑一轮测试。最多循环 10 轮，直到所有测试通过或者达到上限输出详细报告。

端侧 VLA 模型的工程优势

这套链路在工程落地时有个关键选择：VLA 模型是跑在本地还是云端？

Mano-AFK 默认使用 Mano-P 作为视觉测试的本地后端。Mano-P 是明略科技自研的端侧 GUI-VLA 模型，4B 参数量化后在 Apple M4 Pro 上解码速度达到 76 tokens/s，峰值内存占用 4.3GB。

本地运行意味着几件事：测试截图不会上传到第三方服务器（对涉及敏感数据的应用很重要）；不产生 API 调用费用（每次测试零成本）；不受网络延迟影响（本地推理延迟可预测）。

当然系统也支持切换到云端模式（Claude CUA），适合没有 Apple Silicon 的环境或者需要更强推理能力的场景。

经验持久化：越用越准

Mano-AFK 有个额外的机制：它维护了两个跨项目持久化的文件。

rules.md 记录从历史 bug 修复中提炼出的构建规则。比如某个 bug 经过了 3 轮修复才搞定，系统会把修复过程中学到的 pattern 写入 rules.md，下次遇到类似场景直接规避。

preferences.md 记录用户的风格偏好。配色方案、组件库选择、代码风格——这些随着项目积累越来越精确，构建出来的应用越来越接近用户预期，测试通过率也随之上升。

这种自我进化机制让整套系统的可用性随时间增长而提升，和传统自动化测试那种「写完就衰减」的模式形成对比。

这对测试工程师意味着什么

说回开头的成本问题。

VLA 模型驱动的测试管道不会让测试工程师消失，但会改变他们的工作重心。手动写 E2E 脚本和维护选择器这类重复劳动会大幅减少。更多精力可以放在测试策略设计、边界条件发现、以及验收标准定义上——这些才是测试工程的真正核心能力。

对于个人开发者和小团队来说，这类工具的价值更直接：独立开发一个应用时，再也不用在写完代码后切换到「测试人员」心态去手动点一遍每个功能。AI 帮你看、帮你点、帮你判断。

Mano-AFK 项目：mano-afk
Mano-P 项目：Mano-P