知识分享
技术文章、实战教程、经验心得
LLM 驱动的自动化测试系列（14）：落地与工程化——为什么测试场景的 Token 账单,反而是这个系列里最便宜的
同一个作者的企业级 Bug 修复流程,调试阶段烧掉了数千美金 Token；这个系列里验证过的测试场景——AutoRestTest 测一个 15 个接口的 API 只要一毛钱,pytest-triage 默认每次运行最多花 10 次模型调用——差了几个数量级。这篇把 13 篇文章积累的证据摆在一起,回答规划里剩下的三个问题：测试场景的成本量级为什么比代码生成低,人工确认门该放在流程的哪个节点,以及到底有哪些场景明确不该用 LLM。
LLM 驱动的自动化测试系列（13）：Flaky Test 不是重跑几次就能解决的分类问题
477 star 的 pytest-rerunfailures 和 397 star 的 flaky，处理不稳定测试的手段永远是同一句话：失败了就重跑几次。这解决不了规划里提出的问题——一次失败到底是真 bug、环境抖动，还是测试本身写得有问题。真正尝试用 LLM 做这个根因分类的，是一个只有 2 star、上线不到两个月的项目 pytest-triage，而它最值得学习的地方，反而是它给 AI 判断加的四条安全约束——AI 从头到尾不允许影响测试的通过/失败结果。
LLM 驱动的自动化测试系列（12）：像素 diff 之外，谁真的在让 LLM「看懂」UI 变化
7.2k star 的 BackstopJS 处理噪声的全部手段就是四个数字配置项：misMatchThreshold、requireSameDimensions、ignoreAntialiasing、usePreciseMatching——本质上还是在跟字体渲染抖动死磕像素级容差。真正把 VLM/LLM 接进视觉回归判断链路的，是一个只有 23 star 的项目 vlmkit，而且它自己的内部评测数据直接写着某个模型会把红改成红——把这两个项目摆在一起，视觉语义回归到底解决了什么、又引入了什么新问题，答案比想象中更具体。
LLM 驱动的自动化测试系列（11）：API 测试为什么反而是 LLM 最保守的战场
18.5k star 的 Keploy 首页写着'Expand API Coverage using AI'，但把整个开源 Go 代码库翻遍，找不到一行调用大模型的代码——那个 AI 功能只存在于闭源的云端 SaaS。3.6k star 的 Schemathesis 则完全不用 LLM，靠 Hypothesis 这套纯粹的基于属性测试（property-based testing）的模糊测试引擎就能找到真实的服务端 500 错误。反倒是两个不到 100 star 的小项目——AutoRestTest 和 api-automation-agent——才是真正调用大模型 API 的实现。这篇要说清楚：结构化的 API 输入输出天然更适合传统 fuzzing，那 LLM 到底能在这个赛道里做什么传统工具做不到的事，为什么它目前只敢做，不敢像 UI 自动化那样 all-in。
LLM 驱动的自动化测试系列（10）：自愈定位——当启发式打分撞上语义理解的天花板
Healenium 是自愈定位领域最老牌的开源项目，README 宣称'leverages machine learning'，但直接读代码发现核心机制是一套基于 DOM 树相似度的加权打分公式，权重和阈值都是硬编码常量，跟机器学习没有关系；更值得注意的是它 2026 年新增了一个 AI 生成 XPath 的接口，但代码里直接写着'必须是付费的 hlm-ai 服务'。这篇先拆穿 Healenium 的打分公式到底怎么算，再看 MarketSquare/robotframework-selfhealing-agents 这个真正基于 LLM 的自愈项目怎么设计多智能体架构，最后回答规划里提的问题：自愈成功率和误判率的权衡，到底卡在哪。
LLM 驱动的自动化测试系列（09）：移动端自动化（五）——当通用 Agent 框架下沉到测试场景
MetaGPT 是一个'多智能体软件公司'框架，主打需求分析、代码生成这类通用软件工程场景，但它内置了一个 Android 测试 demo。直接读代码会发现规划文档里的一个预设是错的：这个 demo 没有复用 MetaGPT 通常宣传的产品经理/工程师/QA 角色分工，而是只有一个自定义 Role，复用的是 Team/Environment/Role/Action 这套更底层的调度骨架；更关键的是，README 里明确写着它'借鉴了 AppAgent 的思路和代码'——这篇拆解这个通用框架到底继承了 AppAgent 的哪些设计、复用通用骨架换来了什么、又付出了什么代价。
LLM 驱动的自动化测试系列（08）：移动端自动化（四）——AppAgent：解析树与视觉特征的结合
AppAgent 是腾讯开源的 CHI 2025 论文项目，跟前几篇纯视觉（ARTEMIS/Mobilerun）或纯坐标（Mobile-Agent-v3）的方案不同：它用无障碍树给截图上的元素画数字标签，模型只需要挑一个数字——'解析树'和'视觉'其实不是两个独立感知通道，而是结构信息负责标注位置，视觉模型负责决策。这篇拆解它自主探索阶段怎么靠反思四分类（BACK/INEFFECTIVE/CONTINUE/SUCCESS）自己攒文档，网格兜底机制在解析树失效时怎么退化，也如实指出网格兜底路径里一个真实存在的坐标换算 bug。
LLM 驱动的自动化测试系列（07）：移动端自动化（三）——Mobile-Agent-v3 与自研 GUI-Owl 模型路线
Mobile-Agent-v3 是阿里通义实验室（Tongyi Lab）基于自研 GUI-Owl 模型打造的多智能体框架，跟前两篇依赖通用 VLM（Gemini/GPT/Claude）做感知的 ARTEMIS、Mobilerun 走的是完全不同的路：自己训练一个专门做 GUI grounding 的模型，让它输出'绝对像素坐标'而不用再猜。这篇拆解它 Manager/Executor/ActionReflector/Notetaker 四角色的具体分工、'连续两次失败才升级给 Manager'的容错阈值设计，也如实指出代码里一个真实存在的 HarmonyOS 输入 bug。
LLM 驱动的自动化测试系列（06）：移动端自动化（二）——DroidRun/Mobilerun 的角色级模型拆分
DroidRun（现更名为 Mobilerun）用统一的设备驱动抽象把 Android 和 iOS 塞进同一套工具接口，但它跟上一篇的 ARTEMIS 走的是完全不同的路：不是'任务级'选择 Flash 还是 Pro，而是'角色级'——Manager、Executor、FastAgent 三个角色分别配模型、配温度。这篇拆解它的多智能体工作流、Portal 无障碍服务、App Card 机制，也如实指出它那块'91.4%'的 benchmark 徽章在仓库里其实找不到任何本地可考证的说明。
LLM 自动化测试系列（05）：移动端自动化（一）——ARTEMIS 的双模式架构拆解
Google 开源的 ARTEMIS 让 AI 助手和测试套件像人一样操作真机。这篇先讲清楚它是什么、特色在哪，再深挖 Flash/Pro 双模式的图结构、'verify vs assert'的语法级区分、两层预执行安全网，以及最容易被忽略的一点——它给'元素定位'单独配了一个 Google 自研的具身推理模型 Gemini Robotics-ER，而不是让通用 VLM 顺手做定位。这些技术点跟它宣称的 AndroidWorld 99%+ 到底是什么因果关系，这篇尽量说清楚。
LLM 自动化测试系列（04）：Web UI 自动化——Midscene 的视觉驱动脚本化
字节跳动开源的 Midscene 走的是纯视觉定位路线：不写 selector，直接把截图交给视觉模型，用自然语言描述'点击提交按钮'。这篇拆解它的三种模型角色分工（Default/Planning/Insight）、aiAct 的重规划循环、规划缓存与定位缓存各自的失效判定逻辑，以及跟 Stagehand 这类基于 DOM/无障碍树的方案比，鲁棒性和成本的权衡到底在哪。
LLM 自动化测试系列（03）：单元测试生成——TestGen-LLM 与 Qodo Cover
让 LLM '随便写点测试'，产出的往往是编译不过、断言写死 true、或者根本不提升覆盖率的垃圾测试。Meta 的 TestGen-LLM 论文给出的解法不是让模型变聪明，而是用一套机械化的过滤器把不合格的产出全部筛掉。这篇拆解这套过滤器的具体设计，以及它的开源实现 Qodo Cover 怎么把这套思路落地成可跑的 CLI 工具。