前阵子，团队里一个做了十年测试的老同事跑来找我，表情有点困惑。
“哥，我看你们天天聊Skill、SKILL.md，我看了一下，这不就是写提示词吗？跟我写测试用例有什么关系？”
我说：“你把你上个月写的那份‘优惠券叠加规则’的用例，打开给我看看。”
他打开了一个Excel，里面是40多条用例：前置条件、操作步骤、预期结果、优先级，按正常流程、异常场景、边界值分好了组，每条用例的断言写得清清楚楚。
我看完说了一句话，他愣住了。
“你这份Excel，就是一份SKILL.md。你写了十年测试用例，其实一直在写Skill，只是之前没有SKILL.md这个容器。 ”
一、你以为你在写用例，其实你在封装“判定逻辑”
先别急着反驳。我们把一份测试用例拆开看。
一条标准的测试用例，长这样：
前置条件：用户已登录，账户余额大于0
操作步骤：进入提现页 → 输入金额100 → 点击提交
预期结果：提现申请创建成功，余额减少100，流水记录生成
异常分支：金额为负数时提示错误，余额不足时拦截
现在把这条用例，翻译成一段SKILL.md的正文：
任务
验证用户提现流程是否按预期执行。
前置条件
- 用户已登录
- 账户余额大于0
执行步骤
- 进入提现页
- 输入金额100
- 点击提交
断言
- 提现申请创建成功
- 余额减少100
- 流水记录生成
异常处理
- 金额为负数：提示错误，不创建提现单
- 余额不足：拦截，不创建提现单
发现了吗？内容一模一样。 你写测试用例时做的“前置条件、步骤、预期结果、异常分支”，就是Skill正文里的“前置条件、执行步骤、断言、异常处理”。
你不是在“写用例”，你是在把“怎么判断一个功能对不对”这件事，封装成一套可执行的判定逻辑。
而这，就是Skill的本质。
二、测试用例和Skill，到底差在哪？
差在三个地方，而且这三个地方，恰恰是测试工程师的强项。
第一个差别：用例是“给人看的”，Skill是“给Agent执行的”
你写的用例，是给测试同事看的。测试同事看完，知道“哦，这里要验余额，那里要验流水”。但这句话里有很多隐含信息——“流水记录生成”这个断言，到底是查哪张表、看哪个字段、什么值算“生成”？
人脑能补全这些隐含信息，Agent不能。
Skill要求你把“人脑补全的部分”显式写出来。 这正是测试工程师最擅长的——你写用例的时候，本来就在训练自己“把模糊的需求变成明确的判定”。
第二个差别：用例是“一次性的”，Skill是“可复用的”
你写了一份“优惠券叠加”的用例，下一个项目来了类似的促销规则，你会怎么办？复制一份，改改字段名。
Skill的做法是：把“优惠券叠加”的判定逻辑封装成一个Skill，下一个项目调用它，只需要传入新的规则参数。
测试工程师本来就有“复用”的意识——你写用例时，会把公共的登录步骤抽成前置条件，会把重复的校验抽成公共断言。Skill只是把这种复用，从“人工复制”升级成了“Agent自动调用”。
第三个差别：用例靠“人执行”，Skill靠“Agent执行”
这是最根本的差别。你写的用例再好，也需要一个人坐在电脑前，一步步操作、一条条核对。
Skill写好了，Agent可以自己执行、自己判断、自己重试。你从“执行者”变成了“规则制定者”。
但注意：Agent能执行的前提，是你把规则写得足够明确。 这恰恰是你写十年用例练出来的能力——把“我觉得这里应该没问题”变成“我验证了这三个字段，值分别是X、Y、Z”。
三、怎么把你的“用例经验”翻译成Skill？
不用从头学。你现有的测试用例，稍微改一下结构，就是一份可用的SKILL.md。
第一步：把“用例集”改成“任务定义”
你原来的用例集，是按功能模块分的。改成Skill，第一步是把“这个Skill要完成什么任务”说清楚。
原来：优惠券叠加规则测试用例（40条）
改成：
任务
验证优惠券叠加场景下的金额计算和状态流转是否正确。
第二步：把“前置条件”改成“输入约束”
你写的“用户已登录、账户余额大于0、优惠券在有效期内”，在Skill里叫“输入约束”。这不是文字游戏，是让Agent知道“什么条件下这个Skill适用，什么条件下不适用”。
输入约束
- 用户已登录
- 优惠券状态为“未使用”且未过期
- 订单金额大于0
- 不适用于：已取消订单、已退款订单
第三步：把“预期结果”改成“分层断言”
这是最关键的一步。你原来写的“提现成功”，在Skill里要拆成三层：
断言
协议层
- HTTP状态码 200
数据层
- 响应体 code 字段为 0
- 响应体 data.withdraw_id 非空
业务层
- 数据库 withdraw 表新增一条记录，状态为“处理中”
- 用户余额 = 原余额 - 提现金额
- 流水表新增一条“提现”类型记录
你写用例时本来就在做这件事——你知道“提现成功”不只是页面弹个提示，还要查余额、查流水、查状态。只是以前你把这些写在“备注”里，现在要写进“断言”里。
第四步：把“异常用例”改成“异常处理规则”
你写的“金额为负数时提示错误”“余额不足时拦截”，在Skill里是“异常处理”。但要注意——不要只写“提示错误”，要写清楚“错误码是什么、错误信息包含什么、系统状态有没有变化” 。
异常处理
- 金额为负数：返回400，错误码 AMOUNT_INVALID，不创建提现单，余额不变
- 余额不足：返回400，错误码 BALANCE_INSUFFICIENT，不创建提现单，余额不变
- 重复提交：返回409，错误码 DUPLICATE_REQUEST，返回已存在的提现单ID
四、一个真实的对比：同一个经验，两种写法
我们拿“退款金额校验”这个场景做对比。
用例写法（你写了十年的方式）：
用例编号：REF-012 场景：退款金额超过订单实付金额 前置条件：订单已支付，实付金额100元 步骤：发起退款，金额输入150元 预期结果：退款失败，提示“退款金额不能超过实付金额”
Skill写法（同一份经验，换了个容器）：
断言
- 协议层：HTTP 400
- 数据层：响应体 code = REFUND_AMOUNT_EXCEEDED
- 业务层：
- 退款单未创建
- 订单状态保持“已支付”不变
- 用户余额未增加
- 操作日志记录一条“退款金额超限”事件
内容没有变，变的是“颗粒度”和“可执行性”。
用例写法里，“退款失败”是一个人可以理解的结论。Skill写法里，“退款失败”被拆成了四个可验证的事实。Agent拿到后者，才知道该去查哪张表、看哪个字段、比对什么值。
五、避坑指南
坑一：把用例原文直接粘进SKILL.md。 用例是给人看的，里面有大量隐含信息（“验证成功”“检查正确”）。SKILL.md要的是显式规则，不能有“你懂的”这种假设。
坑二：断言只写一层。 只写“HTTP 200”的断言，等于没写。三层断言（协议、数据、业务）是底线。
坑三：异常处理只写“提示错误”。 要写清楚错误码、错误信息、系统状态有没有变化。Agent需要这些信息来判断“失败得对不对”。
坑四：Skill写得太长。 一份SKILL.md超过500行，就要拆分。把详细的用例模板、业务规则库放到references/目录，SKILL.md只留核心流程。
坑五：写完不验证。 写完Skill，用你原来的用例集跑一遍，看看Agent执行的结果和你人工执行的结果是否一致。不一致的地方，就是你没写清楚的地方。
六、你早就有的三个“Skill资产”
写了十年用例，你手里其实已经有三样东西，可以直接变成Skill。
第一，你的用例库。 那些写得最细、断言最完整的用例，就是最好的SKILL.md素材。挑出你最有信心的10条，按上面的四步翻译一遍。
第二，你的Bug记录。 每一个你发现过的Bug，背后都有一条“AI不知道的判定规则”。“用户用特殊字符密码可以绕过验证”——这条规则写进Skill，下次Agent就会去测特殊字符。
第三，你的检查清单。 你每次上线前都要过一遍的那个“脑子里的清单”——接口通不通、数据对不对、异常拦没拦住——把它写下来，就是一份Skill。
最后
Skill不是新东西。它是你写用例时，一直在做的那件事——把模糊的“应该没问题”，变成明确的“验证了这三个字段”。
只是以前，这份判定逻辑的“执行者”是人。现在，执行者可以是Agent。
你不需要重新学一套方法论。你只需要把你写了十年的用例，换一个容器装。
那个老同事后来把“优惠券叠加”那份Excel，花了一个下午改成了SKILL.md。第二天他跑了一遍，Agent生成的用例覆盖了他漏掉的三个边界场景。
他说了一句话：“原来我十年前就该写这个。 ”
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
