如何用 30 分鐘把測試用例提示詞改寫成 Claude Code 的 SKILL.md SOP

2026-10-30 6

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 本文揭秘测试工程师如何将“许愿式提示词”升级为AI可执行的SKILL.md——不是写愿望，而是写结构化SOP：明确触发条件、分步操作、校验规则与输出格式。30分钟手把手改造，让Claude Code真正听懂、照做、产出高质量测试用例。

上个月，团队里一个测试新人跑来找我，表情有点委屈。

“哥，我在项目里放了一个 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。