Anthropic Agent Skills 爆火，测试开发能拿它做什么？

Prompt是“说明书”，Skill是“操作手册+工具箱”。你写了八百行系统提示词，AI还是不知道你们的测试环境叫什么名字。

大家好，我是某互联网公司的测试架构师。

上个月，团队里一个做自动化的同事跑来找我，表情有点崩溃。

“哥，我花了两周写了一套系统提示词，一千多行。结果今天AI跑‘登录’用例的时候，卡在验证码上二十分钟。”

他说：“我在提示词里写了‘请处理验证码’，但它不知道怎么处理。”

我问：“你有没有告诉它，你们的验证码是图形验证码还是滑块？有没有告诉它，测试环境的验证码白名单怎么配置？”

他沉默了。

这不是他一个人的困境。

一、为什么Prompt堆得再多，AI还是不会干活？

我们过去用AI做测试，基本套路就是写一段系统提示词：“你是资深测试工程师，请按照以下步骤执行回归测试……”然后期待它自己搞定一切。

这个思路有一个根本性缺陷：LLM是语言模型，不是操作系统的内核。

它可以告诉你“应该先登录再查询”，但面对动态验证码、偶尔超时的API、需要滑动解锁的按钮，纯文本推理能力完全不够用。

Prompt是说明书，告诉Agent“拧开螺丝”。但真实任务执行，需要知道螺丝刀在哪个抽屉、顺时针拧几圈、遇到滑丝怎么处理——这些确定性操作流程，Prompt给不了。

Anthropic在2025年10月推出、12月正式开放为行业标准的Agent Skills，解决的就是这个问题。

二、Skill到底是什么？一句话说清楚

Anthropic官方对Skill的定义很干脆：一个Skill就是一个文件夹。 里面必须有一个SKILL.md文件，还可以放脚本（scripts/）、参考资料（references/）、静态资源（assets/）。

用大白话说：Skill就是把“资深测试工程师怎么做用例设计”的完整经验，封装成一个文件夹。AI在需要的时候自动加载，按你的要求执行任务。

Skill的核心设计理念是渐进式披露（Progressive Disclosure） 。平时Claude只加载每个Skill的名字和描述——大约100个Token。等到它判断这个Skill和当前任务相关时，才把完整内容加载进来。

这个设计意味着：你可以装几十个Skill，上下文不会爆炸。只有真正用到的Skill才会占用Token。

Skill和MCP的区别是什么？ MCP解决的是“模型能用什么工具”——连数据库、接GitHub、操作浏览器。Skill解决的是“模型该怎么用这些工具”——按什么步骤、什么格式、什么标准。MCP给AI提供“手”，Skill给AI提供“操作手册”。

三、Anthropic官方Web Testing Skill：测试开发最该抄的一套设计

最近我在Anthropic官方Skills仓库里看到一个很值得测试工程师研究的Skill：webapp-testing。它使用Playwright和本地Web应用交互，可以做前端功能验证、UI行为调试、浏览器截图和Console日志分析。

表面上看，这不就是UI自动化测试吗？

我把它的SKILL.md拆了一遍，发现真正值得看的其实不是Playwright。而是Anthropic在尝试回答一个更有意思的问题：如果把Web测试交给一个Agent，它到底应该怎么判断、怎么观察、怎么执行，又怎么证明自己真的测过？

核心设计：“先侦察、再执行”

Anthropic在这个Skill里做了一个叫 Reconnaissance-Then-Action 的设计。翻译成人话就是：别着急点，先看看页面到底长什么样。

官方给动态Web应用设计的流程是：打开页面 → 等待页面进入可分析状态 → 截图/检查DOM → 根据真实页面识别Selector → 再执行用户操作。

看起来只是多了一步“观察”。但对测试Agent来说非常关键。因为大量AI自动化脚本失败，并不是模型不会写Playwright。真正的问题是：模型在猜页面。如果AI不先读取页面结构，直接靠猜CSS selector，生成的脚本只能在当前机器跑通。

它教的不是API，是“测试决策树”

官方Skill当前的核心逻辑是一条测试决策树：

• 页面是静态还是动态？静态直接操作，动态先等加载
• 页面加载完成了吗？没完成就等待，不要急着点
• 要操作的元素在不在？不在就重新定位，不要死磕原选择器
• 操作完了怎么验证？截图 + Console日志 + 断言三重证据

传统UI自动化通常是：测试工程师理解页面 → 找元素 → 设计步骤 → 写Playwright → 机器执行。

而Skill想把它逐渐变成：测试工程师定义目标 → Agent理解页面 → Agent找元素 → Agent决定操作 → Playwright执行 → Agent判断结果。

人的职责开始从“把每一步写出来”，转向“告诉Agent我要验证什么”。这个变化，比生成几行Playwright代码重要得多。

四、测试开发可以直接落地的四个Skill

看完官方Skill，我结合团队的实际项目，总结了一套可以直接落地的测试Skill组合。

Skill ①：测试用例生成

这是测试人最核心的Skill。上传PRD或功能描述，自动生成覆盖正常流程、异常场景、边界值、权限隔离的用例。

SKILL.md核心片段：

---
name: test-case-generator
description: 根据功能描述自动生成覆盖正常流程、异常场景、边界条件和权限校验的结构化测试用例。当用户提到“生成测试用例”“编写测试”“测试覆盖”“测试场景”时自动触发。
when_to_use: 用户需要从需求文档或功能描述生成测试用例时使用。适用于功能测试、回归测试、接口测试的用例设计阶段。
---

正文部分写清楚四步：理解需求 → 识别场景 → 生成用例 → 自检。SKILL.md控制在500行以内，详细的用例模板和示例放到references/目录。

Skill ②：接口测试用例生成

核心思路是“拆解”。不让LLM一次性生成整个测试文件，而是把任务拆成三个独立Skill：参数构造Skill负责根据参数类型和约束生成合法测试数据；依赖链处理Skill负责分析接口前置条件，自动生成获取token等setup代码；断言生成Skill根据响应schema和业务规则，生成状态码断言、字段存在性断言、值范围断言。每个Skill职责单一，通过编排器组合调用。

Skill ③：测试数据生成

批量生成测试数据——用户信息、订单数据、商品数据，覆盖各种边界条件。以前手工构造100条测试数据至少半天，现在几分钟搞定。

Skill ④：测试报告生成

汇总所有测试结果，生成结构化的测试报告——执行概览、失败分析、质量评估、发布建议。一键出报告，不用手动整理。

五、怎么写一个测试Skill？三步走

第一步：搭目录结构（2分钟）

Skill必须放在Claude Code能识别的位置：

关键规则：SKILL.md文件名必须全大写，写成skill.md不行。文件夹命名必须用kebab-case，比如test-case-generator✅，Test Case Generator❌。

第二步：写SKILL.md（30分钟）

SKILL.md分两部分：YAML头信息 + Markdown正文。

头信息控制Skill什么时候触发。description是最重要的字段——Claude把所有Skill的description预加载进上下文，用来判断该不该触发这个Skill。要写清楚“什么时候用”，而不是“它有什么用”。

description的好坏对比：

• ❌ 坏的：description: 帮助用户生成测试用例
• ✅ 好的：description: 当用户需要从需求文档或功能描述生成测试用例时使用。适用于功能测试、回归测试、接口测试的用例设计阶段。

正文就是操作手册，告诉Claude“这件事具体怎么做”。用祈使句。“运行脚本”“检查输出”，不要用第二人称。

第三步：按需扩展scripts和references

references/目录放按需加载的长文档——用例模板、业务规则库、历史Bug模式。

scripts/目录放可执行的代码——格式化脚本、数据校验脚本。Claude不看代码内容，只看执行结果。

scripts vs references的简单判断： 需要执行才能得到结果 → 放scripts/。只需要阅读参考 → 放references/。

六、避坑指南

坑一：SKILL.md超过500行还不拆分

Claude每次加载Skill都要读完整的SKILL.md。超过500行会浪费大量Token。利用渐进式披露——SKILL.md只放核心流程，详细内容移到references/目录。

坑二：description写得太空

写“帮助测试”这种描述，Claude永远不知道什么时候该用它。要写清楚“触发条件”——什么场景下、用户说什么话时用这个Skill。

坑三：只建Skill，不做回归测试

Skill不是一次性产物。模型在变、业务在变，Skill也会“悄悄退化”。2026年，阿里开源了skill-up，专门面向Agent Skill的评测与演进工具。用声明式YAML写评测用例，跨多个Agent引擎跑评测，让AI自动修复失败的Skill。

坑四：把Skill和MCP搞混

MCP解决“能不能连”，Skill解决“会不会做”。两者是协作关系，不是替代关系。最常见的组合是：MCP提供手和眼，Skill提供做事方法。

七、行业趋势：Skill正在成为测试人的新底层资产

2026年，Skill生态正在爆发。

腾讯、阿里、字节在七天内先后出手——字节推出Agent Skills功能，阿里发布“悟空”工作平台，腾讯上线SkillHub，汇聚超过28000个Skill。信通院正式发布“软件测试智能体评估”标准，从技术、工程、场景三个维度对测试智能体做出系统性定义，涵盖测试分析设计、测试开发执行、测试评估修复等19个能力模块。

字节2026年春招“测试开发工程师-开发者AI”岗位，硬性要求里出现了一句话： “对AI Agent有深入理解和实践经验” 。腾讯招聘测试开发工程师，要求“1年以上LLM/Agent工程实践经验”。

测试开发工程师的核心能力，正在从“会写自动化脚本”变成“会设计Skill、会编排Agent、会管理智能体体系”。

最后

传统测试的底层资产是“测试用例库”——用例是一次性的，用完就扔。

AI时代的底层资产正在变成“Skill库”——Skill是可组合、可复用的能力单元。

一个Skill封装的不只是一个具体输入输出，而是一种“做某件事的方法”。你今天花30分钟写了一个“测试用例生成”的Skill，以后每一个项目都能复用。你今天花20分钟优化了Skill的规则，以后每一次生成都会更精准。

Skill不是让你“少干活”，是让你“把经验留下来”。

下次你发现自己在写第N版系统提示词的时候，停下来，花30分钟把它封装成一个Skill。

30分钟的投入，换的是未来每一天的效率翻倍。