TestStar | 为什么 AI UI 测试进了生产就“崩“？一个最被低估的层面

为什么 AI UI 测试进了生产就"崩"？一个最被低估的层面

一份基于真实项目的 AI 测试平台复盘。这个系列我会从架构、Token、自愈、记忆、知识库几个角度，把踩过的真坑写出来。关注我，系列持续更新。

引子：测试工程师的两难

我做过一个不严谨的统计：在我能接触到的 12 个中型研发团队里，UI 自动化测试的"信任度"全部低于 50%。

这是什么意思？意思是说，当 CI 报红的时候，一半以上的研发不会第一时间去看测试报告，而是直接重跑。他们不相信失败信号。失败的代码改动、失败的环境抖动、失败的浏览器升级、失败的 testid 缺失——这些都会被同一片红色徽章覆盖住。研发团队用行动投了票：他们不再相信 UI 测试。

这不是一个孤立现象。Google、Microsoft 都有公开数据，业界共识是 flaky tests（飘红用例）会吞噬 QA 工程师 20-30% 的工作时间。一个团队花 100 小时写出的 UI 自动化脚本，其中 25 小时是被它自己造成的混乱吃掉的。

所以，过去十年，整个行业都在寻找"银弹"：

• 我们试过把 Selenium 换成 Playwright——更快、更稳一点，但没解决根本问题。
• 我们试过录制回放工具——Selenium IDE、Katalon——开始很爽，越改越痛苦。
• 我们试过契约测试、Pact、API-only——放弃了 UI 测试，但放弃了"用户视角"。
• 我们试过自愈工具——Healenium、Mabl、Testim——看起来更聪明了，但维护成本只是换了个地方。
• 然后，2023 年开始，我们试过 AI。

AI 来了，故事却出现了一个反直觉的分裂：

本地 demo 跑得 9/10，生产大规模跑只有 6/10，甚至不到。

这是 TestStar 团队在 2026 年 8 月做 Tier 1 稳定性验证时，被现实检验后写下的判断（来源：内部 Tier 1 验证报告）。也是这篇文章想认真讨论的核心命题。

我不想在这篇文章里再讲一遍"AI 改变测试"的宏观叙事。我想讨论的是：当 AI UI 测试从 demo 走向生产时，到底卡在哪？

我会在三个递进的命题上展开：

为了把这三个命题讲透，我会用 TestStar 这个真实项目做案例。它不是 Midscene 的替代品，不是另一个开源框架，而是 在 Midscene 之上做编排 + 自愈 + 记忆的"平台层"。代码规模超 2.2 万行 Python 后端 + 超 1 万行原生 JS 前端，覆盖一条从"用例生成"到"自愈修复"到"知识沉淀"的完整链路。它的所有数字都来自真实跑过的实验，包括那些失败的、跑挂的、不得不回滚的。

如果你正在考虑把 AI 引入测试流程，或者已经试过一个 AI 测试工具、效果却不如预期——这篇里的很多问题，你应该也会遇到。

一、传统 UI 自动化的"原罪"

要理解 AI UI 自动化为什么会出现，我们必须先看清传统 UI 自动化为什么会失灵。这不是为了怀旧，而是因为 AI 测试的很多设计取舍，其实是在回应传统工具的原罪。

1.1 选择器脆弱性：DOM 一改，全线崩溃

传统 UI 自动化的核心假设是：测试可以通过精确的"路径"找到要操作的元素。这个假设在 2010 年之前的 Web 2.0 时代还勉强成立，因为页面结构相对静态，前端框架主要是 jQuery。

但 2015 年之后，React/Vue/Angular 三大框架普及，前端进入"组件化 + 状态管理"时代。一个按钮今天挂在 #root > div:nth-child(3) > button，明天版本升级后可能就变成了 #app > main > section > button。选择器像寄生虫一样依赖宿主——宿主一重构，寄生虫死一半。

而另一个问题是，测试代码和业务代码共用同一个 DOM 结构——但两者的演化节奏完全不同：

• 业务代码：每周迭代，组件重构是常态
• 测试代码：每季度迭代，维护成本压在少数 QA 身上

结果就是：测试代码永远是业务代码的"考古学证据"——你从选择器里能读出产品三年来的演化史。

行业曾经试图用各种"稳定选择器"来缓解：

• data-testid 属性：让前端给测试"留后门"
• role / aria-label：用语义化属性定位
• text 匹配：用按钮文字定位

这些方案在小规模项目里有效，但在大型项目里都会遇到同一个问题：前端开发不愿意给测试写专属属性，因为他们认为这是"污染业务代码"。这是组织问题，不是技术问题。

1.2 Flaky Tests 的黑洞：20-30% 的时间被吞噬

"飘红"是 UI 自动化测试最顽固、最常见的问题之一。一个飘红的测试用例意味着：同样代码、同样环境、同样输入，今天过明天挂，没有规律。

飘红的来源极其分散：

• 时序问题：浏览器还在加载动画，测试就开始找元素了
• 网络抖动：测试服务器响应慢了 200ms，整个链路 timeout
• 动态内容：广告弹窗、cookie 横幅、A/B 实验随机展示
• 测试顺序依赖：用例 A 创建的数据，影响用例 B 的查询
• 浏览器版本差异：本地 Chrome 124，CI 是 Chrome 120，同一段脚本表现不同
• Docker 时区问题：跑在容器里的 date() 返回 UTC，与本地时区不一致

Microsoft Research 在 2017 年的一项研究里给出过惊人的数据：业界大型代码库里，flaky tests 的"修复-复发"周期平均是 4.5 天。一个 QA 工程师发现自己刚修好的用例又飘红，在大型代码库里不是意外，而是常态。

这种状态真正损害的往往不是技术债务，而是信任债务：

• 飘红第一次，研发会去看
• 飘红第二次，研发会重跑
• 飘红第三次，研发会禁用
• 飘红第四次，研发会说：“这测试有问题，别信它”

一旦测试失去信任，它就死了。代码还活着，但没人看了。

1.3 隐性盲区：Canvas、iframe、自定义控件

传统 UI 自动化有一个根本性的物理限制：它只能看见 DOM。

这意味着以下场景全是盲区：

• <canvas> 元素：游戏、可视化图表、富文本编辑器、白板工具——所有画在 canvas 上的东西
• <svg> 元素：图标、矢量插画、动态图表——DOM 里只是一个空壳
• <iframe> 跨域内容：第三方登录、广告位、嵌入式组件
• 自定义控件：用 <div> + CSS 模拟的 <select>、<input type="date">，没有 ARIA 标注
• shadow DOM：Web Components 隔离的子树，外部选择器无法穿透
• 图标按钮：只有图标的按钮，DOM 上没有文字，依赖 alt/tooltip

更讽刺的是，越是现代的 Web 应用，这些盲区越多。React 生态里大量组件库（Material-UI、Ant Design、Tailwind UI）都会把原生控件改造成自定义控件，因为设计师觉得原生太丑。

结果是：传统 UI 自动化测试覆盖率最高的产品，恰恰是视觉上最朴素的产品。一旦产品做了一定程度的视觉创新，自动化就开始失明。

1.4 CI/CD 集成的天然摩擦

本地跑得好好的用例，放到 CI 里就挂。这种故事每个测试工程师都讲过十遍。

根因是 CI 环境的特殊性：

• headless 模式：没有显示设备，浏览器需要虚拟帧缓冲，本地正常的行为可能异常
• 时区：CI 容器默认 UTC，依赖时间判断的脚本会出错
• 字体：CI 容器里没有本地字体，渲染结果像素级不同
• 分辨率：headless 默认 800×600，本地是 1920×1080，元素位置全部变了
• 资源限制：CPU/内存配额低，浏览器启动慢、动画卡顿
• 随机数：很多"随机"行为其实是伪随机的，CI 的 seed 不一样结果不一样

更隐蔽的是**“本地能跑、CI 飘红、研发放假了没人看”**这个组合。很多团队的真实情况是：CI 报告每周才有人看一次，飘红的用例要等周一才会被发现，到那时已经没人记得改了啥。

1.5 视觉断言的"先天无能"

传统 UI 自动化有一个容易被忽视的限制：它能验证 DOM 状态，但验证不了"用户看到的东西对不对"。

举个例子：

一个购物车页面，"结算"按钮的 DOM 上是存在的，但颜色被 CSS 错配成透明色，用户看不见。

传统自动化会通过——按钮在 DOM 上、能点击。但用户根本没法用。

另一个例子：

一个列表页，第一行因为 CSS bug 被遮盖了，但 DOM 上数据是对的。

传统自动化也会通过——行存在、字段值正确。但用户看到的是空白。

这种"DOM 存在 ≠ 视觉正确"的鸿沟，是传统自动化永远跨不过去的，因为它的眼睛是结构化的（DOM 树），不是视觉化的（像素）。

1.6 录制回放的陷阱

为了降低 UI 自动化的门槛，业界曾推出大量"录制回放"工具：

• Selenium IDE
• Katalon Recorder
• UI.Vision RPA
• BrowserStack 低代码平台

这些工具的工作模式都是：用户在浏览器里点几下，工具自动生成脚本。看起来完美解决了"写脚本难"的问题。

但用过的人都知道：录制回放的脚本维护成本远高于手写。

原因很简单：录制工具生成的脚本是"扁平"的，每一步都依赖上一步的精确位置。一旦页面结构变化，整个流程都需要重录。而手写脚本至少可以抽象出 Page Object 模式、组件复用，把易变部分和稳定部分分离。

录制回放还有一个更现实的局限：它让"写测试"这件事变得没有心智模型——开发者不知道为什么这次能点中，下次点不中，因为背后是黑盒。这恰恰是软件工程最忌讳的"无模型"。

1.7 行业的几种应对

面对这些问题，行业形成了四条主流应对路径：

路径一：换工具。从 Selenium 迁移到 Playwright，因为后者架构更新、API 更现代、原生支持 headless。但本质问题没解决——还是 DOM-based。

路径二：加自愈。Healenium、Mabl、Testim 等工具在选择器失败时自动尝试其他策略（AI 推测、视觉相似度、属性组合）。有效，但只是"延缓症状"。

路径三：转 API。放弃 UI 测试，把验证下沉到 API 层。这是 Martin Fowler 长期鼓吹的方向。对很多团队来说是务实选择，但对"用户视角"是一种放弃。

路径四：引入 AI。也就是我们今天讨论的主题。

二、AI UI 自动化：理想与现实的鸿沟

2023 年开始，多模态大模型的爆发让"AI 看见屏幕、点击按钮"成为可能。最早的产品是 Adept ACT-1，后来字节跳动的 Midscene.js、OpenAI 的 Operator、以及一批开源项目（Browser-Use、Skyvern、Self-Operated-Computer）相继涌现。

故事一开始很美好：“用自然语言描述，AI 自动操作浏览器”。

• “点击登录按钮”
• “在搜索框输入 iphone”
• “断言页面出现价格 ¥5999”

这种 DSL 太香了。写测试的门槛大幅降低，测试工程师从"找元素"变成了"写意图"。

但是，2025-2026 年间，行业开始面对一个现实：AI UI 测试在本地 demo 里几乎完美，在生产大规模跑里却问题重重。

2.1 Demo 9/10，Production 6/10

这是 TestStar 在 Tier 1 验证里实测出的差距（内部验证报告）：

注意一个反直觉点：第一次生产跑（Run6）的 token 是 54K，跟本地 cache 命中一样。这说明 token 本身不是问题，问题是——

Run6 失败的原因不是 AI 不准，而是"AI 的判断"和"系统的判断"不一致。

Run6 的 exit_code 是 None，子进程其实成功跑完了，但 worker 线程被记忆写入卡死，DB 写不进去，API 返回 None。这是典型的"工具能跑但平台撑不住"。

这种"工具 vs 平台"的张力是 AI UI 自动化走到生产时的最大障碍。Skyvern 团队在自己的博客里也承认（虽然它本身也是执行引擎方）：

“Browser-Use is great for demos and experimentation, but may require careful error handling and prompt engineering for production reliability. Skyvern is built for production environments where reliability, observability, and scalability matter most.”（来源：Skyvern vs Browser-Use 对比）

2.2 幻觉与不稳定：模型"看到"不存在的元素

AI UI 测试最让人抓狂的特性是幻觉。

具体表现：

• 模型"看到"页面上有一个不存在的按钮
• 模型"记错"了刚才的操作，明明点过了却以为没点
• 模型"误解"了页面布局，把侧边栏当成主内容
• 模型"丢失"了上下文，连续操作 5 步后忘了前 2 步干了啥

这些幻觉在大模型时代并不新鲜，但用在 UI 自动化上有特殊杀伤力：因为一次幻觉就会让整个用例失败，而且失败模式跟真实 bug 难以区分。

此外，模型在某些场景下会出现"自信的幻觉"——它坚定地认为某个元素存在，并继续基于这个错误假设操作。这种错误比"犹豫"更难发现，因为日志看起来一切正常。

2.3 Token 成本：480K tokens / 6 分钟的实测

这是很多 AI 测试宣传里不会讲的部分：token 成本是结构性问题，不是优化能解决的。

一条 19 步的用例，第一次跑就烧掉约 48 万 token、99 次调用、6 分钟。按 2026 年价格折算单次 ¥3-5，一次不算贵，但要算生产规模：

• 1000 个用例 × 每天跑 2 次 = 每天 2000 次
• 2000 × ¥3 = 每天 ¥6000 → 一个月 ¥18 万

这个数字没有任何测试团队承担得起。所以 cache 不是"锦上添花"，是生产化的前提。

接入 cache 后，token 降到 54K（省 88.7%）、调用降到 16 次（省 83.8%）、耗时降到 114 秒（省 68.9%）——单次从 ¥3 变成 ¥0.34，月成本从 ¥18 万压到约 ¥2 万。这是从"实验室玩具"到"商用基础设施"的分水岭。

• 结果：成功

从 ¥3/次变成 ¥0.34/次，每月成本从 ¥18 万降到 ¥2 万。这是从"实验室玩具"到"商用基础设施"的分水岭。

2.4 复杂流程掉链子：登录风控、动态渲染、Canvas

AI UI 测试在简单场景下表现惊人（打开百度、搜个词、截图），但在真实业务流程里经常掉链子：

登录风控：很多产品在 AI 检测到自动化行为时会触发验证码、滑块、短信验证。AI 面对这种"反 AI"的机制毫无办法——它没有真人的环境。

动态渲染：瀑布流、虚拟列表、懒加载，AI 在第一次截图时常常拍到的是空白，必须反复滚动等待。但"等待多久"是个开放问题。

Canvas / WebGL：AI 看见了像素，但不知道像素代表什么。游戏、数据可视化、白板工具是 AI 测试的"无人区"。

多步跨页：登录 → 列表 → 详情 → 表单 → 提交，AI 每一步都有可能因为幻觉累积而偏移，最终到达一个完全不同的状态。

Skyvern 团队在自家博客里承认这一点（虽然视角是 Skylvern 自家更擅长）：

“Both [Browser-Use and Midscene.js] are open-source AI browser automation tools. However, there are gaps in production readiness, observability features, and enterprise-grade error handling in both.”（来源：Skyvern vs Midscene.js 对比）

2.5 Prompt 敏感：一字之差行为大变

这是 AI 测试最反直觉的特性：同一个意图，不同的 prompt 表达，行为差异巨大。

举个例子，对 Midscene 而言：

• “点击登录按钮” — 可能点中
• “点击登录” — 可能点不中（因为页面上有"登录账号"、"立即登录"等多个匹配）
• “点击页面顶部右上角的蓝色’登录’按钮” — 通常更稳，但 token 也更多

更麻烦的是这种敏感性没有规律：

• 今天 “点击登录” 能成功
• 明天模型升级，“点击登录” 失败
• 改回 “点击登录按钮” 又成功

这意味着 AI 测试用例的回归测试本身就是个难题。你以为 prompt 没改，但模型版本变了；你以为 prompt 改了，但模型返回的策略变了。

2.6 可观测性缺失：跑挂后黑盒

传统自动化失败时，QA 至少能看到：

• 选择器报错：“element not found: #submit-btn”
• HTTP 请求日志
• 截图（在断言前自动截的）

AI 测试失败时，看到的常常是：

• “assertion failed”
• 一份 JSON 报告
• 一堆 AI 思考过程的文本（但这些文本可能是编造的）

AI 测试的失败信号是自然语言，而自然语言本身就有歧义。"AI 没找到按钮"和"按钮被遮挡"和"按钮根本没渲染"在 AI 输出里看起来差不多。

TestStar 团队对此的解法是结构化日志 + 分层展示：

• 原始 Midscene 日志（step/agent/ai/plan/task/cli 六类日志文件）
• 失败时的标准化错误摘要
• 自愈过程的 diff 弹窗（人类语言 + diff 高亮）
• SSE 流式日志，让 QA 实时看到 AI 思考过程

但这是事后补救。从根本上看，AI 决策的"黑盒性"是结构性的，不是工程能完全解决的。

2.7 三大主流工具对比

聊到 AI UI 自动化，绕不开三个名字：Browser-Use、Midscene.js、Skyvern。

注意：这个对比高度依赖搜索结果，而 Skyvern 的官方博客占据了搜索结果大头，所以我对对比结论保持谨慎。但 “执行引擎会趋同、差异在 Harness 层” 这个判断是确定的。

2.8 92% 项目踩的 4 个感知模块设计盲区

2026 年一篇关于 AI Agent 感知模块的研究（来源：CSDN 技术博客）指出：

“92% 的 AI Agent 项目在感知模块的设计中踩了 4 个隐性设计盲区：跨模态注意力坍塌、时间戳漂移积累、对抗性鲁棒性悬崖、动态环境遗忘。”

翻译成 UI 测试的语言：

• 跨模态注意力坍塌：AI 同时看截图和 DOM 时，容易被某种信息源主导，另一种被忽略
• 时间戳漂移：AI 不知道"刚才的截图"和"现在的页面"已经不一致了
• 对抗性鲁棒性：某些特殊设计的页面（极端颜色对比、隐藏元素）让 AI 完全失效
• 动态环境遗忘：长流程中 AI 忘了前面的状态，做出前后矛盾的决策

这 4 个盲区在 demo 里几乎不会出现，但在生产规模里会以指数级放大。

三、Harness Engineering：被忽略的胜负手

讲完传统 UI 自动化的原罪和 AI UI 自动化的鸿沟，是时候讨论本文的第一核心命题了：

单独一个 AI 浏览器工具，不足以构成"AI 测试平台"。真正的胜负手在它们之上的 Harness 层。

3.1 执行引擎 ≠ 平台

我观察到一个现象：很多人把 Midscene、Skyvern、Browser-Use 这些工具等同于"AI 测试平台"。这是严重的认知错误。

它们本质上是执行引擎——负责"把自然语言翻译成浏览器操作"。就像数据库的存储引擎、虚拟机的指令执行器一样，是一个底层能力。

但"测试平台"需要的不只是执行：

• 失败兜底：跑挂了怎么办？重试？放弃？人工介入？
• 自愈：失败的原因是 AI 出错还是产品改动？能修复吗？怎么修？
• 可观测：失败时人类能复盘吗？能定位吗？能归因吗？
• 重试与幂等：网络抖动需要重试，但怎么避免重复点击付款按钮？
• 记忆与沉淀：今天失败的经验，明天能不能用上？
• 调度与编排：1000 个用例怎么排？哪些优先？哪些可以并发？
• 知识与配置：哪个按钮在页面的什么位置？登录流程有没有"陷阱"？

这些能力全部都不在执行引擎里，必须由上层的 Harness 提供。

3.2 Harness 层的定义

借鉴 2026 年奇点大会披露的 “From SQL to Self-Healing Agent” 路线图（来源：CSDN），我们可以把 Harness 层定义为：

┌─────────────────────────────────┐
│ Harness 层 │
│ 失败兜底 · 自愈 · 重试 · 记忆 · │
│ 可观测 · 调度 · 知识 · 告警 │
└─────────────────────────────────┘
↓ 封装
┌─────────────────────────────────┐
│ AI 执行引擎（任选） │
│ Midscene / Skyvern / Browser-Use│
└─────────────────────────────────┘
↓ 调用
┌─────────────────────────────────┐
│ 浏览器 / 操作系统 │
└─────────────────────────────────┘

Harness 层是"工具"和"平台"之间的分水岭。没有 Harness 层，AI 测试永远停在 demo；有 Harness 层，AI 测试才能进入生产。

3.3 从 SQL 到 Self-Healing Agent

2026 奇点大会披露了一个有意思的对比：

这个对比揭示了一个范式跃迁：

• 传统范式：人写规则，机器执行。规则失败，人修复。
• 新范式：人描述意图，AI 执行规则，AI 自愈规则。

新范式的关键不是"AI 更聪明了"，而是"AI 能自我修复"。自愈能力才是 AI 测试与 AI 自动化的本质区别。

3.4 生产失败率 30% → 99%：Harness Engineering 的承诺

2026 年一篇关于 “AI Agent Harness Engineering 任务失败率过高” 的技术文章（来源：CSDN）给出了一个惊人的数据：

“Local demos typically succeed 9 out of 10 times, but production environments see dramatic drops. Production failure rates can exceed 30%, and sometimes more than half of agent tasks fail to complete.”

并提出一个工程框架，目标是把生产失败率从 60% 拉到 99%。这个框架的核心是：

这五条，就是 Harness Engineering 的全部。

3.5 为什么单独一个工具不够

回到执行引擎视角，你会发现：

• Midscene：纯视觉驱动，自愈能力是"重试 + 重新理解页面"，没有持久化记忆
• Browser-Use：以 demo 为目标，没有生产级别的可观测性
• Skyvern：自带工作流持久化和 CV+HTML 双模态，但缺乏跨用例的知识共享机制

没有一个执行引擎能解决所有问题。这是合理的——它们是引擎，不是平台。

真正的差异化竞争发生在 Harness 层：

• 谁能把失败分类做得更准？
• 谁的自愈闭环能跑通？
• 谁的知识库能积累得更厚？
• 谁的可观测性能让 QA 信任？

这是 TestStar 押注的方向，也应该是所有想"做 AI 测试平台"的团队押注的方向。

3.6 从工具到平台的关键跃迁

我见过的一个典型教训是：

一个团队花 3 个月评估了 5 个 AI 测试工具，最终选了"看起来最像 demo 的那个"。半年后他们发现工具能跑但平台撑不住，又花了 6 个月自研 Harness 层，总计 9 个月才达到稳定状态。

如果他们一开始就把"Harness 层"作为评估标准，决策会完全不同：

• 这个工具的失败信号能不能结构化？（决定自愈能不能做）
• 这个工具的日志能不能被外部订阅？（决定可观测性）
• 这个工具的执行过程能不能被干预？（决定自愈闭环）
• 这个工具能不能被外部知识增强？（决定知识库）
• 这个工具的 API 能不能纳入调度系统？（决定规模）

这五个问题的回答，比"哪个工具能跑通 demo"重要得多。

四、TestStar 实战（一）：分层架构与三个核心指标

讲完了行业判断，我用 TestStar 这个真实项目做案例，演示 Harness 层的具体设计。

TestStar 的整体定位是：

基于 Midscene（字节开源的视觉驱动浏览器引擎）构建的 AI Native UI 测试平台。它不是自研执行引擎，而是在 Midscene 之上构建的编排层 + 自愈层 + 记忆层。

代码规模：

• 后端：超 2.2 万行 Python（FastAPI）
• 前端：超 1 万行原生 JS（SPA，无框架依赖）
• 子系统：核心编排引擎（执行 / 自愈 / 记忆 / 知识）、LLM 代理层、执行服务层、数据校验、多端设备农场

4.1 整体架构

TestStar 是典型的三层结构：前端 Web 控制台（仪表盘、用例工坊、套件调度、知识库、自愈界面）→ 中间后端服务（核心编排引擎、LLM 代理层、执行服务层）→ 最底层拉起 Midscene CLI 驱动浏览器，去操作被测应用。存储用 SQLite 或 PostgreSQL，另可接一个记忆服务（知识库）做语义检索。

整个架构的核心思想：不自研浏览器驱动，做编排层。

为什么不自研？因为浏览器驱动的工程量是天文数字。Chromium 本身就有 3000 万行代码，加上视觉模型、多模态理解、DOM 操作封装，自己做需要几十人年。TestStar 选择站在 Midscene 这个"中等水平、调试体验好、有字节背书"的巨人肩膀上，把工程力量集中在 Harness 层——这才是差异化所在。

4.2 Token 与稳定性双指标体系

判断一个 AI 测试平台能不能商用，最关键的两个指标是：

• Token 消耗：决定能不能规模化
• 稳定性：决定能不能信任

TestStar 在 Tier 1 验证（2026-08-10，内部验证报告）里，用一条真实业务用例（登录 → 进 SQL 控制台 → 输 SQL → 执行 → 断言，19 个步骤）连续跑了 8 次。token 从首次的 480K 一路降到 cache 命中后的 54K，耗时从 367 秒压到 114 秒，最后一次只花 65 秒——从最初的失败，一步步跑到稳定通过。

关键数据（从 Run1 到 Run7）：

• Token 节省 88.7%（480K → 54K）
• AI 调用次数节省 83.8%（99 → 16）
• 耗时节省 68.9%（367s → 114s）
• 修后用例成功率 100%（5/5）

这四个数字不是孤立优化的结果，而是 cache + 工程卫生 + 自愈 的整体效果。

4.3 执行引擎的几个设计取舍

执行引擎是后端体量最大的模块，几个取舍值得读者知道：

决策一：用子进程拉起执行，而不是进程内调用。 好处是隔离——Midscene 一旦崩溃不会拖垮整体（跑测时真崩过一次）；超时能强制终止（900 秒）；出问题时能按 PID 排查。

决策二：日志边跑边推。 传统 CI 是"跑完一起看"，AI 测试则适合"边跑边看"——QA 能实时判断 AI 是不是跑偏了，必要时人工介入。

决策三：启动时回捞中断的任务。 服务如果跑着跑着重启，会自动把没跑完的标记为异常，不丢结果。

决策四：只判结果，不判"为什么"。 执行引擎只负责判断这次跑没跑通，不为 AI 的每一步决策做解释——可解释性是另一道题，不该在这层硬啃。

4.4 CI Smoke 接入（P1-3）：从"实验室数字"到"生产数字"的桥

这是 TestStar 在 Tier 2 收尾阶段做的关键工程：让 AI 测试真正接入 CI 流程。

交付物（2026-08-10）：

• 一个 CI 冒烟脚本：启动服务、采集 KPI（自愈率 / token / 耗时）、校验关键开关、返回退出码
• CI 配置里在常规测试之后多加一个 “CI smoke” 步骤

端到端验证：

• 2 suites / 88 runs
• 36% 成功率
• 自愈控制功能正常，CI 通过（exit 0）

真实的工程价值：

很多人不理解"36% 成功率"意味着失败。这是误解。对一个新集成的 AI 测试平台，第一次跑 CI 出现 36% 成功率是正常的。重要的是：

未来 2 周的真实数据积累，才是这个 CI 接入的真正价值所在。

4.5 关键判断：什么时候不能用 TestStar

诚实地说，TestStar 不是万能的。以下场景我们承认做不好：

• Canvas / WebGL 应用：游戏、可视化、白板
• 强风控页面：验证码、滑块、行为检测
• 极短用例（< 5 步）：cache 命中收益不抵启动开销
• 跨域联邦登录：OAuth、SAML 等多步跳转
• 强动态 SPA：每次刷新 DOM 完全重排

判断标准：如果你的应用是"表单 + 列表 + 详情"为主的中后台系统（OA、CRM、运营后台、BI 平台、数据查询控制台等），TestStar 适用。如果是"游戏 / 视频 / 直播 / 工具型 App"，不建议用。

五、TestStar 实战（二）：自愈层，从"失败即停止"到"失败即学习"

如果让我在 TestStar 的所有能力里只保留一个，我会保留自愈层。

自愈层是 TestStar 与"普通 LLM 自动化测试"的分水岭。没有自愈层，它就是个 wrapper；有自愈层，它才是个 platform。

5.1 失败分类器：分门别类地理解失败

自愈的第一步是理解失败。TestStar 的自愈模块里有一个失败分类器，把失败分出门类：

• 8 类核心失败：等待超时、网络不可达、找不到元素、断言不成立、页面结构变了、登录态失效、数据被污染、陷入死循环——每类配一条默认对策（超时就延长等待重试，网络就退避重试，找不到元素就深度重定位）。
• 再加上 6 类根因（环境偶发、死循环、数据累积、登录失效、前置数据缺失、连坐失败）和 2 类兜底（无法归类、主动跳过）。

加在一起 16 类。不是越多越好——分类太粗，策略不精准；太细，分类本身就不准（证据不足以区分）。16 类是拿 8 个真实失败样本试出来的平衡点，单测 8/8 判对。

5.2 自愈闭环流程

分类完成后，进入自愈主流程：

┌──────────────┐
│ 失败信号 │
└──────┬───────┘
↓
┌──────────────┐
│ 失败分类器 → 输出（失败类别, 修复策略） │
└──────┬───────┘
↓
┌──────────────┐
│ 根据策略选分支： │
│ • 深度重定位 → deepLocate + 模型降级 │
│ • AI 诊断 → LLM 诊断 + 上下文注入 │
│ • 直接重试 │
│ • 标记跳过 │
└──────┬───────┘
↓
┌──────────────┐
│ 诊断（L0-L4 分层 + 6 类陷阱 + 修复纪律）
└──────┬───────┘
↓
┌──────────────┐
│ 修复（AI 生成 YAML patch）
└──────┬───────┘
↓
┌──────────────┐
│ 置信度门控（高置信自动应用，否则人工审核）
└──────┬───────┘
↓
┌──────────────┐
│ 重试（应用 patch 后重新跑）
└──────┬───────┘
↓
┌──────────────┐
│ 固化（成功后写入新版本 / 沉淀失败记忆）
└──────────────┘

5.3 置信度门控：不是所有修复都自动应用

自愈最怕两件事：AI 把对的目标改错、或把一个用例的修法错用到另一个用例造成回归。但 100% 交给人工又看不过来。

TestStar 的解法是置信度门控：AI 每次修复都给出一个置信度，够高就自动应用；不够就弹窗交给人审——附上具体改了什么（diff 高亮）和为什么这么改（自然语言）。

5.4 深度验证数据：60% 总体 / 100% 可修复

2026-08-10，团队用 5 个故意失败的用例实测。结果很能说明问题：两类纯物理失败（网络完全不可达、1 秒极限超时）合理放弃——它们本来就不该救；三类可修复失败（元素定位、断言更新、元素改名）全部救回。

• 总体救回率 3/5 = 60%
• 可修复失败救回率 3/3 = 100%

5.5 "诚实>虚增"原则

60% 这个数字看上去不漂亮，但这是 TestStar 团队故意选择公布的。

如果虚增到 80%，掩盖的事实是：

• 网络不可达不该救（是网络问题，不是测试问题）
• 1s 极端超时是测试设计错误，不该救

救不回有救不回的理由，跟"AI 不够强"是两回事。把这些"本就不该救"的失败计入统计，是不诚实的。

TestStar 团队明确写下这个原则：

“诚实 > 虚增。60% 是诚实水平，虚增到 80% 会掩盖’物理失败本就不该救’的事实。”

这个原则在 AI 测试领域尤其重要，因为：

• AI 测试本身就是"不确定"的
• 客户和团队对 AI 测试的信任，本来就脆弱
• 用虚增的数据建立信任，一旦翻车，全盘皆输

5.6 deeplocate 落入 AI 诊断的优化

早期版本的「深度重定位」分支有个 bug：deepLocate + 模型降级都失败后，直接放弃，没有给 AI 诊断机会。

这导致一种常见 case 救不回：元素改名了，deepLocate 用旧名字找不到，模型降级也没找到，但 AI 诊断可能能给"用新名字"或者"按位置定位"的建议。

修复后：

• deeplocate 失败后不再直接放弃
• 落入「AI 诊断」分支（LLM 诊断 + 上下文注入）
• LLM 有机会用更灵活的方式修复

这个改动让 case2（element）和 case5（rename）从救不回变成救回。

5.7 错误提取的"假错误"识别

自愈有个隐藏陷阱：AI 修复基于的"错误信号"可能是错的。

TestStar 早期版本遇到过这种问题：日志里有这样一行：

“Continue on error: skip summary-xxx.json”

AI 看到 “error” 字样，把它当成失败原因，开始诊断。但真实失败原因在另一行。

修复方案：加一层"真实错误提取"——从 Midscene 日志里只扫真正的错误行（如 waitFor timeout、Assertion failed 开头的行），排除 Continue on error 这类配置行。

这是一个看似细节但非常关键的工程——自愈的前提是失败信号可信，否则越修越乱。

5.8 自愈可控

自愈层上线后，一个自然的产品问题是：用户能不能关掉它？

有些场景下用户不想自愈——关键金融场景错一个都不能容忍、调试期想看真实失败不要被修复掩盖、或想让失败真实沉淀给模型训练。TestStar 的自愈做到了可被全局开关、可按团队风险偏好灵活调节，并提供端到端验证。

• 关闭自愈 + 失败用例 → 日志明确跳过自愈，不触发 ✅
• 开启自愈 + 失败用例 → 走深度重定位 → AI 诊断（约 1.5 万字符上下文）✅
• 三个配置随运行记录持久化到 DB ✅

5.9 手动触发自愈 + diff 弹窗

除了自动自愈，TestStar 还提供手动触发自愈：

• 缺陷面板上的"AI 诊断"按钮（确认后触发，结果回显并刷新）
• 手动触发自愈的 API：从运行记录读取用例与错误，再走完整自愈流程

自愈详情通过 diff 弹窗展示：

• 元信息（成功/失败/尝试/置信度）
• AI 自然语言
• diff（带颜色高亮）
• 关闭方式：X 按钮 / 点击遮罩 / ESC

这个弹窗是"AI 决策可解释"的一次工程实践。AI 不是黑盒，它的每个修复都有"为什么这样改"的解释（自然语言）和"具体改了什么"的 diff。

5.10 自愈层的真实边界

承认自愈层的局限：

能救的：

• 元素改名 / 位置移动（DOM 结构变化）
• 断言条件更新（数据范围变化）
• 网络瞬时抖动
• 数据累积导致的污染

不能救的：

• 网络完全不可达
• 服务器 500 错误
• 验证码 / 风控拦截
• 产品本身有 bug
• 测试用例本身逻辑错误（比如断言了不存在的东西）

AI 测试自愈不是万能解药，但它能把"60% 的失败变成通过"，把"剩下 40% 的失败变成有结构的缺陷报告"。这是从"混乱"到"有序"的质变。

六、TestStar 实战（三）：记忆与知识，从"一次性测试"到"持续进化的智能体"

讲完执行引擎和自愈层，本文第三个核心命题要登场了：

执行引擎会趋同，差异化最终落在"谁记得更多、谁沉淀得更准"。

TestStar 的记忆系统，底层是记忆存储，上面包含三种记忆内容（Wiki 页面知识、Skill 经验、失败教训）。

6.1 记忆存储：语义检索优先，本地降级

记忆存储有两种做法：接一个语义检索后端（能模糊查"上次是怎么失败的"这类经验，生产可用但有运维成本），或者就用本地文件（简单可靠、部署零成本）。TestStar 做成"语义检索优先、接不上自动降级到本地文件"——演示时零依赖能启动，生产能上语义检索，还能灰度切换。

6.2 记忆写入别阻塞主流程

实现上踩过一个大坑：每跑一次用例，记忆要同步写入一批记录，结果把执行线程卡死，服务一度全接口 404——AI 跑成功了，但结果写不进库、接口返回空。这就是"工具能跑但平台撑不住"。

修复很简单：把写入挪到独立后台线程，主流程不等它——写入先排进队列、立刻返回，后台慢慢落库；搜索类读取仍保持同步（自愈和查询依赖它，不能异步）。验证下来，主流程耗时从约 10 秒降到 0ms。

这个修的不只是性能，它验证了一条原则：

任何在请求路径上的同步阻塞，都可能让整个平台卡死。

这条值得写进每个 Harness 层的"反模式清单"。

6.3 三种记忆：Wiki / Skill / 失败记忆

TestStar 的记忆分三类，对应不同的生命周期：

Wiki 知识（持久化）：

• 页面元素的结构化描述（11 elements schema）
• 业务流程的"陷阱"清单
• 失效模式的人工标注

Skill 蒸馏（从成功用例提炼）：

• 多次成功的步骤组合
• 高频有效的操作模式
• LLM 总结的"经验"

失败记忆（累积）：

• 每次失败的指纹（错误类型、上下文）
• 失败时的 AI 思考
• 最终修复方案

三种记忆的价值不同：

• Wiki 是"知识"：告诉 AI “这个按钮在页面顶部”
• Skill 是"经验"：告诉 AI “类似场景下这样做有效”
• 失败记忆是"教训"：告诉 AI “上次这样失败了”

一个完整的记忆系统需要三者配合，只做一种记忆是不够的。

6.4 页面知识库注入：结构化锚点 → AI 视觉

Wiki 知识最具体的应用是页面元素知识库。

TestStar 的页面知识库（一份针对具体查询控制台的配置）定义了 11 个元素，每个元素就是一对「语义 + 位置」：

元素： 登录入口
语义: "密码登录"
位置: "登录页顶部 tab 区域"
元素： 登录按钮
语义: "登录按钮"
位置: "登录表单底部"
元素： 实例连接
语义: "实例卡片连接按钮"
位置: "实例列表每行右侧"
……（共 11 个，形式相同）

注入流程：

┌──────────────────┐
│ 执行 yaml │
│ aiAct: 点击登录 │
└────────┬─────────┘
↓
┌──────────────────┐
│ 静态分析（注入前）
│ 命中 "登录" → [login_button]
└────────┬─────────┘
↓
┌──────────────────┐
│ 注入 location 提示
│ aiAct: 点击登录（位置：登录表单底部）
└────────┬─────────┘
↓
┌──────────────────┐
│ AI 接收 prompt
│ 优先用 location 锚点定位
│ 失败回退纯视觉理解
└──────────────────┘

6.5 实测数据：知识库注入的双面性

知识库注入后，团队跑了两次实验——一次冷缓存、一次热缓存：

• 冷缓存：token 297K、耗时 208 秒、通过
• 热缓存：token 57K、耗时 99 秒、通过

关键发现：注入会让 prompt 变长，冷缓存下 token 更贵（297K ≈ 未注入时的 190K）；但热缓存下恢复正常（57K），且稳定性明显提升——顺带解决了之前一次"密码识别失败"的问题。

结论：知识库注入是"长期投资"——

• 短期：冷启动贵一点
• 长期：缓存命中后成本持平，稳定性持续受益

这个取舍不是免费的，但对生产环境是值得的。

6.6 覆盖度验证：80% 命中

团队对知识库做了静态覆盖度验证：拿一个真实用例，数它的交互与断言步骤（共 15 个），看知识库能命中其中多少——结果是 12 个，80%。未命中的 3 个都有合理原因：

• "关闭弹窗"这类通用逻辑
• 数据断言（不涉及具体元素）
• 一处临时使用的特殊元素

80% 是个健康数字——既说明知识库粒度够用，也说明没有为了追求数字而过度抽象。

6.7 通用 schema 抽象的陷阱

TestStar 团队做了一次明确的决策：不做通用 schema 抽象。

理由是"过早抽象是工程灾难"（内部 TODO 文档原文）：

“P2-3: UI 知识库抽象成通用 schema。不做理由: 过早抽象是工程灾难。先做 P1-1 沉淀一条用例的真实知识，跑 2 周，看哪些字段真有用、哪些是过度设计，再决定要不要抽象。”

这是一个反直觉但正确的判断：

• 现在做通用 schema：3 个月，产出一个"什么都能描述但什么都没描述清楚"的 schema
• 先做单用例深度：1 周，产出 11 个具体元素，跑 2 周验证

单用例深度 > 多用例抽象。这是工程上常见的教训，但在 AI 测试领域特别容易犯——因为 AI 测试的"通用"看起来很容易（“都是页面元素嘛”），每个产品的页面结构差异却往往很大。

6.8 记忆系统的真实边界

承认记忆系统的局限：

记忆不是越多越好：

• Wiki 知识有"半衰期"——产品改版后旧知识失效
• 失败记忆有"噪音"——环境偶发失败被记住，反而误导

记忆的"遗忘机制"：TestStar 当前没有自动遗忘，但这是个明确的改进方向（v3 候选）。

记忆的"冲突解决"：当 Wiki 知识说"按钮在顶部"、失败记忆说"上次失败因为按钮在顶部"、Skill 经验说"用 location 提示有效"——三者冲突时怎么仲裁？

这是 Harness 层还没完全解决的问题，但它是 AI 测试平台进化的方向。

七、复盘与展望：诚实大于虚增

让我用 TestStar 团队的内部维护原则做收尾。这五条规则是整个项目的"宪法"，比任何技术细节都重要：

7.1 五条维护规则

规则一：每条任务必须有"不做会怎样"

防止为了"看起来忙"加任务。

每个 TODO 项都必须能回答两个问题：

• 不做会导致什么后果？
• 做了能避免/解决什么后果？

回答不了的，要么删掉，要么等回答清楚再加。

规则二：P1 任务严格串行

每个 P1 完成 + Tier 1 验收 KPI 后才进下一个，避免并发堆债。

P1 是"不做 Tier 2 跑不下去的事"，所以必须先验证再做下一个。并发做 P1 容易让债务堆积，最后一起爆发。

规则三：P2 标记"暂禁"是默认

任何新建议都要回答"为什么不做 Tier 1/2 的核心"。

P2 是"做了可能更好但不做也能活的事"。默认是暂禁，除非能论证它是 Tier 1/2 的瓶颈。

规则四：做完 P0/P1 必须更新对应阶段（Tier）的验证报告

不沉淀等于没做。

每个阶段结束必须有报告，记录：

• 做了哪些改动
• 关键数据
• 发现的真实问题
• 留给下个阶段的事

不沉淀等于没做，这是 TestStar 团队对自己最严格的要求。

规则五：不使用 “TODO” / “TBD” / “FIXME” 作为任务名

每条要明确"做什么"。

模糊的任务名是技术债务的开始。每条任务必须明确说"做什么"，否则就是借口。

7.2 “扩生成能力等于扩垃圾”

这是 TestStar 团队的内部金句，出现在内部 TODO 文档的多个地方：

“扩生成能力等于扩垃圾。”
“Tier 1 主动清到只剩 1 个用例，就是为了不分散精力。”

字面意思是：

• 测试用例库的扩充是"扩展生成能力"的一种
• 但如果底层执行引擎还没稳定，扩用例只是"扩故障面"

这个原则适用于整个 AI 测试领域：

• 用例库不要先扩，先把现有用例稳定到 100%
• 模型版本不要先换，先把当前版本的 edge case 全踩过
• 不要先加新功能，先把现有功能的所有失败模式穷尽

克制是 AI 测试项目最稀缺的品质。

7.3 “诚实 > 虚增”

这是另一个内部金句：

“60% 是诚实水平，虚增到 80% 会掩盖’物理失败本就不该救’的事实。”

应用场景：

• 自愈率：60% 就说 60%，不虚增
• 测试覆盖率：80% 就说 80%，不"四舍五入到 90%"
• 成功率：5/5 就说 5/5，不说"100% 通过"（暗示永远通过）

虚增的数据会建立虚假的信任，虚假的信任一旦崩塌，全盘皆输。

7.4 Tier 1/2/3 的克制哲学

TestStar 团队把项目分成三个 Tier：

• Tier 1：底座验收（cache + 工程卫生 + 单用例稳定）—— 已完成
• Tier 2：核心差异化能力（自愈 / 记忆 / 知识 / CI 接入）—— 框架完成，深度验证中
• Tier 3：远期方向（PRD → Test Plan / V2 架构 / Agent Copilot）—— 暂禁

每个 Tier 有严格的进入门槛：

• Tier 1 完成 → 才进入 Tier 2
• Tier 2 全部 KPI 超额 → 才进入 Tier 3

这是一个反"敏捷"的哲学：不追求每个 sprint 都交付新功能，追求每个阶段都把基础打牢。

7.5 未完成的事：诚实承认

TestStar 不完美。以下问题诚实承认还没解决：

真实 CI 数据缺失：

• smoke 脚本写好了
• 真实 CI 2 周数据还没积累
• 真实失败率 / token 月成本 / 人工介入频率——都是未知数

多场景横向验证：

• 只有"数据查询"一条用例深度验证
• 其他场景（CRM、复杂 SPA、低代码平台）未验证

自愈通用性：

• 5 case 救回率 60%，是"通用机制"验证
• 真实产品 URL 上的救回率，未知

V2 架构重设计：

• 已经写了架构设计文档（内部架构重设计文档）
• 但 V2 还在"等 Tier 1+2 KPI 全部超额完成"的远期阶段

AI 模型依赖：

• 依赖字节 Midscene
• 自身不掌握浏览器驱动层
• 如果 Midscene 停止维护，TestStar 的根基会动摇

7.6 行业判断：三个预测

基于 TestStar 的实践，我对 AI UI 自动化行业做三个预测：

预测一：执行引擎会趋同

2026-2027 年，Midscene / Browser-Use / Skyvern / 各种新出的工具，核心能力会越来越像：

• 都支持自然语言描述
• 都支持多模态视觉
• 都有基本的失败重试
• 都有基本的可观测性

执行引擎的差异化会越来越小，真正的竞争在 Harness 层。

预测二：Harness 工程会成为独立赛道

会出现一批"Harness for AI Agent"的工具，专门做：

• 失败分类与归因
• 自愈决策
• 记忆与知识管理
• 可观测性增强
• 调度与编排

这就像数据库时代的"中间件"——围绕执行引擎做增强。

预测三：知识库会成为真正的护城河

执行引擎趋同后，差异化落在"谁知道得多、谁记得准"。

• 谁积累了更多页面知识？
• 谁沉淀了更准确的失败模式？
• 谁蒸馏了更有效的 Skill？

知识是数据，是数据就构成壁垒。

八、给测试工程师的建议

最后给读者几条实操建议。这些都是从 TestStar 的实战里提炼的，不是空话：

建议一：先用 AI 跑通 demo，再考虑生产

不要被 AI 测试工具的 demo 视频迷惑。先花一周在你自己最熟悉的 1-2 个用例上跑通 demo，再决定要不要投入。

跑通 demo 后问自己：

• 这个工具的失败信号是结构化的吗？
• 我能在不读源代码的情况下定位失败原因吗？
• 我能控制它的重试、自愈、人工介入吗？

三个问题都"是"，才值得进一步投入。

建议二：token 成本是第一 KPI

不要把 AI 测试当作"花点 token 换点自动化"的事。token 成本是结构性问题，决定能不能规模化。

第一次跑之前，先估算 token：

• 单次用例平均多少 token？
• 每天要跑多少次？
• 月成本能承受吗？

跑通后立即接 cache。没有 cache 的 AI 测试，不应该上生产。

建议三：失败分类先做，AI 修复后做

很多人一上来就想做"AI 自动修复失败"。这是错的。

正确顺序：

跳过前两步直接做 AI 修复，会变成"AI 乱修、QA 痛苦"的状态。

建议四：知识库从单用例开始，不要先抽象 schema

如果你要给 AI 测试加知识库：

• 先做单用例：选一个最稳定的用例，沉淀 10-20 个具体元素
• 跑两周：看哪些字段真有用
• 再决定要不要抽象

不要一开始就做"通用页面 schema"。抽象的成本是隐藏的——你会在抽象上花 3 个月，最后发现 60% 的字段没人在乎。

建议五：CI smoke 是必做项

不要相信"在我机器上能跑"。把 CI smoke 集成当作 AI 测试的"出厂测试"。

CI smoke 至少要覆盖：

• 启动服务
• 跑通 1-2 个用例
• 验证 token / 耗时 / 成功率
• 验证 exit code

没有 CI smoke，AI 测试就是"实验室玩具"。

建议六：诚实大于虚增

最后一条，也是最重要的一条：

不要为了说服别人而虚增数据。

成功率 60% 就说 60%。自愈率 3/5 就说 3/5。

你的团队和客户会看这些数据做决策。虚增的数据会建立虚假的信任，虚假的信任一旦崩塌，全盘皆输。

TestStar 团队写下的"诚实 > 虚增"，是整个项目最珍贵的原则之一。

尾声

回到文章开头的问题：当 AI UI 测试从 demo 走向生产时，到底卡在哪？

我的回答是三句话：

这三个判断不是从教科书来的，是从 TestStar 的 2.2 万行代码、8 次跑通的用例、3 个 Tier 的克制迭代里提炼的。它们也许不适用于所有团队，但至少是被真实数据验证过的。

对正打算做 AI UI 测试的人，可以带走的是一套决策框架——“五问评估法”：失败信号结构化吗？日志可订阅吗？执行可干预吗？知识可增强吗？API 可调度吗？这五个回答，比 demo 跑得多好看重要。

测试工程师的核心价值，从来不是"会用某个工具"，而是"能判断什么时候该信、什么时候该怀疑"。

附录：TestStar 关键数据速查

📌 这是「AI 测试平台实战」系列的第 1 篇。

下一篇会讲：自愈闭环怎么设计——从 16 类失败到置信度门控。把"AI 修复对了不敢全信，AI 修复错了又不能没人看"这件事讲透。

关注我，系列持续更新，不错过。评论区交流也欢迎。