别再堆 Prompt 了，Agent Skills 才是测试智能体的正确打开方式

Prompt是“说明书”Skill是“手和脚”。你写了100行系统提示词它还是不知道你的测试环境叫什么名字。大家好我是某互联网公司的测试架构师。上个月团队里一个做自动化的同事跑来找我表情有点崩溃。“哥我花了三天写了一套系统提示词八百多行。结果今天AI跑‘登录’用例的时候卡在验证码上二十分钟。”他说“我在提示词里写了‘请处理验证码’但它不知道怎么处理。”我问“你有没有告诉它你们的验证码是图形验证码还是滑块有没有告诉它测试环境的验证码白名单怎么配置”他沉默了。这就是目前大多数测试团队用AI的真实状态——堆了一堆Prompt但AI还是一个只会“回答问题”的聊天机器人不是一个能“干活”的测试智能体。问题不在模型在于你给它的东西根本不是一个“能力单元”。一、Prompt 堆得再多也解决不了“执行问题”很多人对AI的理解还停留在“写更好的提示词”。“你是资深测试工程师遵循以下步骤执行回归测试第一步读取需求文档第二步生成测试用例第三步执行测试……”这段Prompt写得没问题。但它有一个根本性缺陷LLM是语言模型不是操作系统的内核。它可以告诉你“应该先登录再查询”但面对一个动态验证码、一个偶尔超时的API、一个需要滑动解锁的按钮LLM的纯文本推理能力完全不够用。举个最简单的例子。同样是测“登录”功能用Prompt的方式你写“用测试账号登录然后截图”。Agent打开页面、输入账号密码、点击登录卡住了——验证码图片它识别不了等了三秒就以为登录失败直接abort。用Skill的方式你封装一个“登录Skill”里面写清楚了验证码的处理策略——测试环境走白名单绕过、预发布环境走Mock验证码接口、生产环境只读不写。Agent拿到这个Skill知道登录页有哪些元素、验证码怎么处理、登录失败重试几次、成功后截图存到哪里。Prompt是说明书Skill是手和脚。说明书告诉你“拧开螺丝”。Skill知道螺丝刀在哪个抽屉、顺时针拧三圈半、遇到滑丝怎么处理。二、Skill到底是什么一句话说清楚很多人第一次接触Skill以为就是“高级一点的Prompt”。完全不是一回事。Anthropic官方对Skill的定义很干脆一个Skill就是一个文件夹。里面必须有一个SKILL.md文件还可以放脚本scripts/、参考资料references/、静态资源assets/。用大白话说Skill就是把“资深测试工程师怎么做用例设计”的完整经验封装成一个AI能随时调用的“能力包”。一次写好长期复用团队共享。Skill和MCP的区别是什么MCP解决的是“模型能用什么工具”——连数据库、接GitHub、操作浏览器。Skill解决的是“模型该怎么用这些工具”——按什么步骤、什么格式、什么标准。两者是协作关系不是替代关系。三、SKILL.md到底怎么写SKILL.md是整个Skill的“大脑”。它分两部分YAML头信息 Markdown正文。YAML头信息头信息控制Skill什么时候触发、怎么触发--- name: test-case-generator description: 根据功能描述自动生成覆盖正常流程、异常场景、边界条件和权限校验的结构化测试用例。当用户提到“生成测试用例”“编写测试”“测试覆盖”“测试场景”时自动触发。 when_to_use: 用户需要从需求文档或功能描述生成测试用例时使用。 disable-model-invocation: false allowed-tools: Read, Write, Edit, Bash ---每个字段的含义nameSkill名称只能用小写字母、数字和连字符description最重要的字段。Claude把所有Skill的description预加载进上下文用来判断该不该触发这个Skill。要写清楚“什么时候用”而不是“它有什么用”when_to_use额外的触发上下文Markdown正文正文就是操作手册——告诉Claude“这件事具体怎么做”。## 任务 根据用户提供的功能描述或需求文档生成覆盖正常流程、异常操作、边界条件和权限校验四大类场景的测试用例。 ## 执行步骤 ### 步骤1理解需求 读取用户提供的功能描述提取 - 核心功能是什么 - 输入参数和约束条件 - 业务规则和状态流转 - 权限和角色要求 ### 步骤2识别测试场景 基于需求分析系统性地列出所有测试场景 正常流程至少覆盖1条完整的Happy Path 异常场景参数缺失、格式错误、业务规则违反、依赖服务超时 边界条件数值边界、状态边界、时间窗口边界 权限校验未授权访问、越权操作 ### 步骤3生成用例 为每个场景生成结构化用例包含 - 用例编号{模块}-{类型}-{序号} - 测试场景一句话描述 - 前置条件执行前必须满足的条件 - 测试步骤编号列表每步具体可执行 - 预期结果执行后的期望结果 - 优先级P0/P1/P2 ### 步骤4自检 对照场景分类检查是否有遗漏 - [ ] 每个功能点是否有至少1条正向用例 - [ ] 每个输入参数是否有异常场景覆盖 - [ ] 边界值是否覆盖了上下界 - [ ] 不同角色权限是否都有验证 ## 输出格式 Markdown表格可直接复制到Excel或测试管理工具。三个写正文的黄金原则步骤要具体可执行。不要写“验证数据是否正确”要写“调用GET /api/order/{id}检查返回的status字段是否为已取消”SKILL.md控制在500行以内。超过500行把详细内容移到references/目录用祈使句。“运行脚本”“检查输出”不要用第二人称四、测试Skill的四步落地法以测试用例设计为例一套完整的Skill流水线可以拆成四个环节Skill ①需求拆解——把PRD变成“测试地图”输入一份需求文档输出结构化的功能清单、业务规则、数据约束和风险预判。几秒钟就能把几十页PRD变成一张清晰的测试地图。Skill ②用例生成——把“测试地图”变成“测试用例”基于测试地图自动生成覆盖正常流程、异常操作、边界条件和权限校验的结构化用例。40多条用例不到1分钟生成。Skill ③场景补全——把“没想到”的找出来基于历史Bug模式自动识别“AI没想到但很可能出问题”的隐藏场景。比如并发场景、状态流转边界、跨模块数据一致性。Skill ④质量评审——给用例集“打分”对整份用例集做自动化质量评审从覆盖完整性、用例规范性、逻辑一致性、优先级合理性四个维度打分给出改进建议。传统方式啃PRD半天→ 梳理测试点半天→ 写用例1-2天→ 人工评审半天——总计3-4天。Skill流水线调用四个Skill——2小时出初稿人工审核1小时定稿。五、Skill最难的地方它也会“悄悄退化”这是最容易忽略但影响最大的问题。你什么都没改但模型版本从4.0切到4.5Skill的行为就跟着漂了。同样的输入昨天输出40条用例今天只输出25条。代码评审看不出来脚本跑不出错但Skill确实“坏”了。一个Skill的行为受到至少8种因素的影响SKILL.md中的自然语言描述、工具名称和说明、Agent引擎的执行机制、大模型版本与参数、用户输入的具体措辞、上下文长度、文件脚本和环境、外部API返回结果。阿里开源了skill-up专门解决这个问题。它把软件测试那套方法论完整平移到了Skill上用声明式YAML写评测用例跨多个Agent引擎跑评测让AI自动修复失败的Skill或补充评测用例然后重新跑——形成一个“评测到进化”的闭环。一个标准的Skill评测项目长这样my-skill/ ├── SKILL.md ├── evals/ │ ├── eval.yaml │ └── cases/ │ ├── basic-test.yaml │ └── edge-case.yaml └── scripts/眼熟吗这就是一个标准的测试工程目录。cases/是测试用例集eval.yaml是评测配置。一个真正“可交付”的Skill应该有自己配套的评测用例——就像一段线上代码有自己的单元测试一样。六、避坑指南坑一SKILL.md超过500行还不拆分。Claude每次加载Skill都要读完整的SKILL.md。超过500行会浪费大量Token。利用渐进式披露——SKILL.md只放核心流程详细内容移到references/目录。坑二description写得太空。description是Claude判断“要不要触发这个Skill”的唯一依据。写“帮助测试”这种描述Claude永远不知道什么时候该用它。要写清楚“触发条件”——什么场景下、用户说什么话时用这个Skill。坑三Skill粒度拆太细或太粗。SkillsBench2026年2月Amazon、CMU、Stanford、Oxford联合发布发现小而模块化的Skill2-3个模块显著优于大型数据转储。测试用例生成流水线拆成4个Skill是极限拆成5个以上就开始反噬了。坑四只建Skill不做回归测试。Skill不是一次性产物。模型在变、业务在变Skill也需要持续验证。每发现一个线上问题补充一条对应的回归用例。评测集不是一次性工程是持续积累的资产。最后Prompt是“对话”Skill是“流程”。对话不可控流程可复现。你写了八百行系统提示词AI还是不知道你的测试环境叫什么名字。你封装一个“登录Skill”里面写清楚了验证码处理策略、环境白名单配置、失败重试次数——AI拿到就知道怎么干。别再堆Prompt了。把经验封装成Skill把流程固化下来让AI真正“会干活”。下次你发现自己在写第N版系统提示词的时候停下来花30分钟把它封装成一个Skill。30分钟的投入换的是未来每一天的效率翻倍。