关注 霍格沃兹软件测试开发 公众号，回复「资料」, 领取人工智能测试开发技术合集

最近，Skill 正在成为 AI Agent 和 AI Coding 工具中的高频概念。

过去，我们想让大模型按照某种固定方法完成任务，通常会写一段很长的 Prompt：

• 先做什么；

• 再做什么；

• 必须遵守哪些规则；

• 输出什么格式；

• 遇到异常如何处理；

• 可以使用哪些工具。

但当同一套要求需要反复复制、不断补充时，单纯依靠 Prompt 就会出现几个问题：

• 提示词越来越长；

• 每次执行标准不一致；

• 团队经验难以复用；

• 规则修改后需要到处同步；

• 大量无关内容占用上下文。

Skill 正是为解决这类问题而出现的。

它并不是简单地把 Prompt 写得更长，而是把一类任务需要使用的知识、流程、规则、模板和脚本，沉淀成 Agent 可以重复调用的能力包。

本文将从 Skill 的基本概念开始，讲清楚它的工作原理，以及它与 Prompt、Tool、Workflow、MCP 之间的区别，并结合软件测试场景介绍 Skill 的设计、评测和企业落地方法。

阅读目录

1. Skill 到底是什么？

2. Skill 不只是“本地文件夹”

3. 一个标准 Skill 包含什么？

4. Skills 的工作原理：渐进式加载

5. Skills 真的更省 Token 吗？

6. Skill 和 Prompt 有什么区别？

7. Skill、Tool、Workflow 和 MCP 有什么区别？

8. 什么任务适合做成 Skill？

9. 什么任务不适合做成 Skill？

10. 测试团队如何落地一个 Skill？

11. 一个高质量 Skill 应该怎样设计？

12. Skill 也需要测试和评估

13. 企业使用 Skill，还要关注安全与治理

14. 如何判断一个 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：

1. 发现；

2. 正确匹配；

3. 按需加载；

4. 按照说明执行；

5. 调用相应的脚本和工具；

6. 对结果进行检查。

三、一个标准 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 的核心机制不是把所有内容一次性塞给模型，而是渐进式加载，也可以理解为按需加载。

整个过程通常分为三个阶段。

第一阶段：发现 Skill

Agent 开始执行任务时，只需要先知道：

• 当前有哪些 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 的自然语言指令。

两者的主要区别在于生命周期、组织形式和复用方式。

对比维度	Prompt	Skill
主要目标	完成当前一次任务	沉淀一类任务的能力
使用周期	单次或短期使用	长期复用
内容形式	一段任务指令	说明、规则、资料、模板和脚本
触发方式	用户直接输入	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 应用通过一种相对统一的方式，连接外部系统中的数据和工具。

例如：

• GitHub；

• Jira；

• 企业知识库；

• 数据库；

• 浏览器；

• 文件系统；

• 测试平台；

• 监控平台。

它解决的问题是：

Agent 如何通过标准协议访问外部数据和能力？

四者可以组合使用。

例如，一个接口测试 Agent 可以：

1. 使用 Skill 定义接口测试设计方法；

2. 使用 Workflow 编排接口分析、用例生成和执行顺序；

3. 通过 MCP 连接接口管理平台和测试平台；

4. 调用 Tool 执行接口测试；

5. 使用 Skill 中的脚本检查测试结果。

因此，Skill、Tool、Workflow 和 MCP 不是互相替代的关系，而是分别负责方法、动作、流程和连接。

八、什么任务适合做成 Skill？

并不是所有任务都值得创建 Skill。

适合封装成 Skill 的任务，通常具备以下特点。

1. 高频重复

例如：

• 根据需求生成测试用例；

• 分析接口测试场景；

• 执行代码审查；

• 生成测试报告；

• 分析线上故障；

• 按照品牌规范重写文章；

• 执行版本发布检查。

如果一项任务需要反复说明同一套要求，就具备一定的沉淀价值。

2. 已经形成相对成熟的方法

Skill 应该建立在已经跑通的实践之上。

例如，团队已经明确测试用例设计需要经过：

理解需求
→ 提取功能点
→ 拆分业务场景
→ 分析状态流转
→ 补充异常和边界场景
→ 生成测试用例
→ 检查覆盖范围

这样的流程适合沉淀为 Skill。

如果团队自己都没有形成稳定的方法，过早制作 Skill，通常只会把不成熟的流程固定下来。

3. 对输出一致性要求较高

例如，企业测试报告必须包含：

• 测试范围；

• 测试环境；

• 执行结果；

• 缺陷统计；

• 遗留风险；

• 上线建议。

这类任务适合通过模板、规则和脚本提高输出一致性。

4. 单靠一句 Prompt 难以稳定完成

如果每次执行任务都需要补充：

• 内部业务知识；

• 项目特殊规则；

• 输出模板；

• 工具参数；

• 异常处理要求；

• 历史经验。

说明它已经不是一个简单 Prompt 能够稳定解决的问题。

5. 可以拆分成相对完整的能力单元

Skill 的粒度不能太大，也不能太小。

过大的 Skill 可能包含大量无关内容，导致触发不准确。

过小的 Skill 又会导致一个任务需要组合大量能力包，增加执行复杂度。

一个好的 Skill 应该像设计合理的函数：

职责相对单一，但可以独立完成一个有价值的任务单元。

九、什么任务不适合做成 Skill？

1. 一次性的小任务

例如：

帮我把这句话写得更自然一点。

这种任务直接使用 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 时代之后，企业知识工程、流程工程和软件工程的一次重新组合。