上个月，团队里一个测试新人跑来找我，表情有点委屈。
“哥，我在项目里放了一个 SKILL.md，为什么 Claude Code 还是不会干活？”
我让他把文件打开。里面写着一段话：“你是资深测试工程师，请帮我生成测试用例，覆盖正常和异常场景。”
我看完就笑了。我说：“你这不是 Skill，是许愿。”
他愣了一下：“SKILL.md 不就是写提示词吗？”
这是大多数测试人刚接触 Skill 时的第一个误解。 SKILL.md 不是提示词。它是一份结构化的操作手册。你写“帮我生成用例”，AI 只会给你一段文本。你写清楚“第一步读什么、第二步拆什么、第三步输出什么格式、遇到异常怎么处理”，AI 才知道该怎么干活。
今天这篇文章，我带你用 30 分钟，把一个“许愿式 Prompt”改造成 AI 真正照做的 SOP。不绕弯子，直接上手。
第 0-5 分钟：先看看你的“许愿”缺了什么
打开你之前写的那段提示词，对照下面四个问题：
问题一：AI 知道什么时候该用这个 Skill 吗？你写“帮助测试”，AI 不知道什么时候触发。你得写“当用户提到生成测试用例、编写测试、测试覆盖时触发”。
问题二：AI 知道第一步该干什么吗？你写“请生成测试用例”，AI 直接从“生成”开始，跳过了“理解需求”和“拆解场景”。你得写清楚步骤顺序。
问题三：AI 知道什么算“对”吗？你写“覆盖异常场景”，AI 不知道要覆盖哪几类异常。你得写“参数缺失、类型错误、鉴权失败、重复提交、边界值”。
问题四：AI 知道输出什么格式吗？你写“生成用例”，AI 可能给你 Markdown 表格，可能给你 JSON，可能给你一段文字。你得写死格式。
这四个问题，就是“许愿式 Prompt”和“SOP”之间的差距。
第 5-15 分钟：把“愿望”翻译成“步骤”
打开一个空白文件，开始写 SKILL.md 的正文。不要一上来就想“怎么写得好”，先把流程按顺序列出来。
一个测试用例生成的 SOP，骨架大概是这样的：
任务
根据用户提供的功能描述或需求文档，生成覆盖四大类场景的测试用例。
执行步骤
步骤1：理解需求
读取用户提供的功能描述，提取：
- 核心功能是什么
- 输入参数和约束条件
- 业务规则和状态流转
- 权限和角色要求
步骤2：识别测试场景
- 正常流程：至少覆盖1条完整的Happy Path
- 异常场景：参数缺失、格式错误、依赖服务超时
- 边界条件：数值边界、状态边界、时间窗口边界
- 权限校验：未授权访问、越权操作
步骤3：生成用例
每条用例包含：用例编号、测试场景、前置条件、测试步骤、预期结果、优先级
步骤4：自检
- [ ] 每个功能点是否有至少1条正向用例？
- [ ] 每个输入参数是否有异常场景覆盖？
- [ ] 边界值是否覆盖了上下界？
- [ ] 不同角色权限是否都有验证？
输出格式
Markdown表格，可直接复制到Excel或测试管理工具。
这一步的关键，是“把动词写具体”。
不要说“分析需求”，要说“提取功能点、输入参数、业务规则、权限要求”。 不要说“生成用例”，要说“每条用例包含用例编号、测试场景、前置条件、测试步骤、预期结果、优先级”。 不要说“检查覆盖”，要说“逐项检查四个自检项”。
AI 不知道“分析”是什么意思。它只知道“提取哪些字段”。
第 15-25 分钟：给 Skill 装一个“触发开关”
正文写好了，接下来写头信息。头信息决定了 Claude Code 什么时候自动加载这个 Skill。
name: test-case-generator
description: 根据功能描述或需求文档生成覆盖正常流程、异常场景、边界条件和权限校验的结构化测试用例。当用户提到“生成测试用例”“编写测试”“测试覆盖”“测试场景”时自动触发。
when_to_use: 用户需要从需求文档或功能描述生成测试用例时使用。适用于功能测试、回归测试、接口测试的用例设计阶段。
allowed-tools: Read, Write, Edit
description 是 Skill 的“门牌号”，不是广告词。
❌ 写“帮助用户生成测试用例”——AI 不知道什么时候该用
✅ 写“当用户提到生成测试用例、编写测试、测试覆盖、测试场景时自动触发”——AI 一听到这些词就加载
when_to_use 要写清楚适用场景和不适用场景。 比如加一句“不适用于性能测试脚本生成”，能防止 AI 在错误的场景下加载这个 Skill。
第 25-30 分钟：验证——让 AI 真的跑一遍
Skill 写好了，不要直接拿去用。先做一次验证。
方法：找一条你之前人工写过的、符合规范的用例，让 Claude Code 用这个 Skill 重新生成一遍，对比三件事：
格式是否一致？（表格的列是不是你定义的列）
覆盖是否完整？（四类场景是不是都覆盖了）
自检是否执行？（AI 有没有真的对照自检清单检查）
不一致的地方，就是 SKILL.md 里没写清楚的地方。
比如 AI 生成的用例没有“越权操作”场景，说明你的异常场景清单里没写“越权操作”具体怎么测。补进去，重新验证。
验证通过的标准：AI 生成的用例，和你人工写的，在格式和覆盖度上没有显著差异。
一个真实的对比：改之前 vs 改之后
改之前（许愿式 Prompt）：
“你是资深测试工程师，请帮我生成登录功能的测试用例，覆盖正常和异常场景。”
AI 输出：三条用例——“登录成功”“密码错误”“账号不存在”。格式是纯文本，没有前置条件，没有优先级，断言只写了“登录成功”。
改之后（SOP 版 Skill）：
name:test-case-generator
description:根据功能描述生成覆盖正常流程、异常场景、边界条件和权限校验的结构化测试用例。当用户提到“生成测试用例”“编写测试”时触发。
任务
根据用户提供的功能描述，生成覆盖四大类场景的测试用例。
执行步骤
步骤1：理解需求
提取：核心功能、输入参数、业务规则、权限要求。
步骤2：识别测试场景
-正常流程：HappyPath
-异常场景：参数缺失、格式错误、鉴权失败、重复提交
-边界条件：数值边界、状态边界
-权限校验：未授权、越权
步骤3：生成用例
每条用例包含：编号、场景、前置条件、步骤、预期结果、优先级。
步骤4：自检
-[]覆盖四类场景？
-[]每条用例有前置条件和优先级？
输出格式
Markdown表格。
AI 输出：十二条用例，覆盖正常登录、密码错误、账号不存在、手机号格式错误、密码为空、验证码过期、账号锁定、重复提交、越权访问等场景。表格格式规范，每条有前置条件和优先级。
同样的 AI，同样的模型，输入换了一个容器，输出质量差了一个量级。
避坑指南
坑一：把 SKILL.md 写成“愿望清单”。 “请覆盖所有场景”“请保证质量”——这些是愿望，不是指令。AI 不知道“所有”是多少，“保证”是什么标准。
坑二：步骤写得太粗。 “第一步分析需求，第二步生成用例”——这不是步骤，是标题。每一步要写清楚“提取哪些字段、按什么规则判断、输出什么内容”。
坑三：description 写得太空。 写“帮助测试”等于没写。要写清楚触发词：用户说什么话、什么场景下加载。
坑四：写完不验证。 Skill 不是“写完就能用”的。用真实输入跑一遍，对比人工结果。不一致的地方，就是规则没写清楚的地方。
坑五：SKILL.md 超过 500 行。 详细模板、示例、业务规则库放到 references/ 目录，正文只留核心流程。
最后
许愿式 Prompt 和 SOP 的区别，不是“写得好不好”，是“AI 能不能照做”。
你写“帮我生成用例”，AI 只能给你一段文本。你写清楚第一步读什么、第二步拆什么、第三步输出什么格式、遇到异常怎么处理，AI 才知道该怎么干活。
30 分钟，把一段许愿改写成一份 SOP。 你今天花 30 分钟写的东西，会在未来每一个项目里替你干活。
下次你发现自己在对话框里反复描述同一套流程的时候，停下来，花 30 分钟把它封装成 Skill。
别许愿了。写 SOP。
