最近Anthropic 开源了一个很值得关注的项目anthropics/skills。从仓库 README 来看这个项目不是简单放了一批 Prompt 模板而是把 Claude 使用的一套Agent Skills 能力机制开放出来里面包含技能示例、规范、模板以及文档处理相关的复杂 Skill 参考实现。简单说Skills 的目标是让 Agent 在面对特定任务时可以动态加载一组已经封装好的说明、脚本和资源从而更稳定地完成任务。这件事对做 Agent、做 AI 工具、做智能化测试的人来说都值得看一下。因为很多团队现在遇到的问题已经不是“模型会不会回答”而是同一类任务每次都要重新写 Prompt不同项目里重复复制同一套规则Agent 接了很多工具但不知道怎么稳定完成业务流程测试经验、文档规范、执行步骤很难沉淀一旦流程变复杂结果就开始不稳定Skills 想解决的正是这些问题。目录Anthropic Skills 到底是什么它和 Prompt、MCP、工具调用有什么区别为什么 Skills 对 Agent 工程化很关键一个 Skill 的结构长什么样测试开发为什么应该关注 Skills测试团队可以沉淀哪些 Skills企业落地时真正难点在哪里写在最后Agent 能力开始进入可管理阶段01 Anthropic Skills 到底是什么按照 Anthropic README 的描述Skills 是一些文件夹里面包含说明、脚本和资源。Claude 可以在需要时动态加载它们用来完成某类专门任务。也就是说Skill 不是一句提示词。它更像一个“能力包”。一个 Skill 通常可以包含这些内容组成部分作用SKILL.md描述这个技能是什么、什么时候使用、如何执行脚本文件封装可执行逻辑比如 Python、Shell、JS模板文件固定输出格式比如文档模板、表格模板、报告模板参考资料业务规则、操作手册、规范说明示例案例给 Agent 提供可参考的输入输出样例如果用软件工程的方式理解Skill 有点像一个可复用模块。以前我们让 Agent 干活经常是这样但 Skills 的思路更接近这样这就是 Skills 的关键价值把一次性的提示词变成可复用的任务能力。02 它和 Prompt、MCP、工具调用有什么区别很多人第一次看到 Skills容易把它理解成 Prompt 模板。但它和 Prompt、Tool Calling、MCP 的定位并不一样。可以先看这张表类型主要解决什么问题典型特点常见局限Prompt告诉模型这次怎么做灵活、上手快难复用容易越写越长Tool Calling让模型调用某个具体工具适合执行原子动作只解决“能调用”不解决完整流程MCP标准化连接外部工具和数据源适合打通系统能力更偏连接协议不负责业务方法沉淀Skills封装一类任务的流程、规则、脚本和资源可复用、可管理、可组合需要设计、测试和维护一句话概括MCP 更像“连接器”Skills 更像“任务方法论”。比如在测试开发场景里我们要让 Agent 做接口自动化。MCP 可以让 Agent 连接Git 仓库接口文档测试平台数据库CI/CD 系统Tool Calling 可以让 Agent 调用执行 pytest读取 Swagger生成报告查询数据库Prompt 可以告诉 Agent“请根据 Swagger 生成接口自动化测试脚本。”但 Skill 可以把完整流程沉淀下来这时候Skill 不只是“调用一个工具”而是描述了任务怎么拆每一步怎么做输出格式是什么质量标准是什么失败后怎么处理这才是 Agent 进入工程化以后真正需要的能力。03 为什么 Skills 对 Agent 工程化很关键现在很多团队做 Agent早期效果看起来都不错。让模型写文档、生成代码、分析日志、整理报告短期内都能看到效率提升。但只要放到真实项目里很快会遇到几个问题。第一Prompt 很难长期维护刚开始只有一两段提示词大家还能接受。后来规则越来越多输出格式业务背景命名规范代码风格异常处理评审标准安全限制最后 Prompt 会越来越长。更麻烦的是不同人各写一份不同项目复制一份版本很快就乱了。第二工具接得多不代表任务做得好现在很多 Agent 都能接工具。但能接工具不等于能完成业务流程。比如 Agent 能调用浏览器不代表它懂怎么做 Web 测试。 Agent 能执行 pytest不代表它会设计接口断言。 Agent 能访问数据库不代表它知道数据一致性该怎么验证。工具只是能力入口。真正影响结果质量的是任务流程和工程经验。第三企业知识不能全塞进上下文一个企业内部可能有大量规范品牌规范文档模板测试规范代码规范上线流程缺陷分级标准性能测试报告模板接口自动化框架规范如果每次都把这些内容全部塞进上下文不现实。Skills 的设计思路是只在需要时加载相关技能。这对复杂 Agent 系统非常重要。因为 Agent 的能力越多越不能靠一个巨大的系统提示词解决问题。04 一个 Skill 的结构长什么样Anthropic 给出的基础 Skill 很简单。一个文件夹里面有一个SKILL.md。示例结构类似这样--- name: my-skill-name description: A clear description of what this skill does and when to use it --- # My Skill Name [Add your instructions here that Claude will follow when this skill is active] ## Examples - Example usage 1 - Example usage 2 ## Guidelines - Guideline 1 - Guideline 2其中最重要的是两个字段字段作用nameSkill 的唯一标识description描述这个 Skill 做什么、什么时候应该使用这里有一个很容易被忽略的点description 不是普通介绍而是 Skill 能不能被正确触发的关键。比如下面这种写法就很弱description: 用于测试它太泛了。Agent 很难判断什么时候该用它。更好的写法应该像这样description: 根据需求文档、接口文档或页面说明生成结构化测试点和测试用例。适用于功能测试、接口测试、边界值分析、异常场景补充和用例评审。这个描述明确告诉 Agent输入可能是什么任务目标是什么适用场景是什么能输出什么结果这背后其实不是写 Prompt 的能力而是任务抽象能力。05 测试开发为什么应该关注 Skills对测试开发来说Skills 最值得关注的地方在于测试经验可以被封装成 Agent 可调用的能力。很多测试人的价值并不只是会点工具。真正有价值的是这些判断需求里哪些地方容易漏测哪些字段必须做边界值哪些状态流转容易出问题支付、库存、优惠券有哪些高风险链路接口自动化不能只断言状态码UI 自动化不能全靠 XPath性能测试不能只看平均响应时间RAG 测试不能只看答案像不像Agent 测试不能只跑正常流程这些经验过去通常存在于测试负责人脑子里项目复盘文档里评审会议记录里团队内部规范里老员工带新人过程中但它们很难被稳定复用。Skills 提供了一个新的承载方式。比如一个“测试用例生成 Skill”可以这样设计--- name: test-case-design description: 根据需求文档、接口文档或页面说明生成结构化测试点和测试用例。适用于功能测试、接口测试、边界值分析、异常场景补充和用例评审。 --- # 测试用例生成 Skill ## 执行流程 1. 识别业务对象、用户角色和核心流程 2. 拆分正常流程、异常流程和边界条件 3. 对字段补充空值、长度、格式、重复提交等场景 4. 对关键链路补充状态流转和数据一致性检查 5. 输出测试点、测试用例、优先级、前置条件和预期结果 ## 输出格式 | 模块 | 测试点 | 用例标题 | 前置条件 | 操作步骤 | 预期结果 | 优先级 |这个 Skill 的价值不在于“让模型帮我写几条用例”。而在于它把测试用例设计的流程固化下来了。当团队里每个人都使用同一套 Skill输出质量才有可能趋于稳定。06 测试团队可以沉淀哪些 Skills如果从测试团队的真实工作出发下面这些场景都适合优先做成 Skills。1. 需求评审 Skill适用场景PRD 评审用户故事评审接口需求评审上线前需求补充检查主要解决需求描述不完整业务规则不清晰异常流程缺失验收标准模糊测试边界不明确可以设计成这样的流程输出可以是问题类型问题描述影响范围建议补充优先级业务规则缺失未说明退款失败后的处理方式支付/售后链路补充失败状态和重试规则高边界条件不足未说明优惠券叠加规则营销活动明确叠加、互斥、过期策略中验收标准模糊未定义导出成功标准报表模块明确字段、格式、数据量限制中2. 测试用例设计 Skill适用场景根据需求生成测试点根据页面生成用例根据接口文档生成接口测试场景用例评审前补充遗漏场景主要解决测试点遗漏用例颗粒度不一致异常场景不足边界值设计不完整建议输出结构模块测试点用例标题前置条件操作步骤预期结果优先级登录手机号格式校验输入非法手机号登录用户未登录输入 10 位手机号并提交提示手机号格式错误P1登录密码错误次数限制连续输错密码触发限制账号存在连续输入错误密码 5 次账号进入限制状态P03. 接口自动化 Skill适用场景根据 Swagger/OpenAPI 生成测试脚本为接口补充断言生成 Pytest Requests 项目结构分析接口自动化失败日志流程可以设计成Skill 里可以固化这些规则规则说明必填参数必须覆盖防止只生成正常路径状态码不能作为唯一断言需要校验业务字段鉴权信息不能硬编码需要从环境变量读取测试数据要可复用避免用例之间互相污染失败日志要可定位至少保留请求、响应、断言失败原因4. UI 自动化 Skill适用场景根据页面结构生成 Playwright/Selenium 脚本生成 Page Object 模板检查 UI 自动化脚本稳定性分析失败截图和日志可以沉淀定位策略优先级页面对象分层规范等待策略断言策略失败截图规范重试策略例如定位策略可以写进 Skill优先级定位方式说明1data-testid最稳定推荐业务页面补充2可访问性属性适合按钮、输入框、链接3文本定位适合稳定文案4CSS 选择器可用但要控制复杂度5XPath尽量少用避免脆弱定位5. 性能分析 Skill适用场景分析压测报告定位性能瓶颈生成性能测试结论输出优化建议性能测试最怕报告里只有数据没有分析。Skill 可以把分析路径固化下来输出结构可以是分析维度观察结果可能原因建议动作响应时间P95 明显升高数据库查询慢检查慢 SQL 和索引错误率高并发下 5xx 增加连接池不足调整连接池和超时配置CPU压测中持续 90% 以上计算逻辑密集分析热点方法和线程模型6. 大模型应用测试 Skill这是未来测试开发很值得补的一类能力。适用场景测 RAG 系统测智能客服测 Agent 工具调用测多模态应用测企业知识库问答可以沉淀这些测试维度测试对象重点关注Prompt指令遵循、格式稳定性、边界输入RAG召回准确性、答案忠实度、引用一致性Agent工具选择、任务分解、失败恢复多模态图文理解、OCR、页面识别安全提示词注入、越权访问、敏感信息泄露这类 Skill 对测试开发尤其重要。因为 AI 应用测试不是简单问一句“回答对不对”。它要看模型是否按照业务规则回答检索内容是否支撑最终答案工具调用是否正确多轮对话里状态是否稳定异常输入下是否有防护错误结果是否可追踪07 企业落地时真正难点在哪里从 Anthropic 的模板看写一个基础 Skill 并不复杂。真正难的是让 Skill 在团队里长期可用。1. Skill 不是越多越好很多团队一开始容易把所有流程都写成 Skill。但 Skill 多了以后会出现新的问题命名重复职责边界不清触发条件冲突输出格式不统一版本没人维护旧 Skill 失效没人知道所以企业内部需要的不只是 Skills而是 Skills 管理机制。可以简单分成三层个人 Skill 可以快速试错。 团队 Skill 需要统一规范。 企业级 Skill 必须有版本、权限和审计。2. Skill 要有清晰边界一个 Skill 只应该解决一类任务。如果一个 Skill 同时负责需求分析用例生成自动化脚本性能分析报告生成缺陷归因它很快就会变成另一个“大 Prompt”。更好的方式是拆开每个 Skill 只负责一个清晰环节。这样才容易维护也更容易评估质量。3. Skill 必须能被验证一个 Skill 写得好不好不能只看输出像不像。要看它是否能稳定满足标准。比如测试用例 Skill可以检查检查项说明是否覆盖主流程不能只生成边角场景是否覆盖异常流程要包含失败、取消、超时、重复提交是否包含边界值字段长度、金额、数量、时间都要考虑是否有明确预期结果不能写“系统正常处理”这种空话是否能用于评审输出要结构化方便团队讨论接口自动化 Skill可以检查检查项说明脚本是否可运行不能只生成伪代码是否有断言不能只发请求是否区分环境不能写死测试地址是否处理鉴权Token、Cookie、Header 要可配置失败日志是否清晰便于定位问题没有验证规则的 Skill最后还是会变成“看起来很智能实际不可控”。4. Skill 要进入工程链路如果 Skill 只是生成一段文字它的价值有限。更好的落地方式是让它进入测试工程链路。比如这样一来Agent 就不只是“辅助写东西”而是可以参与完整的质量流程。这也是测试开发未来可以重点关注的方向。08 一个测试团队可以怎么开始如果团队想尝试 Skills不建议一上来就做复杂系统。可以按下面这个路径走。第一步先选高频、稳定、可验证的场景优先推荐这三个优先级Skill 类型原因1测试用例生成 Skill高频、容易验证、价值明显2接口自动化 Skill和工程链路结合紧密3测试报告 Skill输出标准化适合团队复用不要一开始就做“万能测试 Agent”。万能通常意味着边界不清最后很难稳定。第二步把团队 SOP 改成 SKILL.md很多团队其实已经有规范只是没有结构化。可以把原来的文档改成这种形式--- name: requirement-review description: 对需求文档进行测试视角评审识别业务规则缺失、异常流程遗漏、边界条件不足和可测试性风险。 --- # 需求评审 Skill ## 输入 - PRD 文档 - 用户故事 - 接口说明 - 页面原型 ## 执行步骤 1. 识别业务目标 2. 拆分用户角色 3. 梳理主流程 4. 补充异常流程 5. 检查字段规则 6. 输出风险问题 ## 输出格式 | 问题类型 | 问题描述 | 影响范围 | 建议补充 | 优先级 |这样做的好处是团队原来的测试经验不会丢而是变成了 Agent 可以复用的能力。第三步给 Skill 加真实案例只有规则还不够。最好补充真实案例。比如类型示例好的测试点明确输入、操作、预期结果差的测试点只有一句“验证登录功能正常”好的断言校验状态码、业务码、关键字段、数据库状态差的断言只判断接口返回 200好的风险描述指出影响范围和可能后果差的风险描述只写“这里可能有问题”案例越具体Agent 输出越稳定。第四步逐步接入工具链Skill 稳定后再考虑接工具。比如Git 仓库测试平台CI/CDAllure 报告Jira/禅道飞书/企业微信知识库MCP Server合理路径应该是不要一开始就追求全自动。对测试团队来说先把“生成质量”和“评审效率”提升起来通常更容易看到效果。09 这件事对测试开发的启发Anthropic Skills 这个项目真正值得看的是它提供了一个很清晰的方向Agent 能力需要被封装、复用、组合和治理。过去我们使用大模型更多是在写 Prompt。后来开始接工具、接插件、接 MCP。但当 Agent 真正进入业务流程后还缺一层东西把人的经验和团队流程沉淀成可复用能力。这正是 Skills 的位置。对于测试开发来说未来值得思考的不是“AI 会不会替代测试”而是测试经验能不能被结构化 测试流程能不能被工具化 测试判断能不能被沉淀成 Agent 可调用的能力如果一个测试团队能把下面这些东西沉淀好需求评审方法用例设计方法接口断言规范UI 自动化分层规范性能分析路径大模型应用测试维度测试报告模板缺陷归因流程那 Agent 就不只是一个聊天助手而会逐渐变成测试工程链路中的一部分。这也是 Anthropic Skills 值得关注的地方。它不是让 Agent 变得“更会说”而是让 Agent 的能力开始有了工程化封装的形态。结尾Agent 发展到现在大家已经不缺模型也不缺工具。真正缺的是如何复用能力如何管理能力如何验证能力如何让能力进入真实工程流程Anthropic Skills 提供了一个很好的参考。对测试开发来说这也是一个信号未来的竞争力可能不只是会写自动化脚本也不只是会调用大模型 API。更重要的是能不能把测试经验封装成标准化、可复用、可验证的 Agent 能力。这件事值得测试团队提前开始做。
