上个月我做了一次完整的UI回归测试结束之后干的第一件事是把花了两周时间精心调教的那个“万能Skill”整个删掉了。不是它不聪明恰恰是它太“全能”反而成了整个测试流程里最难用的一环。这篇文章想给你一套正好相反的思路——不搞万能Skill而是用5个职责单一的Agent Skill把UI自动化从脚本生成、驱动配置、断言编写、失败诊断到报告生成这段最耗体力的链路完整串起来。适合正在用或准备用Agent做测试提效的测试工程师也适合想戒掉“宏大Skill瘾”的Agent爱好者。1. 先泼一盆冷水我为什么把“万能Skill”扔进了回收站那会儿我刚接触Agent不久和很多测试同学一样第一反应是“既然AI这么强干脆做一个全流程通吃的Skill”。我给它取了个名字叫QA-Master听起来就很厉害。里面塞了录制脚本转换、驱动配置、断言生成、失败重跑、报告生成甚至还有测试数据造数几乎把UI自动化团队的活全包了。实际用起来就像把整个测试团队的活压在一个实习生身上什么都接什么都做得不够专业。第一个问题是上下文被打爆。Skill的描述文件越来越长System Prompt加到了几千字每次Agent调用时模型都得把整套指令重新读一遍响应速度从几秒拖到十几秒。第二个问题是不可控。某个环节出了问题比如断言写得不稳你得判断到底是用户给的信息不够还是Skill里的指令写岔了排查链路很长。第三个问题最致命复用性极差。换一个项目录制的轨迹格式不同、页面元素规则不同整个万能Skill几乎要推倒重来。后来我换了一个思路把QA-Master拆成了几个各管一段的专用Skill。效果立刻不一样每个Skill指令短、定位清晰AI执行起来又快又准换项目时只需要调整其中一个Skill其他完全不动。这也让我重新理解了Skill和Agent的关系——Agent是那个根据目标做规划、决定下一步做什么的“大脑”Skill是它随时能抽出来用的“专业工具包”。你让Agent去完成一次回归测试它会想先准备环境、再生成用例、执行、出问题再诊断、最后出报告。这个想的过程就是Agent在工作而每一步具体用什么方式执行靠的是Skill。做完这个拆分之后我回头看热搜里那些关于“skill和agent的区别”“agent做项目是不是需要很多个skill”的问题其实答案已经很明显了项目当然需要多个Skill但Skill多不代表堆料。关键是粒度要小、职责要单一、能独立验证。接下来就按这个思路讲讲我在UI自动化这条链路上最终沉淀下来的5个Skill。2. UI自动化全链路里哪些环节值得做成Skill在写Skill之前你得先把这条流水线摆上桌看清楚。一次完整的UI自动化从0到1大致要经过这些环节梳理测试需求、准备浏览器和驱动环境、录制或编写操作轨迹、把轨迹转成可执行脚本、编写断言、跑测试用例、失败用例诊断、聚合测试结果、生成报告、发给相关同事。这中间并不是每一环都适合用Skill封装有的环节交给AI反而画蛇添足。我把每个环节过了一遍做了个价值评估环节做成Skill的价值是否推荐原因需求分析和用例设计低否高度依赖业务上下文AI容易放飞更适合人工主导环境准备浏览器驱动高是版本匹配问题出现频率极高解决路径确定脚本生成高是录制轨迹到代码是强模板化翻译AI效率远超手写断言编写中高是需要语义判断但限定边界后AI很稳测试执行中否本来就该由CI或pytest负责不需要单独Skill失败诊断高是排查链路人肉走很慢AI能显著提速结果聚合中低否测试框架自带做成Skill反而增加维护成本报告生成高是模板化强、跨团队复用价值高还能顺带接监控数据通知与告警低否一行配置的事做成Skill收益低筛完之后我留下了5个分别对应脚本生成、驱动配置、断言编写、失败诊断、报告生成。这5个环节省掉的都是每天重复的机械劳动而且每一环的输入输出都能被明确定义Skill做出来之后天然方便串联。为什么不是更多比如执行环节我也试过但做完之后发现多此一举——pytest或者CI本来就能跑Agent去调用一遍反而绕远路。Skill不是越多越好而是要把Agent从“被迫思考如何执行细节”的负担里解放出来。5个刚好覆盖从执行到报告的主干价值链路再多就会回到维护成本失控的老路。3. 逐个拆解5个Skill的输入、输出与核心设计这一节是整篇的核心干货。每个Skill我会把它的定位、输入输出设计和最容易踩的细节一次说清。3.1 Skill 1ui-recorder录制轨迹一键变成可用脚本录制回放工具很多但录完生成的脚本往往带着一堆录制器独有的冗余标记直接跑根本不行。ui-recorder这个Skill的作用是接收录制轨迹文件输出干净的、符合团队代码规范的测试脚本。它面对的核心问题是格式转换AI做这种强模板化的翻译非常擅长。我在设计里把录制轨迹定义成了统一的JSON schema不管Web端还是Android端录制器导出的数据都先规范成这个格式{ url: https://shop.example.com/login, device: desktop, actions: [ {type: goto, value: https://shop.example.com/login, waitUntil: load}, {type: type, selector: #username, value: test_user}, {type: type, selector: #password, value: Passw0rd!}, {type: click, selector: button.login-btn}, {type: waitForURL, value: **/home} ] }Agent拿到这个JSON之后按要求输出一段Playwright脚本def test_login(page): page.goto(https://shop.example.com/login, wait_untilload) page.fill(#username, test_user) page.fill(#password, Passw0rd!) page.click(button.login-btn) page.wait_for_url(**/home)这里有一个很关键的细节Skill指令里必须写明“识别动态数据并参数化”。录制轨迹里经常会出现时间戳、随机生成的订单号、手机号这些动态值如果不处理第二天回放就必定失败。我的做法是让Skill把这类值自动替换成参数占位符并在脚本里加上对应的fixture或数据文件。如果用的是Appium录制的Android轨迹schema不一样但只要在Skill指令里声明支持两种格式并给每个端一到两个示例Agent就能完成跨端转换。3.2 Skill 2browser-driver-setup把环境配置做成确认式操作UI自动化里有一个特别烦的问题浏览器驱动和浏览器版本不匹配。Chrome一升级chromedriver马上罢工所有用例在环境准备阶段就挂了。我之前处理这个问题靠的是搜索引擎和记忆现在靠browser-driver-setup这个Skill。它的设计目标是把环境配置做成一次确认式操作而不是靠人肉翻文档。这个Skill会先指导Agent去探测当前浏览器版本google-chrome --version拿到版本号之后再根据项目技术栈输出对应的安装命令和验证脚本。如果是Selenium项目会给到对应版本的ChromeDriver下载链接如果是Playwright项目直接让Agent输出playwright install这类自动管理驱动的命令。Skill里还内置了一个决策逻辑优先推荐让工具自动管驱动因为手动维护driver版本清单的工作量根本不值得。这里我想强调一个经验很多测试同学用Selenium习惯了但从维护成本来说Playwright这类自带驱动管理的方案省心得多。Skill的输出里会明确标注更优方案让Agent在遇到版本匹配问题时不只是“修好”还会提示团队可以往哪个方向做根治。3.3 Skill 3assert-writer让AI写会“等”的断言断言是最容易“看起来对、跑起来挂”的环节。很多AI生成的断言是直接把页面取到的文本和期望值做硬比较完全没考虑页面渲染、网络延迟这些因素结果就是用例偶发失败。assert-writer这个Skill要解决的就是这个问题让AI生成带显式等待和重试语义的断言代码。使用方式很简单测试人员告诉Agent“我要校验订单金额大于99支付成功文案要出现”Skill会约束AI输出分类明确的断言# 存在性断言 expect(page.locator(.toast.success)).to_be_visible(timeout10000) # 文本匹配 expect(page.locator(.order-title)).to_have_text(支付成功) # 数值断言 total_price float(page.locator(.total).inner_text().replace(¥, )) assert total_price 99, f金额异常: {total_price}三类断言分别对应页面元素是否出现、文本内容是否符合预期、数值范围是否合理。用到to_be_visible和to_have_text这种带自动重试的API比直接assert一个inner_text要稳得多。这也是我给这个Skill定的一条铁律凡是涉及UI状态的断言禁止输出没有等待逻辑的裸代码。如果你在别的AI工具里让它“随便写一段断言”大概率拿到的就是裸断言跑两轮就露馅了。3.4 Skill 4failure-doctor失败用例不再靠肉眼翻日志用例失败之后最耗时间的不是修代码而是定位问题出在哪。并发冲突、元素没找到、断言值对不上、驱动挂了、网络超时每一种失败的处理方式都不一样。failure-doctor这个Skill做的事情就是给AI划定一个分析框架让它按分类来诊断而不是自由发挥。我在Skill里内置了这么一张分类表失败类型常见日志Agent应该看哪里处理建议元素定位失败TimeoutError, NoSuchElementselector是否为动态ID或绝对路径改用data-testid或相对定位断言失败AssertionError实际值与期望值对比判断是否为文案或数据变更环境异常WebDriverException浏览器版本与驱动匹配情况调用browser-driver-setup重新配置疑似业务bug无通用日志关键词截图和页面元素状态标记为需人工确认Skill的指令会要求Agent先输出“失败类型选项”再给“判断依据”最后才给“修复建议”。这样设计的好处是即使AI最后的判断出了偏差测试人员也能快速看出它是在哪一步跑的偏。实际用下来这个Skill能消灭大概80%的“哦原来是环境问题”的无效人工排查剩下的20%它也能把现场信息整理得明明白白再交给人工。3.5 Skill 5report-builder测试结果和监控截图自动汇成PDF报告生成是跨团队价值最高的一个环节却往往被忽略。report-builder这个Skill的职责是读取测试结果JSON结合截图和监控数据输出一份能直接发出去的HTML和PDF报告。它不是简单地堆数据而是按团队模板排版。我的做法是让Skill先生成干净HTML模板再用无头浏览器打印成PDFplaywright pdf report.html report.pdf如果团队有Grafana监控我会在Skill里额外编排一个步骤用Grafana的渲染接口导出一张当晚时段的监控截图然后把它嵌到报告里。这样测试负责人打开PDF一眼就能把用例通过率和后端负载关联起来看不用再切三个系统。模板里的关键信息一般包括执行项目、执行时间、通过率、失败用例明细、趋势图、每个关键用例的截图、环境说明。Skill允许传入团队自定义模板变量比如品牌名称、报告标题前缀生成时自动代入。4. 一次真实回归测试五个Skill是怎么在各站接力干活的理论说完了上实战。前阵子公司商城要做一次发版回归覆盖Web端的登录、搜索、加购、下单外加Android端的关键路径冒烟。放在以前这个流程光准备环境和处理录制脚本就得花掉一整个下午这次我全程用Agent编排这5个Skill来跑。整体调用顺序是这样的步骤使用的Skill输入输出1browser-driver-setupChrome版本、项目类型驱动配置命令与验证脚本2ui-recorder录制轨迹JSON可运行的pytest脚本3assert-writer页面URL、断言需求带等待策略的断言代码4执行阶段pytest命令测试结果JSON、截图、日志5failure-doctor失败用例的日志、截图原因分类、修复建议、是否重跑6report-builder结果JSON、截图、监控数据HTML报告 PDF编排层我直接用了Agent工作流逻辑是这样一段伪代码steps: - skill: browser-driver-setup input: { browser: chrome, project: shop } - skill: ui-recorder input: { trace: trace.json, framework: playwright-pytest } - skill: assert-writer input: url: order_success assertions: - total_price 99 - title 支付成功 - run: pytest tests/ -m regression - if_failed: skill: failure-doctor input: { logs: pytest-output, screenshots: failure_screenshots } - skill: report-builder input: results: result.json screenshots: [*.png] grafana_dashboards: [overview]中间有一个细节值得单独说一下。执行阶段中有一条用例因为网络抖动超时了failure-doctor读取日志后判定为环境异常并建议重跑一次。编排层按它的建议自动重跑了该用例第二次通过最终报告里这条用例被标记为“通过重跑一次”。整个过程我没有手工介入放在以前这种波动失败通常要人在CI日志里翻半天。整轮跑完结果JSON、失败截图、Grafana监控图自动汇进报告PDF生成后直接推到钉钉群。时间从以前的2到3天压缩到一上午主要省下来的不是执行时间而是脚本整理、环境处理、失败排查这些穿插在中间的等待和沟通成本。这给我最深的体会是Agent的价值不一定是一次性把节奏拉满而是把链路中每一段碎片化的人工操作变成了一条自动运转的流水线。5. Skill设计里容易忽略的四个关键决策很多教程只会教你写SKILL.md的格式但真正决定这套体系能不能长期跑下去的是下面四个设计决策。它们都是我在实际落地过程中被反复折磨之后总结出来的。第一个决策是输入输出全部JSON化。五个Skill接力上一站的输出就是下一站的输入如果输出是一段格式混乱的自然语言下游Skill根本没法稳定消费。JSON是最不依赖语言的中间格式字段可预期、可校验。我给每个Skill规定了严格的输入输出schema即使某个环节换成了别的实现接口也不变。第二个决策是Skill的粒度要“一站一段”。一个Skill只处理一个环节如果某个Skill的指令字数超过800就要考虑拆分了。这是一个经验阈值超过这个量级之后AI误读指令的概率明显上升且后续维护成本激增。反之也不要拆得过于细碎比如把“点击按钮”单独做成一个Skill那纯粹是折腾自己。第三个决策是Skill内部的结构要分层。一份好的SKILL.md不是一段长篇指令而是角色定位加固定指令加示例输入输出加防呆条款。角色定位告诉AI它在这个环节扮演什么固定指令是必须遵守的操作步骤示例让AI少走弯路防呆条款把容易犯的错误明令禁止。把这四部分清楚地分开比混在一段自然语言里稳定得多。第四个决策是给Skill本身写验收用例。每个Skill都准备一份最小的夹具数据比如ui-recorder的夹具是一条只有三步操作的录制轨迹assert-writer的夹具是一个带浮动价格的订单页面。每次改了Skill内容先跑一遍夹具确认输出没有回归。这个习惯一开始我觉得麻烦但救了我好几次——有次我在report-builder里加了个模板变量差点把原本能正常生成PDF的链路搞挂跑夹具后秒发现问题。Skill也是代码不测试就等于裸奔。6. 实测中踩到的五个坑以及对应修法最后分享五个我实际踩过的坑每一个都是付费买来的经验。如果你也打算把这套方法落地大概率会碰到其中几个。坑一是把整页DOM快照直接塞给AI。第一次用assert-writer时我让Agent读取page.content()拿到的完整HTML结果Prompt里塞了接近10万个字符模型开始输出一些前言不搭后语的断言。修法是在Skill指令里写明“只提取关键节点比如input、button、提示文案、价格等汇总为精简结构再提交给AI”也可以先用locator把目标元素缩小到具体范围再让AI分析。坑二是录制轨迹里的动态数据没有处理。录制时输入了带时间戳的账号第二天回放时账号已存在脚本启动就挂。修法是ui-recorder指令里强制要求识别动态值并参数化这个前面已经提过但值得再强调一遍因为它发生的频率太高了。坑三是AI生成了一堆又长又脆的XPath。它给了一个这样子的路径//*[idapp]/div[2]/div[1]/div[3]/button[2]下次前端加了一个隐藏节点选择器就挂了。修法是在Skill里明确规定禁止生成绝对路径XPath优先使用data-testid、role或者文本定位。前端同学只要约定好data-testid这个问题几乎可以根除。坑四是报告里的截图路径打不开。report-builder早期生成的PDF里图片用的是本机绝对路径文件发给Windows同事直接裂图。修法是所有图片在Skill内部先拷贝到报告目录用相对路径引用条件允许时直接base64嵌进HTML彻底摆脱环境依赖。坑五是录制轨迹里全是冗余回放动作。录了20次鼠标经过同一菜单生成的脚本跑起来慢、还容易误触。修法是在Skill指令里加一条“轨迹清理规则”连续对同一元素的操作只保留最后一次间隔过短的移动事件合并超过3秒的等待记录为显式等待。经过这一层过滤脚本长度和稳定性都有明显改善。等这些坑填完之后我发现这5个Skill带给团队最大的价值反而不是测试提效本身而是把个人脑子里那套“怎么跑测试”的经验变成了每个成员都能调用的知识资产。招了个新人不需要从零教他怎么配驱动、怎么写断言直接让他跟着Agent把这些Skill跑一遍基本就上手了。如果你想照着做我的建议是别急着一次性铺开所有环节先从你上个月最痛的那个测试环节开始做一个Skill跑稳再加下一个。