关注 霍格沃兹软件测试开发 公众号回复「资料」, 领取人工智能测试开发技术合集最近Skill 正在成为 AI Agent 和 AI Coding 工具中的高频概念。过去我们想让大模型按照某种固定方法完成任务通常会写一段很长的 Prompt先做什么再做什么必须遵守哪些规则输出什么格式遇到异常如何处理可以使用哪些工具。但当同一套要求需要反复复制、不断补充时单纯依靠 Prompt 就会出现几个问题提示词越来越长每次执行标准不一致团队经验难以复用规则修改后需要到处同步大量无关内容占用上下文。Skill 正是为解决这类问题而出现的。它并不是简单地把 Prompt 写得更长而是把一类任务需要使用的知识、流程、规则、模板和脚本沉淀成 Agent 可以重复调用的能力包。本文将从 Skill 的基本概念开始讲清楚它的工作原理以及它与 Prompt、Tool、Workflow、MCP 之间的区别并结合软件测试场景介绍 Skill 的设计、评测和企业落地方法。阅读目录Skill 到底是什么Skill 不只是“本地文件夹”一个标准 Skill 包含什么Skills 的工作原理渐进式加载Skills 真的更省 Token 吗Skill 和 Prompt 有什么区别Skill、Tool、Workflow 和 MCP 有什么区别什么任务适合做成 Skill什么任务不适合做成 Skill测试团队如何落地一个 Skill一个高质量 Skill 应该怎样设计Skill 也需要测试和评估企业使用 Skill还要关注安全与治理如何判断一个 Skill 是否值得建设一、Skill 到底是什么可以先用一句话概括Skill 是面向 AI Agent 的可复用能力包它将完成某类任务所需的操作流程、专业知识、规则、模板和脚本组织起来让 Agent 在相关任务中按需加载并执行。在目前常见的 Agent Skills 实现中一个 Skill 通常以结构化目录的形式存在其中包含一个核心说明文件例如SKILL.md。这个说明文件会告诉 Agent这个 Skill 可以解决什么问题哪些任务适合调用它哪些任务不应该调用它执行任务时应该遵循什么流程最终应该输出什么结果什么时候需要读取模板和参考资料什么时候需要运行脚本或者调用工具。因此Skill 不能简单理解成一段更长的 Prompt。更准确的理解是Prompt 是一次任务的说明Skill 是一类任务的标准作业方法。例如我们可以在 Prompt 中告诉模型请根据下面的需求文档生成测试用例覆盖正常、异常和边界场景。而一个测试用例生成 Skill可以进一步规定如何解析需求如何提取业务角色如何识别状态流转如何拆分正常、异常、边界和权限场景用例必须包含哪些字段如何检查业务场景覆盖情况最终通过什么脚本进行格式校验。Skill 不只是告诉模型“要生成测试用例”还会告诉 Agent“按照什么标准和流程生成测试用例”。二、Skill 不只是“本地文件夹”很多介绍会把 Skill 定义成“一个结构化的本地文件夹”。这个说法容易理解但不够完整。从实现方式来看Skill 确实经常表现为一个目录其中存放说明文档、脚本、模板和参考资料。但 Skill 并不一定只能存在于本地。在不同的 Agent 平台中Skill 可以保存在本地项目中跟随代码仓库统一管理安装到个人 Agent 环境由企业管理员统一分发上传到云端或者容器环境中执行作为团队内部能力包进行共享。因此更准确的表述应该是Skill 是以结构化目录为常见载体的可移植能力包而不是只能存在于本地的文件夹。真正重要的不是它存放在哪里而是它是否能够被 Agent发现正确匹配按需加载按照说明执行调用相应的脚本和工具对结果进行检查。三、一个标准 Skill 包含什么一个测试用例生成 Skill目录结构可能如下test-case-generation/ ├── SKILL.md ├── references/ │ ├── test-design-rules.md │ ├── priority-definition.md │ └── business-terms.md ├── scripts/ │ ├── validate_cases.py │ └── check_coverage.py ├── assets/ │ └── test-case-template.xlsx └── evals/ └── evals.json不同 Agent 平台的具体规范可能存在差异但一个相对完整的 Skill通常包括以下几类内容。1. 主说明文件SKILL.md可以理解为 Skill 的入口文件。它通常负责说明Skill 名称Skill 功能适用场景不适用场景输入要求执行步骤输出格式使用限制需要读取的其他资料可以运行的脚本或工具。一个简化示例如下--- name: test-case-generation description: 根据产品需求、用户故事或接口文档生成结构化测试用例适用于功能测试、接口测试、业务流程测试和回归测试设计任务。 --- # 测试用例生成 ## 执行流程 1. 阅读并理解需求。 2. 提取业务角色、功能点和约束条件。 3. 拆分正常、异常、边界、权限和状态流转场景。 4. 按照指定模板生成测试用例。 5. 运行校验脚本检查字段完整性和重复用例。 6. 输出覆盖范围以及需要人工确认的问题。 ## 输出要求 每条用例必须包含 - 用例标题 - 优先级 - 前置条件 - 操作步骤 - 预期结果 - 用例类型其中description非常重要。它不仅要说明这个 Skill 能做什么还要说明在什么场景下应该调用它。因为 Agent 往往需要根据 Skill 的名称和描述判断当前任务是否与它匹配。2. 规则和参考资料references目录适合存放模型完成任务时可能用到的专业知识和业务资料。例如企业测试规范业务术语表产品功能说明接口字段定义数据库表结构支付业务规则历史故障案例品牌内容规范。这些内容不一定需要每次都加载。例如在进行普通登录功能测试时可能不需要读取支付业务规则只有当任务涉及支付流程时Agent 才需要加载对应文档。3. 模板和静态资源assets目录可以存放测试用例模板测试报告模板Word 或 Excel 文件JSON Schema配置文件模板图片或者其他静态资源。如果团队对输出格式要求很高与其在 Prompt 中反复描述不如直接提供一个标准模板。4. 脚本文件scripts目录适合存放确定性程序。例如检查字段是否缺失校验 JSON 或 YAML 格式检查测试用例编号是否重复统计接口覆盖情况批量处理文件对比配置差异执行自动化测试检查文章中的敏感词。大模型擅长理解、推理和生成但很多精确性检查更适合交给脚本完成。例如模型负责理解需求和设计测试场景 脚本负责格式检查和数据校验 人工负责高风险业务判断这种组合通常比完全依赖模型更加可靠。5. 评测数据为了验证 Skill 是否有效还可以为它准备专门的测试数据和评测用例。例如哪些问题应该触发 Skill哪些问题不应该触发 Skill标准输入文件预期输出结构必须覆盖的关键业务场景不允许出现的错误结果。Skill 不只是需要被编写也需要被测试。四、Skills 的工作原理渐进式加载Skills 的核心机制不是把所有内容一次性塞给模型而是渐进式加载也可以理解为按需加载。整个过程通常分为三个阶段。第一阶段发现 SkillAgent 开始执行任务时只需要先知道当前有哪些 Skills每个 Skill 的名称是什么每个 Skill 大致负责什么每个 Skill 适合处理哪些场景。此时通常只需要加载 Skill 的名称和简介不需要读取每个 Skill 的完整内容。例如test-case-generation 根据需求文档生成结构化测试点和测试用例。 api-test-analysis 根据接口文档分析参数、鉴权、幂等性和异常场景。 release-check 执行版本发布前的配置、数据和回滚检查。 article-rewrite 按照品牌规范重写技术文章。这一阶段相当于让 Agent 先查看能力目录。第二阶段匹配并激活 Skill当用户提交任务后Agent 会判断任务是否与某个 Skill 匹配。例如用户提出根据这份支付需求生成完整测试用例并检查业务场景覆盖情况。Agent 发现这个任务符合test-case-generation的适用范围于是加载对应的SKILL.md。如果任务没有匹配任何 Skill则可以按照普通任务处理。第三阶段按需读取资料并执行Agent 读取SKILL.md后会根据其中规定的步骤执行任务。如果主说明文件要求支付业务需要读取支付规则会员业务需要读取会员等级说明最终输出需要套用 Excel 模板生成后需要运行校验脚本Agent 就会在执行到对应环节时再加载相关文件或者运行脚本。整个流程可以概括为这种机制的价值在于只有当前任务真正需要的信息才进入上下文不相关的内容暂时不加载。五、Skills 真的更省 Token 吗“Skill 更省 Token”这个说法有一定道理但不能绝对化。它减少的主要是无关上下文占用。假设一个 Agent 中安装了 50 个 Skills每个 Skill 都包含大量说明和参考资料。如果 Agent 每次启动时都把这些内容全部读入上下文会产生大量无效消耗也可能干扰模型对当前任务的理解。采用渐进式加载后初始阶段只加载 Skill 的名称和描述任务匹配后才加载主说明文件详细资料在真正需要时再读取。这样可以减少无关内容对上下文窗口的占用。但这不代表使用 Skill 后每次任务消耗的 Token 一定更少。因为 Skill 被激活后主说明文件仍然需要进入上下文参考资料可能需要继续读取脚本执行结果也可能返回给模型复杂 Skill 还可能增加额外的执行步骤。所以更严谨的说法是Skills 可以减少无关内容对上下文窗口的占用提高上下文使用效率但不代表每次任务的总 Token 消耗一定更低。六、Skill 和 Prompt 有什么区别Prompt 和 Skill 不是相互替代的关系。事实上Skill 的主说明文件中也包含大量类似 Prompt 的自然语言指令。两者的主要区别在于生命周期、组织形式和复用方式。对比维度PromptSkill主要目标完成当前一次任务沉淀一类任务的能力使用周期单次或短期使用长期复用内容形式一段任务指令说明、规则、资料、模板和脚本触发方式用户直接输入Agent 自动匹配或用户指定维护方式分散在不同对话中集中维护和版本管理输出一致性依赖每次 Prompt 的完整程度可通过模板和校验提高稳定性团队复用相对较弱相对较强执行能力主要描述任务要求可以结合脚本和工具完成任务可以这样理解Prompt 是一次工作安排Skill 是标准作业指导书Agent 是负责执行任务的工作人员Tool 和脚本是执行任务时使用的工具设备。例如帮我生成支付功能的测试用例。这是一个 Prompt。而支付测试 Skill 可能会长期沉淀支付状态流转重复支付风险回调幂等性金额篡改检查支付超时处理退款并发场景第三方渠道异常测试用例输出模板校验脚本。这就不再是一次性说明而是一套可复用的专业能力。七、Skill、Tool、Workflow 和 MCP 有什么区别这些概念经常同时出现但它们解决的问题并不相同。Skill沉淀“应该怎么做”Skill 主要描述某一类任务需要遵循的专业知识操作流程业务规则输出模板常见错误工具使用方法。它解决的问题是这件事情应该按照什么方法和标准完成Tool提供“可以做什么”Tool 通常是 Agent 可以直接调用的具体能力。例如查询数据库搜索网页读取文件调用接口执行自动化测试创建工单发送邮件修改代码。它解决的问题是Agent 可以执行哪些具体动作Skill 可以告诉 Agent 在什么情况下调用某个 Tool但 Skill 本身不等于 Tool。Workflow规定“按照什么顺序做”Workflow 更强调任务步骤、执行顺序和分支控制。例如读取需求 → 分析功能点 → 生成测试用例 → 人工审核 → 执行自动化测试 → 输出测试报告它解决的问题是多个步骤、工具和 Agent 应该如何组织起来MCP提供“如何连接外部系统”MCP 是 Model Context Protocol也就是模型上下文协议。它主要用于让 AI 应用通过一种相对统一的方式连接外部系统中的数据和工具。例如GitHubJira企业知识库数据库浏览器文件系统测试平台监控平台。它解决的问题是Agent 如何通过标准协议访问外部数据和能力四者可以组合使用。例如一个接口测试 Agent 可以使用 Skill 定义接口测试设计方法使用 Workflow 编排接口分析、用例生成和执行顺序通过 MCP 连接接口管理平台和测试平台调用 Tool 执行接口测试使用 Skill 中的脚本检查测试结果。因此Skill、Tool、Workflow 和 MCP 不是互相替代的关系而是分别负责方法、动作、流程和连接。八、什么任务适合做成 Skill并不是所有任务都值得创建 Skill。适合封装成 Skill 的任务通常具备以下特点。1. 高频重复例如根据需求生成测试用例分析接口测试场景执行代码审查生成测试报告分析线上故障按照品牌规范重写文章执行版本发布检查。如果一项任务需要反复说明同一套要求就具备一定的沉淀价值。2. 已经形成相对成熟的方法Skill 应该建立在已经跑通的实践之上。例如团队已经明确测试用例设计需要经过理解需求 → 提取功能点 → 拆分业务场景 → 分析状态流转 → 补充异常和边界场景 → 生成测试用例 → 检查覆盖范围这样的流程适合沉淀为 Skill。如果团队自己都没有形成稳定的方法过早制作 Skill通常只会把不成熟的流程固定下来。3. 对输出一致性要求较高例如企业测试报告必须包含测试范围测试环境执行结果缺陷统计遗留风险上线建议。这类任务适合通过模板、规则和脚本提高输出一致性。4. 单靠一句 Prompt 难以稳定完成如果每次执行任务都需要补充内部业务知识项目特殊规则输出模板工具参数异常处理要求历史经验。说明它已经不是一个简单 Prompt 能够稳定解决的问题。5. 可以拆分成相对完整的能力单元Skill 的粒度不能太大也不能太小。过大的 Skill 可能包含大量无关内容导致触发不准确。过小的 Skill 又会导致一个任务需要组合大量能力包增加执行复杂度。一个好的 Skill 应该像设计合理的函数职责相对单一但可以独立完成一个有价值的任务单元。九、什么任务不适合做成 Skill1. 一次性的小任务例如帮我把这句话写得更自然一点。这种任务直接使用 Prompt 就足够了没有必要专门维护 Skill。2. 方法还没有跑通的任务如果业务流程仍在频繁变化过早 Skill 化只会增加维护成本。每次流程变化都可能需要同步修改主说明文件参考资料输出模板脚本逻辑评测用例。3. 很少重复的任务创建 Skill 需要设计、测试、维护和更新。如果一项任务一年只执行一两次封装收益可能低于维护成本。4. 高度依赖临场专家判断的任务有些任务缺少统一标准需要专家结合实际情况进行判断。这类任务可以只把相对固定的步骤封装成 Skill将高风险决策保留给人工。5. 模型本身已经能稳定完成的任务创建 Skill 的目的不是为了显得更加专业。如果没有 Skill 时模型已经能够以较低成本稳定完成任务增加 Skill 未必能够带来明显收益。十、测试团队如何落地一个 Skill以“测试用例生成 Skill”为例。第一步明确输入Skill 支持的输入可以包括产品需求文档用户故事原型说明接口文档业务流程文档历史缺陷数据库字段说明。同时也要说明最低输入要求。如果需求信息严重不足Agent 不应该直接生成大量看似完整、实际缺乏依据的测试用例而应该标记待确认问题。第二步固化测试设计流程可以将测试用例设计流程沉淀为理解需求 → 识别角色和业务对象 → 提取功能点 → 拆分业务场景 → 分析状态流转 → 补充正常、异常和边界情况 → 检查权限和数据一致性 → 生成测试用例 → 检查覆盖范围第三步沉淀领域规则以支付业务为例需要特别检查重复支付支付超时回调重复金额篡改订单状态不一致退款和支付并发第三方渠道异常幂等性控制回调签名验证支付成功但业务处理失败。这些内容才是 Skill 真正有价值的部分。“注意异常场景”“注意边界值”属于通用知识真正能够形成企业能力壁垒的是具体业务中的历史故障高频缺陷特殊约束风险规则专家经验。第四步提供输出模板例如字段说明用例编号唯一编号所属模块对应业务模块用例标题描述测试目标优先级P0、P1、P2、P3前置条件执行前需要满足的条件操作步骤可执行的具体步骤预期结果对应的验证结果用例类型正常、异常、边界、权限、兼容性关联需求对应需求编号第五步加入确定性校验可以编写脚本检查是否缺少预期结果用例编号是否重复是否存在重复标题是否覆盖正常和异常场景是否覆盖关键状态输出字段是否符合规范优先级是否符合定义是否遗漏核心业务规则。最终形成一个完整闭环模型负责理解和设计 → 脚本负责格式与规则校验 → 模型根据校验结果修复 → 人工负责高风险业务判断十一、一个高质量 Skill 应该怎样设计1. 从真实任务中提炼不要一开始就让模型凭空生成一套 Skill。更合理的方法是先完成几次真实任务记录哪些步骤每次都会执行哪些信息经常遗漏人工经常纠正哪些问题哪些资料经常需要查阅哪些格式必须统一哪些环节可以脚本化哪些判断必须保留给人工。然后再把已经验证有效的方法沉淀下来。2. 写好 Skill 描述很多 Skill 不是内容写得不好而是没有被正确触发。例如下面的描述过于模糊description: 帮助生成测试内容。Agent 很难判断在什么情况下应该使用。更清晰的描述可以是description: 根据产品需求、用户故事和接口文档生成结构化测试点与测试用例适用于功能测试、接口测试、业务流程测试、回归测试和测试覆盖分析任务。好的描述应该同时说明Skill 可以做什么适用于哪些输入适用于哪些任务可能涉及哪些关键词。3. 主说明文件保持聚焦SKILL.md不应该变成一个巨大的知识库。它应该重点保留Skill 目标输入要求执行流程关键约束常见错误输出要求其他资料的读取条件。大量背景资料应该拆分到独立文件中按需加载。4. 提供默认执行方法如果一个任务有多种工具或者多种实现方式最好在 Skill 中提供默认方案。不要每次都让 Agent 从大量工具中重新选择。例如默认使用 Playwright 执行 Web 自动化移动端任务才使用 Appium接口验证默认使用现有测试框架只有现有框架不支持时才创建临时脚本。这样可以减少不必要的决策和执行差异。5. 加入常见错误清单Skill 最有价值的内容往往不是通用知识而是团队真实踩过的坑。例如## 常见陷阱 - 订单取消后仍可能收到延迟支付回调。 - 支付成功不代表业务订单一定更新成功。 - 退款接口成功只代表受理成功不代表资金已经到账。 - 回调通知必须验证签名并进行幂等处理。 - 支付状态与订单状态可能出现短暂不一致。这些内容来自真实项目经验可以显著提升 Agent 的任务质量。6. 建立“执行—校验—修复”闭环成熟的 Skill 不应该只要求 Agent 生成结果还应该要求它检查和修复。例如执行任务 → 运行校验 → 分析错误 → 修复问题 → 再次校验 → 校验通过后输出通过这种闭环可以降低格式错误和规则遗漏。7. 明确人工介入条件Skill 还需要说明哪些情况下必须停止自动执行并请求人工判断。例如需求存在明显冲突涉及生产数据删除涉及资金和账户操作无法判断业务规则输入资料之间存在矛盾自动化执行可能影响线上环境生成结果缺乏足够证据。Skill 的价值不是取消人工而是明确机器与人的责任边界。十二、Skill 也需要测试和评估创建一个 Skill不代表它已经可以稳定使用。至少需要评估以下几个方面。1. 触发准确性检查应该触发时是否触发不应该触发时是否误触发不同表达方式下能否识别简短任务和复杂任务下表现是否一致多个 Skills 同时匹配时是否选择正确。例如测试用例生成 Skill 应该在下面的请求中触发根据这份需求设计测试用例。但不应该在下面的请求中触发什么是边界值分析法后者只是一个概念解释并不需要执行完整的测试用例生成流程。2. 输出质量检查任务是否真正完成输出是否准确格式是否符合规范是否覆盖关键业务场景是否存在模型编造是否比普通 Prompt 更稳定。3. 执行过程检查是否按照规定步骤执行是否读取了正确资料是否遗漏关键规则是否调用了正确脚本是否跳过校验是否反复执行无意义的操作。4. 执行效率检查是否加载了过多资料是否运行了不必要的工具Token 消耗是否合理执行时间是否可以接受是否频繁调用高成本服务。5. 对照评测可以针对同一组任务分别执行不使用 Skill使用当前 Skill使用旧版本 Skill使用优化后的新版本 Skill。然后对比正确率覆盖率格式一致性运行成本人工修改量执行时间。只有经过对照评测才能判断 Skill 是否真正带来了价值。十三、企业使用 Skill还要关注安全与治理当 Skill 中只有文字说明时它更接近一份操作手册。但当 Skill 可以运行 Shell 命令访问文件系统安装外部依赖调用企业接口修改代码连接数据库执行自动化测试操作生产环境。它就不再只是一个提示词文件而是一种具备执行能力的软件供应链资产。企业落地时需要重点关注以下问题。1. 权限最小化只授予 Skill 完成任务所需要的最低权限。例如测试报告 Skill 不应该拥有生产数据库写权限代码审查 Skill 不应该默认拥有发布权限文档生成 Skill 不应该访问不相关的用户数据。2. 脚本必须经过审查第三方 Skill 中的脚本需要进行代码审查。不能因为它是“AI Skill”就默认认为其中的命令和代码是安全的。需要重点检查是否删除文件是否上传数据是否读取密钥是否下载未知依赖是否执行高风险命令是否访问未经授权的地址。3. 固定依赖版本脚本依赖应尽量锁定版本。否则外部依赖更新后可能导致执行行为发生变化结果无法复现引入新的安全风险原有脚本突然失效。4. 隔离敏感信息不要把以下信息直接写进 Skill 文件账号密码API Key数据库连接密码生产环境凭证用户隐私数据内部敏感配置。敏感信息应该通过专门的密钥管理系统或者运行环境注入。5. 高风险操作增加人工审批涉及以下任务时不应该完全自动执行删除数据修改生产配置发布上线资金操作账号权限变更大批量发送消息导出敏感数据。这些操作需要明确的人工确认节点。6. 像代码一样管理版本Skill 应该具备明确负责人版本号变更记录测试用例审核流程回滚能力权限控制。因为业务规则、工具版本和项目流程都会变化。7. 定期检查是否失效一个长期不维护的 Skill可能会把已经过时的方法稳定地执行下去。例如接口字段已经变化产品流程已经调整工具命令已经废弃安全规范已经更新业务规则已经失效。因此Skill 需要定期进行有效性检查而不是创建完成后永久不动。十四、如何判断一个 Skill 是否值得建设可以使用下面这组问题进行判断这项任务是否高频重复是否已经形成相对稳定的方法是否需要团队统一执行标准是否依赖特定业务知识是否经常需要重复输入很长的 Prompt是否可以通过模板提高输出一致性是否存在可以脚本化的确定性环节是否能够设计测试用例评估效果是否有明确的维护负责人Skill 带来的收益是否高于维护成本如果大部分答案都是“是”这项任务通常适合建设成 Skill。如果多数答案都是“否”直接使用 Prompt、模板或者简单脚本可能更加合适。总结Skill 的本质不是文件夹也不是一段更高级的 Prompt。它真正解决的是如何把人类已经验证过的专业知识、操作流程和工具使用方法沉淀为 AI Agent 可以发现、加载、执行、校验和持续迭代的能力。可以用几句话总结 Skill 与其他概念的关系Prompt告诉模型这一次要做什么Skill告诉 Agent 这一类任务长期应该怎么做Tool提供可以执行的具体动作Workflow组织任务步骤和控制流程MCP提供连接外部数据和工具的标准协议Agent根据目标进行判断组合这些能力完成任务。未来企业使用的大模型可能会越来越相似。真正拉开差距的不一定只是模型参数而是企业能否把自己的业务规则专家经验历史案例操作流程质量标准工具能力。持续沉淀成一套可复用、可评测、可治理的 Agent Skills。从这个角度看Skill 不只是 AI 工具中的一个新功能。它更像是进入 Agent 时代之后企业知识工程、流程工程和软件工程的一次重新组合。本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容侧重测试实践、工具应用与工程经验整理。