1. 这套 Skill 体系到底解决了什么问题

我日常跟 AI Agent 打交道的时间，比跟真人同事说话的时间还长。从最早拿 Claude 写点小脚本，到后来把 Agent 塞进测试流程里跑自动化，中间踩的坑能填满一个中型会议室。今天要聊的这 25 个 Skill，不是从某个文档里抄来的清单，是我自己每天在用的、经过反复筛选留下来的东西。

先说清楚“Skill”在这里指什么。在 AI Agent 的语境下，Skill 可以理解为一个封装好的能力单元——它可能是一段提示词模板、一个工具调用配置、一套工作流编排逻辑，或者一个针对特定场景优化过的 Agent 行为模式。你可以把它类比成手机上的 App：Agent 是操作系统，Skill 就是跑在上面的应用。没有 Skill 的 Agent 就像一个刚装好系统的手机，能开机但干不了什么正事。

这套东西解决的核心问题是：让 AI Agent 在测试场景下从“能聊”变成“能干”。我见过太多人拿 Claude 或者别的模型，问一句答一句，效率还不如自己动手。问题不在于模型不够强，而在于没有给它配好 Skill。一个配置得当的测试 Skill，能让 Agent 自动完成从用例生成、边界分析、异常注入到结果校验的完整链路，你只需要在关键节点做决策。

适合谁来参考？三类人：一是测试工程师，想把手里的重复劳动交给 Agent；二是 Agent 开发者，需要一套经过实战检验的 Skill 设计思路；三是技术管理者，在评估 AI 辅助测试到底能落地到什么程度。不管你用的是 Claude Code、还是自己搭的 Agent 框架，下面的内容都能直接抄作业。

2. 测试类 Skill 的核心设计逻辑

2.1 为什么测试场景特别适合 Skill 化

测试工作有一个天然优势：输入输出边界清晰。你给一个函数、一个接口、一个页面，期望的输出是可以被验证的。这跟写文案、做设计不一样，后者很难定义“对了”。测试的确定性让 Skill 的编排变得可行——Agent 知道什么算通过，什么算失败，中间的过程可以拆成可复用的步骤。

另一个原因是测试的重复性极高。回归测试、冒烟测试、兼容性测试，每次迭代都要跑一遍。人做这些事会烦、会漏、会偷懒，Agent 不会。只要 Skill 定义好了，它每次执行的标准是一致的。我实测下来，一个配置好的回归测试 Skill，能把原本需要 40 分钟的用例执行压缩到 8 分钟左右，而且漏测率明显下降。

但这里有个前提：Skill 的粒度要控制好。太粗了，一个 Skill 干所有事，调试起来像拆炸弹；太细了，调一次测试要串联十几个 Skill，维护成本反而上去了。我的经验是，一个 Skill 对应一个明确的测试阶段或测试类型，比如“接口参数边界生成”是一个 Skill，“异常响应校验”是另一个，不要混在一起。

2.2 Skill 的三种形态与选型建议

在实际使用中，我手里的 25 个 Skill 大致分成三类，每类的设计思路和适用场景不一样。

第一类是提示词型 Skill。本质是一段精心设计的提示词模板，通过变量注入来适配不同场景。比如“测试用例生成 Skill”，里面固化了等价类划分、边界值分析、判定表这些方法的提示逻辑，你只需要把需求描述和接口定义传进去，它就能输出结构化的用例。这类 Skill 的优点是轻量、易改、不依赖外部工具；缺点是能力上限受模型本身限制，复杂逻辑还是得靠人兜底。

第二类是工具调用型 Skill。这类 Skill 会绑定具体的工具或 API，比如调用 Postman 跑接口、调用 Selenium 操作浏览器、调用数据库客户端校验数据。Agent 通过 Skill 来编排这些工具的调用顺序和参数传递。优点是能真正“动手”，缺点是配置复杂，环境依赖多，换个机器可能就跑不起来。

第三类是编排型 Skill。这类 Skill 不直接干活，而是协调多个子 Skill 的执行。比如“全量回归测试 Skill”，它会依次调用用例生成、环境准备、用例执行、结果汇总这几个子 Skill，并处理它们之间的数据流转。编排型 Skill 的设计难度最高，但价值也最大，因为它把零散的能力串成了完整的流水线。

选型建议很简单：先用提示词型验证想法，再用工具调用型落地执行，最后用编排型串成流程。不要一上来就搞编排，很容易因为某个子 Skill 不稳定导致整条链路崩掉。

2.3 我踩过的三个设计坑

第一个坑是过度依赖模型推理。早期我设计了一个“自动判断测试是否通过”的 Skill，让模型自己看响应内容判断对错。结果发现，模型对模糊边界的判断很不稳定，同样的响应有时候说通过有时候说失败。后来改成“模型提取关键字段 + 规则引擎比对”的混合模式，稳定性才上来。教训是：能用确定性规则的地方，不要让模型做判断。

第二个坑是Skill 之间耦合太紧。我一开始把用例生成和用例执行写在一个 Skill 里，后来想单独调整生成逻辑，发现执行部分也跟着受影响。拆开之后，两个 Skill 各自独立迭代，维护成本降了一大截。Skill 之间应该通过明确定义的输入输出接口通信，而不是共享内部状态。

第三个坑是忽略失败处理。测试场景下，失败是常态——环境挂了、接口超时、数据被污染。我最初的 Skill 只考虑了成功路径，一遇到异常就整个流程卡死。后来在每个 Skill 里都加了重试、降级和超时处理，才算是能稳定跑起来。这个经验很朴素但很重要：测试 Skill 的健壮性，比功能丰富度更重要。

3. 25 个 Skill 的分类拆解与实操要点

3.1 用例设计与生成类（6 个）

这一类是我用得最频繁的，基本上每天都会跑。核心思路是让 Agent 根据需求文档、接口定义或者代码变更，自动生成覆盖度足够的测试用例。

Skill 1：需求文档解析与测试点提取。输入是一段需求描述或者 PRD 链接，输出是结构化的测试点列表。关键在于提示词里要明确要求 Agent 按“功能点-测试维度-预期结果”的三层结构输出，并且强制它标注每个测试点的优先级。我实测下来，如果不加优先级标注，生成的用例会平铺直叙，后续执行时不好做取舍。

Skill 2：接口参数边界值生成。这个 Skill 针对 RESTful 接口，输入是接口的请求参数定义（类型、范围、是否必填），输出是一组边界值用例。比如一个 int 型参数范围是 1-100，它会生成 0、1、100、101、-1 以及 null 的测试数据。这里有个细节：要区分“合法边界”和“非法边界”，并且明确标注每个用例的预期响应码。我一般会要求 Agent 同时输出 curl 命令，方便直接复制执行。

Skill 3：等价类划分助手。对于输入域很大的场景，穷举不现实，这个 Skill 帮我把输入划分成若干等价类，每个类取一个代表值。提示词里我会强调“划分依据要可解释”，避免 Agent 给出莫名其妙的分类。输出格式是表格：等价类编号、划分依据、代表值、预期结果。

Skill 4：状态迁移用例生成。针对有状态的对象，比如订单、工单、用户账号，这个 Skill 会根据状态机定义生成迁移路径用例。关键是要求 Agent 覆盖所有合法迁移和至少一条非法迁移。我通常会额外要求它输出状态迁移图的可视化描述（用文字描述节点和边），方便人工复核。

Skill 5：代码变更影响面分析。输入是一次 commit 的 diff，输出是受影响的测试范围建议。这个 Skill 需要结合代码结构信息，我一般会先把 diff 和相关文件的类名、方法名喂给它。实测下来，它对简单的增删改判断比较准，但对重构类的变更容易误判，需要人工确认。

Skill 6：测试用例去重与合并。多个来源生成的用例经常有重复，这个 Skill 负责语义层面的去重。它不是简单的字符串比对，而是理解用例的测试意图，把测同一件事的用例合并成一条。这个 Skill 我建议放在用例生成流程的最后一步，避免过早合并导致覆盖度丢失。

3.2 执行与编排类（7 个）

用例生成好了，接下来是执行。这一类 Skill 的核心是让 Agent 能够驱动各种测试工具，并且处理执行过程中的异常。

Skill 7：接口测试批量执行。输入是一组接口用例（通常来自 Skill 2 的输出），输出是执行结果汇总。这个 Skill 会调用 HTTP 客户端逐个执行，记录响应码、响应时间、响应体关键字段。我一般会配置并发执行，但并发数控制在 5 以内，避免把测试环境打挂。

Skill 8：UI 自动化脚本生成与执行。输入是页面操作描述，输出是可执行的自动化脚本并直接运行。这个 Skill 我主要用来处理回归场景，比如“登录-搜索-下单-支付”这条主流程。需要注意的是，UI 自动化的稳定性受页面加载速度影响很大，我在 Skill 里加了显式等待和重试逻辑，不然误报率会很高。

Skill 9：数据库校验 Skill。接口测试跑完之后，经常需要校验数据是否正确落库。这个 Skill 接收 SQL 查询语句和预期结果，自动连接数据库执行比对。我一般会把它和接口测试 Skill 串联使用，形成“调接口-查数据库-比对”的闭环。

Skill 10：测试数据准备与清理。测试前需要造数据，测试后需要清数据。这个 Skill 负责根据用例需求生成测试数据，并在执行完成后清理。关键是要保证清理的幂等性，避免重复执行导致数据错乱。我的做法是给每条测试数据打上唯一标记，清理时按标记删除。

Skill 11：多环境切换执行。同一套用例需要在开发、测试、预发等多个环境跑。这个 Skill 负责管理环境配置，根据传入的环境标识自动切换 base URL、数据库连接、认证信息等。配置信息我建议用环境变量管理，不要硬编码在 Skill 里。

Skill 12：定时任务编排。这个 Skill 让 Agent 能够按计划执行测试任务，比如每天凌晨跑一遍全量回归。它本质上是一个调度器，负责任务的触发、排队和结果通知。我一般会配合消息通知使用，跑完自动把结果推到工作群。

Skill 13：失败用例自动重试。测试执行中难免有偶发失败，这个 Skill 负责对失败用例进行有限次重试，并区分“真失败”和“环境抖动”。重试次数我一般设为 2 次，超过就标记为真实失败。重试之间加一个短暂的等待，给环境恢复的时间。

3.3 分析与报告类（5 个）

测试跑完了，结果怎么呈现、怎么分析，直接决定了测试的价值能不能被看见。

Skill 14：测试结果汇总与统计。输入是原始执行结果，输出是结构化的统计报告：总数、通过数、失败数、跳过数、通过率、平均响应时间。这个 Skill 看起来简单，但格式统一很重要，不然后续的自动化分析没法做。

Skill 15：失败原因智能归类。失败用例的原因五花八门，这个 Skill 负责把失败原因归类：是断言失败、超时、环境错误还是数据问题。归类之后，排查效率会高很多。我实测下来，它对常见错误的归类准确率在 85% 左右，剩下的需要人工复核。

Skill 16：测试覆盖率分析。结合代码覆盖率工具的输出，这个 Skill 分析哪些代码路径没有被测试覆盖到，并给出补充用例的建议。这个 Skill 对提升测试质量很有帮助，但前提是覆盖率数据要准确。

Skill 17：性能趋势分析。把多次执行的响应时间数据汇总，分析性能趋势。如果某个接口的响应时间持续上升，这个 Skill 会发出预警。我一般会保留最近 30 次执行的数据做趋势判断。

Skill 18：测试报告生成。把上面的分析结果整合成一份可读的报告，支持 Markdown 和 HTML 两种格式。报告里我会要求包含执行摘要、失败详情、趋势图表和建议措施四个部分。这个 Skill 的输出通常直接发给团队，所以格式和措辞要规范。

3.4 辅助与增强类（7 个）

这一类 Skill 不直接参与测试执行，但能显著提升整体效率。

Skill 19：测试环境健康检查。在跑测试之前，先检查环境是否可用：服务是否启动、数据库是否连通、依赖的第三方接口是否正常。这个 Skill 能避免大量因环境问题导致的误报。

Skill 20：测试日志采集与检索。测试执行过程中产生的日志分散在各个地方，这个 Skill 负责统一采集，并支持按关键字检索。排查问题时，能快速定位到相关日志。

Skill 21：缺陷报告自动生成。测试失败后，这个 Skill 根据失败信息自动生成缺陷报告草稿，包含复现步骤、预期结果、实际结果、环境信息。我一般会人工润色后再提交，但草稿能省掉大量重复劳动。

Skill 22：测试用例评审助手。用例写完之后，这个 Skill 从覆盖度、可执行性、可维护性三个维度给出评审意见。它不能替代人工评审，但能提前发现一些明显问题。

Skill 23：测试数据脱敏。从生产环境同步数据到测试环境时，这个 Skill 负责对敏感字段进行脱敏处理。这个 Skill 的合规意义大于技术意义，但必须要有。

Skill 24：API 文档与用例同步。接口文档更新后，这个 Skill 检查现有用例是否还匹配，不匹配的给出更新建议。这个 Skill 能有效防止用例和实际接口脱节。

Skill 25：测试知识库检索。把历史测试经验、常见问题、解决方案沉淀成知识库，这个 Skill 支持 Agent 在需要时检索相关知识。用得越久，这个 Skill 的价值越大。

4. 实操流程：从零搭建一条测试 Skill 流水线

4.1 环境准备与基础配置

先说环境。我用的是 Claude Code 作为 Agent 运行环境，配合 VS Code 做编辑和调试。安装 Claude Code 的过程不复杂，但有几个点需要注意。

Windows 环境下，如果遇到提示需要启用虚拟机平台的情况，直接在“启用或关闭 Windows 功能”里勾选对应选项，重启后即可。这个提示本身不是错误，是 Claude Code 的某些依赖需要虚拟化支持。Linux 和 macOS 下一般不会有这个问题。

安装完成后，第一件事是配置工作目录。我建议单独建一个目录专门放 Skill 定义和测试脚本，不要跟业务代码混在一起。目录结构大概是这样：

test-skills/ skills/ # 存放各个 Skill 的定义文件 case-gen/ # 用例生成类 executor/ # 执行类 reporter/ # 报告类 configs/ # 环境配置、数据库连接等 data/ # 测试数据 reports/ # 测试报告输出

每个 Skill 一个目录，目录里放 Skill 的定义文件（通常是 Markdown 或 YAML 格式）和相关的辅助脚本。这样组织的好处是，增删改 Skill 不会互相影响，也方便版本管理。

4.2 第一个 Skill 的完整实现

拿“接口参数边界值生成”这个 Skill 举例，完整走一遍实现过程。

首先定义 Skill 的输入输出。输入需要：接口路径、请求方法、参数列表（每个参数包含名称、类型、是否必填、取值范围）。输出需要：一组测试用例，每条包含用例编号、参数组合、预期响应码、用例说明。

Skill 定义文件的核心是提示词。我写的提示词大概是这样：

你是一个接口测试专家。根据以下接口定义，生成边界值测试用例。 接口信息： - 路径：{{path}} - 方法：{{method}} - 参数：{{params}} 要求： 1. 对每个参数，分别取最小值、最小值-1、最大值、最大值+1、正常值、null、空字符串 2. 必填参数缺失时，预期响应码为 400 3. 类型不匹配时，预期响应码为 400 4. 输出格式为 Markdown 表格，包含：用例编号、参数组合、预期响应码、说明 5. 用例编号格式为 BV-001 起递增

这里的关键是把预期结果也纳入生成范围。很多人生成用例只生成输入，不生成预期输出，导致后续没法自动校验。我强制要求 Agent 输出预期响应码，这样执行 Skill 才能自动比对。

定义好之后，实际使用时只需要把接口信息填进去。我一般会写一个简单的脚本，从 Swagger 或者 OpenAPI 文档里提取接口定义，自动填充到模板里，避免手工输入出错。

4.3 多 Skill 串联的编排配置

单个 Skill 跑通之后，下一步是把它们串起来。我以“接口回归测试”这条链路为例，说明编排配置怎么写。

整条链路包含四个 Skill：环境检查（Skill 19）、用例生成（Skill 2）、批量执行（Skill 7）、报告生成（Skill 18）。编排配置的核心是定义每个 Skill 的输入来源和输出流向。

环境检查 Skill 不需要输入，输出是一个状态标识（healthy 或 unhealthy）。如果状态是 unhealthy，整条链路终止，并发送告警。如果 healthy，继续执行。

用例生成 Skill 的输入是接口定义文件路径，输出是用例列表。这个输出直接作为批量执行 Skill 的输入。

批量执行 Skill 的输入是用例列表和环境配置，输出是执行结果。执行结果再传给报告生成 Skill。

报告生成 Skill 的输入是执行结果，输出是报告文件路径。最后把报告路径推送到通知渠道。

编排配置里我加了两个关键控制：超时控制和失败熔断。每个 Skill 有独立的超时时间，超过就标记为失败并继续下一个（或者终止，取决于配置）。失败熔断是指，如果连续 N 个用例执行失败，自动停止后续执行，避免浪费时间。

4.4 参数计算与阈值设定

Skill 执行过程中涉及不少参数，这些参数设多少合适，直接决定了流水线好不好用。我把自己常用的参数和计算依据列一下。

并发数：接口测试的并发数我一般设为 5。计算依据是测试环境的承载能力——大多数测试环境的数据库连接池在 10-20 之间，并发 5 能保证不把连接池打满，同时又有一定的执行效率。如果测试环境配置较高，可以适当上调，但不要超过连接池上限的一半。

超时时间：单个接口的超时我设为 10 秒。依据是正常接口响应时间一般在 200ms 以内，10 秒是 50 倍余量，足以覆盖偶发的慢查询。如果接口本身是批量处理或者涉及复杂计算，可以单独调高。

重试次数：失败重试设为 2 次。依据是偶发失败的恢复概率——第一次重试能恢复约 70% 的偶发失败，第二次再恢复约 50% 的剩余部分，两次之后还失败的基本就是真失败了。重试间隔设为 3 秒，给环境恢复的时间。

覆盖率阈值：我要求核心模块的代码覆盖率不低于 80%，非核心模块不低于 60%。这个阈值不是拍脑袋定的，是结合历史缺陷分布算出来的——80% 覆盖率下，遗留缺陷密度能控制在可接受范围内。

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

5.1 Skill 执行失败的典型原因

用这套东西的过程中，失败是家常便饭。我把最常见的几类问题和排查思路整理成表，方便快速定位。

这张表是我踩了无数坑之后总结的，基本上覆盖了 80% 的常见问题。遇到新问题，先对照这张表排查，大部分情况下能快速定位。

5.2 提示词调优的实战经验

Skill 的效果好不好，七成看提示词。我调提示词有几个习惯，分享出来。

第一，给示例。不要只描述要求，直接给一个输入输出的例子。比如生成用例的 Skill，我会在提示词里放一条完整的示例用例，Agent 照着模仿，格式稳定性会高很多。

第二，加约束。明确告诉 Agent 不要做什么，比告诉它要做什么更有效。比如“不要生成重复用例”、“不要使用模糊的预期结果描述”、“不要省略必填参数”。

第三，分步骤。复杂任务拆成多个步骤，让 Agent 一步步来。比如先提取测试点，再生成用例，最后做去重。一次性让 Agent 干完所有事，质量往往不如分步执行。

第四，留后门。提示词里加一句“如果信息不足，请列出需要补充的信息，不要猜测”。这样 Agent 遇到不确定的情况会主动询问，而不是瞎编。

5.3 性能优化的几个关键点

Skill 跑得慢是常见抱怨。我优化下来，效果最明显的几个点：

减少不必要的模型调用。能用规则判断的地方，不要调模型。比如响应码校验、字段存在性检查，这些用代码几毫秒就能完成，调模型要几秒钟。

缓存重复结果。同一个接口定义生成的用例，如果接口没变，不需要重新生成。我加了一层缓存，命中缓存时直接返回，省掉模型调用时间。

并行执行独立任务。多个不相关的 Skill 可以并行跑，比如环境检查和用例生成可以同时进行。但要注意资源竞争，并行度不要太高。

精简提示词。提示词不是越长越好，冗余的描述会增加模型处理时间。我定期清理提示词，删掉不必要的内容，响应速度能提升 20% 左右。

5.4 安全与合规注意事项

测试 Skill 涉及数据操作，安全上不能马虎。几条硬性要求：

• 测试环境的数据脱敏 Skill 必须启用，尤其是涉及用户信息的场景
• 数据库操作 Skill 要限制权限，只给必要的读写权限，不要用管理员账号
• 接口测试 Skill 要避免对生产环境发起请求，环境配置里做好隔离
• 测试数据清理 Skill 要保证幂等，避免误删有效数据
• 所有 Skill 的操作日志要保留，便于追溯

这些不是可选项，是底线。我见过因为测试脚本误操作导致数据污染的案例，修复成本很高。

6. 关于 Skill 组合的一些个人体会

这套 25 个 Skill 不是一开始就设计好的，是慢慢攒出来的。最开始只有三四个，用着用着发现缺什么就补什么。有些 Skill 用了一段时间发现不好用，就删掉或者合并了。现在留下来的，都是经过实战检验的。

我最大的体会是：Skill 的价值不在于数量，在于组合。单独一个用例生成 Skill 没什么了不起，但把它和执行 Skill、报告 Skill 串起来，就能形成一条自动化流水线，价值是单个 Skill 的好几倍。所以设计 Skill 的时候，要多想想它怎么跟其他 Skill 配合，而不是孤立地追求功能强大。

另一个体会是：不要追求一步到位。我见过有人想一次性设计一套完美的 Skill 体系，结果设计了两周还没跑起来。正确的做法是先跑通一个最小闭环，哪怕只有两个 Skill，先让它跑起来，然后在用的过程中迭代。用起来的 Skill 才会变好，放在文档里的 Skill 永远是纸上谈兵。

最后分享一个小技巧：给每个 Skill 写一个“使用说明”，记录它的适用场景、输入输出示例、已知限制和注意事项。这个说明不用很正式，几句话就行，但能省掉大量回忆和试错的时间。我现在的 Skill 目录里，每个 Skill 都配了说明，新来的同事照着说明就能上手，不用我一个个教。