如何把 API 測試規則封裝成 SKILL.md，供 AI 重複使用

2026-10-28 8

版权

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

简介： 本文揭示测试工程师重复向AI口述接口测试规则的低效痛点，提出将口头规则封装为结构化SKILL.md文件的方法：明确触发条件、前置步骤、三层断言、7类异常场景及自检清单。一次编写，长期复用，提升AI输出稳定性与团队协作效率。

上个月，团队里一个测试同学跑来找我，表情很崩溃。

“哥，我每天跟AI说的话，能绕地球一圈。”

我问他什么意思。他把聊天记录翻给我看，几乎每条对话开头都是同一段话：

“先调登录接口拿 token，把 token 放到后续请求的 header 里。业务接口的断言要检查 HTTP 200、code=0、data 不为空、关键字段类型正确。异常场景要测参数缺失、参数类型错误、鉴权失败、重复提交……”

他每天要跟AI说这段话至少五六遍。换个接口，换个模块，同样的开头重新说一遍。更麻烦的是，他休假的时候，同事接手他的活，AI不知道这些规则，生成的脚本断言只有status_code == 200。

我问他：“这段话你说了多久了？”

他说：“从我开始用AI写接口测试，说到现在，三个月了。”

我说：“你花了三个月，每天重复说一段本可以只写一次的话。 ”

图片
一、为什么“每次都说”是效率最大的漏斗？
先算一笔账。

一段完整的接口测试规则，包括登录拿token、断言分层、异常场景清单，写全了大概300字。每天说5遍，一个月22个工作日，就是33000字。三个月下来，将近10万字。

这10万字里，有9万字是重复的。

更贵的不是打字的时间，是每次都要重新说，意味着每次AI都可能漏掉某一条规则。你今天忘了说“鉴权失败要测”，AI就不测。明天忘了说“断言要查data字段”，AI就只查code。你输出的稳定性，取决于你每次的记忆力。

这不是“AI不好用”。这是你把一个应该固化的规则，当成了每次都要重新交代的口头约定。

二、这段话，其实就是一份SKILL.md
把你每天跟AI说的那段话，按SKILL.md的结构写出来，是这样的：

name: api-test-standard
description: 面向REST API的接口测试标准流程。当用户需要生成接口测试用例、编写接口自动化脚本、或提到“接口测试”“API测试”“生成用例”时触发。
when_to_use: 需要为任意REST接口生成测试用例或自动化脚本时使用。

allowed-tools: Read, Write, Bash

任务

为REST API生成符合团队标准的测试用例和自动化脚本。

前置步骤（必须执行）

调用登录接口 POST /api/v1/login，获取token
将token放入后续请求的 Authorization header
如果登录失败，终止执行并报告登录异常

断言标准（三层，缺一不可）

协议层

HTTP状态码符合预期
数据层
response.code = 0
response.data 不为空
关键字段类型正确、值在合法范围内
业务层
业务状态流转正确
金额/数量计算正确
关联数据一致

异常场景（必须覆盖）

参数缺失（逐个必填参数）
参数类型错误
参数格式错误（手机号、邮箱、日期）
鉴权失败（无token、token过期、越权）
重复提交（幂等性）
资源不存在
边界值（最大、最小、刚好越界）

输出要求

每条用例标注它覆盖了哪一层断言、对应哪个异常场景
断言禁止只写 status_code == 200
你每天说的那段话，翻译成这个结构，就是一份完整的Skill。

区别在于：以前你每次说，AI每次听。现在你写一次，AI每次都按这个标准执行。

三、封装成Skill之后，发生了什么？
我们团队那个测试同学，花了一个下午把这段话写成了SKILL.md。第二周他跟我说了三件事。

第一件事：他不再说那段话了。每次生成接口测试用例，只需要说“用api-test-standard测这个接口”，剩下的规则Skill里都有。

第二件事：AI的断言质量稳定了。以前他忘了说“查data字段”，AI就只查code。现在Skill里写死了三层断言，AI每次都会查。规则的稳定性，不再取决于他当天记不记得。

第三件事：他同事也能用了。他休假的时候，同事调用同一个Skill，生成的用例断言层级和他自己生成的一模一样。经验从“个人记忆”变成了“团队资产”。

四、怎么封装？四步走
第一步：把你最常说的那段话，原样写下来
不要一上来就想“怎么写得好”。先把你在对话框里重复次数最多的那段话，原封不动地打到一个文本文件里。

“重复次数最多”就是最好的封装信号。你说了五遍以上的规则，就值得写进Skill。

第二步：按“前置条件、执行步骤、断言、异常”拆开
你写测试用例时的结构，直接套过来：

你每次都说“先调登录拿token”——这是前置步骤。
你每次都说“断言要查code、查data、查业务状态”——这是断言标准。
你每次都说“异常要测参数缺失、鉴权失败、重复提交”——这是异常场景清单。
你写用例时怎么组织信息，Skill就怎么组织。

第三步：把“模糊表述”改成“可执行规则”
这一步是唯一需要动脑的地方。

模糊表述：“断言要检查业务正确性。”可执行规则：“response.code = 0 且 response.data 不为空且关键字段类型正确。”

模糊表述：“要测异常情况。”可执行规则：“逐个必填参数测缺失、测类型错误、测鉴权失败、测重复提交、测边界值。”

Agent不知道“正确”是什么意思。它只知道“字段等于什么值”。

第四步：加一个“自检清单”
在SKILL.md末尾加一段：

自检

生成用例后，检查：

[ ] 是否包含登录前置步骤？
[ ] 每条用例是否标注了断言层级？
[ ] 异常场景是否覆盖了7类？
[ ] 有没有断言只写了 status_code == 200？
这段自检清单，是让Agent在生成完之后，自己检查一遍有没有漏。你以前每次口头提醒的“别忘了查鉴权”，现在写进了自检项里。

五、避坑指南
坑一：把Skill写成“聊天记录”。你那段话是口语化的，Skill需要结构化。“先调登录拿token”要写成“调用POST /api/v1/login获取token，放入Authorization header”。口语是给人听的，结构化是给Agent执行的。

坑二：SKILL.md超过500行。详细的接口文档、业务规则库放到references/目录，SKILL.md只留核心流程和断言标准。

坑三：description写得太空。写“帮助接口测试”等于没写。要写清楚触发条件：用户提到“接口测试”“API测试”“生成用例”时触发。

坑四：写完不验证。用你之前手动生成过的用例做对比，看看Skill生成的断言层级、异常覆盖，和你人工生成的是否一致。不一致的地方，就是你没写清楚的地方。

坑五：只封装，不迭代。每发现一次AI漏掉的规则，就补进Skill。三个月后，你的Skill会比你记忆里的规则更全。

最后
你每天跟AI说的那段话，不是“提示词”，是“还没被封装的经验”。

你说了三个月，说明它足够重要、足够稳定、足够值得复用。只是你一直把它放在对话框里，没有把它放进一个文件里。

把它写成SKILL.md，一次封装，长期生效。你不再需要每天重复那段话，AI不再需要每天重新理解你的规则，团队不再需要每个人各自跟AI“口头约定”。

你花一个下午封装的东西，会在未来每一天替你说话。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。