“AI 测试”喊了这么久真正让它落地产生价值的场景并不算多UI 自动化是其中一个比较实的。但这半年我观察到一个现象很多人一上来就想搞一个“万能 Skill”想让 Agent 一个技能包干完所有事——从解析需求、生成脚本、跑用例、分析失败到出报告全塞进一个 SKILL.md 里。结果往往是一次次被上下文长度打脸被工具误调度折磨最后一顿操作猛如虎回头还得手工补报告。我现在的做法正好相反拆。把 UI 自动化到报告生成拆成 5 个各管一摊的小 Skill让 Agent 像项目经理一样调度它们跑通了整条链路。这篇文章就把这套设计思路、每个 Skill 的落地方案、以及踩过的坑完整写出来给正在用 Agent 做测试提效的朋友一个可直接参考的样本。1. 先想清楚为什么一个“万能 Skill”撑不起全流程1.1 大而全的 Skill 在 Agent 机制里是怎么“卡壳”的我先说个真实感受。Agent 用 Skill 的执行机制是基于模型对 Skill 描述的理解动态调用工具和流程的。你把需求解析、脚本生成、执行命令、失败重试、报告模板全写进一个 Skill 里看着很全能模型每次调用之前得先把几百行指令读完再自己判断“现在该走哪条分支”。这在短流程里没什么问题一旦 UI 自动化这种多步骤长流程跑起来问题就非常明显。首先是上下文窗口的浪费。一个万能 Skill 的 SKILL.md 动辄两三百行模型每轮对话都要把这些内容当成上下文的一部分。前面几轮还能保持判断力跑到中间阶段前面读过的指令早就被冲淡了模型开始出现“该执行脚本的时候去解析需求”“该生成报告的时候去改代码”这种错乱。其次是 Prompt 冲突。你想让 Skill 既覆盖“严谨的脚本生成”又覆盖“简洁的报告输出”这两类任务的信息优先级、输出格式完全不同。写在一个 Skill 里模型很难同时满足。你要是再塞进去一个“失败重试策略”它分分钟把重试逻辑写到测试代码里去。最后是没法针对单个环节优化。真实项目里脚本生成这个环节天天改报告模板可能一两个月才动一次。放在一起改脚本生成会担心影响报告逻辑改报告模板又怕碰坏执行流程维护成本成倍上升。用一句话概括就是万能 Skill 把“串行流程的复杂度”全压在了“模型一次性理解所有规则”上模型扛不住人的维护也扛不住。1.2 用“工厂流水线”思路拆解测试流程想通之后我换了个类比别把 Skill 当“全能工人”把整套流程当工厂流水线。流水线上每个人只负责一道工序工位之间用标准容器传递半成品。哪个工位出了问题就修哪个工位其他环节完全不受影响。UI 自动化测试这个流程本质上也能切成几段独立工序理解需求用户一句“帮我测一下登录出个报告”怎么变成可执行的测试用例生成脚本有了用例步骤怎么变成浏览器或手机能跑的自动化代码执行调度代码跑起来需要什么环境浏览器驱动、设备、依赖库谁来管失败分析跑挂了是元素没找到断言不对还是环境问题报告输出结果怎么汇总成一份看得懂的文档并且送到该看的人手里每一段的输入输出清晰依赖的工具也不同。自然语言解析靠大模型执行调度需要 Shell 能力报告生成又依赖模板渲染和文件写入。硬塞一个 Skill本质上是逼模型在同一个上下文里同时扮演五个角色当然容易精神分裂。拆开之后每个 Skill 只负责一个角色Prompt 可以写得特别专注上下文只在对应环节被加载反而省 token。1.3 拆完之后五个 Skill 各守一段基于这个思路我最终沉淀下 5 个 Skill名字和各自职责如下Skill 名称核心职责典型输入典型输出spec-parser解析用户需求为结构化用例自然语言测试描述test_plan.json用例清单script-generator根据用例清单生成 pytest 代码test_plan.jsontest_xxx.py可执行脚本executor执行测试、管理驱动与设备、收集产物脚本路径results.json、截图、日志failure-analyzer分析失败原因并给出修复建议results.json、截图、日志failure_analysis.mdreport-builder生成测试报告并推送通知各类执行产物report.html、report.pdf、推送消息后面你会看到这 5 个 Skill 之间不只是“各干各的”它们有一套固定的前后依赖关系。这套组合跑通之后一个原本要人工花 1 小时完成的中小型测试流程压缩到十几分钟完全可行。提示这 5 个 Skill 的划分不是绝对的如果你的项目没有 App 端或者报告不需要推送完全可以砍掉某个 Skill 或者合并相近的职责。关键是保持“单一职责”这个原则。2. 五个 Skill 怎么串起来编排逻辑与上下文流转2.1 Agent 是“项目经理”Skill 是“专员”拆完 5 个 Skill 之后很多人会问那 Agent 本身还干什么答案是Agent 当项目经理只做两件事——理解用户意图决定调用哪个 Skill 以及什么时候调用。我举个实际场景。用户对 Agent 说“验证一下登录模块正确密码能登录成功错误密码要报提示跑完把报告发群里。”Agent 收到这句话后的内部思考大致是这样用户要的是“验证登录模块”这属于解析需求 → 生成脚本 → 执行 → 出报告的完整链路。于是它开始一级级调用调用 spec-parser把一句话拆成两个用例正确密码登录成功、错误密码提示错误spec-parser 把结果写进 test_plan.jsonAgent 读取后交给 script-generatorscript-generator 生成 test_login.pyAgent 调用 executor跑 pytest test_login.py执行结束executor 把结果写入 results.jsonAgent 再调 failure-analyzer 看有没有失败最后调 report-builder生成 HTML 报告并推送到企业微信。注意这个过程中 Agent 没有直接写测试代码没有自己跑命令也没有自己拼报告。它做的是“看下一步该谁上场”。当然5 个 Skill 个个都可能需要调用底层工具跑 Shell、读写文件但这些工具绑定在各自 Skill 内部而不是堆在 Agent 的全局上下文里。2.2 上下文流转用“文件”传递半成品不靠对话记忆这是整条链路能不能稳定跑通的关键也是我最想强调的经验Skill 之间的数据交换一律通过文件完成不要让 Agent 靠对话历史记上一轮结果。具体流程是spec-parser 写artifacts/test_plan.jsonscript-generator 读test_plan.json写artifacts/test_login.pyexecutor 读脚本路径执行后写artifacts/results.json并把截图、日志放进artifacts/screenshots/和artifacts/logs/failure-analyzer 读results.json和附件写artifacts/failure_analysis.mdreport-builder 读所有这些产物在artifacts/reports/下生成报告。为什么必须走文件两个原因。第一UI 自动化执行期间会有大量中间产物截图、日志一多塞进对话历史马上把上下文撑爆。第二文件是“断点续跑”的基础。如果流程跑到第 4 步挂了你只需要重置 Agent 会话告诉它“读一下 artifacts/test_login.py 和 results.json接着分析”它就能跳过前 3 步继续干活。靠对话记忆的话会话一断全部归零。我在每个 Skill 的 Prompt 里都会写一句硬性要求“执行完成后只返回产物文件路径和一两行摘要不得把完整日志或代码内容粘贴回对话。”这一句直接让 token 消耗降低了非常可观的比例。2.3 顺序链路之外还要给 Agent“提前判断”的提示Skill 的 Trigger 条件也得写清楚。比如 report-builder 的 SKILL.md 描述里我第一句话就是“等测试执行结束、results.json 存在之后再调用。用户问报告时如果还没执行先调用 executor。”这句话不是给人类看的是给模型看的。它可以有效避免 Agent 在用户说“给我出个报告”时真的跳过执行环节直接拿空数据渲染。同样failure-analyzer 的描述里写“仅当 results.json 中存在 failed 或 error 状态的用例时优先调用全部通过的情况下可以跳过这一步。”这一个条件就能省掉大部分多余调用。3. 每个 Skill 的落地细节核心 Prompt 与实操参数3.1 spec-parser把“人话”变成结构化用例这个 Skill 是所有环节的地基。如果需求解析错了后面脚本、报告全是白搭。我给它定义的核心指令是把用户的测试描述转换成 JSON 数组每个用例包含id、title、preconditions、steps、assertions五个字段并且只输出 JSON不要任何解释。一个简单的 Prompt 骨架如下你是测试用例解析器。用户会输入对某个功能模块的测试描述你需要 1. 提取出所有可独立验证的测试场景 2. 每个场景输出为一个 JSON 对象 3. 字段格式{id: TC001, title: ..., preconditions: [...], steps: [...], assertions: [...]} 4. 如果用户描述中没有明确前置条件preconditions 给空数组 5. 只输出 JSON 数组不要输出任何解释文字。有一段经验我想特别分享一开始我让这个 Skill 自由发挥结果 AI 把一些口语化的表达也当成测试步骤写进去了。比如用户说“顺便看看登录按钮好不好看”模型居然生成了一条“验证登录按钮美观度”的用例。后来我在指令里加了一句“忽略与功能验证无关的主观描述”这个问题就基本消失了。另外我要求这个 Skill 输出里带一个assumptions字段记录需求不明确时的合理假设。例如用户没说用哪套环境它默认测试环境。这个字段在后续脚本生成阶段非常有用能减少很多来回确认。3.2 script-generator管住技术栈防止 AI 自由发挥这个 Skill 是最容易翻车的原因是大模型写代码时“自由意志”太强。今天给你生成 Selenium明天给你生成 Playwright后天甚至冒出个你没装的库。所以 script-generator 的 Prompt 第一要务是“锁死技术栈”。我在这个 Skill 里固定了规则Web 端用 Playwright PytestApp 端用 Appium Pytest。脚本风格统一用 Page Object 模式选择器优先用role、placeholder、text等语义化定位方式禁止使用动态生成的 id。等待策略统一用 Playwright 的自动等待或显式expect禁止写死time.sleep()。一个生成出的测试脚本大概长这样import pytest from playwright.sync_api import Page, expect def test_login_success(page: Page): page.goto(https://example.com/login) page.get_by_placeholder(用户名).fill(test_user) page.get_by_placeholder(密码).fill(correct_password) page.get_by_role(button, name登录).click() expect(page).to_have_url(https://example.com/home)这个 Skill 我设置了明确的输入输出它的 Prompt 里有这么一条“读取test_plan.json为每一个测试场景生成一个独立测试函数函数命名必须是test_开头文件保存到artifacts/目录只返回文件路径和函数清单。”为什么这么强调“只返回文件路径”因为之前它跑完会把整段代码完整打印回对话里一个 8 个用例的脚本能占掉 3000 token吃了大亏。3.3 executor驱动管理、失败重试与环境检查executor 是所有 Skill 里最需要“实操能力”的一个它不能只靠 Prompt 指挥模型还得挂上真实工具调用。我的实现方式是给这个 Skill 绑定几个脚本工具run_shell(command)、read_file(path)、write_file(path, content)。Agent 通过这几个工具去执行命令。它的核心指令包括四步检查环境Web 端确认浏览器与对应 driver 是否已安装且版本匹配App 端先用adb devices确认设备在线执行测试运行pytest artifacts/test_login.py --tbshort -q加--tbshort是为了控制日志长度收集产物不管成功还是失败把输出重定向到artifacts/logs/并截图保存到artifacts/screenshots/汇总结果把 pytest 的 ExitCode 转为 JSON 结果写入artifacts/results.json。失败重试策略我踩过不少坑总结下来规则可以是这样的环境类失败driver 启动失败、端口占用、设备断连自动重试 1 次断言失败和元素定位失败不重试直接进入失败分析环节。为什么断言失败不重试因为 UI 自动化里断言失败往往是功能 bug重试只会浪费时间。这个 Skill 的 Prompt 我加了一段自我检查逻辑“执行完命令后确认 exit code 为 0 才算成功。如果 pytest 返回非 0不要擅自改脚本先记录失败状态留给 failure-analyzer 处理。”一开始没加这句的时候模型会在用例失败后自己动手改测试代码然后重新跑改得面目全非还不告诉你非常坑。3.4 failure-analyzer定位根因但禁止编造失败分析是 AI 提效最明显的一环。以前出问题了人得打开日志、翻截图、猜原因。现在 Agent 能一口气把这些材料看完给你一个分类结论。但这个环节也是最容易“AI 一本正经胡说八道”的必须给模型立好规矩。这个 Skill 的输入是results.json 对应日志 截图。它在 Prompt 里被要求把失败原因归为以下五类失败分类典型表现处理建议元素定位失败NoSuchElementException / timeout检查选择器是否动态、是否在 iframe 中页面加载超时Page load timeout检查网络、环境、接口响应断言不通过AssertionError / expect 失败比对预期与实际值看业务逻辑脚本自身错误AttributeError / NameError检查代码逻辑、依赖缺失环境问题driver 崩溃、设备离线检查驱动版本、设备连接Prompt 里有两条硬性约束。第一优先看截图和日志最后 20 行不要把整个日志丢给模型。第二如果分析不出根因必须明确写“需要人工确认”严禁为了凑结论编一个原因。我见过模型把一次环境问题一本正经地分析成“登录按钮文案变化导致断言失败”原因就是它只看了代码没看截图又不好意思说不知道。实操里这个 Skill 的输出我设计成failure_analysis.md格式固定为“失败用例 ID → 失败分类 → 证据截图/日志片段 → 根因分析 → 修复建议”。这个文件既给 AI 自己看也会被 report-builder 引用到报告里给开发同学做参考。3.5 report-builder聚合结果、生成报告、推送通知最后一个环节是报告生成。很多团队到了这步就把结果直接贴到群里一张丑丑的文本截图。实际上模型在这里能做的远远不止贴日志而是值得“重新组织信息”。我的 report-builder 指令包含三件事读取results.json、failure_analysis.md、截图等产物生成一份 Markdown 格式的测试摘要包含总用例数、通过数、失败数、通过率、耗时、失败列表及原因使用 HTML 模板文件渲染一份带样式的报告报告头部放通过率主体放失败用例详情和截图缩略图将 HTML 转为 PDF通过 Webhook 推送到企业微信或钉钉群。关键在第一步。AI 的价值不是把 results.json 里的字段原样抄一遍而是写出类似“本次共执行 6 个用例通过 5 个通过率 83.3%。失败的 TC002 经分析是环境问题导致非业务功能缺陷”的人类可读摘要。后面再用模板把摘要和明细拼成正式报告。HTML 转 PDF 的方案我用了两种轻量报告用 Playwright 的page.pdf()直接渲染如果需要带监控趋势比如把历史多轮通过率做成曲线我会上报数据到 Grafana再用 Grafana 的截图导出 PDF 拼进报告。这个组合实测下来比较稳美观度也能达到给领导看的水平。4. Skill 工程化SKILL.md 结构、描述写法与调试方法4.1 一个标准 Skill 的文件结构Skill 不是只有 SKILL.md 一个文件。我的每个 Skill 都按固定目录组织以 report-builder 为例skills/report-builder/ ├── SKILL.md ├── scripts/ │ ├── render_report.py │ └── send_webhook.py ├── templates/ │ ├── report.html.j2 │ └── report.md.j2 └── references/ └── grafana_dashboard.jsonSKILL.md是入口里面写清楚何时该用这个 Skill、底层怎么操作、输入输出在哪里。scripts/放的是可以被 Agent 调用的现成工具脚本。templates/放报告模板。这样模型拿到 Skill 后不需要凭空想“报告长什么样”只需要往模板里填数据。4.2 desc 怎么写Agent 才不会乱调用SKILL.md 的 YAML Frontmatter 里description字段是最重要的。它是 Agent 决定“要不要调这个 Skill”的唯一依据。写得模糊Agent 就会在错误的时机调用。以 failure-analyzer 为例我的 desc 写作分析 UI 自动化测试失败结果定位失败根因并给出修复建议。 仅当 artifacts/results.json 已存在且包含失败用例时使用 如果所有用例通过无需调用此 Skill。这段描述只有两句话但信息密度很高。第一句说明功能第二句是精确的触发条件并且反着告诉 Agent 什么情况不用调。后一句话往往比第一句更管用。我对比过不写触发条件的版本Agent 在用户说“帮我跑一下测试顺便看看有什么问题”时会先调 failure-analyzer因为用户提了“问题”两个字。加了后半句之后它就会先判断结果文件里有没有失败再决定调用准确率高很多。4.3 调试 Skill 的两类实用技巧第一个技巧是“干跑模式”。我在每个 Skill 的“测试环境”里都加了同样的开关如果DRY_RUNtrue环境变量存在只输出“将要执行的动作和参数”不真正执行测试、不生成文件。平时我写完一个新 Skill先开干跑模式用几条典型指令验证调度逻辑对不对确认无误再改成真实执行。这个模式省了我大量时间精力因为很多错误根本不在代码里而在模型对 Skill 理解的偏差上。第二个技巧是给每个 Skill 记录调用日志。我在 SKILL.md 里加了一条通用指令“每次调用结束后将调用时间、输入摘要、输出文件路径追加写入artifacts/skill_log.csv。” 一旦 Agent 链路出了诡异问题我只需要打开这个 CSV 就能还原它每一步干了什么再也不用靠猜。有次线上链路突然全挂就是这个日志救了我。打开发现 executor 连续调了三次第一次是执行第二次是 Agent 误以为没跑成功又跑了一次第三次是它把第一次的截图删了。排查起来一目了然。4.4 什么时候该用代码工具什么时候纯 Prompt 就够不少人在做 Skill 时容易陷入一个误区什么都让模型自己发挥。实际上有一个简单的判断标准——如果这个环节的结果“确定性要求高”就必须绑代码工具如果结果“开放性要求高”可以让模型自由生成。比如 executor 执行 pytestexit code 是多少、日志存哪里这些必须是确定性的不能让模型临场发挥。report-builder 里的 HTML 渲染也最好用模板脚本控制。反之spec-parser 把自然语言拆成用例、failure-analyzer 分析根因这类任务没有标准答案就用 Prompt 驱动模型。按这个标准我的 5 个 Skill 里spec-parser 和 failure-analyzer 是偏纯 Prompt 的script-generator 是 Prompt 代码生成的混合executor 和 report-builder 主要是脚本工具 少量 Prompt 调度。5. 常见问题与排查技巧实录整套体系跑了一段时间也积累了不少“翻车现场”的处理经验。我挑几个高频问题整理成速查表供大家直接对号入座现象根因排查与解决浏览器启动后秒退报 session not createdChrome 自动升级driver 版本不匹配检查 chromedriver 与浏览器版本改用 WebDriver Manager 自动匹配在 executor 脚本里加版本校验AI 生成的 xpath 全是//*[idapp]/div[3]/...一改版就挂模型偏好用绝对路径或动态 idscript-generator 的 Prompt 明确禁止使用动态 id要求优先按 role/placeholder/text 定位Agent 在没执行测试时就直接去生成报告report-builder 触发条件没写清楚在 SKILL.md 里增加“仅当 results.json 存在时调用”的条件长流程跑到第 4 步突然开始乱来上下文被中间产物撑爆模型丢失前序判断严控 skill 输出内容长度强制只返回文件路径和摘要重要数据全部走文件流转pytest 并发执行时端口冲突多个用例同时启动同一服务executor 里加一个并发控制策略同一时间只跑一个危险用例或用独立端口参数报告里的通过率跟实际执行对不上report-builder 直接读取 pytest 原始输出而不是标准化 results.json统一以 executor 写的 results.json 为准删除对终端文本的依赖Appium 始终连不上 Android 设备adb 服务状态异常或设备离线executor 执行前先跑adb devices设备不存在则提示重启 adb 服务不要盲目重试这些问题的共同点大多数不是模型能力不够而是 Skill 的边界和触发条件没设计好。把它们一一修正之后整条链路的稳定性会有非常明显的提升。6. 落地效果与后续还能怎么扩展这套五个 Skill 的组合跑通之后最直观的收益是“从需求到报告”的耗时大幅缩短。举个例子一个登录加下单的中型流程拆成 6 条用例过去测试工程师从头写脚本、跑环境、定位失败、拼报告平均要 50 分钟到一个小时。现在丢给 Agent 一条指令平均 10 到 15 分钟能拿到一份带失败根因和修复建议的 PDF 报告。模型偶尔生成的代码还要人工 review 微调但整体节奏完全不一样了。后续我计划做三件事。一是接一个页面元素知识库让 script-generator 生成选择器时参考历史沉淀减少踩重复的坑。二是引入视觉能力让 failure-analyzer 不只看日志还通过截图做视觉断言比如判断按钮是否被遮挡、样式是否错乱。三是把多轮执行结果存起来让报告不仅显示本次情况还能带出连续几轮通过率的变化趋势给团队做质量看板用。如果你也想在自己的项目里落地这套玩法我的建议是别一上来就把 5 个 Skill 全部搭完先把最核心的 3 个跑起来spec-parser、script-generator、executor。这三者能打通从需求到执行的链路价值已经非常明显。等稳定了再加上 failure-analyzer 和 report-builder逐步补全整条流水线。实测下来这种小步快跑的方式比一次到位的试错成本低太多。