接口测试进行到第三轮迭代时，很多人面对满屏的assert response.json()['code'] == 200开始陷入沉思。上游字段再次改动，几十个用例里的断言需要逐个重写。改到一半时，测试同事离职了，接手的人看着这些硬编码的魔数直挠头。
更糟糕的是，如今许多团队开始使用Claude Code或Copilot生成接口用例。生成速度是快了，但产出的依然是硬编码的断言，该脆弱的照样脆弱，该出问题的迟早会出问题。
这并非工具的问题，而是测试逻辑的封装粒度不够。今天我们来聊聊一套从工程实战中总结出的解决方案——通过Skills将校验逻辑模块化，让智能体自动组合请求与校验。
一、接口测试的“脚本地狱”正在吞噬你的时间
打开任何一个运行两年以上的接口测试仓库，你大概率会看到这样的代码：
def test_login_success():
resp = requests.post("/api/login", json={"user":"admin","pass":"123456"})
assert resp.status_code == 200
assert resp.json()["code"] == 0
assert resp.json()["data"]["token"] != ""
这还只是“正常登录”这一个用例。再加上密码错误、账号不存在、验证码过期、字段缺失……每个用例里都堆满了高度重复的断言结构。字段名一改，全量重测。测试套件越写越像一本锁死版本的字典，业务一迭代，字典就变成废纸。
更令人焦虑的是，AI代码助手虽然来了，但也学会了复制粘贴这种硬编码模式，只不过复制得更快、更多。硬编码断言的本质，是把测试人员的判断力锁死在脚本里，每一次业务变更都需要人工解锁。效率提升的边际收益，全被维护成本吃掉了。
二、从“写断言”到“教AI判断正确性”
硬编码断言为什么脆弱？因为它用“具体值”来定义正确性。而正确的定义，本来应该来自接口契约和业务规则。
如果一个接口文档里写了“成功时返回状态码200，code字段为0，data.token为非空字符串”，那么这个规则就不应该被人肉翻译成三行assert，而应该直接被机器消费。
这就是本质变化：接口测试的核心活动正在从“编写用例脚本”转向“让智能体理解契约并自主校验”。
这个转向中，校验逻辑必须从一次性脚本中解耦出来，变成可组合、可复用的独立单元。这些单元就是Skills。
三、Skills如何让智能体学会接口测试
一个Skill就是一个封装好的校验能力。例如：
| Skill名称 | 能力描述 |
|---|---|
| HttpStatusCodeSkill | 校验响应状态码是否符合预期 |
| JsonPathExistsSkill | 校验JSON路径是否存在且非空 |
| JsonSchemaSkill | 校验响应结构是否匹配JSON Schema |
| ResponseTimeSkill | 校验响应时间是否在阈值内 |
| BusinessRuleSkill | 校验自定义业务规则（如金额计算） |
每个Skill都有标准接口：接收一段校验描述，输出一个可执行的校验函数。
而智能体的工作流，是把接口文档、测试场景和已有的Skills清单一起丢给大模型，让它自动规划“用哪些Skill、按什么顺序、带什么参数”来完成这次校验。
流程如下：
核心在于：智能体不直接生成断言代码，而是生成一份校验计划。这个计划由Skills解释执行。当接口字段变化时，只需要重新让智能体读取新的文档，重新生成校验计划，Skills本身的代码一行不用改。
四、实战：从零搭一个自动组合请求与校验的智能体
我们直接看代码。下面是一个最小可运行的Skills执行框架，用Python实现。
第一步，定义Skill基类和两个基础Skill：
from abc import ABC, abstractmethod
import requests
import jsonpath_ng
class BaseSkill(ABC):
@abstractmethod
def execute(self, response, params: dict) -> tuple[bool, str]:
"""返回 (是否通过, 失败原因)"""
class HttpStatusCodeSkill(BaseSkill):
def execute(self, response, params):
expected = params.get("expected", 200)
if response.status_code != expected:
return False, f"期望状态码 {expected}, 实际 {response.status_code}"
return True, ""
class JsonPathExistsSkill(BaseSkill):
def execute(self, response, params):
path = params["path"]
matches = jsonpath_ng.parse(path).find(response.json())
if not matches:
return False, f"路径 {path} 不存在或值为空"
return True, ""
第二步，构建Skill注册表：
SKILL_REGISTRY = {
"http_status_code": HttpStatusCodeSkill(),
"json_path_exists": JsonPathExistsSkill(),
# 更多Skills按需注册...
}
第三步，智能体规划与执行引擎：
这里用一段提示词让大模型（比如Claude）根据接口文档输出校验计划。我们只把大模型返回的JSON计划接进来。
import json
def run_test_from_plan(api_doc, plan_json):
"""
plan_json 是智能体输出的校验计划，结构示例：
{
"request": {"method":"POST", "url":"/api/login", "body": {...}},
"checks": [
{"skill":"http_status_code", "params":{"expected":200}},
{"skill":"json_path_exists", "params":{"path":"$.data.token"}}
]
}
"""
plan = json.loads(plan_json)
# 发送请求
req = plan["request"]
if req["method"] == "POST":
resp = requests.post(f"https://your-host{req['url']}", json=req.get("body", {}))
else:
resp = requests.get(f"https://your-host{req['url']}")
# 逐个执行校验
for check in plan["checks"]:
skill_name = check["skill"]
skill = SKILL_REGISTRY.get(skill_name)
if not skill:
print(f"[WARN] 未知Skill: {skill_name}")
continue
passed, reason = skill.execute(resp, check.get("params", {}))
if not passed:
print(f"[FAIL] {skill_name}: {reason}")
else:
print(f"[PASS] {skill_name}")
模拟：智能体根据API文档生成的计划
mock_plan = '''
{
"request": {
"method": "POST",
"url": "/api/login",
"body": {"username":"admin","password":"123456"}
},
"checks": [
{"skill":"http_status_code", "params":{"expected":200}},
{"skill":"json_path_exists", "params":{"path":"$.data.token"}}
]
}
'''
run_test_from_plan(None, mock_plan)
当你需要增加新的校验维度时，只需新增一个Skill类，注册到字典里。智能体自然就能在下次规划时选用它。不用再一个用例一个用例地改断言。
五、你缺的不是工具，是技能模块化思维
回看上面的代码，会发现一个关键设计：执行器完全不关心接口是什么，Skills不关心自己被谁调用。这种解耦让测试套件的演化速度能跟上业务。
从工程落地角度，有三条可以直接拿走用的原则：
- 凡是重复出现三次的断言模式，必须抽取为Skill。状态码校验、字段存在性校验、类型校验，这些都是通用件。
- 让接口文档当唯一的真相源。只要智能体能读懂OpenAPI Spec，你就不需要再用人眼去对着文档写断言。
- 校验计划是可审计的。智能体生成的JSON计划可以进版本管理，任何人随时能看清“这次接口测试到底查了哪些东西”。
这条路线走下去，测试人员的工作重心会从“写校验代码”转向“定义校验技能和审查校验计划”。前者的天花板是手速，后者的天花板是设计能力。
六、最后一个问题
你现在维护的那套接口测试，如果明天上游团队把接口字段全面重构，你需要改多少行断言？如果答案是“几乎全部”，那说明你手里的不是测试资产，是负债。
当智能体已经能做到自动组合Skills完成校验，人该做的事，是设计出足够健壮的技能模块，让AI有兵可用。
你的断言复用率，现在有多少？
```
