往期文章：
这两年，所有的开发者都有一个共同的体会：AI 编程越来越高效，但人反而越来越累了。
借助 Cursor、Claude Code 这类 AI 编程工具与大模型，写代码正在变得前所未有地顺畅。不管是搭界面、对接口、写样板逻辑，还是死磕复杂的算法，AI 都能在眨眼间生成大段可用代码。
可以说，我们已经彻底告别了一行行手敲的"古法编程"。
但问题是，绝大多数团队，依然在用"古法测试"来验证 AI 写的代码。
代码生成的效率起飞了，但验证环节依然是个深不见底的"人力黑洞"：你要自己跑项目、盯报错、手动点页面、肉眼对 UI、截图存证、整理上下文，最后再把这些残局扔回给 AI 去修。这种"代码一秒生成，测试手点半天"的巨大割裂感，正是让我们感到身心俱疲的根源。
既然 AI 都能写代码了，为什么不能顺手把测试也给做了？
一、AI 测试引擎的"三大定律"
要真正解决"人肉测试"的痛点，我们需要的不只是一个"会写脚本的 AI"，而是一个全新的验证基建。
在我看来，一个真正合格的 AI 测试引擎，必须遵循以下三大定律：
- 定律一：意图与实现彻底解耦（Decoupling Intent from Implementation） 传统的 UI 自动化测试与 DOM、XPath 深度耦合，导致测试资产极其脆弱。AI 测试的输入必须直接源自 PRD、技术文档或自然语言，测试用例仅描述"业务意图（Intent）"，绝不绑定任何底层代码结构。前端的任何重构，都不应导致测试流程的阻断。
- 定律二：执行与判定必须物理隔离（Separation of Execution and Judgment） 鉴于大模型天然存在的"幻觉"现象，同源执行与判定必然导致系统性误判。真正的 AI 测试架构中，必须由 Runner 专职感知屏幕并执行动作，再由独立的 Judge 提取证据包进行校验。用严密的"机械约束"来驾驭不确定的 AI，是不可逾越的护栏。
- 定律三：自我进化（Self-Evolution） 这是 AI 测试与传统测试最本质的分水岭。传统脚本会随着代码迭代而逐渐"腐化"，但 AI 引擎应该在每一次的断言失败、人工纠偏和受控重试中，持续反向优化测试用例。它不再是一个静态的工具，而必须是一个越跑越准的自我进化系统。
然而，在工程落地时，完全满足这三大定律的代价往往极其高昂。 自动化测试属于极高频操作，如果每一次点击决策都依赖顶配大模型，算力成本将彻底阻断其进入日常 CI/CD 流水线的可能。
因此，**多模型 Agent 编排（Agent Orchestration）**成为了必然的破局之道。这也正是开源项目 Munk AI 的架构灵魂。而在目前所有的模型生态中，最完美契合这套编排理念的搭档，正是 Gemini 和 Gemma 4。
二、云端大脑 Gemini：提取业务意图，构建结构化测试计划
既然"定律一"要求意图与实现彻底解耦，那么测试系统的输入就不应再是底层的 UI 代码，而是人类真实的业务"意图（Intent）"------它们通常承载于 PRD（需求文档）、技术方案或是最新的代码 Diff 变更之中。
这正是 Gemini 的核心职责。在 Munk AI 的架构中，它扮演着 Plan Agent（规划者）和 Review Agent（审查者）的角色。它不参与任何底层的设备交互，而是专注于顶层的"脑力推演"：精准理解测试目标，并为下游制定出严格的测试约束。
在这一层，Gemini 的核心优势无可替代：
- 超大规模上下文的吞吐能力：它能一口气消化数万字的 PRD、变更摘要和代码库上下文，从中精准剥离出测试目标与边界风险。
- 极其稳定的结构化输出：测试引擎需要的绝不是一篇发散的分析报告，而是严格、可被下游机器无缝执行的结构化测试计划（RequirementPlan）。Gemini 在应对复杂 Schema 约束时表现出了惊人的稳定性。
- 高价值但低频的算力倾斜：生成测试计划属于一次性的前置工作。将这种"重逻辑推理、低调用频次"的重任交给最聪明的云端大脑 Gemini，实现了算力分配的全局最优解。
三、本地小脑 Gemma 4：跨模态感知，驱动高频测试执行
结构化测试计划有了，但谁来负责跑？
如果在执行阶段依然依赖云端顶配大模型，那么每一次看屏幕、找按钮、判断状态都需要发起一次昂贵的 API 请求。
这种架构在理论上很酷，但最终的账单会教你做人。
在 Munk AI 的架构中，真正负责执行落地的是轻量、敏捷的 Gemma 4。
作为 Runner Agent，它相当于系统的"本地小脑"。它不需要理解宏大的业务逻辑，只需要在受控的上下文中回答一个极其具体的问题："基于眼前的界面截图，我现在该点哪里，下一步做什么？"
- 将高频交互的成本彻底打下来：测试执行需要高频地感知屏幕并做出步级决策（Step-level decision）。Gemma 4 足够小巧，支持本地运行或极低成本的 API 调用，完美契合了"成本驱动的多模型编排"理念。
- 多模态感知（Perception）的降维打击：Gemma 4 并非直接去解析冰冷的底层代码。系统会先通过视觉模型（Vision）、OCR 和图标检测（Icon Detection）提取屏幕像素，并将其转化为结构化的 UI 语义喂给 Gemma 4。正是基于这种跨模态的感知链路，Munk AI 才能彻底抛弃 XPath，真正做到"像人一样看懂界面"。
结论很清晰：云端的 Gemini 负责"想得深"，本地的 Gemma 4 负责"跑得快、跑得起"。
四、如何驾驭不确定的 AI？构建"护栏闭环"
具备了聪明的规划大脑与敏捷的执行小脑，是否就意味着系统可以放任自流？答案是否定的。
大模型天然伴随着不可预期的随机性与幻觉。为了防止 AI 在复杂的 UI 交互中陷入死循环或凭空捏造结果，我们必须在架构上严格落实**"定律二：执行与判定物理隔离"**。这正是近期业内爆火的 Harness Engineering（驾驭工程） 的核心思想：用坚固的机械约束来驾驭庞大但不确定的 AI。
因此，Munk AI 引入了一套严密的护栏闭环：
- 受控的"执行者"（Runner）：基于 Gemma 4 的 Runner 每次只负责输出单纯的步级动作指令（如点击、滑动），确保系统状态机的流转严格受控。
- 独立的"裁判"（Judge） ：用例执行完毕后，完全独立的 Judge Agent 会介入。它不负责操作，而是基于完整的执行轨迹、DOM 树与屏幕快照等"物理证据"，冷静地判定测试是否真正通过。这彻底斩断了"既当裁判又当运动员"所导致的系统性误判。
- 携带上下文的纠偏重试（Retry Handoff）：遇到网络延迟或弹窗阻挡？系统不会盲目重跑，而是将"上一轮失败原因的诊断"作为上下文，发起一轮带有修正建议的受控重试。
而这正是定律三所呼唤的：自我进化（Self-Evolution）。
随着系统的持续运转，每一次失败的断言、每一次 Judge 的纠偏记录，都会作为高质量的语料沉淀下来，反向优化上游测试用例的表达。
这意味着， Munk AI 摆脱了传统脚本日渐腐化的宿命，成为一个越跑越准、测试资产越跑越优质的自我进化系统。
五、结语：逃离"古法测试"，拥抱 AI 验证新基建
AI Coding 的上半场，业界都在疯狂竞逐代码的生成速度；但下半场的胜负手，注定属于那些率先建立起 AI 时代验证基础设施的团队。
真正的 AI 自动化测试，绝不是一个套着大模型外壳的"高级脚本生成器"。
它必须遵循：解耦、隔离与进化的"三大定律"，成为一套能理解意图、能独立执行、能自我修正的工程闭环系统。
这也正是 Munk AI 诞生的初衷。
通过 Gemini 与 Gemma 4 的多智能体编排，我们将繁冗的机械验证彻底剥离，把开发者从"古法测试"的泥潭中解放出来，使其能将全部精力倾注于更高维度的架构与规则设计。
代码廉价的时代已经到来。现在，是时候把验证的权力交还给机器了。
如果你对这套 AI 自动化测试的新范式感兴趣，欢迎关注并参与 Munk AI 的开源建设。让我们一起，为未来的软件工程构筑最坚固的验证基建！
- 👀 探索最终产物 ：munk.sh
- ⭐ 关注 GitHub 仓库，见证项目的开源演进 ：github.com/chaxiu/munk...
- 🐦 关注我的 X/Twitter ：x.com/iBoyCoder
- 💬 加入开发者社群，探讨 AI 自动化测试的落地实践：关注公众号 @朱涛的自习室，获取进群方式；