最近团队里好几个测试同事都在折腾 Claude Code问得最多的不是怎么安装而是Skill 到底是个啥为什么别人家的 AI 测试那么聪明让它生成接口用例、补断言、写复现步骤一步到位我这边同一个工具只会机械地列几条assert status_code 200说实话Claude Code 本身是个好用的 AI 编程助手命令行交互、能读项目上下文、能直接跑命令但如果只是把它当成“会打字的结对编程机器人”那和用网页版 AI 没什么区别。真正让它从“能用”变成“好用”的是 Skill 这套技能包机制。把测试场景里重复出现的动作沉淀成 Skill相当于给 AI 装了一套行业级的工作流之后你再喊它干活它就知道先看接口文档、再列测试点、生成 pytest 用例、顺带做边界值和异常场景分析——一套动作行云流水而不是东一榔头西一棒子。这篇文章我就从零开始讲清楚 Claude Code Skill 是什么、怎么装、怎么写、怎么在 AI 测试场景里落地最后再附上我踩过的坑和排查建议。无论你是刚装的 Claude Code还是已经写了好几个 Skill 但在实际项目里触发不灵这篇都能给你点实在的参考。1. 先搞清楚Skill 到底是什么和普通提示词有什么区别1.1 从“大号提示词”到“工程化技能包”在 Skill 出现之前我们想让 AI 按固定套路干活靠的是在 CLAUDE.md 里写一堆提示词或者每次对话都手动贴一大段“你现在是一个测试专家请按以下步骤……”这种话。手动贴一次两次还能忍每天贴十几次就疯了而且不同人贴的提示词质量参差不齐出来的结果自然不稳定。Skill 说白了就是把这类“固定工作流提示词”做成了可复用、可分发、有标准目录结构的“技能包”。它不是一个能独立运行的程序而是一份结构化的指令文档里面有触发条件、有执行步骤、有输入输出格式、还有示例。Claude Code 读到了这份文档就知道“哦用户现在要的是接口测试用例”然后按照你写好的套路去干活。我习惯把它理解成“给 AI 的岗位培训手册”——你不可能指望一个新同事什么都不懂就干活干得漂亮但你给一份完整 SOP再配几个标准示例他上手就快很多。Skill 干的就是这件事。1.2 一个 Skill 的内部结构长什么样一个标准的 Claude Code Skill 其实只由几个文件组成~/.claude/skills/ └── api-test-case-generator/ # 技能包目录名建议用短横线连接 ├── SKILL.md # 核心文件技能说明和全部工作流指令 ├── reference/ # 可选用来放参考文档、模板、数据样例 │ └── pytest_template.py └── scripts/ # 可选用来放辅助脚本 └── parse_swagger.py核心只有SKILL.md一个文件剩下的都是辅助资产。SKILL.md里会有 YAML 格式的开头写着技能名称和描述后面是 Markdown 格式的正文给模型具体的执行步骤、规则、示例。真正用起来就会发现这个文件写得好不好直接决定这个技能包好不好用。1.3 为什么说 Skill 是 AI 测试提效的关键做 AI 测试的人每天面对的是大量重复且标准化的工作读接口文档、梳理测试点、写用例骨架、设计边界值、根据报错写复现步骤。这些工作有个共同点——套路相对固定但每次的输入参数不一样。这恰恰是 Skill 最擅长的场景。拿接口测试举例。没有 Skill 的时候你让 AI 生成用例它可能生成十条“正常入参、返回 200”的用例再补几条“参数为空”就完事了。但如果你写一个 Skill 告诉它接口测试必须包含正常流程、必填项校验、参数类型校验、边界值、枚举值校验、依赖字段校验、鉴权校验、异常码处理这八个维度每个维度给两条示例它产出的用例质量直接上一个台阶。这才是 Skill 真正的价值——把你团队里测试专家的经验“固化”下来让 AI 按照高水准的标准去执行而不是靠模型自己自由发挥。2. 环境准备Claude Code 安装与基础配置2.1 安装官方 CLI 的两种方式如果你还没装 Claude Code最快的办法是走 npm。系统里装好 Node.js 18 以上版本后执行npm install -g anthropic-ai/claude-code装完验证一下版本claude --version如果提示找不到命令多半是 npm 全局目录没加进系统 PATHnpm config get prefix看一下路径把对应的 bin 目录加进去就行。除了 npm官方也在推桌面版对于不习惯命令行的人更友好但注意桌面版和 CLI 版的技能目录、配置目录是分开的写 Skill 的时候别搞混了。装好之后第一次运行claude会要求登录 Claude 账号完成认证。认证通过以后它就能读取项目文件、执行命令、调用工具了。2.2 项目级配置 CLAUDE.md 的正确姿势很多人不知道Claude Code 有一个“项目记忆”机制就是项目根目录下的CLAUDE.md文件。每次进入项目AI 都会自动读取这个文件作为上下文。这个文件写得好AI 对你的项目了如指掌写不好它就像个刚入职还什么都没看过的实习生。我在做 AI 测试时通常会在CLAUDE.md里写这些内容# 项目测试规范 - 测试框架pytest requests - 测试目录tests/api/ - 接口文档位置docs/openapi.yaml - 测试环境https://staging.example.com - 通用断言规范状态码、响应时间500ms、关键字段存在性 - 常用账号在 tests/conftest.py 中配置禁止硬编码写完这个文件再配合 SkillAI 后续生成的测试代码就会主动从docs/openapi.yaml里读接口定义往tests/api/目录下写用例用统一的 fixture 管理账号。这些细节靠对话里临时交代是记不住的写进项目记忆里才能稳定生效。2.3 用 CC Switch 管理多套身份与模型配置在实际工作中我们经常要在不同模型服务、不同 API 配置之间切换比如公司有内部网关个人有订阅的模型服务可能还有本地模型。每次手动改环境变量太折腾了我目前用的是开源小工具 CC Switch。CC Switch 的用法就是把各种 API 地址、密钥、模型名保存成一套套配置需要哪个一键切换改完重启 Claude Code 就能生效。在公司项目和自己项目之间切换再也不用反复导出环境变量。这个工具本质是管理配置文件不涉及任何敏感操作用起来很轻。配置文件的读写位置一般在用户主目录下不同版本略有差异不确定的话直接看 CC Switch 的界面提示就行。有一点要注意切换配置后最好把当前的 Claude Code 会话退出重开否则新配置不一定能完全生效。3. 从零手写一个 AI 测试 Skill3.1 场景选择与需求拆解我要做哪个测试环节手里已经有能跑的 Claude Code 之后下一步就是写自己的第一个 Skill。写 Skill 之前一定先想清楚“我要解决什么场景下的什么问题”而不是为了写而写。以我自己为例团队里最耗时间的是接口自动化测试用例的编写。每次后端更新接口我都要照着新文档改一堆用例痛点非常明确重复劳动多、覆盖面不全、新人写的用例质量参差不齐。所以最值得做的一个 Skill 就是“接口测试用例生成器”。拆解这个场景的需求可以归纳成四条能自动识别接口文档Swagger/OpenAPI 格式或者代码注解能按统一的测试维度生成用例输出格式最好是可执行的 pytest 代码生成的用例要覆盖正常流程、边界值、异常场景、权限校验等目标定清楚Skill 写起来就有方向了。3.2 编写 SKILL.md结构、参数与示例在~/.claude/skills/下新建目录api-test-case-generator然后创建SKILL.md。我建议采用下面这个结构是从实际使用反馈里慢慢调整出来的--- name: api-test-case-generator description: 根据接口文档生成接口自动化测试用例。当用户要求生成接口测试用例、补充测试用例或提供接口信息要求测试时使用。适用于 pytest requests 的项目。 allowed-tools: Read, Write, Edit, Bash --- # API 测试用例生成 Skill ## 适用场景 - 根据 OpenAPI/Swagger 文档生成接口测试用例 - 根据用户提供的接口定义生成 pytest 用例代码 - 对现有测试用例进行补全和增强 ## 执行步骤 1. 查找项目中的接口文档优先查看 docs/openapi.yaml 或 docs/swagger.json如果找不到询问用户接口定义 2. 梳理接口基本信息方法、路径、请求参数、请求体结构、鉴权方式 3. 按以下维度生成测试用例 - 正常流程合法参数返回预期结果 - 必填校验缺少必填字段时的错误返回 - 类型校验字段类型错误时的错误返回 - 边界值数值字段的最小值、最大值、临界值 - 枚举校验枚举字段传入非法值时的行为 - 业务依赖存在依赖关系的字段校验 - 权限校验未登录、无权限、普通用户访问的情况 4. 生成 pytest 代码保存到 tests/api/ 目录 ## 输出规范 每个接口至少覆盖以下分类 - test_{接口名}_normal正常流程 - test_{接口名}_missing_required_field必填字段缺失 - test_{接口名}_invalid_type字段类型错误 - test_{接口名}_boundary_value边界值 - test_{接口名}_unauthorized未授权访问 ## 示例 用户输入POST /api/v1/login参数 { username, password } 生成 - test_login_normal正确用户名密码返回 200 且包含 token 字段 - test_login_missing_username缺少 username返回 400 - test_login_invalid_password_typepassword 传入数字返回 400我特别想强调description那段。Claude Code 是根据这段描述判断“当前用户请求要不要调用这个 Skill”的写得太宽泛无关场景也会触发写得太窄该触发的时候又触发不了。我踩过的坑是初始版本只写了“生成接口测试用例”结果用户说“帮我测一下这个接口”的时候模型识别不出这是同一个需求。后来改成“当用户要求生成接口测试用例、补充测试用例或提供接口信息要求测试时使用”触发率就明显上来了。3.3 放入技能目录并实测效果写完SKILL.md保存到~/.claude/skills/api-test-case-generator/目录下回到 Claude Code 里新建一个会话输入“帮我看一下登录接口生成一份测试用例”。正常情况下模型会主动调起这个 Skill按你写好的步骤走。第一次实测多半不会完全满意这是正常的。我那个版本跑了之后发现模型没有主动去查 OpenAPI 文档而是凭空脑补接口定义。原因就是SKILL.md里第一步写得太温和模型忽略了。我把“查找接口文档”改得更强制化明确写上“必须先查看 docs/openapi.yaml如果文件不存在再询问用户”行为立刻就规范了。所以 Skill 写完一定要放到真实项目里去跑、去调光看好不好看是没用的。我通常是跑三到五次真实需求然后根据输出质量反向修正SKILL.md的描述和步骤。这个迭代过程才是 Skill 从“能用”到“好用”的关键。4. 高手进阶本地模型、MCP 与 Skill 的组合玩法4.1 用 Ollama 跑本地模型配合 Claude Code 免费用Claude Code 默认接的是官方模型服务但工作里经常有没法把项目代码发到外部服务的场景或者你想省点用量的情况。我目前的方案是用 Ollama 在本地跑模型然后通过环境变量把 Claude Code 的模型接口指向本地的 Ollama 服务。装 Ollama 很简单从官网下载对应系统版本安装然后拉模型ollama pull qwen3:14b拉完模型启动服务再把 Claude Code 的请求地址指向本地的兼容接口。以 bash 为例export ANTHROPIC_BASE_URLhttp://localhost:11434 export ANTHROPIC_AUTH_TOKENollama export ANTHROPIC_MODELqwen3:14b claude配合本地模型跑的时候有一点要有心理准备开源小模型的能力上限和官方模型有明显差距复杂逻辑推理和精准执行步骤还原会差一些。但做接口用例生成这类标准化任务本地模型完全够用数据不出本机这一点对很多项目来说是刚需。Skill 的写法在这种组合下没区别它本质是提示词工程模型换了指令照样生效。4.2 MCP 接入测试数据源让 Skill 真正“读得到”业务数据MCPModel Context Protocol是另一套值得掌握的东西。如果说 Skill 给模型的是“怎么干活的流程”那 MCP 给模型的是“能摸到的数据源”。没有 MCP 的时候AI 只能靠读文件来获取信息接了 MCP 以后它可以直接查询数据库、读接口监控平台、拉取测试管理平台的数据。我在测试场景里最常用的两个 MCP 是数据库查询和接口平台。比如要让 Skill 生成测试数据第一步需要知道数据库里真实的枚举值之前我得手动查出来贴到对话里。现在给 Claude Code 配好数据库 MCPSkill 里写“先查询该字段在数据库中的枚举值再生成用例”AI 就能自己连数据库查样例数据然后基于真实数据生成测试用例。配置 MCP 的方式claude mcp add testdb --env DB_URLpostgres://user:passlocalhost/testdb -- npx modelcontextprotocol/server-postgres配置完之后模型在同一次会话里可以自动调用 MCP 工具去执行查询。这里有一个经验SKILL.md里要让模型“先用工具确认数据再生成结果”不然很多模型为了省事会跳过调用直接脑补数据导致生成的用例跟实际业务对不上。4.3 测试断言与缺陷复现场景的实战案例Skill 不只能生成用例缺陷复现也是 AI 测试里很有价值的一个场景。传统的 bug 复现步骤要人工写经常写得含糊不清开发拿到手还要猜。写一个“缺陷复现助手” Skill把流程固化成“读取报错日志 → 定位请求和参数 → 最小化复现路径 → 生成复现命令和预期结果”处理线上问题的效率能提升不少。我简单贴一下这个 Skill 的思路--- name: bug-reproducer description: 根据错误日志或用户描述生成缺陷复现方案。当用户提供报错信息、测试失败信息并要求定位问题时使用。 --- # 缺陷复现助手 ## 执行步骤 1. 读取用户提供的日志或失败信息 2. 定位到对应的接口路径、请求参数、响应内容 3. 分析可能的原因参数问题、数据问题、环境问题、代码逻辑 4. 生成最小化复现命令包含完整请求参数 5. 给出预期正确行为和实际错误行为实际用下来这个 Skill 能逼着模型按“定位 → 分析 → 复现 → 验证”的顺序走而不是一上来就瞎猜原因。结合前面的 MCP 数据库查询它还能自动查出测试数据的状态判断是数据被改过还是代码逻辑有问题。5. 常见问题与排查技巧实录5.1 我踩过的几个典型坑第一个坑是 Skill 目录放错了位置。最早我以为技能包放在项目目录.claude/skills/下就行结果项目一多每个项目都要复制一份。后来才发现用户级目录~/.claude/skills/是全局生效的项目级目录只对当前项目生效。个人日常使用建议放用户级团队协作才考虑把 Skill 跟项目代码一起入库。第二个坑是description写得太学院派模型判断不了什么时候该触发。我有一次写“本技能用于接口测试场景下的用例生成与补全”看似没问题但实际对话里用户不会说“请使用接口用例生成技能”而是说“帮我测测这个接口”模型就很难把这两件事关联起来。后来我把描述改成包含各种用户真实说法“生成接口测试用例”“补充测试用例”“测试接口”“帮我测一下这个接口怎么测”触发率明显提升。第三个坑是上下文太长导致执行中途“失忆”。Skill 里如果写了一大堆背景知识模型读着读着就把前面的执行步骤忘了。解决的思路是保持SKILL.md精简把详细模板和长示例放到reference/目录下的文件里让模型按需读取而不是一次性塞进上下文。5.2 问题速查表现象原因解决方法Skill 完全不生效目录名不对或 SKILL.md 不在正确路径检查路径~/.claude/skills/技能名/SKILL.md该触发时不触发description 与用户表达匹配度低在描述里加入用户常用说法和近义词不该触发时乱触发description 写得太宽泛明确适用场景和禁止场景输出格式不稳定SKILL.md 缺少输出规范和示例增加固定格式模板和正反示例生成了用例但接口信息是编的缺少强制查阅接口文档的步骤把“先查文档”写成强制前置步骤配置了本地模型但没走 Ollama环境变量未设置或会话未重启确认 ANTHROPIC_BASE_URL 并重开会话5.3 两条让团队真正用好 Skill 的落地建议第一Skill 一定要放进代码仓库做版本管理。我们团队现在的做法是建了一个ai-test-skills仓库里面按技能分类每个 Skill 一个文件夹SKILL.md走评审流程改完打标签发布。这样每个测试工程师拉下来就能用而且不会出现“我本地改了技能但大家都不知道”的情况。第二一个 Skill 管一件事别做“瑞士军刀”。我最早也想把接口测试、UI 测试、缺陷复现、测试报告生成全部塞进一个 Skill结果模型一会执行这个流程一会执行那个流程行为非常不可控。拆成四个独立 Skill 之后每个都轻量、清晰、触发准确整体效果反而更好。我个人在实际操作中的体会是Skill 不是写一次就完事的东西它是一个需要持续迭代的工作流引擎。你每用一次就有机会发现某个步骤写得不够明确、某个异常场景没有覆盖、某个输出格式不符合团队规范。把这些反馈一点点补回SKILL.md里几个月下来你手里的 AI 测试助手就和刚开箱时的它完全是两个水平了。最后再分享一个小技巧新写一个 Skill 之后别急着塞复杂场景先用一个高频反复出现的需求反复验证三五次把描述、步骤、示例打磨顺了再推广这个顺序下来基本上不会翻车。
