这两年我一直在折腾企业级接口自动化，从最早的工具录制回放到后来基于Python的pytest全家桶，框架层面能踩的坑基本都踩完了。但真正让业务团队参与进来的瓶颈从来不是工具，而是“写脚本”这道门槛。今年我把整个接口自动化流程切换成了 Claude Code + GLM-5 + Skills 的组合，实现了从自然语言描述到可执行脚本的零代码生成，业务同事在对话框里提需求，我负责审核和兜底，一周时间就把三条核心交易链路的接口用例全部覆盖，后续迭代也顺了不少。这篇把整体方案、落地细节和踩坑记录完整梳理一遍，给同样在接口自动化里挣扎的朋友一个参考。

先说这个方案解决了什么问题。传统的接口自动化分工里，业务提需求、测试写脚本、研发维护接口文档，三方之间反复对齐的成本非常高。哪怕有了postman、jmeter这样的录制工具，也只是降低了入门门槛，一旦接口字段调整、依赖关系变化，脚本照样要人肉去改。而纯靠AI在网页里问一段代码，拿到手还是一段片段，没法直接落地运行。Claude Code + GLM-5 + Skills 的思路是把“AI生成能力”和“工程约束”绑在一起：Claude Code负责在终端里读写文件、执行命令、跑测试，GLM-5负责理解和生成代码，Skills则像给AI装了一整套企业级测试规范模板，让生成结果不是“能跑的代码”，而是“符合团队规范、可直接进CI的测试资产”。适合的读者是那些已经有一定接口测试基础、想用AI重构现有自动化体系的人，也适合刚接手企业自动化建设、想从零搭建一套低门槛体系的小团队。

1. 方案设计与核心思路拆解

1.1 企业级接口自动化的真实痛点

接口自动化这事，表面看是技术问题，本质上其实是协作问题。我梳理了一下过去几年在不同项目里遇到的核心痛点，大致能归成四类。

第一类是脚本门槛。业务团队最懂业务规则，但让他们去写requests调用、处理断言、设计数据驱动，基本不现实。测试团队懂技术但往往离业务语义有距离，需求传递过程中会丢失大量隐含规则。第二类是资产沉淀问题。接口自动化最值钱的不是代码，而是对业务规则的显式化描述。但传统做法里，这些规则散落在测试用例、接口文档、开发的口头说明里，根本没有一个结构化载体。第三类是执行链路的割裂。脚本写完只是开始，还要处理环境切换、数据清理、报告输出、CI接入，每一步都是额外的工程成本。第四类是维护成本。接口一变，脚本就得跟着改，改完还要重新验证，这导致很多团队的自动化用例越写越少。

这个方案能成立，核心在于换了一种思路：把“写脚本”这个动作从人转移到AI，把“业务规则”从人脑转移到结构化文档，把“生成规范”从口头要求转移到Skill约束。人只需要负责描述场景、审核结果和处理异常，剩下的重复工作全部交给AI。

1.2 为什么选择 Claude Code + GLM-5 + Skills

先说Claude Code。它是个跑在终端里的AI编程代理，不是简单的聊天机器人。它既能理解自然语言指令，也能直接操作代码库：创建文件、编辑代码、执行命令、查看运行结果、根据报错自动修复。这一点对接口自动化来说非常重要，因为生成脚本只是第一步，生成之后要能运行、要能根据报错调整，这才是闭环。

再说GLM-5。作为生成脚本的底座模型，我选择它主要看中两点。一是代码生成能力稳定，尤其在中文业务语义理解上，能把“创建一个用户然后查一下余额扣没扣”这种口语化描述，准确翻译成接口调用顺序和断言逻辑。二是长上下文处理能力强，企业级接口描述文档往往很长，拆分为分片后仍然能保持对前文规则的遵循，不会“说着说着就忘了”。

Skills是Claude Code的技能系统，本质是一组可复用的指令模板和工具集合。你可以把它理解成给AI装了一本“企业测试规范手册”。AI每次执行任务时，会根据任务描述自动匹配对应的Skill，加载里面写的规则、模板、检查项，然后按照这些约束去生成内容。这套机制的价值在于：不同团队、不同项目对测试脚本的要求是不一样的，有的要求pytest风格，有的要求带上性能标记，有的要求必须从配置中心读取环境变量。原来这些规范靠代码评审人肉把关，现在直接内嵌到AI的工作流里。

1.3 整体工作流闭环

整个流程从用户输入自然语言描述开始，到 CI 里跑出测试报告结束，大致分了五步：

1. 维护一份结构化的接口描述库，也就是企业接口资产的沉淀，所有接口的路径、方法、参数、业务规则都写在这里。
2. 用户在Claude Code里输入自然语言场景，比如“生成一个下单成功后库存扣减的用例”。
3. Claude Code自动匹配到对应Skill，加载生成规范，调用GLM-5生成pytest脚本。
4. 脚本自动落盘到指定目录，Claude Code自动执行一遍，收集运行结果。
5. 出现失败的用例，AI根据报错自动修复，稳定后提交代码，CI里定时执行。

这套流程里，人能完全零代码完成脚本产出，但要保证质量和安全性，审核和兜底环节不能省。

2. 环境准备与工具链搭建

2.1 安装 Claude Code CLI

Claude Code以CLI方式提供，安装很简单，一条npm命令搞定。需要提前装好Node.js，建议版本不低于18。

npm install -g @anthropic-ai/claude-code

安装完成后在终端执行claude就能进入交互模式。首次使用需要登录授权，这里直接按官方提示操作就行。我的建议是在本地开发环境装一个，在CI机器上再单独装一个，两边用的API凭据分开，权限做好隔离。

2.2 接入 GLM-5 模型

Claude Code默认使用官方模型，但支持通过环境变量自定义接口地址和模型名称。如果你的企业里有自己的模型网关，或者想直接用GLM-5，只需要修改配置文件。

配置文件位置在~/.claude/settings.json，内容大概长这样：

{ "env": { "ANTHROPIC_BASE_URL": "https://your-model-gateway.example.com/anthropic", "ANTHROPIC_MODEL": "glm-5", "ANTHROPIC_AUTH_TOKEN": "sk-xxxxxxxx" } }

这里解释一下三个变量的作用。ANTHROPIC_BASE_URL是模型接口的网关地址，只要网关兼容Anthropic的接口协议就能通。ANTHROPIC_MODEL指定模型名，我用的是glm-5。ANTHROPIC_AUTH_TOKEN是调用模型时用的鉴权凭据，注意这个token不要提交到git仓库，最好通过环境变量注入。

配置完成后，在终端重新启动claude，会话里的模型就切到GLM-5了。验证方法很简单，随便问一句“你是什么模型”，如果返回GLM-5说明对接成功。

2.3 Skills 目录与加载机制

Skills的目录结构有固定要求，Claude Code会扫描项目里的.claude/skills目录，每个子目录对应一个Skill，目录名就是技能名。

.claude/ └── skills/ └── api-test-gen/ ├── SKILL.md └── scripts/ ├── validate_schema.py └── generate_report.py

SKILL.md是Skill的核心文件，里面用Markdown写成，分成头部元信息和正文字节两部分。头部元信息里最重要的两个字段是name和description，其中description决定了AI什么时候会自动加载这个技能，所以要写清楚适用场景。正文部分写生成规则、模板、检查项，AI在生成脚本的时候会严格参照这里的内容。

这里有个关键细节，SKILL.md 里描述的规则要尽量具体。比如“断言必须包含状态码校验”这种描述就太含糊，AI会一脸懵。要写成“每个接口用例必须断言：HTTP状态码等于预期值、响应中的code字段等于0、业务关键字段等于场景预期值”。规则越具体，生成出来的脚本越稳定。

3. 零代码生成接口脚本的核心实操

3.1 第一步：沉淀企业接口资产

很多AI生成代码效果差，根源不在模型能力，而在没有给模型足够可靠的上下文。业务字段的口径、接口之间的依赖关系、响应报文的层级结构，这些信息模型自己猜不准，必须由人来提供。所以做这套方案的第一步，是要把企业接口信息结构化。

我这里用了一份YAML格式的接口描述库，每个接口占一段，字段包括：接口名称、路径、方法、请求参数、业务规则、关联接口。以“创建用户”接口为例：

create_user: path: /api/v1/users method: POST description: 创建用户，成功后会生成用户ID并初始化账户余额 request: name: string, 必填, 用户姓名 phone: string, 必填, 11位手机号 id_card: string, 可选, 身份证号 response: data.user_id: string, 新用户ID data.balance: number, 初始余额，固定为0 business_rules: - 手机号不能重复，重复时返回错误码 USER_PHONE_EXISTS - 创建成功后自动初始化余额账户 related_apis: - get_user_detail - query_balance

这份描述库是整个零代码体系的基石。AI生成脚本时先读对应接口的描述，再结合业务场景组织调用顺序，而不是凭它自己的“常识”猜测。描述库的维护可以逐步完善，初期只需要覆盖核心链路，后面随着接口变更持续迭代。

3.2 第二步：设计“接口测试生成”Skill

Skill的设计是整个方案里最重要的工程决策，它决定了AI产出的脚本质量上限。我设计的api-test-gen技能核心内容包括四块：输出格式规范、断言规则、数据管理约定和环境变量约定。

--- name: api-test-gen description: 根据业务场景描述生成pytest接口自动化测试脚本。当用户要求生成接口测试用例、接口自动化脚本，或描述一个业务场景希望转为自动化用例时，自动加载本技能。 --- # 生成脚本必须遵守的规则 1. 使用 pytest + requests 编写，文件名以 test_ 开头，存放于 test_api/ 目录。 2. 测试数据不得硬编码，统一从 test_config.py 和 data_factory.py 导入。 3. 接口基础地址从 test_config.BASE_URL 读取，请求头从 test_config.get_headers() 获取。 4. 每个用例必须包含两个层面断言： - 协议层：HTTP状态码必须等于预期值。 - 业务层：响应中的 code 字段等于 0，业务关键字段与场景预期一致。 5. 用例之间禁止相互依赖，需要前置状态时通过调用接口或数据工厂准备。 6. 涉及金额、库存等关键字段时，执行成功后必须调用查询接口反向校验。 7. 不得在用例中写入任何真实Token、密码、证书等敏感信息。 8. 生成完成后，立即用 pytest --collect-only 校验用例可被正常收集。

这里我特别强调第6条，反向校验很多手工写的脚本都会漏掉。比如下单接口返回成功，只能说明接口本身没报错，但库存到底扣没扣、扣得对不对，必须再查一次库存接口才能确认。AI按这条规则生成的脚本，业务有效性远高于只检查状态码的脚本。

3.3 第三步：用自然语言生成完整测试用例

工具链和技能都准备好以后，生成用例的操作简单到有点不真实。我直接在Claude Code的交互界面里输入：

生成一个创建用户后查询用户详情的用例，要求： 1. 创建用户，手机号用随机号 2. 断言创建成功且返回用户ID 3. 再用返回的用户ID查询详情 4. 校验查询结果的用户名与创建时一致

Claude Code会自动匹配到api-test-gen技能，加载SKILL.md里的规则，调用GLM-5生成脚本。生成的脚本大概长这样：

import requests from test_config import BASE_URL, get_headers from data_factory import random_phone def test_create_user_and_get_detail(): headers = get_headers() phone = random_phone() payload = { "name": "测试用户", "phone": phone } resp = requests.post(f"{BASE_URL}/api/v1/users", json=payload, headers=headers) assert resp.status_code == 200 resp_body = resp.json() assert resp_body["code"] == 0 user_id = resp_body["data"]["user_id"] assert user_id is not None detail_resp = requests.get(f"{BASE_URL}/api/v1/users/{user_id}", headers=headers) assert detail_resp.status_code == 200 detail_body = detail_resp.json() assert detail_body["code"] == 0 assert detail_body["data"]["name"] == "测试用户"

生成完成后，Claude Code会自动在当前目录执行pytest --collect-only检查脚本能否被正常收集，还会直接跑一遍测试并汇报结果。如果中间有失败，它会读报错信息自动修。这一整条链路，用户全程没有写过一行代码。

3.4 第四步：批量生成与CI集成落地

单个用例跑通只是起点，企业级自动化的价值在批量回归。实操中我是这么做的：把核心业务链路的场景用自然语言一条条写进场景清单文件里，然后在Claude Code里一次性批量生成。

我在项目里维护了一份scenarios.md，每一条对应一个业务场景，描述风格一致。比如：

场景1：用户注册成功后，查询用户详情和账户余额，校验初始余额为0 场景2：用户充值100元后，查询账户余额，校验余额增加100 场景3：用户下单购买商品后，查询库存，校验库存扣减1 场景4：用户取消订单后，查询库存，校验库存回补

然后在Claude Code里发一条指令：

读取 scenarios.md，逐一生成对应的 pytest 用例到 test_api/ 目录，生成后用 pytest 执行并汇报结果

Claude Code会逐条读取、生成、执行、修复，直到全部通过。这样一次性能生成几十个用例，而且因为Skill里写了统一规范，生成的脚本风格高度一致，后续维护成本直线下降。

CI集成方面，AI生成的脚本最终以普通pytest文件形式提交到代码仓库。持续集成里的任务只负责拉代码、装依赖、跑pytest、收集报告，不需要再调用AI。这一点很重要，AI是生成和维护脚本的“生产工具”，不是每次执行时的“运行时依赖”。CI配置示例：

api-test: stage: test script: - pip install -r requirements.txt - pytest test_api/ -v --html=report.html artifacts: paths: - report.html rules: - if: '$CI_PIPELINE_SOURCE == "schedule"'

4. 常见问题与排查技巧实录

4.1 生成脚本不规范，怎么用规则去约束

很多第一次用这套方案的人会问一个问题：AI生成的脚本风格不稳定怎么办？我第一次试跑的时候也遇到过，同一个场景生成的脚本，第一次建了独立函数，第二次全堆在主函数里，断言方式也不统一。

后来我找到了根因：SKILL.md里的规则写得太笼统。只写“断言要完整”等于没写，AI只能靠猜。于是我重新整理了SKILL.md，把每条规则都写成可以直接机械执行的要求。比如“必须使用 pytest + requests”直接写明；比如“文件名必须以 test_ 开头，存放于 test_api/ 目录”；再比如“每个用例必须包含协议层断言和业务层断言”。规则从“原则性描述”改成“操作性要求”之后，生成结果的稳定度明显提升。

还有一个技巧是增加“自检清单”段落，要求AI在生成完脚本后自己检查一遍：是否引用了正确的配置变量、是否有硬编码数据、是否包含反向校验。这个自检动作会把很多低级错误挡在提交之前。

4.2 鉴权与敏感信息处理

企业级接口绕不开登录鉴权，有的系统还用到多级权限、动态Token、签名加密。一开始AI生成脚本的时候，我让它直接把Token写进脚本里，结果Token一过期脚本全挂，还得手动替换。

正确做法是让Skill强制约定鉴权信息统一从配置模块读取。我在test_config.py里封装了一个get_headers()函数，内部做登录、拿Token、缓存刷新，业务脚本里只调用这个函数，完全不感知Token的获取细节。这样一来，AI生成的脚本里不会出现任何真实Token，也兼顾了脚本的独立性。

另一个安全细节是日志脱敏。有些接口响应里包含用户手机号、身份证号等敏感信息，断言失败时pytest会打印完整的响应体。我在Skill里加了一条规则：断言语句中不得直接拼接整个响应体，关键字段校验用单独的变量保存，日志打印时做掩码处理。

4.3 领域语义理解错误，接口描述库来兜底

AI生成脚本过程中，我最担心的问题不是语法错误，而是“语义错误”――生成的代码能跑，但断言的业务口径和真实规则不一致。比如创建用户的接口，业务上要求手机号唯一，但AI可能生成两条用同一个手机号的用例，分别在两个测试函数里，造数逻辑一跑就冲突。

这类问题的根治思路还是要靠接口描述库，把字段约束、状态流转、依赖关系写清楚，让AI生成前先读取对应接口的描述。我在Skill里加了一条规则：生成用例前，必须读取api_catalog.yaml中相关接口的business_rules和related_apis字段，根据里面的约束组织数据。这样AI就不再凭“常识”发挥，而是有据可依。

如果某个接口还没有录入描述库，我会先用半自动方式补一条占位描述，把已知的关键字段填上，再让AI生成。实操下来，描述库越完整，生成的脚本越不需要人工改。

4.4 上下文溢出与长文档处理

企业接口动辄几百个，接口描述库如果整体塞给AI，很容易触发上下文长度限制，或者导致AI“遗忘”前面的规则。这个问题我在处理一个大型老系统时遇到过，那个系统的接口文档有几百页，一次加载直接溢出。

解决方案是给Skill配置一个“按需加载”机制。接口描述库按模块拆分成多个文件，比如api_catalog_user.yaml、api_catalog_order.yaml、api_catalog_payment.yaml。SKILL.md里写明：生成用例前，先根据场景关键词定位相关的接口描述文件，只加载这部分内容。Claude Code的执行指令里也带上明确的路径提示，让加载范围进一步收敛。这样上下文里始终只有当前场景需要的信息，生成准确率反而更高了。

5. 踩坑实录与经验沉淀

5.1 最大的坑：让AI自由发挥

这套方案刚上手的时候，我犯过一个严重错误，就是只给AI一句“生成订单流程的接口用例”，没有任何约束。结果AI脑补了一堆不存在的接口和数据，生成的脚本完全不能用。

后来我把教训总结成一句话：AI做接口自动化，真正需要的是“写什么”的结构化信息和“怎么写”的规范约束，而不是“你来想”。所有能让AI明确知道的信息都要提供，所有能约束生成行为的规则都要写进Skill。零代码不等于零输入，它意味着要把你的业务知识转换成AI能理解的结构化语言。

5.2 “看起来对”和“跑起来对”是两回事

另一个印象深刻的坑是脚本能跑通，但断言根本没生效。有一次AI生成的用例里，创建用户后没有校验返回体里的关键字段，只检查了HTTP 200，这种用例跑得再绿也毫无价值。问题的本质是断言只停留在协议层，没有深入业务层。

为了根治这个问题，我在Skill里明确要求所有用例必须有双层断言，还加了一个“断言质量检查项”：每个用例必须至少包含一个对响应体中data字段下具体业务字段的断言。同时我会在代码评审环节抽查几个用例，专门看断言是否覆盖了核心业务规则。

5.3 Skill也当代码维护

很多人把Skill当成一份AI的“使用说明书”，写完就不管了。实际这套体系里，Skill的质量直接决定了测试资产的质量，所以要把Skill当代码一样维护：版本管理、变更评审、定期复盘。

我现在的做法是把.claude/skills目录纳入git版本管理。每次业务规则调整，同步更新SKILL.md和接口描述库，提交时写明变更原因。这样Skill的演化过程有迹可循，也方便多人在同一套规范上协作。

5.4 这个体系的扩展空间

跑通这套体系之后，我还在持续往里面加东西。目前已经在尝试的方向有三个：一是接口变更感知，把接口描述库和线上接口文档做定时比对，发现差异时自动提示需要重生成的用例；二是失败用例自动修复，CI跑挂之后把报错信息喂给Claude Code，让它尝试定位原因并给出修复建议，人工确认后再合入；三是测试数据工厂化，把造数逻辑沉淀成独立的数据工厂模块，由AI调用工厂方法生成测试数据，而不是在用例里随机造数。

我个人在实际操作中最大的体会是，这套方案真正解决的不是“怎么写脚本”，而是“怎么让不懂代码的人也能参与自动化测试资产的建设”。业务同事描述场景、AI生成脚本、测试人员审核兜底，分工比传统模式清晰太多。最后再分享一个小技巧：如果你发现AI生成脚本偶尔出现低级错误，不用急着改SKILL.md规则，先试试在指令末尾加一句“生成完成后请自查：是否满足SKILL.md中所有约束，是否存在硬编码数据，断言是否覆盖业务关键字段”。这个简单的自查提示，能把不少隐患挡在运行之前。