接口测试进行到第三轮迭代时，很多人面对满屏的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都有标准接口：接收一段校验描述，输出一个可执行的校验函数。

而智能体的工作流，是把接口文档、测试场景和已有的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有兵可用。

你的断言复用率，现在有多少？