1. 从“会用AI”到“用好AI”：测试Skill到底解决了什么问题

这两年我一直在做AI辅助测试的落地，从最早的“把需求丢给大模型让它写用例”，到后来自己攒了一套Skill库，中间踩的坑比想象中多得多。很多人以为AI测试就是“让AI写个脚本”，实际用下来你会发现，真正拉开效率差距的不是模型本身，而是你有没有一套结构化的Skill体系。所谓Skill，说白了就是把某类测试任务的输入规范、执行逻辑、输出格式、校验规则打包成一个可复用的能力单元，让AI在特定场景下稳定输出你想要的结果，而不是每次都要重新“调教”。

我日常在用的这25个Skill，覆盖了接口测试、UI自动化、性能压测、数据构造、缺陷分析、测试报告生成等环节。它们不是那种“看起来很酷但用不上”的玩具，而是真正嵌入了我每天的工作流。比如接口用例生成Skill，输入一份Swagger文档，它能自动产出带边界值、异常场景的pytest用例骨架；再比如日志分析Skill，丢进去一段报错日志，它能定位到具体的失败断言和可能的原因。这些Skill的共同特点是：输入明确、输出可控、可重复执行。

适合谁来参考？如果你已经在用AI辅助测试，但总觉得“差点意思”——输出不稳定、每次都要重新写提示词、团队里没法共享——那这套Skill思路就是为你准备的。如果你刚开始接触AI测试，也可以从最简单的几个Skill入手，先感受一下“结构化提示词”和“随手一问”之间的差距。下面我会把整套体系拆开讲，包括设计思路、核心Skill的实现细节、实操流程、以及那些只有真正用过才会知道的坑。

2. 整套Skill体系的设计思路与选型考量

2.1 为什么不是“一个大而全的提示词”而是25个Skill

最开始我也试过写一个“万能测试提示词”，把需求描述、用例生成、脚本编写、报告输出全塞进去。结果就是：模型在长上下文里开始“遗忘”前面的约束，输出的用例格式时好时坏，有时候甚至把pytest和unittest的写法混在一起。后来我意识到，测试工作本身就是分阶段的，每个阶段的输入输出边界很清晰，强行合并只会让AI“精神分裂”。

拆成25个Skill之后，每个Skill只负责一个明确的子任务，提示词可以写得非常具体。比如“接口异常用例生成Skill”里，我会明确告诉模型：只考虑HTTP状态码4xx和5xx的场景，参数只考虑空值、超长、特殊字符、类型错误四类，输出必须是pytest的parametrize格式。这样模型不需要“猜”我要什么，输出稳定性直接上了一个台阶。

另一个考量是复用性。团队里不同人负责不同模块，但接口测试的Skill是通用的。我把Skill做成标准化的Markdown模板，每个人都可以直接调用，也可以根据自己的模块特点微调参数。这比口口相传“你要这样问AI”高效得多。

2.2 Skill的三种类型：生成型、分析型、执行型

我用的这25个Skill，按功能可以分成三类：

• 生成型：输入原始材料（需求文档、接口定义、数据库表结构），输出测试用例、测试数据、脚本骨架。比如“Swagger转pytest用例Skill”、“测试数据工厂Skill”。
• 分析型：输入运行结果（日志、报告、堆栈信息），输出问题定位、根因分析、修复建议。比如“失败用例归因Skill”、“性能瓶颈分析Skill”。
• 执行型：输入执行指令和参数，驱动测试工具完成操作并返回结构化结果。比如“Appium元素定位Skill”、“压测场景编排Skill”。

这三类Skill的提示词设计逻辑完全不同。生成型重在“约束输出格式”，分析型重在“提供分析框架”，执行型重在“参数校验和异常处理”。后面我会分别展开。

2.3 选型背后的核心原则：可验证、可组合、可迭代

每个Skill在设计时我都会问自己三个问题：第一，输出能不能被自动验证？比如生成的用例能不能直接跑通，分析结论能不能对应到具体的日志行。第二，能不能和其他Skill组合？比如“用例生成Skill”的输出，可以直接作为“脚本执行Skill”的输入。第三，能不能根据反馈迭代？如果某个Skill连续三次输出都不理想，我就知道提示词需要调整了。

这三个原则听起来简单，但实际做的时候很容易跑偏。我见过有人把Skill设计得特别“智能”，让AI自由发挥，结果每次输出都不一样，根本没法用在自动化流程里。测试工作的本质是“可重复、可验证”，Skill也必须遵循这个逻辑。

3. 核心Skill的详细拆解与实操要点

3.1 接口测试类Skill：从Swagger到可执行用例

接口测试是我用得最多的场景，相关的Skill有6个。最核心的是“Swagger转pytest用例Skill”，输入是一份OpenAPI/Swagger的JSON或YAML，输出是带完整断言的pytest测试文件。

提示词的关键部分是这样的：

你是一个接口测试用例生成器。输入是Swagger文档，输出是pytest测试文件。 要求： 1. 每个接口生成至少3个用例：正常场景、参数异常、权限异常 2. 正常场景使用文档中的example值 3. 参数异常覆盖：必填参数缺失、参数类型错误、参数超长 4. 断言必须包含：状态码、响应时间、关键字段存在性 5. 使用requests库，base_url从环境变量读取 6. 输出格式：每个接口一个测试类，方法名格式为test_{method}_{path}

这里有几个细节值得说。第一，为什么要求“每个接口至少3个用例”？因为实际跑下来，只测正常场景的用例覆盖率极低，而参数异常和权限异常是最容易出问题的地方。第二，为什么断言要包含响应时间？因为很多性能问题在功能测试阶段就能暴露，比如某个接口正常返回但耗时超过2秒，这本身就是个信号。第三，base_url从环境变量读取，是为了让同一份用例能在不同环境跑，不用改代码。

实操中我发现，Swagger文档的质量直接决定生成用例的质量。如果文档里没有example值，模型就会自己“编”数据，这时候生成的用例往往跑不通。我的做法是先用一个“Swagger文档校验Skill”检查文档完整性，缺失的example值手动补上，再走生成流程。

另一个坑是路径参数的处理。比如/api/users/{id}，模型有时候会生成/api/users/1，有时候会生成/api/users/{id}，导致请求失败。我在提示词里明确要求：路径参数必须用f-string替换，并且从fixture中获取测试数据。这样生成的代码才能直接跑。

3.2 UI自动化类Skill：元素定位与操作序列生成

UI自动化这块我主要用Appium和Playwright，相关的Skill有5个。最常用的是“页面元素定位Skill”，输入是页面截图或DOM结构，输出是稳定的元素定位表达式。

这个Skill的设计难点在于：AI看到的截图和实际DOM结构可能有差异，而且同一个元素可能有多种定位方式。我的提示词里会要求模型按优先级输出定位方式：

按以下优先级输出元素定位方式： 1. accessibility id（最稳定） 2. resource-id（Android）/ name（iOS） 3. 文本内容（仅当文本唯一时） 4. XPath（仅当前三种都不可用时，且必须使用相对路径）

为什么把XPath放在最后？因为XPath对页面结构变化极其敏感，今天能用的XPath明天可能就失效了。我踩过的坑是：早期大量使用绝对路径XPath，结果每次UI改版都要重新维护定位表达式，工作量巨大。后来强制要求优先使用accessibility id和resource-id，维护成本直接降了一半。

还有一个“操作序列生成Skill”，输入是测试场景描述（比如“登录后添加商品到购物车并结算”），输出是Appium的操作步骤代码。这个Skill的关键是处理等待和异常。我会在提示词里要求：每个操作后必须加显式等待，等待条件必须是元素可见或可点击，不能用sleep。异常处理要区分“元素找不到”和“操作超时”，分别给出不同的重试策略。

实测下来，操作序列生成Skill的输出大概有70%可以直接用，剩下30%需要微调。主要问题是模型对页面跳转的时序理解不够准确，比如点击登录后需要等待页面加载完成才能操作下一个元素，模型有时候会漏掉这个等待。我的做法是在提示词里加一条：如果操作涉及页面跳转，必须加等待新页面关键元素出现的逻辑。

3.3 性能测试类Skill：场景编排与瓶颈分析

性能测试相关的Skill有4个，其中“压测场景编排Skill”和“性能瓶颈分析Skill”是核心。

压测场景编排Skill的输入是业务场景描述和预期指标（比如TPS、响应时间、错误率），输出是Locust或JMeter的脚本。提示词里我会明确要求：

• 每个场景必须包含思考时间（think time），模拟真实用户行为
• 必须设置阶梯式加压（ramp-up），不能一次性打满
• 必须包含断言，错误率超过阈值时自动停止

为什么强调阶梯式加压？因为一次性打满压力，你根本不知道系统的拐点在哪里。阶梯式加压可以帮你找到系统从正常到劣化的临界点，这个数据比“最大TPS”更有价值。

性能瓶颈分析Skill的输入是压测报告和服务器监控数据，输出是瓶颈定位和优化建议。这个Skill的提示词里我内置了一个分析框架：

按以下顺序分析： 1. 检查错误率：如果错误率>1%，先定位错误类型（超时、连接拒绝、业务异常） 2. 检查响应时间分布：P99是否远大于P50？如果是，说明有长尾请求 3. 检查资源利用率：CPU、内存、IO、网络哪个先到瓶颈？ 4. 检查数据库：慢查询数量、连接池使用率 5. 给出优化建议：按优先级排序，每条建议必须说明预期效果

这个框架是我从多次压测中总结出来的，按这个顺序分析，基本不会漏掉关键问题。实测下来，模型给出的优化建议有60%是直接可用的，比如“增加数据库连接池大小”、“优化某个慢查询的索引”，剩下40%需要结合具体业务判断。

3.4 测试数据构造类Skill：从约束到数据工厂

测试数据构造是个容易被忽视但极其耗时的环节。我用了3个Skill来处理：基础数据生成、关联数据生成、边界数据生成。

基础数据生成Skill的输入是数据表结构或JSON Schema，输出是符合约束的测试数据。提示词里我会要求模型考虑：字段类型、长度限制、枚举值范围、唯一性约束、外键关联。比如用户表有email字段，模型需要生成格式正确且不重复的邮箱地址。

关联数据生成Skill更复杂一些，输入是多张表的关联关系，输出是满足外键约束的数据集。这个Skill的关键是处理生成顺序：先生成主表数据，再生成从表数据，最后生成关联表数据。我会在提示词里明确要求模型输出生成顺序和依赖关系。

边界数据生成Skill是我用得最顺手的。输入是字段定义，输出是边界值、异常值、特殊字符的集合。比如对于“年龄”字段，输出：0、1、17、18、65、99、100、-1、999、null、空字符串、中文数字、科学计数法。这些数据在接口测试和UI测试中都能直接复用。

3.5 缺陷分析与报告类Skill：从日志到结论

缺陷分析类Skill有4个，报告生成类有3个。最核心的是“失败用例归因Skill”，输入是失败的测试用例和对应的日志，输出是失败原因分类和修复建议。

这个Skill的提示词里我定义了一个分类体系：

模型根据日志特征自动分类，并给出对应的处理建议。实测下来，分类准确率大概在80%左右，主要误判发生在“环境问题”和“依赖问题”之间，因为两者都表现为连接失败。我的做法是在提示词里加一条：如果日志中出现具体的第三方服务名称，优先归类为依赖问题。

测试报告生成Skill的输入是测试执行结果（JUnit XML或JSON），输出是结构化的测试报告。我会要求报告包含：执行概览、失败用例列表、失败原因分布、趋势对比、风险提示。趋势对比是很多人会忽略的，但实际很有价值——比如“本次失败率比上次上升了5%”，这个信息能帮你快速判断是不是有新的问题引入。

4. 完整实操流程：从零搭建一套可用的Skill体系

4.1 环境准备与工具选型

搭建Skill体系不需要复杂的工具链，我用的核心工具就几个：

• Skill管理：我用的是Obsidian加一个简单的文件夹结构，每个Skill一个Markdown文件，包含提示词模板、输入示例、输出示例、注意事项。为什么用Obsidian？因为它支持双向链接，我可以把相关的Skill关联起来，比如“用例生成Skill”链接到“脚本执行Skill”。
• AI调用：日常用的是支持长上下文的大模型，通过API调用。我写了一个简单的Python脚本，读取Skill文件，替换输入参数，调用API，保存输出。
• 版本管理：Git。每个Skill的修改都有记录，方便回滚和对比。

如果你不想写代码，也可以用现成的AI客户端，手动复制粘贴提示词。但要想把Skill嵌入自动化流程，还是建议用API调用。

4.2 Skill模板的标准化结构

每个Skill文件我都按统一结构编写：

# Skill名称 ## 用途 一句话说明这个Skill解决什么问题 ## 输入 - 输入类型：文件/文本/JSON - 输入示例：... ## 提示词模板 （完整的提示词，用{{变量}}表示可替换部分） ## 输出格式 - 输出类型：代码/JSON/Markdown - 输出示例：... ## 注意事项 - 已知问题：... - 调优建议：... ## 关联Skill - 上游：... - 下游：...

这个结构的好处是：任何人拿到这个文件，都能快速理解怎么用、输入什么、输出什么、有什么坑。团队协作时，新人可以按图索骥，不用每次都来问我。

4.3 从单个Skill到工作流：串联多个Skill

单个Skill解决单点问题，但实际测试工作是一个流程。我常用的一个工作流是“接口测试全流程”：

1. Swagger校验Skill：检查文档完整性，补全缺失的example
2. 用例生成Skill：生成pytest用例
3. 数据构造Skill：生成测试数据
4. 脚本执行Skill：运行用例并收集结果
5. 失败归因Skill：分析失败原因
6. 报告生成Skill：输出测试报告

这个工作流我封装成了一个Python脚本，输入Swagger文档，输出测试报告。整个流程跑下来，从文档到报告大概需要5-10分钟，其中AI调用占大部分时间。相比人工写用例、跑用例、分析结果，效率提升非常明显。

串联Skill的关键是定义好输入输出格式。比如用例生成Skill的输出必须是合法的pytest文件，脚本执行Skill才能直接运行。如果格式不对，整个流程就断了。我的做法是在每个Skill的输出后面加一个“格式校验”步骤，用简单的正则或AST检查，不合格就重新生成。

4.4 实操现场记录：一次完整的接口测试Skill调用

拿一个实际例子来说。我手头有一个用户管理模块的Swagger文档，包含5个接口：创建用户、查询用户、更新用户、删除用户、批量查询。

第一步，Swagger校验Skill发现“创建用户”接口的email字段没有example值，我手动补了一个test@example.com。

第二步，用例生成Skill输出了一份pytest文件，包含15个测试方法。我检查了一下，发现“批量查询”接口的用例只生成了正常场景，没有参数异常场景。原因是Swagger文档里这个接口的参数定义比较简单，模型没有识别出可异常的参数。我在提示词里加了一条：如果接口参数少于2个，至少生成一个空参数场景。

第三步，数据构造Skill生成了20条用户数据，包括正常数据、边界数据、异常数据。我注意到生成的手机号都是13800138000这种格式，但实际业务要求手机号必须唯一。我在提示词里加了唯一性约束，重新生成后问题解决。

第四步，脚本执行Skill跑完15个用例，8个通过，7个失败。失败归因Skill分析后发现：3个是环境问题（测试环境数据库连接超时），2个是数据问题（测试数据未清理导致唯一约束冲突），2个是用例问题（等待时间不够）。我根据分析结果分别处理，最终15个用例全部通过。

这次实操让我意识到，Skill的输出质量很大程度上取决于输入的完整性和提示词的约束力。输入越规范，输出越稳定。

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

5.1 Skill输出不稳定怎么办

这是最常见的问题。同一个Skill，同样的输入，两次输出可能不一样。原因通常有三个：提示词不够具体、输入信息有歧义、模型本身的随机性。

我的排查顺序是：先检查提示词，看有没有模糊的表述。比如“生成合理的测试数据”就是模糊的，“生成符合以下约束的测试数据：年龄0-120、邮箱格式正确、手机号11位”就是具体的。然后检查输入，看有没有缺失关键信息。最后，如果前两步都没问题，就在提示词里加“输出必须严格遵循以下格式”的强制约束，并降低模型的temperature参数。

5.2 生成的用例跑不通怎么定位

先看错误类型。如果是语法错误，说明模型输出的代码格式有问题，检查提示词里的格式要求是否明确。如果是断言失败，说明生成的预期结果不对，检查输入的业务规则是否完整。如果是元素定位失败，说明定位表达式不稳定，检查是否优先使用了accessibility id。

我整理了一个速查表：

5.3 多个Skill串联时格式不兼容

这个问题我遇到过好几次。比如用例生成Skill输出的是pytest格式，但脚本执行Skill期望的是unittest格式。解决方法是：在Skill的“输出格式”部分明确写清楚格式要求，并且在串联时加一个格式转换步骤。如果两个Skill的格式差异太大，就写一个简单的转换脚本，或者调整其中一个Skill的输出格式。

5.4 团队协作时Skill怎么共享和版本管理

我们用Git管理Skill文件，每个Skill一个Markdown文件。修改Skill时提PR，其他人review后合并。这样既能保证Skill的质量，又能记录修改历史。另外，我会定期整理“Skill使用报告”，统计每个Skill的调用次数、成功率、常见问题，作为优化的依据。

提示：Skill文件里一定要写“注意事项”和“已知问题”，这是团队协作时最有价值的部分。新人拿到Skill，先看注意事项，能避免80%的坑。

5.5 哪些场景不适合用Skill

不是所有测试任务都适合做成Skill。我的经验是：如果任务需要大量人工判断、输入信息极度不结构化、或者输出无法验证，就不适合。比如“探索性测试”就很难做成Skill，因为探索的过程本身就是发散的。再比如“用户体验评估”，需要主观判断，AI的输出参考价值有限。

适合做成Skill的场景通常有这些特征：输入输出边界清晰、有明确的验证标准、重复执行频率高。接口测试、数据构造、报告生成都符合这些特征。

6. 我个人的一些实操心得

这套Skill体系我用了大半年，最大的体会是：AI测试的效率提升不是线性的，而是阶梯式的。刚开始用单个Skill时，感觉只是省了一点写用例的时间。但当Skill数量积累到一定程度，并且串联成工作流之后，整个测试流程的效率发生了质变。以前一个模块的接口测试需要半天，现在从Swagger文档到测试报告只需要半小时，而且覆盖的场景更全。

另一个心得是：Skill需要持续迭代。我每个月会花一两个小时review所有Skill的使用情况，把经常出问题的Skill优化一下，把不再使用的Skill归档。这个过程很像维护一个代码库，不维护就会腐烂。

最后分享一个小技巧：如果你刚开始搭建Skill体系，不要一上来就搞25个。先从你最痛的那个环节开始，做一个Skill，用起来，跑通，再扩展。我最早只做了一个“用例生成Skill”，用了两周觉得稳定了，才慢慢加其他的。这样每一步都有正反馈，不容易半途而废。