从PRD到高质量用例集，四个Skill搞定，效率提升10倍
大家好，我是某互联网公司的测试架构师。
上个月，团队接了个电商购物车模块的改版项目。需求文档不复杂，大概十来页。测试组长看了一眼排期，皱了下眉：“按以前的节奏，光写用例就得3天。”
团队里一个刚转正的测试新人接了这个任务。他花20分钟调用了一个Skill，2小时后交出了一份覆盖正常流程、异常场景、边界值、权限校验的完整用例集。
测试组长看完之后，沉默了一会儿，问了一句：“这是谁写的？质量比我自己写还高。”
他说的“那个东西”，就是今天这篇文章要讲的——4个Agent Skill组合拳。
一、传统用例设计，到底卡在哪？
先说说大多数测试团队的真实状态。
拿到一份需求文档之后，用例设计流程大概是这样的：理解需求文档 → 梳理测试点 → 编写设计测试用例 → 用例评审与优化 → 定稿。
看起来步骤清晰，但实际操作起来处处是坑。
坑一：高度依赖个人经验。 同一个需求，3年经验的工程师和1年经验的工程师，写出来的用例覆盖度可能差一倍。经验没法快速复制。
坑二：漏场景是常态。 异常场景、边界条件、并发场景——这些“非主流程”的内容，人脑枚举永远会漏。
坑三：重复劳动。 每个项目都要重新写一遍相似的用例，同样的模板、同样的格式、同样的检查清单——周而复始。
传统模式下，测试人员大量时间花在机械重复的编写工作上，真正应该投入精力的业务分析和风险识别反而被压缩了。
但2026年的情况已经完全不一样了。
借助AI + Agent Skill能力，我们可以把用例设计的标准化流程、通用规则封装为可复用技能。你不是在“让AI帮你写用例”，而是在“把一套测试工作流交给AI自动执行”。
二、核心思路：四个Skill，覆盖用例设计全流程
很多人第一次接触“Skill”这个概念的时候，以为就是“高级一点的Prompt”。完全不是一回事。Skill是Anthropic在2025年10月推出的“技能包”机制，核心是把提示词、脚本、参考资料打包成一个文件夹，AI在需要时自动发现并调用。
用大白话说：Skill就是把“资深测试工程师怎么做用例设计”的完整经验，封装成一个AI能随时调用的“能力包”。
测试用例设计的全流程，本质上就是一套可以拆成四个环节的标准化流水线：
需求拆解 → 用例生成 → 场景补全 → 质量评审
每一个环节，都可以封装成一个独立的Skill。四个Skill串在一起，就是一条从需求到高质量用例的“自动化流水线”。
下面把这四个Skill逐个拆开，附上可以直接用的Skill模板。
三、Skill ①：需求拆解 —— 把PRD变成“测试地图”
痛点
拿到一份需求文档，第一反应是“从头开始读”。但PRD往往写得不够结构化——功能描述、业务规则、异常说明散落在不同章节。测试人员需要手动提取功能点、梳理业务规则、识别风险点——这个过程高度依赖个人经验。
Skill设计思路
这个Skill的核心任务只有一个：把自然语言的需求文档，变成结构化的“测试地图” ——功能清单、业务规则、数据约束、风险预判。
真实输入
以电商购物车“加入购物车”功能为例：
功能：用户将商品加入购物车
参与者：已登录用户
前置条件：用户已登录，商品处于上架状态
主流程：用户浏览商品 → 点击“加入购物车” → 系统校验库存 → 商品加入购物车 → 提示添加成功
异常情况：库存不足时提示“库存不足”
Skill输出
几秒钟后，AI输出了一份结构化的“测试地图”：
【功能清单】
F1：已登录用户将商品加入购物车
F2：未登录用户点击“加入购物车”（触发登录引导）
F3：购物车数量上限校验
【业务规则】
R1：商品必须处于“上架”状态才能加入购物车
R2：加入购物车时需校验库存，库存不足则拦截
R3：同一商品多次加入，购物车中数量累加
R4：购物车商品数量有上限（需确认具体数值）
【数据约束】
D1：商品ID：必填，字符串，存在性校验
D2：数量：必填，正整数，≥1
D3：用户ID：必填，存在性校验
【风险预判】
⚠️ 高风险：库存校验的并发场景（超卖）
⚠️ 中风险：购物车数量上限的边界值
⚠️ 中风险：未登录状态的跳转逻辑
这个“测试地图”的价值在于：它不是AI凭空想象的，而是从需求文档里“抽”出来的。 测试人员拿到这张地图，对“要测什么”心里已经有了底。
Skill模板（可直接复制）
---
name: prd-to-test-map
description: 从PRD中提取功能点、业务规则、数据约束和风险预判，生成结构化测试地图。适用于需求评审、测试点梳理阶段。
---
## 任务
将用户提供的需求描述或PRD内容，转化为结构化的测试地图。
## 输出格式
按以下四个维度组织输出：
1. **功能清单**：列出所有需要测试的功能点，每个功能用一句话描述
2. **业务规则**：列出所有业务规则（状态流转、计算公式、权限控制、限制条件）
3. **数据约束**：列出输入数据的类型、格式、范围、必填性
4. **风险预判**：基于经验判断哪些功能最容易出问题，标注风险等级（高/中/低）
## 规则
- 只从输入内容中提取信息，不臆造不存在的功能
- 如果某项信息不明确，标注“需确认”而不是猜测
- 风险预判基于通用测试经验：并发场景、边界值、状态流转通常为高风险
四、Skill ②：用例生成 —— 把“测试地图”变成“测试用例”
痛点
有了测试地图，接下来要把它“翻译”成具体的测试用例。传统方式是手动一条条写——前置条件、操作步骤、预期结果。这个过程步骤繁琐、规则固定、重复性极高。
Skill设计思路
这个Skill的核心任务：基于测试地图，自动生成结构化的测试用例，覆盖正常流程、异常操作、边界条件和权限校验四大场景。
真实输出
把Skill①输出的“测试地图”喂给Skill②，AI自动生成了一份完整的测试用例表格：
| 用例编号 | 测试场景 | 前置条件 | 测试步骤 | 预期结果 | 场景类型 | 优先级 |
|---|---|---|---|---|---|---|
| TC-001 | 正常加入购物车 | 用户已登录；商品A库存充足 | 1.浏览商品A 2.点击“加入购物车” | 商品加入购物车；提示“添加成功”；购物车数量+1 | 正常流程 | P0 |
| TC-002 | 库存不足时加入 | 用户已登录；商品A库存为0 | 1.浏览商品A 2.点击“加入购物车” | 提示“库存不足，无法加入”；购物车不变 | 异常场景 | P0 |
| TC-003 | 未登录时加入 | 用户未登录 | 1.浏览商品A 2.点击“加入购物车” | 跳转至登录页；登录后商品自动加入购物车 | 权限校验 | P1 |
| TC-004 | 同一商品重复加入 | 用户已登录；购物车已有1件商品A | 1.再次点击商品A的“加入购物车” | 购物车中商品A数量变为2 | 正常流程 | P1 |
| TC-005 | 购物车数量达到上限 | 用户已登录；购物车已满 | 1.尝试再加入一件商品 | 提示“购物车已满”；无法加入 | 边界条件 | P1 |
40多条用例，覆盖了正常流程、异常场景、边界值、权限校验四大类——如果人工写，至少要2-3天。AI只用了不到1分钟。
Skill模板（可直接复制）
---
name: test-case-generator
description: 根据功能描述自动生成结构化的测试用例。适用于编写测试用例、验证功能完整性、回归测试设计等场景。
---
## 任务
根据用户提供的功能描述或测试地图，生成覆盖正常流程、异常操作、边界条件和权限校验四大类场景的测试用例。
## 输出格式
表格，包含以下字段：
- 用例编号：{模块缩写}-{类型缩写}-{序号}
- 测试场景：一句话描述
- 前置条件：执行前必须满足的条件
- 测试步骤：编号列表，每步一个操作
- 预期结果：执行后的期望结果
- 场景类型：正常流程/异常场景/边界条件/权限校验
- 优先级：P0/P1/P2
## 规则
- 每个功能点至少生成1条正向用例 + 3条异常/边界场景
- 优先覆盖用户高频操作、核心业务链路、高危边界场景
- 测试步骤必须具体可执行，不能是模糊描述
五、Skill ③：场景补全 —— 把“没想到”的找出来
痛点
Skill②生成的用例已经很全面了，但AI毕竟不是人——它可能漏掉一些“只有业务老手才知道”的隐藏场景。比如：并发下单时的库存扣减、优惠券和满减的叠加规则、异常状态下的回滚逻辑。
Skill设计思路
这个Skill的核心任务：基于历史Bug模式或知识图谱，自动识别“AI没想到但很可能出问题”的场景，补充到用例集中。
这里的“知识图谱”可以很简单——就是一张Excel表格，记录着“这个模块历史上出过什么类型的Bug”。
真实输出
基于历史Bug模式，AI自动补充了3条“隐藏场景”：
| 用例编号 | 测试场景 | 补充理由 |
|---|---|---|
| TC-008 | 高并发下同时加入同一商品 | 历史数据显示该模块在秒杀场景下出现过库存超卖 |
| TC-009 | 购物车商品跨设备同步 | 用户在多端登录时，购物车数据需实时同步 |
| TC-010 | 加入购物车时触发价格变更 | 商品价格在用户浏览和点击加入之间发生变化 |
这三条场景，Skill②的“通用用例生成”逻辑覆盖不到。只有结合了历史经验和业务上下文，才能发现它们。
Skill模板（可直接复制）
---
name: test-scenario-completion
description: 基于历史Bug模式和业务知识，补充AI生成的测试用例中遗漏的隐藏场景。
---
## 任务
审查已有的测试用例集，结合历史Bug数据和业务上下文，识别并补充遗漏的测试场景。
## 检查维度
1. **并发场景**：多用户/多请求同时操作同一资源
2. **状态流转**：异常状态下的操作（如已取消订单再次操作）
3. **数据一致性**：跨模块的数据同步（如订单取消→库存回滚）
4. **边界组合**：多个边界条件同时出现的情况
5. **历史故障**：该模块历史上出过什么类型的Bug
## 输出格式
对每个补充的场景，说明：
- 场景描述
- 补充理由（为什么AI会漏掉、为什么重要）
- 具体的测试步骤和预期结果
六、Skill ④：质量评审 —— 给用例集“打分”
痛点
用例写完了，但质量怎么样？覆盖全不全？有没有冗余？有没有逻辑矛盾？传统方式是人工评审——开个会，一群人对着Excel一条条看，效率低下且依赖评审人的经验水平。
Skill设计思路
这个Skill的核心任务：对整份用例集做自动化质量评审，从覆盖完整性、用例规范性、逻辑一致性、优先级合理性四个维度打分，并给出改进建议。
真实输出
AI自动生成了一份“质量评审报告”：
【测试用例质量评审报告】
📊 总体评分：87/100（良好）
📈 各维度评分：
- 覆盖完整性：92/100 ✅
- 用例规范性：85/100 ⚠️（部分用例步骤描述不够具体）
- 逻辑一致性：90/100 ✅
- 优先级合理性：80/100 ⚠️（部分P1用例应升级为P0）
🔴 待改进项（3项）：
1. TC-007：步骤描述过于简略，建议补充具体操作方式
2. TC-009：缺少“同步后验证数据一致性”的步骤
3. 优先级调整：TC-003涉及核心业务流程，建议从P1升级为P0
✅ 评审结论：用例集整体质量良好，建议优先修复3项待改进项后定稿。
这份评审报告的价值在于：让AI先做一轮“预审”，把明显的问题筛出来，人工只需要关注AI搞不定的部分。
Skill模板（可直接复制）
---
name: test-case-reviewer
description: 对测试用例集进行自动化质量评审，从覆盖完整性、规范性、一致性、优先级四个维度打分并给出改进建议。
---
## 任务
审查测试用例集的质量，输出结构化的评审报告。
## 评审维度
1. **覆盖完整性**：是否覆盖了正常流程、异常场景、边界条件、权限校验？
2. **用例规范性**：每条用例是否包含完整的“前置条件-步骤-预期结果”？
3. **逻辑一致性**：前置条件和预期结果之间是否存在逻辑矛盾？
4. **优先级合理性**：P0/P1/P2的划分是否合理？
## 输出格式
- 总体评分（百分制）
- 各维度评分
- 待改进项列表（每条说明问题、位置、改进建议）
- 评审结论（通过/有条件通过/不通过）
七、四个Skill串起来：一条完整的用例生成流水线
把这四个Skill串在一起，就是一套完整的测试用例生成流水线：
📄 需求文档
↓
[Skill ① 需求拆解] → 测试地图（功能清单+业务规则+风险预判）
↓
[Skill ② 用例生成] → 用例初稿（40+条结构化用例）
↓
[Skill ③ 场景补全] → 用例增强（补充3-5条隐藏场景）
↓
[Skill ④ 质量评审] → 评审报告+改进建议
↓
✅ 高质量用例集（人工审核后定稿）
传统方式：啃PRD（半天）→ 梳理测试点（半天）→ 写用例（1-2天）→ 人工评审（半天）→ 修改（半天）——总计3-4天。
Skill流水线方式：调用四个Skill，AI自动完成从需求到用例的全流程——总计2小时出初稿，人工审核1小时定稿。
效率提升：10倍以上。
八、避坑指南
坑一：一上来就想“全自动化”
不要指望四个Skill一次性跑完所有环节，中间没有任何人工介入。AI生成的是“初稿”，不是“终稿” 。我们的流程永远是“AI生成→人工审核→确认定稿”。
解法：在每个Skill的输出环节设置“人工确认点”。比如Skill①输出测试地图后，先让测试负责人确认“功能清单有没有遗漏”，再进入Skill②。
坑二：SKILL.md的description写得太空
Description是AI判断“什么时候启用这个Skill”的唯一依据。写“帮助测试”这种描述，AI永远不知道什么时候该用它。
解法：Description要写清楚“触发条件”。比如：“当用户提到‘生成测试用例’‘编写测试’‘测试覆盖’‘测试场景’等意图时触发此技能。”
坑三：忽略了Skill的“渐进式披露”优势
很多人把Skill当成“把一堆内容塞进去就行”，结果Skill文件越来越大，每次加载都消耗大量上下文。
解法：利用Skill的“渐进式披露”设计——SKILL.md只放核心指令，大段参考资料放到references/目录下，脚本放到scripts/目录下。AI只在需要时才加载这些附加内容。
坑四：只建Skill，不迭代
Skill不是一次建完就完事了。业务在变、需求在变、历史Bug在变——Skill也需要持续更新。
解法：建立Skill的“反馈闭环”——每次使用后记录“AI漏了什么场景”“哪里判断错了”，定期用这些反馈更新SKILL.md。
最后
传统测试的底层资产是“测试用例库”——用例是一次性的，用完就扔。
AI时代的底层资产正在变成“Skill库”——Skill是可组合、可复用的能力单元。
一个Skill封装的不只是一个具体输入输出，而是一种“做某件事的方法”。你今天花30分钟写了一个“需求拆解”的Skill，以后每一个项目都能复用。你今天花20分钟写了一个“用例生成”的Skill，以后每一个功能都能调用。
Skill不是让你“少干活”，是让你“把经验留下来” 。
目前社区已经涌现了大量高质量的测试Skill库。awesome-qa-skills提供了4个测试工作流和25种测试类型技能（58个Skill文件夹），覆盖从需求分析到缺陷报告的全链路。fishzjp/qa-skills提供了10个可复现的QA Agent Skills。还有petrkindlmann/qa-skills提供了50个测试自动化技能。
下次你拿到一份需求文档的时候，别从零开始写用例了。花点时间，把四个Skill搭起来。
2小时后，你会看到一份比你想象中更全的用例集。
而你写的那些Skill，会在未来的每一个项目里，继续替你干活。
本文系作者基于真实项目经验的总结。文中所有Skill结构和配置均来自2026年实际落地项目。
