最近，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其中最重要的是两个字段：
| 字段 | 作用 |
|---|---|
name |
Skill 的唯一标识 |
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 次 | 账号进入限制状态 | P0 |
3. 接口自动化 Skill
适用场景：
-
根据 Swagger/OpenAPI 生成测试脚本
-
为接口补充断言
-
生成 Pytest + Requests 项目结构
-
分析接口自动化失败日志
流程可以设计成：
Skill 里可以固化这些规则：
| 规则 | 说明 |
|---|---|
| 必填参数必须覆盖 | 防止只生成正常路径 |
| 状态码不能作为唯一断言 | 需要校验业务字段 |
| 鉴权信息不能硬编码 | 需要从环境变量读取 |
| 测试数据要可复用 | 避免用例之间互相污染 |
| 失败日志要可定位 | 至少保留请求、响应、断言失败原因 |
4. UI 自动化 Skill
适用场景：
-
根据页面结构生成 Playwright/Selenium 脚本
-
生成 Page Object 模板
-
检查 UI 自动化脚本稳定性
-
分析失败截图和日志
可以沉淀：
-
定位策略优先级
-
页面对象分层规范
-
等待策略
-
断言策略
-
失败截图规范
-
重试策略
例如定位策略可以写进 Skill：
| 优先级 | 定位方式 | 说明 |
|---|---|---|
| 1 | data-testid |
最稳定，推荐业务页面补充 |
| 2 | 可访问性属性 | 适合按钮、输入框、链接 |
| 3 | 文本定位 | 适合稳定文案 |
| 4 | CSS 选择器 | 可用但要控制复杂度 |
| 5 | XPath | 尽量少用，避免脆弱定位 |
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/CD
-
Allure 报告
-
Jira/禅道
-
飞书/企业微信
-
知识库
-
MCP Server
合理路径应该是：
不要一开始就追求全自动。
对测试团队来说，先把"生成质量"和"评审效率"提升起来，通常更容易看到效果。
09 这件事对测试开发的启发
Anthropic Skills 这个项目，真正值得看的是它提供了一个很清晰的方向：
Agent 能力需要被封装、复用、组合和治理。
过去我们使用大模型，更多是在写 Prompt。
后来开始接工具、接插件、接 MCP。
但当 Agent 真正进入业务流程后，还缺一层东西：
把人的经验和团队流程，沉淀成可复用能力。
这正是 Skills 的位置。
对于测试开发来说，未来值得思考的不是：
"AI 会不会替代测试？"
而是：
测试经验能不能被结构化？ 测试流程能不能被工具化？ 测试判断能不能被沉淀成 Agent 可调用的能力？
如果一个测试团队能把下面这些东西沉淀好：
-
需求评审方法
-
用例设计方法
-
接口断言规范
-
UI 自动化分层规范
-
性能分析路径
-
大模型应用测试维度
-
测试报告模板
-
缺陷归因流程
那 Agent 就不只是一个聊天助手，而会逐渐变成测试工程链路中的一部分。
这也是 Anthropic Skills 值得关注的地方。
它不是让 Agent 变得"更会说"，而是让 Agent 的能力开始有了工程化封装的形态。
结尾
Agent 发展到现在，大家已经不缺模型，也不缺工具。
真正缺的是：
-
如何复用能力
-
如何管理能力
-
如何验证能力
-
如何让能力进入真实工程流程
Anthropic Skills 提供了一个很好的参考。
对测试开发来说，这也是一个信号：
未来的竞争力，可能不只是会写自动化脚本，也不只是会调用大模型 API。
更重要的是，能不能把测试经验封装成标准化、可复用、可验证的 Agent 能力。
这件事，值得测试团队提前开始做。