软件测试这件事成本一直在涨。根据 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 生成、架构设计、代码编写、本地部署、自动测试、缺陷修复的完整流程全程无需人工介入。Mano-AFK 全自动化应用构建Mano-AFK × Cider 本地加速端到端应用构建这套流程中最关键的环节是 E2E 测试阶段。在应用部署完成后系统调用 VLA 视觉模型去「看」这个刚建好的应用——打开浏览器、操作界面、验证功能是否符合 PRD 中定义的验收条件。流程拆开来看第一步需求到验收标准。PRD 自动生成时就包含了结构化的验收标准Given-When-Then 格式每条测试用例都能追溯到具体需求。这解决了一个常见问题——代码能跑但不符合需求意图。第二步多层测试覆盖。Lint 检查语法API 测试检查接口E2E 测试检查真实用户体验。三层递进最后一层是最接近真实使用场景的验证。第三步VLA 驱动的视觉验证。这是整条链路的核心差异点。测试命令长这样mano-afk runClick Add Category, fill in Food, pick green, click Save\--urlhttp://localhost:3000\--expectA 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-afkMano-P 项目Mano-P