1. 从“测试”这件事说起：为什么我开始攒 AI 测试 Skill

做测试这行十来年，我经历过纯手工点页面的年代，也经历过 Selenium 脚本满天飞的年代，再到后来接口自动化、性能压测、安全扫描各成体系。但真正让我觉得“工作方式被改写”的，是最近一两年把 AI 拉进测试流程之后。标题里说的“AI 测试 Skill 大全，我日常在用的 25 个”，不是什么官方清单，而是我自己在项目里反复用、反复改、最后沉淀下来的一套东西。所谓 Skill，你可以理解成给 AI 助手预设好的“角色 + 指令 + 上下文 + 输出格式”的组合包，它让 AI 从一个什么都聊两句的通用助手，变成一个懂测试、懂你项目、能直接产出可用结果的专用工具。

这篇文章适合谁看？如果你是被重复用例、重复报告、重复排查折磨的测试工程师，如果你是带团队、想让 AI 真正落地而不是停留在“帮我写个用例”的测试负责人，如果你是刚接触 Agent、Claude 这类工具、想知道别人到底怎么用的新手，那这篇内容应该能给你省下不少自己摸索的时间。我不会只列名字，而是把每一类 Skill 背后的设计逻辑、关键参数、实操步骤、踩过的坑都摊开讲。25 个 Skill 我会按功能分组，但重点不是数量，而是让你看完能自己造出第 26 个、第 27 个。

先说清楚一个前提：Skill 不是插件，也不是某个平台的专属功能。它本质是一段结构化的提示词工程产物，配合 Agent 的工具调用能力（读文件、跑命令、查接口、写报告）才能发挥威力。所以你在 Claude、在支持 Agent 的 IDE、在自建的 Agent 框架里，都能用同一套思路。我下面讲的所有内容，都围绕“怎么设计、怎么用、怎么避坑”展开，不绑定任何特定平台。

2. 测试 Skill 的整体设计思路：先想清楚 AI 该干什么

2.1 为什么不是“一个万能提示词”打天下

刚开始我也偷懒，写了一个巨长的提示词，想让 AI 同时干用例生成、缺陷分析、报告汇总。结果就是它每件事都干得马马虎虎：生成的用例边界条件不全，缺陷分析抓不住根因，报告写得像流水账。后来我想明白了，这跟带新人一样——你不可能让一个新人同时负责功能测试、性能测试、安全测试还都做到位。Skill 的价值就在于“专事专办”，一个 Skill 只解决一类问题，输入输出边界清晰，AI 的注意力才不会被稀释。

我现在的做法是：按测试活动的阶段来切分 Skill。需求阶段有需求解析和测试点提取，设计阶段有用例生成和用例评审，执行阶段有脚本生成、数据构造、日志分析，收尾阶段有缺陷归因和报告生成。每个 Skill 独立可测，组合起来就是一条完整的 AI 辅助测试流水线。这样做还有个好处：某个 Skill 效果不好，我单独调它就行，不会牵一发动全身。

2.2 Skill 的三层结构：角色、约束、输出

我攒下来的 25 个 Skill，拆开看都是同一个骨架，我管它叫“三层结构”。第一层是角色设定，告诉 AI“你是谁”，比如“你是一名有五年经验的接口测试工程师，熟悉 RESTful 规范和常见鉴权方式”。第二层是约束条件，这是最关键的，包括输入格式、必须遵守的规则、禁止做的事情，比如“只基于我提供的接口文档生成用例，不要臆造字段”“每条用例必须包含前置条件、步骤、预期结果”。第三层是输出格式，明确要求用表格、用 JSON、用 Markdown，甚至规定字段名。

很多人写 Skill 效果差，问题基本都出在第二层太弱。AI 天生喜欢“发挥”，你不约束它，它就给你编。我踩过最典型的一个坑：让它根据需求文档生成测试点，它把文档里没写的业务规则也“合理推断”进去了，结果评审时被产品经理当场指出错误。从那以后，我每个 Skill 里都会加一句“信息不足时明确标注‘待确认’，禁止自行补充”。

2.3 参数化：让一个 Skill 适配多个项目

Skill 如果写死了项目名、接口地址、字段名，那换个项目就得重写，太累。我的做法是把可变部分抽成参数，用占位符表示，比如{{project_name}}、{{api_base}}、{{auth_type}}。调用的时候把参数填进去，一个 Skill 就能服务多个项目。这跟写代码抽公共函数是一个道理。下面这张表是我对 Skill 参数化程度的一个分类，你可以对照自己的情况看看该做到哪一档。

我大部分 Skill 停在中度参数化，因为再往上维护成本就超过收益了。这个度怎么把握，后面讲具体 Skill 的时候我会结合例子说。

3. 需求与设计阶段：把测试左移落到实处

3.1 需求解析 Skill：从一段话里挖出可测点

产品经理丢过来一段需求描述，往往夹杂着业务背景、交互细节和一堆“等等”。人读都要读两遍，更别说直接生成用例了。我用的第一个 Skill 就是需求解析，它的任务是把非结构化的需求文本，拆成结构化的测试点清单。提示词的核心指令是：“逐句分析需求，识别其中的功能点、业务规则、边界条件、异常场景，输出为表格，每行包含测试点编号、所属模块、测试点描述、优先级、来源句子”。

这里有个关键技巧：要求 AI 标注“来源句子”。这样评审的时候，任何一个测试点都能追溯到需求原文，避免它自己加戏。实测下来，这个 Skill 能把需求评审的准备时间压缩一半以上，因为测试点清单直接就是评审材料。但要注意，AI 对隐含规则的识别能力有限，比如“金额不能为负”这种没写出来的常识，它有时会漏。所以我的习惯是把它当“第一遍粗筛”，人工再过一遍补漏。

3.2 用例生成 Skill：边界值和等价类怎么交给 AI

用例生成是大家最熟悉的场景，但也是最容易做砸的。我见过太多人直接说“帮我写登录功能的测试用例”，结果 AI 给了一堆“输入正确用户名密码”“输入错误密码”这种没营养的。我的用例生成 Skill 里强制要求 AI 按等价类划分和边界值分析来组织，提示词里明确列出：“对每个输入字段，分别给出有效等价类、无效等价类、上边界、下边界、边界外，并说明取值依据”。

举个实际例子，一个“年龄”字段要求 18 到 60 岁。AI 按我的 Skill 会输出：有效等价类取 30，无效等价类取 10 和 70，上边界取 60、61，下边界取 18、17。这样一套下来，覆盖度比随手写的高得多。我还会在 Skill 里加一条“每条用例必须可独立执行，不依赖其他用例的执行结果”，这是为了保证用例能直接进自动化框架。

3.3 用例评审 Skill：让 AI 当那个“挑刺的人”

用例写完，评审环节最费人。我做了个用例评审 Skill，角色设定是“一名挑剔的资深测试专家”，任务是找出用例里的问题。指令包括：“检查是否存在重复用例、是否遗漏异常场景、预期结果是否可验证、前置条件是否完整、步骤是否可执行”。输出要求按严重程度分级，并给出修改建议。

这个 Skill 有意思的地方在于，我故意把它的“性格”设得严格一点，提示词里写“宁可误报，不可漏报”。因为评审阶段多挑出问题，比上线后才发现强。实测它能抓出大概七成的用例质量问题，剩下三成靠人工。有个小技巧：把用例和对应的需求一起喂给它，它判断“是否遗漏”会准很多，因为有了对照基准。

4. 执行阶段：脚本、数据、日志三件套

4.1 接口脚本生成 Skill：从文档到可跑代码

接口测试脚本的生成，是我用得最频繁的 Skill 之一。输入是接口文档（Swagger 或手写 Markdown 都行），输出是可直接运行的测试脚本。我的提示词里会指定语言和框架，比如“用 Python + requests + pytest 生成，使用参数化，断言覆盖状态码、响应字段类型、关键业务字段值”。为什么要指定这么细？因为不指定的话，AI 可能给你生成一堆风格不统一的代码，后期维护很痛苦。

这里有个参数计算的实际例子。假设接口返回的金额字段是浮点数，直接断言相等会有精度问题。我在 Skill 里加了一条规则：“涉及金额、比率等浮点字段，断言时使用误差范围，默认容差 0.01”。这条规则是我被线上误报坑过之后加的——有次因为浮点精度导致断言失败，排查了半天才发现是 0.1+0.2 不等于 0.3 这种经典问题。AI 默认不会考虑这个，必须你告诉它。

4.2 测试数据构造 Skill：造出“像真的”的数据

测试数据难造，尤其是涉及关联关系的数据。比如造一个订单，得先有用户、有商品、有库存。我做了个数据构造 Skill，核心指令是：“根据表结构或接口定义，生成符合业务规则的测试数据，保持外键关联一致性，覆盖正常值、边界值、特殊字符”。输出格式我要求用 SQL 或 JSON，方便直接导入。

这个 Skill 有个进阶用法：让它生成“脏数据”。提示词里加一句“额外生成 10% 的异常数据，包括超长字符串、特殊字符、空值、类型不匹配”，用来测试系统的容错能力。实测下来，这些脏数据经常能挖出一些隐藏的边界 bug。但要注意，脏数据只能往测试环境灌，千万别手滑导到生产库，这个我在 Skill 里专门加了警告语。

4.3 日志分析 Skill：从海量日志里定位异常

跑完测试，日志一大堆，人工翻太慢。日志分析 Skill 的任务是：输入一段日志，输出异常摘要、可能的根因、相关代码位置建议。提示词里我会定义“异常”的判定标准，比如“包含 ERROR、Exception、超时、连接拒绝等关键词的行，以及响应时间超过阈值的行”。输出要求按时间线排列，并标注出现频次。

这个 Skill 的准确度取决于日志格式的规范性。如果日志是结构化的 JSON，AI 分析起来很准；如果是乱七八糟的文本，效果就打折。所以我在 Skill 里加了一步“先判断日志格式，非结构化时先做格式归一化”。另外，涉及敏感信息的日志（比如用户手机号、身份证号），我会在 Skill 里要求 AI 自动脱敏后再输出，这是合规底线。

5. 缺陷与报告：让 AI 干“整理”的活

5.1 缺陷归因 Skill：从现象到根因的推理

发现一个 bug，现象是“提交订单偶尔失败”。光看现象没法修，得归因。缺陷归因 Skill 的角色是“一名擅长排查问题的测试开发工程师”，输入是现象描述、相关日志、最近变更记录，输出是可能的原因列表，按可能性排序，并给出验证方法。提示词里我要求它“区分前端问题、后端问题、数据问题、环境问题”，这样排查方向更清晰。

我踩过的一个坑是：早期我让它直接给结论，结果它经常“自信地猜错”。后来我改成要求它“给出至少三个可能原因，并说明每个原因的验证步骤”，这样即使第一个猜错，也能顺着验证步骤往下排。这个思路其实来自我自己的排查习惯——先列假设，再逐个验证，而不是一上来就下结论。

5.2 测试报告生成 Skill：把零散结果串成一份能看的报告

测试做完，报告得写。我做的报告生成 Skill，输入是测试执行结果（通过率、失败用例、缺陷列表），输出是结构化的测试报告，包含测试范围、执行概况、缺陷统计、风险提示、结论建议。提示词里我规定了报告的语气：“客观陈述，不夸大通过率，对未覆盖部分明确说明”。

这里有个细节：我要求 AI 在报告里区分“阻塞性缺陷”和“一般缺陷”，并给出上线建议。这个判断标准我会在 Skill 里写清楚，比如“阻塞性缺陷指导致核心流程不可用的问题”。这样生成的报告，直接就能发给项目组，省了我大量排版和措辞的时间。但结论部分我坚持人工确认，因为上线决策不能全交给 AI。

6. 进阶玩法：Agent 化与多 Skill 协作

6.1 从单 Skill 到 Agent：让 AI 自己决定用哪个 Skill

单个 Skill 是工具，Agent 是会用工具的人。当我把上面这些 Skill 都准备好之后，就开始尝试让 Agent 根据任务自动选择 Skill。比如我丢给它一句“帮我测一下这个新接口”，它能自己判断：先调接口脚本生成 Skill，再调数据构造 Skill，跑完之后调日志分析 Skill，最后调报告生成 Skill。这套流程跑通之后，效率提升是数量级的。

但 Agent 化有个前提：每个 Skill 的输入输出必须标准化。如果 A Skill 的输出格式和 B Skill 的输入格式对不上，Agent 就串不起来。所以我在设计每个 Skill 时，都会预留“标准输出”格式，通常是 JSON，字段名统一。这跟微服务之间定接口是一个道理，先定契约，再谈协作。

6.2 多 AI 协作：不同模型干不同活

我现在的做法是，不同 Skill 可以指定不同的模型。比如需要强推理的缺陷归因，用推理能力强的模型；需要快速生成大量用例的，用速度快的模型。这样既保证效果，又控制成本。多 AI 协作的关键是“任务分发”和“结果汇总”，我会用一个调度 Skill 来协调，它负责把任务拆解、分发给对应的 AI、收集结果、合并输出。

这里要提醒一句：多 AI 协作会放大错误。如果第一个环节的 AI 输出有偏差，后面每个环节都会跟着偏。所以我在关键节点都加了“人工确认”开关，比如用例生成后、脚本生成后，先人工扫一眼再往下走。全自动听起来很美，但测试这行，完全放手风险太大。

6.3 Skill 的版本管理与迭代

Skill 是要迭代的。我每个 Skill 都像代码一样有版本号，改动记录写清楚“改了什么、为什么改、效果如何”。比如我的用例生成 Skill 从 v1 到 v5，v1 是基础版，v2 加了边界值要求，v3 加了来源标注，v4 加了浮点容差，v5 加了“禁止臆造字段”。每次迭代都是被实际问题逼出来的。

我建议你也养成记录的习惯。不用多复杂，一个表格就行：Skill 名称、版本、改动点、触发原因、效果对比。时间长了你会发现，这些记录本身就是一份宝贵的经验库，比任何教程都实用。

7. 常见问题与排查技巧实录

7.1 Skill 效果不稳定的排查思路

用 AI 做测试，最头疼的就是“时好时坏”。同一个 Skill，昨天生成的用例挺好，今天就不行了。我总结了几条排查思路。第一，检查输入是否一致，很多时候是输入的需求文档格式变了，AI 的理解就跟着变。第二，检查提示词有没有被无意改动，尤其是团队共用的时候。第三，检查模型版本有没有更新，模型升级有时会改变输出风格。第四，检查上下文长度，输入太长时 AI 会“遗忘”前面的指令。

下面这张表是我整理的常见问题速查表，你可以直接拿去用。

7.2 避坑经验：这些错我替你犯过了

第一个坑：把敏感数据喂给 AI。早期我图省事，直接把生产环境的日志丢进去分析，后来意识到里面有用户信息，赶紧停了。现在我的做法是，所有输入先脱敏，或者只用测试环境数据。这是红线，不能碰。

第二个坑：过度依赖 AI 的结论。有次 AI 分析缺陷，给了一个看起来很合理的根因，我直接信了，结果方向完全错，浪费了一天。从那以后，我要求 AI 必须给“验证步骤”，我自己跑一遍才认。

第三个坑：Skill 写得太复杂。一开始我想把所有功能塞进一个 Skill，结果它什么都干不好。后来拆成小 Skill，每个只干一件事，效果反而好。这跟写函数一样，单一职责原则。

第四个坑：不记录不迭代。用了几个月，发现自己一直在重复调同样的参数。后来开始记录，才发现有些问题早就解决过，只是忘了。

7.3 安全与合规的边界

用 AI 做测试，有几个边界必须守住。第一，不把生产数据、用户隐私数据作为输入。第二，生成的脚本和用例，上线前必须人工审核，尤其是涉及删除、修改操作的。第三，AI 给出的安全测试建议，只用于授权范围内的测试，不能用于未授权的目标。第四，Skill 里涉及权限、鉴权的部分，要确保符合团队的规范。这些不是技术问题，是职业操守问题，我在每个 Skill 里都会写上相应的约束。

8. 我日常在用的 25 个 Skill 清单与分类

前面讲了思路和方法，这里把 25 个 Skill 按类别列出来，每个附一句核心用途，方便你对照自己的需求取用。需要说明的是，具体提示词内容因项目而异，我这里给的是“这个 Skill 解决什么问题”，你可以据此自己填充细节。

需求与设计类（6 个）：需求解析、测试点提取、用例生成、用例评审、测试策略建议、风险评估。执行类（8 个）：接口脚本生成、UI 脚本生成、测试数据构造、脏数据生成、环境检查、日志分析、性能脚本生成、安全扫描辅助。缺陷与报告类（5 个）：缺陷归因、缺陷去重、回归范围建议、测试报告生成、质量度量分析。协作与调度类（3 个）：任务分发、结果汇总、Skill 版本管理。辅助类（3 个）：术语解释、文档摘要、会议纪要整理。

这 25 个不是固定的，项目不同会增减。比如做汽车电子测试的同事，会额外加“信号仿真”和“诊断协议解析”两个 Skill；做 GIS 空间分析的，会加“坐标校验”和“图层比对”。核心思路是一样的：把你重复做的、有固定套路的工作，抽成一个 Skill。

9. 最后分享几个实操小技巧

技巧一：给 Skill 起个好记的名字。我早期用“skill_001”这种编号，后来发现根本记不住。改成“用例生成-接口版”“日志分析-通用版”这种，一眼就知道干什么。

技巧二：在 Skill 里加“示例”。AI 对示例的敏感度远高于抽象描述。与其写“输出要规范”，不如直接给一个规范输出的例子。我每个 Skill 里都至少放一个输入输出示例，效果立竿见影。

技巧三：定期做“Skill 体检”。每隔一段时间，把不用的 Skill 归档，把常用的 Skill 优化。我现在的 25 个，其实是从四十多个里筛出来的，淘汰的那些要么效果不好，要么场景太窄。

技巧四：别追求一步到位。我第一个 Skill 很粗糙，但先用起来，在用的过程中发现问题、迭代改进。等你想完美了再动手，黄花菜都凉了。测试这行，快速试错比完美规划重要。

技巧五：把 Skill 分享给团队。一个人攒不如一群人攒。我们团队现在有个共享的 Skill 库，谁发现好用的就贡献进去，标注适用场景和注意事项。这样新同事上手快，老同事也能捡到别人的经验。当然，涉及项目敏感信息的 Skill 要单独管理，不能混进公共库。

这套东西我用了大半年，最大的感受是：AI 不会取代测试工程师，但会用 AI 的测试工程师，确实能把不会用的甩开一截。关键不在于你用了多少个 Skill，而在于你有没有想清楚每个 Skill 背后的逻辑，有没有在实际项目里反复打磨。工具是死的，人是活的，把 AI 当成一个需要你带、需要你教的新人，你的测试工作会轻松很多。