一、Agent智能体是什么1、AI大模型大海量数据经过海量的参数使用海量的算力训练得到一个神经网络预训练模型使用方式给AI提示词AI生成[文字、音视频]目前AI的角色是聊天机器人例如提示词为”帮我生成一个购物网站的代码“AI就会返回一堆代码也就是[文字]。但是它不会保存成文件、自动运行代码、根据运行结果自动调试修改代码。AI大模型只有第一步的能力没有后续操作的能力。所以这里我们就需要用到一些扩展2、使用工具申明工具功能和用法添加到 提示词 中去这些功能有搜索、文件读写、系统命令等使用工具之前 AI的角色是 聊天机器人 使用工具之后AI的角色是助手3、LOOP循环持续的工作:根据上一个动作的结果决定下一个动作可以主动获取外界信息可以频繁失败重试如下图如果返回的页面状态与结果与“模型理解的目标”不一致会循环重试直到达到目标有了LOOP之后AI的角色就是Agent智能体4、测试AgentAI短视频博主需要的“短视频Agent”的技能是下载、上传、登陆抖音等测试需要的“测试Agent”的技能是用例设计、用例执行、结果分析、输出报告等核心区别技能技能来源function calling代码自己写代码如抖音的登陆等功能封装成函数。然后申明工具功能和用法添加到 提示词 中mcp-server程序/接口别人写好的功能共享出来给大家使用例如添加的MCPplaywrightskillsmd文档允许渐进式的加载一步一步加载。不像MCP一样一次性加载完比较费Token技能内容用例设计(文字) 用例执行 (自动化) 接口封装框架使用框架 web:mcp playwright-mcp mcp-chrome appmcp 报告/分析/文档(文字) 飞书通知 对接禅道二、Agent智能体是什么 {从另外一个角度理解}1、Agent智能体Agent LLM TOOL 其他LLMAI大模型例如Claude、GPT‑5、deepseek-v4-pro等TOOL工具由MCP和SKILL提供其它记忆、编排等2、Agent工具Agent工具不是大模型工具可以让大模型去使用MCP、SKILL常见的Agent工具有Claude Code获取方式npm安装CodeX获取方式应用商店OpenCode获取方式官网下载DeepSeek-TUI获取方式github下载3、搭建环境安装nodehttps://nodejs.org/zh-cn/download安装pythonhttps://www.python.org/downloads/安装Agent工具Claude Codenpm install -g anthropic-ai/claude-code本次不对接claude大模型原因对win不友好本次对接deepseek-v4大模型原因便宜对接方法在DeepSeek API官方文档https://api-docs.deepseek.com/zh-cn/中按照“接入Agent工具-Claude Code”章节操作4、Claude Code使用技巧命令行执行claude即可进入claude可以输入中文指令如果输入错了并且发送了可以按两次ECS就可以打断calude继续生成结果三、MCP1、安装MCP实际工作中可能有不同任务要求例如操作数据库操作浏览器对接第三方服务大模型本身只是个对话机器人相当于一个“大脑”无法直接干这些活干具体的活需要“手脚”去干因此需要通过MCP、SKILL获取这些“手脚”MCP是大模型上下文协议可以使用这个协议添加多个由别人提供、控制的mcp server有操作数据库的mcp server有操作麦当劳的mcp server有操作浏览器的mcp serverplaywright-mcp下面详细介绍下playwright-mcp使用方法安装方法claude mcp add playwright npxplaywright/mcplatest参考https://github.com/microsoft/playwright-mcp使用技巧/mcp #列出所有已安装的MCP可以看到playwright提供了24个TOOL这些TOOL就是二.1章节中描述的TOOL2、WEB端测试实战2.1、探索#API测试因为有接口文档不需要这一步目的让Agent熟悉项目提示词提示词使用技巧 角色设定让AI快速代入资深测试架构师视角思维链(CoT)引导大模型逐步拆解复杂测试策略你是一个资深功能测试工程师精通Web的需求分析和用例设计。 接下来我们一起分步进行一个项目的Web端测试。 现在开始第一步 1.启动浏览器访问http://8.137.210.99:8080/ 2.探索和理解网站功能、页面结构、导航体系 3.输出一个**md文件**作为网站功能地图包含 -页面清单 -各个页面关键元素 -各个页面直接的关系(例如依赖、跳转、顺序)产出网站功能地图2.2、分析目标识别测试目标、优先级、风险点提示词现在开始第二步 基于前面梳理的网站功能地图分析 1.哪些功能是核心流程用户一定会用对项目比较重要 2.哪些地方容易出BUG输入边界、状态改变、权限校验 3.输出**md文件**作为测试范围和优先级矩阵 文件格式表格表头 优先级功能模块测试重点风险等级备注可以为空产出功能列表(含优先级、风险点)2.3、设计目的输出具体的、可执行的测试用例包含前置条件、步骤、预期结果提示词现在开始第三步 读取测试范围与优先级矩阵.md对**P0功能**进行用例设计至少覆盖 1.1个正常的流程和1个异常流程 2.边界值最大/最小/空值/特殊符号 3.用户的正常行为习惯和操作流程产出测试用例2.4、执行临时执行目标由Agent根据用例的内容执行测试得到结果提示词读取测试用例设计_P0.md执行**商品列表加载TC-LIST**的测试用例要求 1.逐条执行 2.记录结果 3.输出结论表格总结 4.对于失败的用例要进行截图保存到文件中记录失败的步骤、原因、错误信息到文件中产出测试报告CI/CD方式执行PASS2.5、沉淀PASS3、落地可复用资产尽可能的落文件例如上面产出的三个md文件md文件段落代码表格图表公式py文件固定化操作和系统、网络的交互可复用代码落地可复用、可维护的自动化代码用于服务当前项目落地可复用、可维护的SKILL可以用于服务其他项目四、SKILL1、SKILL的格式、原则很多人第一次接触 Skill 时会把它理解成“更长一点的提示词”或者“某个平台里的插件”。这样的理解不算完全错误 但还没有抓住重点。 更准确的说法是Skill 是一个包含把任务目标、执行规则、参考知识、输出格式和使用时机一起固化下来得 的技能规范。Skill像是给 AI 补上一层“工作方法”它不直接替代工具也不直接替代模型而是把“这类任务应该怎样做、做到什么 程度、产出什么结果”固定下来简单来说将重复性高的工作固化为可维护、可复用的文件。一个可用的 Skill通常包含三层内容识别层告诉模型这是什么 Skill什么时候该用它规则层说明任务目标、处理步骤、输出格式和质量约束资源层提供样例、模板、规范文档、历史案例等参考材料示例https://github.com/anthropics/skills/blob/main/skills/pdf/SKILL.md这个SKILL的作用是告诉AI如何处理PDF文件AI在加载SKILL的时候不会一次性把所有内容都加载进去而是只会先加载识别层形成一个目录然后根据目录去选择工具。例如用户要去操作PDF文件然后AI根据目录找到这个SKILL.md文件然后再加载这个文件里面的详细内容也就是按需加载。MCP在工作的时候会将所有的MCP、工具都汇总起来当MCP SERVER多的时候效率很低上下文很长Token花费很快。SKILL恰好解决了这个短板。可以看到SKILL会用到不同的python模块这些才是实际干活的工具同时论证了SKILL’不直接替代工具也不直接替代模型而是把“这类任务应该怎样做、做到什么 程度、产出什么结果”固定下来‘当我使用pypdf的时候这个SKILL的内容还不够详细不够覆盖用户所面对的各种复杂的应用场景它还可以提供更详细的内容供我们参考“接下来的步骤”章节。因此SKILL既有按需加载的特性又有懒加载逐步加载的特性2、安装SKILL作为md文件可以让LLM手动加载也可以放在指定的目录自动加载当前项目根目录~/.claude/skills/自定义名称/SKILL.md #所有SKILL必须用统一固定的文件名SKILL.md复制md的源码到SKILL.md中/skills #列出所有已安装的skill3、API测试实战3.1、OpenAPIOpenAPI原 Swagger 规范是一种用于描述 RESTful API 的标准化格式JSON/YAML。它定义了 API 的端点、 请求参数、响应结构、认证方式、数据类型等细节使得API 的设计、文档生成、代码生成和自动化测试可以基于同 一份文档内容进行。3.2、用自然语言完成测试过去测试人员往往需要自己完成一整套链路阅读接口文档--梳理请求参数--理解返回结构--提炼测试点--设计正常、异常与边界用例--再决定生成什么形式的测试资产而在 AI 参与之后这条链路的前半段可以被大幅加速。例如可以给出如下任务描述请读取 openapi.json并完成以下任务 1. 列出与“用户登录”相关的核心接口及其请求参数 2. 基于接口定义设计功能、异常、边界三类测试用例 3. 执行接口测试用例输出结果 4. 测试账号xxxxxxqq.com/xxxxxx只看第一次生成结果AI 在 API 测试场景里通常已经足够令人惊艳。但只要把过程重复一遍问题就会很快暴露出来。例如同样一个任务新开一个对话后往往会出现输出风格开始变化用例标题开始变化用例覆盖度开始变化代码风格开始变化这时Skill 的价值就真正体现出来了复用把成功的方法留到下一次继续使用约束减少输出漂移和技术选型漂移定制让模型贴近本团队的业务风格和工程规范将自己项目的风险和业务逻辑补充进去补充把模型本来没有稳定掌握的方法补进去这也正是 API 测试场景比很多 UI 场景更迫切需要 Skill 的原因简单来说如果每次都靠自由对话驱动就很难形成资产如果能把成功的方法固定下来AI 的价值才会从一次演示变成长期能力3.3、第一个版本的Skill第一个版本的核心目标是先把Skill做出来基本步骤1. 和AI进行对话指导AI做一个还算满意的结果2. 梳理对话内容提炼有价值的指令3. 按照Skill格式创建第一个版本核心内容基于 OpenAPI 文档理解接口选择pytest requests作为技术方案围绕正常、异常、边界和认证等场景设计用例断言不能只有状态码示例.claude/skills/api-test-engineer-v1/SKILL.md--- name: api-test-engineer-v1 description: 基于 openapi.json 生成 pytest requests 接口测试代码 --- # API Test Engineer V1 ## 适用场景 当需要基于 openapi.json 生成接口自动化测试代码时使用。 ## 任务目标 基于 OpenAPI 文档输出 pytest requests jsonschema 的接口测试代码。 ## 核心原则 - 优先覆盖正常、异常、边界、认证相关场景 - 不臆造文档中不存在的接口和字段 - 断言不能只有状态码 ## 工作步骤 1. 读取 openapi.json 2. 定位目标接口 3. 提炼测试点 4. 生成 pytest 测试代码 ## 输出要求 - 优先输出可执行代码 - 如认证信息或环境信息缺失列出待确认项使用方法打开Glaude窗口输入这个Skill的名称/api-test-engineer-v1查询第一个版本的结果发现断言做的不好只验证了状态码关联关系做的不好有的用例需要先登陆才能执行而生成的代码中没有登陆就做执行的接口测试了测试账号是随机生成的这样的代码运行起来必然会报错。3.4、第二个版本的Skill第二个版本的核心目标是从可用走向稳定第一版 Skill 跑通之后检验它能不能稳定的投入生产现在能做用例筛选吗能解决接口依赖和数据关联吗输出的结构稳定吗生成的结果真的易维护、易扩展吗根据需要在Skill中添加更多的指导和约束识别用例的重要性和优先级识别接口以来和数据关联为用例添加mark已备筛选把单个测试文件拆成更易维护的结构能够识别和复用上一次的产出由于第一版的上下文会影响制作Skill必须在一个新窗口生成第二版Skill.claude/skills/api-auto-test-engineer-v2/SKILL.md--- name: api-auto-test-engineer-v2 description: 基于 openapi.json 生成可维护的 pytest requests 接口自动化测试工程。 --- # API Auto Test Engineer V2 ## 目标 1. 读取 openapi.json理解接口、数据结构、依赖关系和安全声明 2. 结合 test_data.txt 推断可执行的测试链路 3. 先生成测试设计文档 4. 再基于测试设计文档生成 pytest requests 自动化测试代码 ## 工作流程 1. 检查项目根目录和 openapi.json 2. 梳理接口列表、资源分组、认证方式、CRUD 链路和路径参数依赖 3. 检查是否存在 test_data.txt 4. 检查现有工程中的 tests/、conftest.py、pytest.ini 5. 先生成测试设计文档再决定代码结构和文件拆分方案 ## 两阶段输出规则 第一阶段先生成 test_design.md 第二阶段只有在无关键阻塞项时才继续生成 conftest.py、pytest.ini、tests/*.py ## 认证处理规则 1. 有认证接口 有认证输入 - 生成真实认证 fixture 2. 无认证接口 有静态认证信息 - 生成静态认证 fixture 3. 既无认证链路也无稳定认证信息 - 输出待确认项不伪造认证 fixture.claude/skills/api-auto-test-engineer-v2/test_data.txt #测试数据例如测试账号密码等等971045897qq.com 123456第二个版本还增加了测试数据复杂事情拆分执行的理念将测试设计和自动化代码分步骤进行生成后者复用前者规定了代码生成到test/目录下如果公司或者项目还有其他要求都可以加入到Skill中查看代码发现没有失败重试requests()函数被放到了fixtrue中将不会生成日志后续难以定位问题没有使用插件没法自动生成测试报告没有发邮件告警的功能。3.5、第三个版本的Skill第三个版本的核心目标是Skill是否把我的经验沉淀成了资产这时我们不再只是盯着“它能不能生成代码”而是开始反过来问自己我的接口测试经验到底是什么我平时做测试时真正依赖的方法论是什么我亲自做这件事会比当前 Skill 做得更好吗哪些能力是现在就能沉淀进 Skill 的哪些暂时还不能我要如何评审和维护AI的产出很多老司机会觉得自己做确实比 Skill 做得更好更知道先看哪些风险更知道哪些接口应该串成链路更知道哪些待确认项不能跳过更知道哪些结果适合进入工程哪些结果只是看起来热闹从AI技术角度来讲现阶段人工评估依然是智能的“金标准”这就意味着我们的Skill如果想要实用、可靠、可持续一定要预留人工介入的接口.claude/skills/api-auto-test-engineer/SKILL.md--- name: api-auto-test-engineer description: 基于 openapi.json 生成可维护的 Python 接口自动化测试工程。适用于需要分析依赖链路、生成 pytest requests 测试代码并复用 test_data.txt 时。 --- # API 自动化测试工程师 ## 输出结构标准 详细规范请阅读 [output standards](references/output-standards.md) ## 失败判定 - 没有先生成测试设计文档就直接开始写 .py - 设计文档中存在关键待确认项却仍然继续生成代码 - 明明存在认证接口和认证输入却仍生成一个静态认证 fixture - 所有测试都被塞进同一个大文件且没有明确的拆分策略 - 断言过于宽泛只剩“状态码小于 500”这类低价值判断 ## 约束与边界 - 不要臆造规范中不存在的参数、字段或成功条件 - 除非 openapi.json 或 test_data.txt 明确支持否则不要擅自假设鉴权行为 - 对仍无法确认的假设用注释或结果说明显式标出.claude/skills/api-auto-test-engineer/references/output-standards.md## 输出结构标准 - 目录结构标准按认证域/业务域拆目录 - 文件拆分标准同一资源放同一文件 - fixture 分层标准全局 fixture 放 conftest.py - 断言标准 - 失败信号判定.claude/skills/api-auto-test-engineer/references/dependency-analysis.md## 接口依赖分析 - 鉴权依赖 - 资源生命周期依赖CRUD 链路 - 路径参数依赖 - 测试数据依赖 设计文档至少包含 - 输入信息 - 认证与依赖分析 - 资源分组与测试范围 - 文件拆分方案 - 核心用例设计 - test_data.txt 使用计划 - 待确认项至此我们在工作中真正值得重点 review 的不是执行层的py而是设计层的md测试范围是否合理依赖分析是否成立待确认项是否被诚实地暴露出来文件结构和断言策略是否适合进入工程Skill 不是把一次提问写得更长而是把个人经验、团队规范和测试方法一步步沉淀为可复用能力。3.6、Skill 与现有自动化工程结合因为 Skill 解决的是“生成方法的稳定性”而不是“让工程问题自动消失”在真实团队里接口自动化最终还是要落回已有工程测试数据怎么准备环境地址怎么切换鉴权 token 怎么获取公共断言怎么复用用例怎么进入 CI 执行这些都不是靠一句提示词就能解决的因此更合理的落地方式通常是下面这条链路AI 和传统自动化并不是互相替代而是各自承担最合适的部分AI 擅长读文档、提测试点、起草代码工程化体系负责环境、执行、复用和持续集成测试人员负责业务判断、风险取舍和结果验收五、Agent的能力边界1、提示词工程很重要提示词就是输入给 AI 大模型的上下文内容。模型更接近于根据当前输入预测下一段最可能出现的内容因此它看到 什么、看得够不够完整会直接影响输出质量。提示词工程本质上就是采用工程化的思想管理、维护和优化提示词内容从而得到更高质量、更稳定的 AI 输出结 果。一个好的提示词至少要说清四件事目标是什么输入材料是什么输出格式是什么成功与失败的判断标准是什么提示词使用技巧 角色设定让AI快速代入资深测试架构师视角 思维链(CoT)引导大模型逐步拆解复杂测试策略2大模型具有概率性传统程序更像“规则机”同样的输入在逻辑不变的前提下通常会得到同样的输出。但大模型的生成本质是概率采样即使任务相同、模型相同在不同上下文、不同轮次下也可能产生略有不同的动作路径。这体现了大模型的灵活性和适应性但在测试工作里对复现、维护、评审造成了困难。因此对于测试AI本身的测试活动中不能单纯的断言一次的结果是对还是错需要对多次结果打分评估才能得出AI能力好坏的结论。3、AI 会有幻觉幻觉可以通俗理解为“一本正经的胡说八道”这和搜索引擎“查不到就返回空白”不同大模型的默认倾向不是沉默而是继续生成尽量给出一个看起来像答案的 输出。关于降低幻觉业绩已经有很多手段了对于我们测试人员来说务必谨记AI 生成的内容不可全盘相信如果公司有 AI 应用要进行幻觉评估4、大模型的上下文是有限的很多人刚使用大模型时会误以为它“总是记得此前的对话内容”。实际上模型能利用的主要是当前会话里被送进上下文窗口的内容。只要对话变长、信息变多、无关内容混进来早期的重要信息就可能被弱化、遗忘甚至被后续内 容覆盖。这就是为什么同一个任务在一段很长的对话后继续执行结果往往会越来越飘。所以一个非常实用的技巧是重要任务不要无限续聊而要及时重开上下文、重置任务边界。5、AI 天然不理解你的业务风险只能利用你主动提供的风险信息模型拥有很强的通用语言能力这会让人产生一种错觉好像它天然懂各自业务。实际上它懂的是训练语料中常见 的业务模式和语言模式而不是你们公司的真实系统、真实用户和真实风险。这也是测试人员在 AI 时代仍然不可替代的一部分价值。AI 可以帮助我们提效但风险判断、优先级判断和业务边界判断最终还是我们最懂业务。因此在测试一些内部系统时需要提前将系统以前容易出现的风险点BUG点告诉它。 AI驱动测试
一、Agent智能体是什么1、AI大模型大海量数据经过海量的参数使用海量的算力训练得到一个神经网络预训练模型使用方式给AI提示词AI生成[文字、音视频]目前AI的角色是聊天机器人例如提示词为”帮我生成一个购物网站的代码“AI就会返回一堆代码也就是[文字]。但是它不会保存成文件、自动运行代码、根据运行结果自动调试修改代码。AI大模型只有第一步的能力没有后续操作的能力。所以这里我们就需要用到一些扩展2、使用工具申明工具功能和用法添加到 提示词 中去这些功能有搜索、文件读写、系统命令等使用工具之前 AI的角色是 聊天机器人 使用工具之后AI的角色是助手3、LOOP循环持续的工作:根据上一个动作的结果决定下一个动作可以主动获取外界信息可以频繁失败重试如下图如果返回的页面状态与结果与“模型理解的目标”不一致会循环重试直到达到目标有了LOOP之后AI的角色就是Agent智能体4、测试AgentAI短视频博主需要的“短视频Agent”的技能是下载、上传、登陆抖音等测试需要的“测试Agent”的技能是用例设计、用例执行、结果分析、输出报告等核心区别技能技能来源function calling代码自己写代码如抖音的登陆等功能封装成函数。然后申明工具功能和用法添加到 提示词 中mcp-server程序/接口别人写好的功能共享出来给大家使用例如添加的MCPplaywrightskillsmd文档允许渐进式的加载一步一步加载。不像MCP一样一次性加载完比较费Token技能内容用例设计(文字) 用例执行 (自动化) 接口封装框架使用框架 web:mcp playwright-mcp mcp-chrome appmcp 报告/分析/文档(文字) 飞书通知 对接禅道二、Agent智能体是什么 {从另外一个角度理解}1、Agent智能体Agent LLM TOOL 其他LLMAI大模型例如Claude、GPT‑5、deepseek-v4-pro等TOOL工具由MCP和SKILL提供其它记忆、编排等2、Agent工具Agent工具不是大模型工具可以让大模型去使用MCP、SKILL常见的Agent工具有Claude Code获取方式npm安装CodeX获取方式应用商店OpenCode获取方式官网下载DeepSeek-TUI获取方式github下载3、搭建环境安装nodehttps://nodejs.org/zh-cn/download安装pythonhttps://www.python.org/downloads/安装Agent工具Claude Codenpm install -g anthropic-ai/claude-code本次不对接claude大模型原因对win不友好本次对接deepseek-v4大模型原因便宜对接方法在DeepSeek API官方文档https://api-docs.deepseek.com/zh-cn/中按照“接入Agent工具-Claude Code”章节操作4、Claude Code使用技巧命令行执行claude即可进入claude可以输入中文指令如果输入错了并且发送了可以按两次ECS就可以打断calude继续生成结果三、MCP1、安装MCP实际工作中可能有不同任务要求例如操作数据库操作浏览器对接第三方服务大模型本身只是个对话机器人相当于一个“大脑”无法直接干这些活干具体的活需要“手脚”去干因此需要通过MCP、SKILL获取这些“手脚”MCP是大模型上下文协议可以使用这个协议添加多个由别人提供、控制的mcp server有操作数据库的mcp server有操作麦当劳的mcp server有操作浏览器的mcp serverplaywright-mcp下面详细介绍下playwright-mcp使用方法安装方法claude mcp add playwright npxplaywright/mcplatest参考https://github.com/microsoft/playwright-mcp使用技巧/mcp #列出所有已安装的MCP可以看到playwright提供了24个TOOL这些TOOL就是二.1章节中描述的TOOL2、WEB端测试实战2.1、探索#API测试因为有接口文档不需要这一步目的让Agent熟悉项目提示词提示词使用技巧 角色设定让AI快速代入资深测试架构师视角思维链(CoT)引导大模型逐步拆解复杂测试策略你是一个资深功能测试工程师精通Web的需求分析和用例设计。 接下来我们一起分步进行一个项目的Web端测试。 现在开始第一步 1.启动浏览器访问http://8.137.210.99:8080/ 2.探索和理解网站功能、页面结构、导航体系 3.输出一个**md文件**作为网站功能地图包含 -页面清单 -各个页面关键元素 -各个页面直接的关系(例如依赖、跳转、顺序)产出网站功能地图2.2、分析目标识别测试目标、优先级、风险点提示词现在开始第二步 基于前面梳理的网站功能地图分析 1.哪些功能是核心流程用户一定会用对项目比较重要 2.哪些地方容易出BUG输入边界、状态改变、权限校验 3.输出**md文件**作为测试范围和优先级矩阵 文件格式表格表头 优先级功能模块测试重点风险等级备注可以为空产出功能列表(含优先级、风险点)2.3、设计目的输出具体的、可执行的测试用例包含前置条件、步骤、预期结果提示词现在开始第三步 读取测试范围与优先级矩阵.md对**P0功能**进行用例设计至少覆盖 1.1个正常的流程和1个异常流程 2.边界值最大/最小/空值/特殊符号 3.用户的正常行为习惯和操作流程产出测试用例2.4、执行临时执行目标由Agent根据用例的内容执行测试得到结果提示词读取测试用例设计_P0.md执行**商品列表加载TC-LIST**的测试用例要求 1.逐条执行 2.记录结果 3.输出结论表格总结 4.对于失败的用例要进行截图保存到文件中记录失败的步骤、原因、错误信息到文件中产出测试报告CI/CD方式执行PASS2.5、沉淀PASS3、落地可复用资产尽可能的落文件例如上面产出的三个md文件md文件段落代码表格图表公式py文件固定化操作和系统、网络的交互可复用代码落地可复用、可维护的自动化代码用于服务当前项目落地可复用、可维护的SKILL可以用于服务其他项目四、SKILL1、SKILL的格式、原则很多人第一次接触 Skill 时会把它理解成“更长一点的提示词”或者“某个平台里的插件”。这样的理解不算完全错误 但还没有抓住重点。 更准确的说法是Skill 是一个包含把任务目标、执行规则、参考知识、输出格式和使用时机一起固化下来得 的技能规范。Skill像是给 AI 补上一层“工作方法”它不直接替代工具也不直接替代模型而是把“这类任务应该怎样做、做到什么 程度、产出什么结果”固定下来简单来说将重复性高的工作固化为可维护、可复用的文件。一个可用的 Skill通常包含三层内容识别层告诉模型这是什么 Skill什么时候该用它规则层说明任务目标、处理步骤、输出格式和质量约束资源层提供样例、模板、规范文档、历史案例等参考材料示例https://github.com/anthropics/skills/blob/main/skills/pdf/SKILL.md这个SKILL的作用是告诉AI如何处理PDF文件AI在加载SKILL的时候不会一次性把所有内容都加载进去而是只会先加载识别层形成一个目录然后根据目录去选择工具。例如用户要去操作PDF文件然后AI根据目录找到这个SKILL.md文件然后再加载这个文件里面的详细内容也就是按需加载。MCP在工作的时候会将所有的MCP、工具都汇总起来当MCP SERVER多的时候效率很低上下文很长Token花费很快。SKILL恰好解决了这个短板。可以看到SKILL会用到不同的python模块这些才是实际干活的工具同时论证了SKILL’不直接替代工具也不直接替代模型而是把“这类任务应该怎样做、做到什么 程度、产出什么结果”固定下来‘当我使用pypdf的时候这个SKILL的内容还不够详细不够覆盖用户所面对的各种复杂的应用场景它还可以提供更详细的内容供我们参考“接下来的步骤”章节。因此SKILL既有按需加载的特性又有懒加载逐步加载的特性2、安装SKILL作为md文件可以让LLM手动加载也可以放在指定的目录自动加载当前项目根目录~/.claude/skills/自定义名称/SKILL.md #所有SKILL必须用统一固定的文件名SKILL.md复制md的源码到SKILL.md中/skills #列出所有已安装的skill3、API测试实战3.1、OpenAPIOpenAPI原 Swagger 规范是一种用于描述 RESTful API 的标准化格式JSON/YAML。它定义了 API 的端点、 请求参数、响应结构、认证方式、数据类型等细节使得API 的设计、文档生成、代码生成和自动化测试可以基于同 一份文档内容进行。3.2、用自然语言完成测试过去测试人员往往需要自己完成一整套链路阅读接口文档--梳理请求参数--理解返回结构--提炼测试点--设计正常、异常与边界用例--再决定生成什么形式的测试资产而在 AI 参与之后这条链路的前半段可以被大幅加速。例如可以给出如下任务描述请读取 openapi.json并完成以下任务 1. 列出与“用户登录”相关的核心接口及其请求参数 2. 基于接口定义设计功能、异常、边界三类测试用例 3. 执行接口测试用例输出结果 4. 测试账号xxxxxxqq.com/xxxxxx只看第一次生成结果AI 在 API 测试场景里通常已经足够令人惊艳。但只要把过程重复一遍问题就会很快暴露出来。例如同样一个任务新开一个对话后往往会出现输出风格开始变化用例标题开始变化用例覆盖度开始变化代码风格开始变化这时Skill 的价值就真正体现出来了复用把成功的方法留到下一次继续使用约束减少输出漂移和技术选型漂移定制让模型贴近本团队的业务风格和工程规范将自己项目的风险和业务逻辑补充进去补充把模型本来没有稳定掌握的方法补进去这也正是 API 测试场景比很多 UI 场景更迫切需要 Skill 的原因简单来说如果每次都靠自由对话驱动就很难形成资产如果能把成功的方法固定下来AI 的价值才会从一次演示变成长期能力3.3、第一个版本的Skill第一个版本的核心目标是先把Skill做出来基本步骤1. 和AI进行对话指导AI做一个还算满意的结果2. 梳理对话内容提炼有价值的指令3. 按照Skill格式创建第一个版本核心内容基于 OpenAPI 文档理解接口选择pytest requests作为技术方案围绕正常、异常、边界和认证等场景设计用例断言不能只有状态码示例.claude/skills/api-test-engineer-v1/SKILL.md--- name: api-test-engineer-v1 description: 基于 openapi.json 生成 pytest requests 接口测试代码 --- # API Test Engineer V1 ## 适用场景 当需要基于 openapi.json 生成接口自动化测试代码时使用。 ## 任务目标 基于 OpenAPI 文档输出 pytest requests jsonschema 的接口测试代码。 ## 核心原则 - 优先覆盖正常、异常、边界、认证相关场景 - 不臆造文档中不存在的接口和字段 - 断言不能只有状态码 ## 工作步骤 1. 读取 openapi.json 2. 定位目标接口 3. 提炼测试点 4. 生成 pytest 测试代码 ## 输出要求 - 优先输出可执行代码 - 如认证信息或环境信息缺失列出待确认项使用方法打开Glaude窗口输入这个Skill的名称/api-test-engineer-v1查询第一个版本的结果发现断言做的不好只验证了状态码关联关系做的不好有的用例需要先登陆才能执行而生成的代码中没有登陆就做执行的接口测试了测试账号是随机生成的这样的代码运行起来必然会报错。3.4、第二个版本的Skill第二个版本的核心目标是从可用走向稳定第一版 Skill 跑通之后检验它能不能稳定的投入生产现在能做用例筛选吗能解决接口依赖和数据关联吗输出的结构稳定吗生成的结果真的易维护、易扩展吗根据需要在Skill中添加更多的指导和约束识别用例的重要性和优先级识别接口以来和数据关联为用例添加mark已备筛选把单个测试文件拆成更易维护的结构能够识别和复用上一次的产出由于第一版的上下文会影响制作Skill必须在一个新窗口生成第二版Skill.claude/skills/api-auto-test-engineer-v2/SKILL.md--- name: api-auto-test-engineer-v2 description: 基于 openapi.json 生成可维护的 pytest requests 接口自动化测试工程。 --- # API Auto Test Engineer V2 ## 目标 1. 读取 openapi.json理解接口、数据结构、依赖关系和安全声明 2. 结合 test_data.txt 推断可执行的测试链路 3. 先生成测试设计文档 4. 再基于测试设计文档生成 pytest requests 自动化测试代码 ## 工作流程 1. 检查项目根目录和 openapi.json 2. 梳理接口列表、资源分组、认证方式、CRUD 链路和路径参数依赖 3. 检查是否存在 test_data.txt 4. 检查现有工程中的 tests/、conftest.py、pytest.ini 5. 先生成测试设计文档再决定代码结构和文件拆分方案 ## 两阶段输出规则 第一阶段先生成 test_design.md 第二阶段只有在无关键阻塞项时才继续生成 conftest.py、pytest.ini、tests/*.py ## 认证处理规则 1. 有认证接口 有认证输入 - 生成真实认证 fixture 2. 无认证接口 有静态认证信息 - 生成静态认证 fixture 3. 既无认证链路也无稳定认证信息 - 输出待确认项不伪造认证 fixture.claude/skills/api-auto-test-engineer-v2/test_data.txt #测试数据例如测试账号密码等等971045897qq.com 123456第二个版本还增加了测试数据复杂事情拆分执行的理念将测试设计和自动化代码分步骤进行生成后者复用前者规定了代码生成到test/目录下如果公司或者项目还有其他要求都可以加入到Skill中查看代码发现没有失败重试requests()函数被放到了fixtrue中将不会生成日志后续难以定位问题没有使用插件没法自动生成测试报告没有发邮件告警的功能。3.5、第三个版本的Skill第三个版本的核心目标是Skill是否把我的经验沉淀成了资产这时我们不再只是盯着“它能不能生成代码”而是开始反过来问自己我的接口测试经验到底是什么我平时做测试时真正依赖的方法论是什么我亲自做这件事会比当前 Skill 做得更好吗哪些能力是现在就能沉淀进 Skill 的哪些暂时还不能我要如何评审和维护AI的产出很多老司机会觉得自己做确实比 Skill 做得更好更知道先看哪些风险更知道哪些接口应该串成链路更知道哪些待确认项不能跳过更知道哪些结果适合进入工程哪些结果只是看起来热闹从AI技术角度来讲现阶段人工评估依然是智能的“金标准”这就意味着我们的Skill如果想要实用、可靠、可持续一定要预留人工介入的接口.claude/skills/api-auto-test-engineer/SKILL.md--- name: api-auto-test-engineer description: 基于 openapi.json 生成可维护的 Python 接口自动化测试工程。适用于需要分析依赖链路、生成 pytest requests 测试代码并复用 test_data.txt 时。 --- # API 自动化测试工程师 ## 输出结构标准 详细规范请阅读 [output standards](references/output-standards.md) ## 失败判定 - 没有先生成测试设计文档就直接开始写 .py - 设计文档中存在关键待确认项却仍然继续生成代码 - 明明存在认证接口和认证输入却仍生成一个静态认证 fixture - 所有测试都被塞进同一个大文件且没有明确的拆分策略 - 断言过于宽泛只剩“状态码小于 500”这类低价值判断 ## 约束与边界 - 不要臆造规范中不存在的参数、字段或成功条件 - 除非 openapi.json 或 test_data.txt 明确支持否则不要擅自假设鉴权行为 - 对仍无法确认的假设用注释或结果说明显式标出.claude/skills/api-auto-test-engineer/references/output-standards.md## 输出结构标准 - 目录结构标准按认证域/业务域拆目录 - 文件拆分标准同一资源放同一文件 - fixture 分层标准全局 fixture 放 conftest.py - 断言标准 - 失败信号判定.claude/skills/api-auto-test-engineer/references/dependency-analysis.md## 接口依赖分析 - 鉴权依赖 - 资源生命周期依赖CRUD 链路 - 路径参数依赖 - 测试数据依赖 设计文档至少包含 - 输入信息 - 认证与依赖分析 - 资源分组与测试范围 - 文件拆分方案 - 核心用例设计 - test_data.txt 使用计划 - 待确认项至此我们在工作中真正值得重点 review 的不是执行层的py而是设计层的md测试范围是否合理依赖分析是否成立待确认项是否被诚实地暴露出来文件结构和断言策略是否适合进入工程Skill 不是把一次提问写得更长而是把个人经验、团队规范和测试方法一步步沉淀为可复用能力。3.6、Skill 与现有自动化工程结合因为 Skill 解决的是“生成方法的稳定性”而不是“让工程问题自动消失”在真实团队里接口自动化最终还是要落回已有工程测试数据怎么准备环境地址怎么切换鉴权 token 怎么获取公共断言怎么复用用例怎么进入 CI 执行这些都不是靠一句提示词就能解决的因此更合理的落地方式通常是下面这条链路AI 和传统自动化并不是互相替代而是各自承担最合适的部分AI 擅长读文档、提测试点、起草代码工程化体系负责环境、执行、复用和持续集成测试人员负责业务判断、风险取舍和结果验收五、Agent的能力边界1、提示词工程很重要提示词就是输入给 AI 大模型的上下文内容。模型更接近于根据当前输入预测下一段最可能出现的内容因此它看到 什么、看得够不够完整会直接影响输出质量。提示词工程本质上就是采用工程化的思想管理、维护和优化提示词内容从而得到更高质量、更稳定的 AI 输出结 果。一个好的提示词至少要说清四件事目标是什么输入材料是什么输出格式是什么成功与失败的判断标准是什么提示词使用技巧 角色设定让AI快速代入资深测试架构师视角 思维链(CoT)引导大模型逐步拆解复杂测试策略2大模型具有概率性传统程序更像“规则机”同样的输入在逻辑不变的前提下通常会得到同样的输出。但大模型的生成本质是概率采样即使任务相同、模型相同在不同上下文、不同轮次下也可能产生略有不同的动作路径。这体现了大模型的灵活性和适应性但在测试工作里对复现、维护、评审造成了困难。因此对于测试AI本身的测试活动中不能单纯的断言一次的结果是对还是错需要对多次结果打分评估才能得出AI能力好坏的结论。3、AI 会有幻觉幻觉可以通俗理解为“一本正经的胡说八道”这和搜索引擎“查不到就返回空白”不同大模型的默认倾向不是沉默而是继续生成尽量给出一个看起来像答案的 输出。关于降低幻觉业绩已经有很多手段了对于我们测试人员来说务必谨记AI 生成的内容不可全盘相信如果公司有 AI 应用要进行幻觉评估4、大模型的上下文是有限的很多人刚使用大模型时会误以为它“总是记得此前的对话内容”。实际上模型能利用的主要是当前会话里被送进上下文窗口的内容。只要对话变长、信息变多、无关内容混进来早期的重要信息就可能被弱化、遗忘甚至被后续内 容覆盖。这就是为什么同一个任务在一段很长的对话后继续执行结果往往会越来越飘。所以一个非常实用的技巧是重要任务不要无限续聊而要及时重开上下文、重置任务边界。5、AI 天然不理解你的业务风险只能利用你主动提供的风险信息模型拥有很强的通用语言能力这会让人产生一种错觉好像它天然懂各自业务。实际上它懂的是训练语料中常见 的业务模式和语言模式而不是你们公司的真实系统、真实用户和真实风险。这也是测试人员在 AI 时代仍然不可替代的一部分价值。AI 可以帮助我们提效但风险判断、优先级判断和业务边界判断最终还是我们最懂业务。因此在测试一些内部系统时需要提前将系统以前容易出现的风险点BUG点告诉它。