1. 从“手搓提示词”到“Skill 工程化”我为什么攒了这 25 个 AI 测试 Skill这两年我一直在做 AI 测试和 Agent 相关的落地从最早用 pytest 写接口自动化到后来折腾 Appium、Maestro 做移动端再到现在把大量重复劳动交给 AI Agent 去跑。说实话真正让我效率翻倍的不是某个大模型又升级了而是我把日常那些高频、琐碎、需要反复交代的测试动作沉淀成了一个个可复用的Skill。所谓 Skill你可以把它理解成给 AI Agent 准备的“技能包”或者“操作手册”。它不像传统自动化脚本那样写死每一步而是把一类任务的上下文、工具调用方式、判断逻辑、输出格式打包在一起让 Agent 在遇到相似场景时能直接调用。打个比方以前你让 AI 帮你写个登录接口的测试用例你得把接口文档、字段规则、断言逻辑全贴一遍现在你只要说“用登录测试 Skill 跑一遍”它自己就知道该读哪个文档、该覆盖哪些边界、该输出什么格式的报告。我日常在用的这 25 个 Skill覆盖了从接口测试、UI 自动化、数据构造、缺陷分析到测试报告生成的全链路。它们不是那种“玩具级”的演示而是我在真实项目里反复打磨、踩了无数坑之后留下来的。有些 Skill 只有几十行配置但省下来的时间是以小时计的有些 Skill 逻辑复杂到需要嵌套调用其他 Skill但一旦跑通整个回归测试的节奏都变了。这篇文章适合三类人看一是正在做 AI 测试开发、想把手头重复工作 Skill 化的工程师二是刚接触 Agent、想知道 Skill 到底怎么落地的人三是团队里负责测试效能、想推动自动化升级的技术负责人。我会把每个 Skill 的设计思路、核心参数、实操步骤和踩坑经验都摊开讲不藏私也不堆砌术语。你看完至少能拿走三五个直接能用的 Skill 模板剩下的也能照着思路自己搭。2. 先搞明白 Skill 和 Agent 的关系不然全是白搭2.1 Skill 不是脚本Agent 也不是万能胶很多人一上来就问“Skill 和 Agent 到底啥区别”我用一个生活化的类比来解释。Agent 就像一个刚入职的测试工程师脑子聪明、学习能力强但对你公司的业务、工具链、规范一无所知。Skill 就是你给他的那本《测试操作手册》里面写清楚了“遇到接口测试该用哪个框架”“UI 元素定位不到时该重试几次”“报告里必须包含哪些字段”。没有 Skill 的 Agent你每次都得从头交代一遍它每次都可能给你不一样的答案。有了 Skill它就变成了一个“带着手册上岗”的熟练工输出稳定、可预期。我见过太多人把 Agent 当万能胶什么都让它现学现卖结果就是每次跑出来的东西都不一样根本没法进 CI 流程。Skill 的本质是约束和复用。约束是告诉 Agent 什么能做、什么不能做、按什么顺序做复用是让同一套逻辑在不同项目、不同环境里都能跑。我攒这 25 个 Skill 的过程其实就是不断把“口头交代”变成“书面规范”的过程。2.2 一个 Skill 的最小结构长什么样我自己的 Skill 通常包含五个部分缺一不可。第一部分是触发条件也就是什么情况下该调用这个 Skill比如“当用户提到登录接口测试时”或者“当检测到 UI 元素定位失败时”。第二部分是输入参数比如接口地址、测试账号、环境标识。第三部分是执行步骤这是核心要写清楚先做什么、再做什么、遇到分支怎么走。第四部分是工具依赖比如需要调用 pytest、requests、Appium 还是某个内部平台。第五部分是输出格式报告是 JSON 还是 Markdown包含哪些字段。这五个部分看起来简单但真正写起来最容易出问题的是第三部分和第五部分。执行步骤写得太粗Agent 就会自由发挥输出格式不固定下游就没法自动解析。我后面会结合具体 Skill 一个个拆。2.3 为什么是 25 个而不是 10 个或 50 个这个数字不是拍脑袋定的。我按测试活动的生命周期梳理了一遍需求分析阶段需要 2 个用例设计阶段需要 4 个环境准备阶段需要 3 个接口测试阶段需要 5 个UI 测试阶段需要 4 个数据构造阶段需要 3 个缺陷分析阶段需要 2 个报告生成阶段需要 2 个。加起来正好 25 个。少于 25 个很多场景就得临时拼凑Agent 的稳定性会下降多于 25 个维护成本太高而且很多 Skill 之间功能重叠反而让 Agent 不知道该选哪个。这 25 个是我目前觉得“刚好够用且不冗余”的平衡点。当然随着项目变化这个数字还会调整但核心思路不变按测试生命周期覆盖按使用频率排序按维护成本取舍。3. 接口测试类 Skill从用例生成到断言校验的 5 个核心件3.1 接口用例自动生成 Skill读文档、抽字段、补边界这个 Skill 是我用得最频繁的之一。它的触发条件很简单用户提供接口文档Swagger、OpenAPI 或者 Markdown 格式都行并说明需要生成测试用例。输入参数包括文档路径、接口筛选条件比如只生成某个模块的、用例数量上限。执行步骤分四步。第一步是解析文档提取每个接口的路径、方法、请求参数、响应结构。第二步是字段分析对每个参数判断类型、是否必填、取值范围。第三步是边界补充根据字段类型自动生成边界值比如字符串长度取 0、1、最大长度、最大长度加一数字取最小值、最大值、零、负数。第四步是组合输出把正常用例和边界用例按优先级排序输出成 YAML 或 JSON 格式。这里有个关键细节不要指望 AI 一次生成所有边界。我的做法是让 Skill 先生成基础用例然后单独跑一个“边界补充”子流程。这样做的原因是基础用例的准确率很高但边界用例需要结合业务规则AI 容易过度发挥。分开跑人工审核边界用例的成本更低。注意接口文档里的枚举值一定要让 Skill 完整提取我踩过坑漏了一个枚举值导致线上出现未覆盖的分支。3.2 接口断言智能校验 Skill不只是状态码 200很多人写接口测试断言只写一个status_code 200这跟没写差不多。这个 Skill 的作用是根据接口的响应结构自动生成多层断言。第一层是 HTTP 状态码第二层是业务状态码第三层是关键字段的存在性和类型第四层是字段值的合理性校验。举个例子一个查询用户信息的接口返回里有个create_time字段。基础断言只检查它存在但这个 Skill 会进一步检查它是否符合时间格式、是否在合理范围内、是否小于当前时间。这些规则不是硬编码的而是 Skill 根据字段名和类型推断出来的。实操的时候我会把这个 Skill 和上面的用例生成 Skill 串联使用。先生成用例再对每个用例自动补断言。这样一套下来接口测试的覆盖率和有效性都上了一个台阶。参数方面我通常会设置一个“断言严格度”开关分宽松、标准、严格三档。宽松档只查状态码和关键字段存在性标准档加上类型和格式校验严格档再加上值域和业务规则校验。日常回归用标准档上线前用严格档。3.3 接口依赖链自动编排 Skill解决登录态和前置数据接口测试最烦的就是依赖。你要测一个下单接口得先登录拿 token再查商品拿 ID再查库存确认有货。这个 Skill 就是专门解决依赖编排的。它的核心逻辑是读取所有接口的输入输出自动构建依赖图然后按拓扑顺序生成调用链。具体实现上我会让 Skill 先扫描所有接口的请求参数和响应字段找出哪些参数是其他接口的输出。比如下单接口需要token和product_id而登录接口输出token商品查询接口输出product_id那依赖关系就建立了。然后 Skill 会生成一个编排脚本按顺序调用这些接口并把前一个接口的输出提取出来传给下一个。这里有个坑循环依赖。我遇到过 A 接口依赖 B 的输出B 又依赖 A 的输出这种情况 Skill 会报错并提示人工介入。我的处理方式是设置一个“依赖深度上限”超过三层就强制人工确认避免 Agent 陷入死循环。3.4 接口 Mock 数据生成 Skill让前端不再等后端这个 Skill 主要是给前后端联调用的。触发条件是用户提供一个接口定义需要生成 Mock 数据。执行步骤是解析接口的响应结构根据字段类型和名称生成合理的假数据然后启动一个本地 Mock 服务把接口路径和假数据绑定。字段类型和假数据的映射关系我整理了一个表放在 Skill 的配置里。比如name字段生成中文姓名email生成合法邮箱phone生成手机号id生成 UUID 或自增数字price生成两位小数的金额。这个映射表是可以扩展的项目里有什么特殊字段直接加进去就行。提示Mock 数据里的时间字段建议生成相对时间比如“当前时间减一天”而不是写死一个日期否则过几天数据就过期了。3.5 接口性能基线对比 Skill回归时顺手跑个压测这个 Skill 是我最近才加进来的但已经帮我发现了两次性能退化。它的逻辑是在接口回归测试跑完后自动对核心接口发起一轮轻量压测记录响应时间、吞吐量、错误率然后和上一次的基线数据对比。如果某个指标退化超过阈值我设的是 20%就自动标记出来。参数方面压测并发数我一般设 10 到 50持续时间 30 秒到 1 分钟避免对测试环境造成太大压力。基线数据存在一个 JSON 文件里每次跑完自动更新。这个 Skill 的价值在于它把性能测试从“专门安排一次”变成了“回归时顺手做掉”成本几乎为零但收益很大。4. UI 自动化类 Skill让 Agent 自己找元素、自己重试4.1 元素定位智能重试 Skill告别 NoSuchElementExceptionUI 自动化最头疼的就是元素定位失败。网络慢一点、动画没结束、弹窗遮挡都会导致找不到元素。这个 Skill 的核心是当定位失败时不是直接报错而是按策略重试。重试策略分三层第一层是等待等 1 秒、2 秒、3 秒递增第二层是换定位方式比如从 ID 换成 XPath 再换成 CSS Selector第三层是截图并调用视觉识别让 AI 看看元素到底在哪。我实测下来三层策略能把元素定位失败率降低 80% 以上。参数配置上等待时间上限我设 10 秒超过就判定为真失败。视觉识别作为最后手段准确率不是 100%但比直接报错强。4.2 页面对象自动生成 Skill从页面结构到 PO 模型Page Object 模式是好东西但手写太累。这个 Skill 的做法是给它一个页面 URL 或者页面截图它自动分析页面结构提取出可交互元素按钮、输入框、下拉框、链接然后生成对应的 Page Object 类。类里面包含元素定位器和常用操作方法。生成出来的代码不是完美的但能省掉 70% 的重复劳动。我一般会在这个基础上手动调整比如合并相似元素、补充业务方法。这个 Skill 支持多种语言输出Python、Java、JavaScript 都行取决于你项目用什么技术栈。4.3 跨端 UI 测试适配 Skill一套用例跑 Web 和 App这个 Skill 解决的是同一套测试逻辑在不同端上复用的问题。它的思路是把测试步骤抽象成“动作 目标 断言”的三元组比如“输入 用户名输入框 值等于 admin”。然后针对 Web 端和 App 端分别配置元素定位映射表。执行的时候Skill 根据当前端类型自动选择对应的定位方式。我目前用它来跑登录、搜索、下单这几个核心流程Web 端用 SeleniumApp 端用 Appium用例逻辑完全共享只有定位配置不同。这样维护成本大幅降低改一个业务逻辑两端同时生效。4.4 视觉回归对比 Skill像素级差异自动识别UI 改版之后怎么快速知道哪些页面视觉上变了这个 Skill 的做法是在测试执行过程中自动截图然后和基线截图做像素级对比。差异超过阈值就标记出来并生成差异图。阈值我一般设 0.5%也就是 1000 个像素里有 5 个不同才报警。这个阈值可以根据页面复杂度调整复杂页面设高一点简单页面设低一点。差异图会高亮显示变化区域方便快速定位。这个 Skill 在响应式布局测试里特别好用能一次性发现多个断点的视觉问题。5. 数据构造与缺陷分析类 Skill脏活累活交给机器5.1 测试数据工厂 Skill按规则批量造数据造测试数据是个体力活尤其是需要大量用户、订单、商品数据的时候。这个 Skill 的输入是数据模板和生成规则比如“生成 1000 个用户其中 10% 是 VIP5% 是禁用状态”。输出是 CSV、JSON 或者直接插入数据库。我常用的规则包括随机姓名、随机手机号、随机邮箱、随机地址、随机金额、随机时间。这些规则都封装在 Skill 里调用的时候只需要指定数量和分布比例。有个细节要注意手机号和邮箱要保证唯一性否则插入数据库会报错。我的做法是生成时加一个递增序号或者随机后缀。5.2 数据库状态快照 Skill测试前后自动对比这个 Skill 解决的是“测试到底改了哪些数据”的问题。它的逻辑是在测试开始前对指定表做一次快照测试结束后再做一次然后对比差异。差异包括新增记录、删除记录、修改记录。输出是一份变更报告标明哪些数据被影响了。这个 Skill 在测试数据清理和回归验证时特别有用。比如你跑了一个下单流程想知道到底生成了哪些订单、扣了哪些库存快照对比一目了然。参数方面可以指定要快照的表名、字段过滤条件、对比精度比如忽略时间戳字段。5.3 缺陷根因分析 Skill从报错日志到可能原因测试失败之后最花时间的就是定位原因。这个 Skill 的做法是收集失败用例的日志、截图、请求响应然后让 AI 分析可能的根因并按可能性排序。比如“元素定位失败”可能是页面加载慢、元素被遮挡、定位器写错“接口断言失败”可能是数据问题、逻辑变更、环境差异。这个 Skill 不是万能的但它能给出排查方向省掉很多盲目试错的时间。我一般会把它和元素定位重试 Skill 配合使用重试失败后再触发根因分析。5.4 测试覆盖率缺口分析 Skill找出没测到的地方这个 Skill 的输入是代码覆盖率报告和需求文档输出是覆盖率缺口列表。它会对比需求里提到的功能点和实际覆盖的代码路径找出哪些功能没测、哪些分支没覆盖。然后按风险等级排序高风险缺口优先补用例。我实测下来这个 Skill 能发现人工容易忽略的边界分支和异常路径。参数方面可以设置覆盖率阈值比如分支覆盖率低于 80% 就报警。6. 报告生成与协作类 Skill让测试结果自己说话6.1 测试报告自动生成 Skill从原始数据到可读报告跑完测试原始数据一堆但领导要看的是结论。这个 Skill 的作用是收集所有测试结果按模块、优先级、失败原因分类汇总生成一份包含通过率、失败列表、趋势图的报告。输出格式支持 Markdown、HTML、PDF。我一般会配置几个关键指标总用例数、通过数、失败数、跳过数、通过率、执行时长、失败原因分布。报告里还会自动附上失败用例的截图和日志链接方便快速定位。6.2 缺陷自动提单 Skill失败用例一键转 Bug这个 Skill 和缺陷管理系统对接当测试用例失败且确认是缺陷时自动创建 Bug 单。字段包括标题、描述、复现步骤、优先级、附件截图和日志。标题和描述由 AI 根据失败信息生成复现步骤从测试用例里提取。这里有个安全阀自动提单前必须人工确认。我设置了一个确认环节Skill 生成提单草稿后需要人工点确认才会真正提交。这样避免误报污染缺陷库。6.3 多 Agent 协作调度 Skill让不同 Agent 各司其职这个 Skill 稍微复杂一点它管理的是多个 Agent 之间的协作。比如一个 Agent 负责接口测试一个负责 UI 测试一个负责数据分析。调度 Skill 的职责是分配任务、收集结果、处理冲突。我目前用它来跑每日回归调度 Skill 先触发接口测试 Agent等接口测试通过后再触发 UI 测试 Agent最后触发报告生成 Agent。如果接口测试失败UI 测试就跳过直接生成失败报告。这样避免了无效执行也节省了资源。7. 实操避坑指南我踩过的那些坑和总结的经验7.1 Skill 粒度控制太粗和太细都是灾难我一开始把 Skill 写得很粗一个 Skill 管所有接口测试结果 Agent 经常搞混场景输出不稳定。后来我又走向另一个极端把每个接口都写成一个 Skill结果维护成本爆炸改一个公共逻辑要改几十个文件。现在的做法是按测试活动类型划分 Skill按项目配置区分具体行为。比如“接口用例生成”是一个 Skill但不同项目的接口文档格式、字段规则通过配置文件区分。这样既保证了逻辑复用又保留了灵活性。7.2 参数默认值别让 Agent 自己猜Skill 的参数一定要有合理的默认值。我吃过亏有个 Skill 没设默认超时时间Agent 有时候等 5 秒有时候等 30 秒导致测试结果不稳定。后来我给所有涉及等待的参数都设了默认值并且写在 Skill 描述里Agent 就不会乱猜了。默认值的设定原则是取常见场景的中间值偏保守。比如超时默认 10 秒重试默认 3 次并发默认 10。7.3 错误处理失败要失败得明明白白Skill 执行失败时输出信息一定要包含失败步骤、失败原因、当前上下文、建议操作。我见过很多 Skill 失败就报一个“执行错误”啥也看不出来。我的做法是在每个关键步骤都加错误捕获失败时输出结构化信息。这样无论是人工排查还是 Agent 自动处理都有据可依。7.4 版本管理Skill 也要进 GitSkill 配置文件一定要纳入版本管理。我一开始觉得 Skill 就是几个配置文件随手改改就行结果有次改错了一个参数导致整个回归测试跑偏查了半天才发现是 Skill 的问题。现在所有 Skill 都放在 Git 仓库里每次修改都有记录可以回滚、可以对比。建议给 Skill 也加上版本号重大变更时升级版本避免影响正在使用的流程。7.5 安全边界哪些事绝对不能让 Agent 干有些操作必须设人工确认环节比如删除数据、提交缺陷、修改生产配置。我的原则是读操作可以自动写操作必须确认删操作绝对禁止自动。Skill 里会明确标注哪些步骤需要人工介入Agent 执行到这些步骤时会暂停等待确认。这样既享受了自动化的效率又守住了安全底线。8. 常见问题速查与排查思路8.1 Skill 不触发或者触发错误怎么办先检查触发条件是否写得太宽泛或太具体。太宽泛会导致误触发太具体会导致该触发时不触发。我的经验是触发条件里至少包含一个明确的关键词和一个场景描述。比如“当用户提到登录接口测试时”就比“当用户提到测试时”好得多。如果还是有问题可以在 Skill 里加一个调试开关输出触发判断的详细日志。8.2 Agent 执行 Skill 时卡住不动最常见的原因是某个步骤在等待一个永远不会满足的条件。比如等待一个元素出现但元素根本不存在。排查方法是看 Skill 的执行日志找到最后执行的步骤检查该步骤的等待条件是否合理。我的做法是给所有等待步骤设上限超时后自动跳过并记录警告而不是无限等待。8.3 Skill 输出格式不对下游解析失败输出格式一定要在 Skill 里严格定义并且加校验。我通常会在 Skill 的最后一步加一个格式校验不符合预期格式就报错而不是把错误数据传给下游。另外输出格式的版本也要管理下游解析逻辑要跟 Skill 输出格式版本对应。8.4 多个 Skill 冲突Agent 不知道选哪个这种情况通常是因为两个 Skill 的触发条件有重叠。解决办法是给 Skill 设优先级或者在触发条件里加互斥规则。比如“接口用例生成”和“接口 Mock 生成”都涉及接口文档但前者用于测试后者用于联调触发条件里要明确区分使用场景。常见问题可能原因排查方法解决措施Skill 不触发触发条件太窄查看触发日志放宽关键词或增加场景描述执行卡住等待条件不满足检查最后执行步骤设等待上限超时跳过输出格式错误格式定义不严校验输出内容加格式校验版本管理多 Skill 冲突触发条件重叠查看触发优先级设优先级或互斥规则参数不稳定默认值缺失检查参数配置补默认值偏保守设定9. 后续扩展方向这 25 个 Skill 还能怎么进化9.1 从单机 Skill 到 Skill 市场我现在这 25 个 Skill 都是自己项目里用的但很多逻辑是通用的。下一步我想把它们整理成可分享的 Skill 包团队里其他人可以直接导入使用。再远一点如果能形成一个内部的 Skill 市场大家把自己写的 Skill 传上去互相复用整体效率还能再上一个台阶。9.2 让 Skill 自己进化基于执行反馈自动优化目前 Skill 的优化还是靠人工跑一段时间发现哪里不好就改哪里。我在尝试让 Skill 记录每次执行的反馈比如哪些步骤经常失败、哪些参数经常需要调整然后基于这些数据自动推荐优化方案。这个方向还在探索阶段但我觉得是 Skill 工程化的必经之路。9.3 跨项目 Skill 迁移一套 Skill 跑多个业务线不同业务线的测试场景有差异但底层逻辑是相通的。我在尝试把 Skill 的核心逻辑和项目配置彻底分离核心逻辑不变项目配置按业务线切换。这样一套 Skill 可以服务多个项目维护成本大幅降低。目前接口测试类 Skill 已经做到了这一点UI 测试类还在推进中。9.4 和 CI/CD 深度集成Skill 成为流水线的一等公民现在我的 Skill 主要还是手动触发或者定时触发下一步想和 CI/CD 流水线深度集成。比如代码提交后自动触发接口测试 Skill合并请求前自动触发 UI 测试 Skill发布前自动触发全量回归 Skill。Skill 的执行结果直接作为流水线的质量门禁不通过就阻断发布。这样测试才真正成为研发流程的一部分而不是一个独立的环节。我个人在实际操作中的体会是Skill 的价值不在于数量多而在于每个 Skill 都经过真实项目的打磨知道它的边界在哪、坑在哪。这 25 个 Skill 我还会继续迭代有些可能会合并有些可能会拆分但核心思路不会变把重复劳动沉淀成可复用的能力让 Agent 干它擅长的让人干人擅长的。最后再分享一个小技巧每次写完一个 Skill先别急着用拿三个不同的场景跑一遍看看输出是否稳定。稳定了再纳入日常流程不稳定就继续改。这个习惯帮我省了很多返工的时间。