上个月，团队里一个测试新人跑来找我，表情有点委屈。
“哥，我在项目里放了一个 SKILL.md，为什么 Claude Code 还是不会干活？”
我让他把文件打开。里面写着一段话：“你是资深测试工程师，请帮我生成测试用例，覆盖正常和异常场景。”
我看完就笑了。我说：“你这不是 Skill，是许愿。”
他愣了一下：“SKILL.md 不就是写提示词吗？”
这是大多数测试人刚接触 Agent Skills 时的第一个误解。 SKILL.md 不是提示词。它是一份结构化的操作手册。你写“帮我生成用例”，Agent 只会给你一段文本。你写清楚“第一步读什么、第二步拆什么、第三步输出什么格式、遇到异常怎么处理”，Agent 才知道该怎么干活。
今天这篇文章，我把“从 PRD 到高质量测试用例”的完整链路拆开讲。不是讲概念，是给你可以直接复制使用的模板和流程。
一、为什么你写的 SKILL.md 总是不生效？
过去一年，很多团队都在尝试用 AI 做测试。但真正跑起来的没几个。
问题出在哪？不是模型不行，是你给它的东西不是一个“能力单元”。
我们过去用 AI 做测试，基本套路就是写一段系统提示词：“你是资深测试工程师，请按照以下步骤执行回归测试……”然后期待它自己搞定一切。这个思路有一个根本性缺陷：LLM 是语言模型，不是操作系统的内核。 它可以告诉你“应该先登录再查询”，但面对动态验证码、偶尔超时的 API、需要滑动解锁的按钮，纯文本推理能力完全不够用。
Prompt 是说明书，告诉 Agent“拧开螺丝”。但真实任务执行，需要知道螺丝刀在哪个抽屉、顺时针拧几圈、遇到滑丝怎么处理——这些确定性操作流程，Prompt 给不了。
Agent Skills 解决的就是这个问题。 Anthropic 官方对 Skill 的定义很干脆：一个 Skill 就是一个文件夹。里面必须有一个 SKILL.md 文件，还可以放脚本、参考资料、静态资源。
用大白话说：Skill 就是把“资深测试工程师怎么做一件事”的完整经验，封装成一个 Agent 能随时调用的能力包。
它和 MCP 的区别是什么？MCP 解决“模型能用什么工具”——连数据库、接 GitHub、操作浏览器。Skill 解决“模型该怎么用这些工具”——按什么步骤、什么格式、什么标准。MCP 给 Agent 提供手，Skill 给 Agent 提供操作手册。 没有 Skill，Agent 有手也不知道怎么干活。
二、全景总览：生成测试用例需要哪几个 Skill？
测试用例设计的全流程，本质上可以拆成四个环节。每个环节封装成一个独立的 Skill，串起来就是一条从需求到用例的自动化流水线。
| 阶段 | Skill | 核心职责 | 输入 | 输出 |
|---|---|---|---|---|
| 需求拆解 | prd-to-test-map |
把 PRD 变成“测试地图” | 需求文档 | 功能清单+业务规则+风险预判 |
| 用例生成 | test-case-generator |
把测试地图变成结构化用例 | 测试地图 | 用例表格（正常/异常/边界/权限） |
| 场景补全 | test-scenario-completion |
基于历史 Bug 补充隐藏场景 | 用例集+历史Bug | 增强用例集 |
| 质量评审 | test-case-reviewer |
给用例集打分并给出改进建议 | 用例集 | 评审报告+改进项 |
数量和不用记，看分布有意思得多。活儿全压在两头：前面把需求拆清楚，后面把质量收干净。 中间的用例生成反而是最“顺”的一环，因为规则明确、格式固定。真正拉开差距的是需求拆解（能不能识别出隐性业务规则）和质量评审（能不能发现用例集的盲区）。
三、逐个拆解：每个 Skill 解决什么问题、怎么写、怎么用？
Skill ①：需求拆解——把 PRD 变成“测试地图”
解决什么问题？
拿到一份需求文档，很多人第一反应是“从头开始读”。但 PRD 往往写得不够结构化——功能描述、业务规则、异常说明散落在不同章节。测试人员需要手动提取功能点、梳理业务规则、识别风险点，这个过程高度依赖个人经验。
SKILL.md 怎么写？
---
name: prd-to-test-map
description: 从PRD中提取功能点、业务规则、数据约束和风险预判，生成结构化测试地图。当用户提到“分析需求”“拆解PRD”“梳理测试点”时触发。
when_to_use: 需求评审阶段，需要将PRD转化为可执行的测试点清单时使用。
---
## 任务
将用户提供的需求描述或PRD内容，转化为结构化的测试地图。
## 输出格式
1. **功能清单**：列出所有需要测试的功能点
2. **业务规则**：状态流转、计算公式、权限控制、限制条件
3. **数据约束**：输入数据的类型、格式、范围、必填性
4. **风险预判**：基于经验判断哪些功能最容易出问题（高/中/低）
## 规则
- 只从输入内容中提取信息，不臆造不存在的功能
- 如果某项信息不明确，标注“需确认”而不是猜测
- 风险预判基于通用测试经验：并发场景、边界值、状态流转通常为高风险
核心规则：事实与猜测分离。 每条输出标注证据来源（需求依据/经验假设/待确认）。需求没写的规则标注[待确认]，不要编造。
实测效果： 一份十来页的 PRD，Agent 在几秒内输出功能清单、业务规则、数据约束、风险预判。功能清单列了 3 条（已登录用户加入购物车、未登录触发登录引导、购物车数量上限校验），业务规则列了 4 条（上架校验、库存校验、数量累加、上限限制），风险预判标出了 3 个高/中风险点。
Skill ②：用例生成——把“测试地图”变成“测试用例”
解决什么问题？
有了测试地图，接下来要把它“翻译”成具体的测试用例。传统方式是手动一条条写——前置条件、操作步骤、预期结果。这个过程步骤繁琐、规则固定、重复性极高。
SKILL.md 怎么写？
---
name: test-case-generator
description: 根据功能描述或需求文档生成覆盖正常流程、异常场景、边界条件和权限校验的结构化测试用例。当用户提到“生成测试用例”“编写测试”“测试覆盖”“测试场景”时自动触发。
when_to_use: 用户需要从需求文档或功能描述生成测试用例时使用。适用于功能测试、回归测试、接口测试的用例设计阶段。
---
## 任务
根据用户提供的功能描述或测试地图，生成覆盖四大类场景的测试用例。
## 执行步骤
### 步骤1：理解测试地图
读取功能清单、业务规则和数据约束。
### 步骤2：识别测试场景
- **正常流程**：至少覆盖1条完整的Happy Path
- **异常场景**：参数缺失、格式错误、依赖服务超时
- **边界条件**：数值边界、状态边界、时间窗口边界
- **权限校验**：未授权访问、越权操作
### 步骤3：生成用例
每条用例包含：用例编号、测试场景、前置条件、测试步骤、预期结果、优先级
### 步骤4：自检
- [ ] 每个功能点是否有至少1条正向用例？
- [ ] 每个输入参数是否有异常场景覆盖？
- [ ] 边界值是否覆盖了上下界？
- [ ] 不同角色权限是否都有验证？
## 输出格式
Markdown表格，可直接复制到Excel或测试管理工具。
核心规则：SKILL.md 控制在 500 行以内。 Anthropic 官方推荐正文目标约 200 行，最多 500 行。超过 500 行，必须把详细内容移到 references/ 目录。
实测效果： 测试新人小陈接了一个“订单取消功能”的用例设计任务。按以往经验，这活儿至少 3 天。他打开 Claude Code，调了这个 Skill，2 小时后交出了一份覆盖正常流程、异常场景、边界值、权限校验的完整用例集。 测试组长看完之后，沉默了一会儿，问了一句：“这是谁写的？质量比我自己写还高。”
Skill ③：场景补全——把“没想到”的找出来
解决什么问题？
Skill ② 生成的用例已经很全面了，但 AI 毕竟不是人——它可能漏掉一些“只有业务老手才知道”的隐藏场景。比如并发下单时的库存扣减、优惠券和满减的叠加规则、异常状态下的回滚逻辑。
SKILL.md 怎么写？
---
name: test-scenario-completion
description: 基于历史Bug模式和业务知识，补充AI生成的测试用例中遗漏的隐藏场景。当用户提到“补充场景”“查漏补缺”“完善用例”时触发。
---
## 任务
审查已有的测试用例集，结合历史Bug数据和业务上下文，识别并补充遗漏的测试场景。
## 检查维度
1. **并发场景**：多用户/多请求同时操作同一资源
2. **状态流转**：异常状态下的操作（如已取消订单再次操作）
3. **数据一致性**：跨模块的数据同步（如订单取消→库存回滚）
4. **边界组合**：多个边界条件同时出现的情况
5. **历史故障**：该模块历史上出过什么类型的Bug
## 输出格式
对每个补充的场景，说明：场景描述、补充理由、具体的测试步骤和预期结果。
核心规则：知识图谱不需要很复杂。 一张 Excel 表格就够了——记录着“这个模块历史上出过什么类型的 Bug”。Agent 读取这张表，就能识别出“AI 没想到但很可能出问题”的场景。
Skill ④：质量评审——给用例集“打分”
解决什么问题？
用例写完了，但质量怎么样？覆盖全不全？有没有冗余？有没有逻辑矛盾？传统方式是人工评审——开个会，一群人对着 Excel 一条条看，效率低下且依赖评审人的经验水平。
SKILL.md 怎么写？
---
name: test-case-reviewer
description: 对测试用例集进行自动化质量评审，从覆盖完整性、规范性、一致性、优先级四个维度打分并给出改进建议。当用户提到“评审用例”“检查用例质量”“用例打分”时触发。
---
## 任务
审查测试用例集的质量，输出结构化的评审报告。
## 评审维度
1. **覆盖完整性**：是否覆盖了正常流程、异常场景、边界条件、权限校验？
2. **用例规范性**：每条用例是否包含完整的“前置条件-步骤-预期结果”？
3. **逻辑一致性**：前置条件和预期结果之间是否存在逻辑矛盾？
4. **优先级合理性**：P0/P1/P2的划分是否合理？
## 输出格式
- 总体评分（百分制）
- 各维度评分
- 待改进项列表（每条说明问题、位置、改进建议）
- 评审结论（通过/有条件通过/不通过）
核心规则：让 AI 先做一轮“预审”。 把明显的问题筛出来，人工只需要关注 AI 搞不定的部分。比如 AI 会指出“TC-007 步骤描述过于简略”“TC-009 缺少同步后验证数据一致性的步骤”“TC-003 涉及核心业务流程，建议从 P1 升级为 P0”。
四、完整流水线：四个 Skill 串起来怎么跑？
在 Claude Code 里，按顺序调用：
第1步：/prd-to-test-map → 输入PRD，输出测试地图
第2步：/test-case-generator → 输入测试地图，输出用例初稿
第3步：/test-scenario-completion → 输入用例集，补充隐藏场景
第4步：/test-case-reviewer → 输入用例集，输出评审报告
传统方式：啃 PRD（半天）→ 梳理测试点（半天）→ 写用例（1-2天）→ 人工评审（半天）→ 修改（半天）——总计 3-4 天。
Skill 流水线：四个 Skill 依次触发——2 小时出初稿，1 小时审核定稿。 效率提升 10 倍以上。
五、落地建议：别一次全装
拆解完四个 Skill 之后，说几条务实的建议。
第一，只装你最痛的那一段。 需求痛装需求拆解，用例痛装用例生成，质量痛装质量评审。全装一遍的结果通常是每个都跑过一次，然后一个都没用起来。
第二，喂进去真东西。 必须给项目真实的 PRD、真实的历史 Bug 表。用假数据跑出来的结果没有参考价值。
第三，打分只当提醒。 评审 Skill 给你 72 分，是让你去看哪条被扣分，不是让你把那个数字抄进周报。
六、踩坑提示：三个最常见的坑
坑一：description 写得太空。 “帮助生成测试用例”——这句话等于没说。Claude 会把所有 Skill 的 description 预加载进上下文，用来判断该不该触发。你写“帮助测试”，它永远不知道什么时候该用。你写“当用户提到生成测试用例、编写测试、测试覆盖、测试场景时触发”，它就知道。description 是 Skill 的“门牌号”，不是广告词。
坑二：SKILL.md 写成百科全书。 超过 500 行就开始浪费 Token。把详细的用例模板、业务规则库、历史 Bug 模式放到 references/ 目录，SKILL.md 只留核心流程和导航。利用渐进式披露机制——平时只加载名字和描述，等到真正使用时才加载完整内容。
坑三：Skill 粒度拆得太细。 一个工作流拆成 10 个 Skill，AI 不知道该用哪个。SkillsBench 的研究发现，2-3 个模块的 Skill 表现最好。测试用例生成拆成四个 Skill 是极限，拆成五个以上就开始反噬了。
额外提醒： 这类 Skill 的名字和能力会跟着版本变，装之前先看它自己那份说明。有些 Skill 要靠 MCP 或 API 接外部服务，意味着浏览器、测试平台、缺陷系统的权限都得开出去。公司的 PRD、日志、用户数据要走这条路，先问一句合规。
七、认知升华：从“工具切换者”到“工作流设计者”
一条链路跑下来，30 条用例变 70 条，但每条都有出处、有覆盖方向、有风险等级。但比数字更重要的是：你终于不用在“写用例、查覆盖、修脚本、拼报告”之间来回切换了。
四个 Skill 可以独立工作，也可以串联成矩阵。但“哪些场景必须覆盖”“哪些断言真正有价值”“失败之后该修脚本还是提 Bug”——这些判断，只能人来做。
以前你是“工具切换者”，现在你是“工作流设计者”。
测试人的经验，值得被封装成 Skill。你今天花 30 分钟写一个“测试用例生成”的 Skill，以后每一个项目都能复用。你今天花 20 分钟优化了 Skill 的规则，以后每一次生成都会更精准。
别只写提示词了。写一个 SKILL.md，让 Agent 真正替你干活。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
