Skill简单学习

发布时间：2026/7/22 8:38:59

1. 什么是 Skill？

Skill（技能）是赋予智能体（Agent）特定领域知识和执行能力的“可移植软件包”。它将多步骤的复杂任务转化为可重复、可审核的标准化工作流。通过 Skill，智能体不仅能“聊天”，还能像专业人士一样稳定交付结果。与传统 Prompt 最大的区别在于：Prompt 是对话级的一次性指令，而 Skill 是可复用的、按需加载的知识资产——可以理解为「给AI新员工准备的入职手册」。

2. Skill 的核心结构

一个标准的 Skill 通常是一个包含SKILL.md文件的目录，并可选择性地包含资源子目录：

my-skill/ ├── SKILL.md # [核心] 包含前置元数据与执行指令 ├── references/ # [可选] 参考文档、政策说明等（按需加载） ├── assets/ # [可选] 模板、静态资源 └── scripts/ # [可选] 智能体可执行的辅助脚本（如 Python/Shell）

SKILL.md 编写规范

SKILL.md由 YAML 前置元数据和 Markdown 正文组成：

---name:my-skill-name# 必填：全小写、含连字符（kebab-case），最多64字符description:>-# 必填：描述技能作用及触发场景，最多1024字符当用户需要处理XX任务时触发。包含关键词：XX、XX。---

Markdown 正文建议包含：

角色定位：明确智能体在执行该任务时的专家身份。
触发条件：明确何时使用该技能。
执行步骤：分步骤说明智能体应做什么（类似SOP）。
预期输出：定义交付物的格式与标准。
边界与约束：明确禁止的操作或负面约束。

3. 如何高效使用 Skill

智能体采用**渐进式披露（Progressive Disclosure）**机制来管理上下文：

Level 1 宣告：启动时系统提示中仅注入技能名称和描述（约100 tokens）。
Level 2 加载：任务匹配时，智能体调用load_skill读取完整指令（通常 < 5000 tokens）。
Level 3 读取资源：按需调用read_skill_resource获取补充文档（几乎无上限）。
Level 4 运行脚本：按需调用run_skill_script执行代码，仅将执行结果返回给对话，代码本身不占用上下文。

最佳实践：保持SKILL.md在 500 行以内，将冗长内容拆分至references/目录，避免拖慢加载速度。

4. 完善与迭代 Skill 的最佳实践

打造生产级 Skill 并非一蹴而就，需要遵循工程化迭代路径：

4.1 评测驱动（Evals-driven）

不要盲目叠加规则。每次修改后，应通过基准测试或 A/B 对比验证：当前 Skill 是否真正比“无 Skill 基线”表现更好？若评测未通过，优先简化 Skill。

4.2 真实场景校准（上岗培训）

在实际使用中持续观察，并执行“三步测试法”：

历史案例回放：拿出过去真实的任务让 Skill 重新生成，比对人工产出。
边界试探：故意给刁钻输入（如字段为空、超长文件），测试其是瞎编还是按规则主动提问。
同行评议：让其他同事加载该 Skill 跑同样任务，暴露“你自己习惯了但别人受不了”的隐性知识。

4.3 安全与风控合规

上线前必须完成合规清单检查：

内容安全：设置输入过滤与输出审核，拦截违禁词与恶意代码。
数据安全：对用户隐私数据进行脱敏，确保会话日志定时清理。
业务风控：配置单用户 Token 上限与调用频次限制，防止滥用。

4.4 版本控制与生命周期管理

Skill 天然适合 Git 管理。建议为每个 Skill 建立独立仓库或在 Monorepo 中独立管理，通过 Code Review 保证质量，并使用 Tag 进行版本发布。任何一次项目规范、架构的变更，必须同步更新关联 Skill 的参考资料，防止 Skill 沦为“技术债务”。

5. 进阶：构建“Skill 流”与复杂编排

当单个 Skill 无法满足复杂业务时，需要将多个原子 Skill 串联成“Skill 流”（Skill Flow）：

5.1 什么是 Skill 流？

Skill 流是指若干 Skill 之间有明确配合关系的组合。例如内容创作场景可拆分为：

调研 Skill：收集主题资料。
写作 Skill：根据资料生成文章。
配图 Skill：为文章生成插图。
发布 Skill：排版并推送到指定平台。

5.2 编排优势

易于维护：某个环节改需求，只需调整对应 Skill，无需重构整个流程。
可复用性：同一个“调研 Skill”既可服务于写文章，也可用于做 PPT 或视频脚本。
灵活迭代：可逐个替换为“更强版本”的 Skill，而不影响整体链路。

6. 避坑指南：新手最常犯的四个错误

企图用一个 Skill 统治所有场景：千万别追求“大而全”。拆分成多个职责单一的 Skill，准确度远超“全能神”。
提示词堆砌无害的废话：“你是一个经验丰富的、细心的、负责的……”这种形容词除了浪费 token 毫无意义。把每一句话都换成可执行的指令，规则要细到可以无脑执行，一律用“必须”、“严禁”。
把 Skill 当成黑盒：如果产出不对，一定要打开看它引用了你给的哪条资料，推理链在哪里断了，然后去改手册，而不是反复生成碰运气。
忽略了调度描述：YAML 头里的 description 是给 AI 调度器看的索引。描述必须准确到场景，例如：“当用户要求审查或评审 Java 代码片段/PR 时使用”，而不是笼统的“帮做事情”。

7. 未来演进方向

多 Skills 智能编排：智能体将像指挥乐队一样，协调多个 Skill 处理跨领域复杂任务。
跨模态能力：Skill 将突破文本限制，支持图像识别、音视频处理。
自主生成与进化：智能体在试错中提炼元 Skill（目前仍处于早期探索阶段）。
自修复机制：基于在线反馈自动优化 Skill 结构，精简冗余内容。

8. 高阶最佳实践：打造生产级 Skill 的底层逻辑

要让 Skill 从“能用”跨越到“好用且稳定”，不仅需要清晰的文档结构，更需要掌握与 AI 模型协同工作的底层逻辑。以下是经过实战检验的核心最佳实践：

8.1 描述（Description）的精准触发机制

description字段是智能体决策是否加载该 Skill 的唯一索引。描述过于模糊会导致 Skill 永远不被触发，或在不该触发时被误触发。

包含具体触发词：不要只写“处理 Figma 相关任务”，而应写明“当用户要求导出 Figma 设计、生成设计规格或进行设计交接时触发”。
说明独特价值：明确该 Skill 与其他相似 Skill 的边界，让调度器能够精准匹配用户意图。

8.2 脚本优先原则（确定性优先）

大语言模型擅长创造性任务，但在处理精确计算、格式转换或数据清洗时容易产生“幻觉”。

核心逻辑：能用脚本处理的，绝不让 AI 凭空生成。例如，生成复杂的 Excel 报表时，应编写 Python 脚本（放入scripts/目录）让 AI 调用执行，而不是让 AI 尝试直接输出二进制格式或复杂的表格代码。
职责分离：将“思考与编排”交给 AI，将“确定性执行”交给代码。

8.3 保持专注与单一职责

一个 Skill 应该只解决一个明确的痛点。

拒绝“全能神”：不要试图把“爬虫 + 数据清洗 + 报表生成 + 邮件发送”塞进同一个 Skill。这会导致指令过长、上下文超载、匹配精度大幅下降。
原子化拆分：将其拆分为web-scraper、data-cleaner、report-generator等多个独立的 Skill。在需要时，智能体会自动组合多个原子 Skill 来完成复杂任务。

8.4 掌握高级工作流编排模式

对于复杂的业务场景，可以在 SKILL.md 中内置以下高级编排逻辑：

顺序编排与回滚机制：多步骤任务中，不仅要明确每一步的依赖关系，还必须包含回滚指令（Rollback instructions）。例如：“如果第四步（创建订阅）失败，必须撤销前三步创建的账户，并清理残留数据。”
迭代精炼模式：对于报告生成等任务，不要指望一次成型。设定“草稿生成 -> 脚本验证 -> 针对性修改”的循环，并必须设置停止条件（如：验证脚本通过、达到最大迭代次数），防止 AI 陷入无限修改的死循环。
上下文感知与降级方案：当面临多种工具或路径选择时，提供清晰的决策树。同时，必须为 AI 没见过的边缘场景提供“降级方案”（如：默认走最通用的选项），而不是直接报错。

8.5 合规前置与审计追溯

在金融、医疗等强监管领域，Skill 的能力不仅是“能做到”，还包括“做到的方式符合规范”。

强制约束内置：将合规检查（如制裁名单核对、禁忌症排查）作为前置步骤硬编码到工作流中，而不是事后追加。
操作留痕：要求智能体在执行关键操作时，必须记录结构化的审计日志，确保全流程可追溯。

8.6 评测驱动与持续迭代闭环

Skill 的完善是一个工程化过程，而非一劳永逸的文案编写。

从真实任务中抽象：初次创建时，先让 AI 直接执行真实任务，引导 AI 复盘成功步骤与失败点，再由 AI 生成 SKILL.md 初稿。
评测用例强绑定：每次新增规则，都必须对应新增评测用例。若评测未通过，优先简化 Skill 而非盲目叠加规则。
真实场景校准：在实际使用中，持续观察模型是否在非预期场景下误触发、是否遗漏关键参考文件，并将这些异常信号转化为新的评测用例，形成迭代闭环。

9. 最佳实践案例解析

理论需要结合实战才能发挥威力。以下是三个经过真实业务场景验证的 Skill 设计案例，展示了如何将最佳实践落地：

案例一：脚本优先原则（确定性任务）

场景：用户经常要求将杂乱的 CSV 数据清洗并转换为标准的 JSON 格式。
错误做法：在 SKILL.md 中写一大段提示词，让 AI 自己“心算”转换逻辑并直接输出 JSON。AI 经常因为数据量大而截断输出，或者在格式上出现语法错误。
最佳实践：

职责分离：AI 只负责理解用户的清洗需求（如：去除空行、重命名字段），不负责执行转换。
引入脚本：在scripts/目录下提供一个csv_to_json.py脚本。
SKILL.md 指令：“当用户要求转换数据时，先提取清洗规则，然后调用run_skill_script('csv_to_json.py', args)执行转换。如果脚本报错，将错误日志反馈给用户并询问是否调整参数。”
效果：输出 100% 准确，彻底杜绝了 AI 的“幻觉”和格式错误。

案例二：单一职责与渐进式披露（复杂任务）

场景：开发一个“前端代码审查”技能。
错误做法：把 React 规范、TypeScript 规范、无障碍（a11y）标准、性能优化指南全部塞进一个长达 2000 行的 SKILL.md。导致 AI 每次只审查一小段代码，也要加载全部规范，不仅 Token 消耗巨大，AI 还容易“抓不住重点”。
最佳实践：

原子化拆分：将大技能拆分为react-review、ts-review、a11y-review三个独立 Skill。
渐进式披露：在 SKILL.md 的正文中，不直接写明具体的代码规范，而是写：“在审查 React 组件时，必须先使用read_skill_resource('references/react-best-practices.md')加载规范，然后对照规范逐行检查。”
效果：AI 的“短期记忆”保持清爽，只在需要时查阅对应的“小抄”，审查深度和准确率大幅提升。

案例三：精准的 Description 触发机制（防误触）

场景：团队内部有一个专门用于“生成数据库 SQL 迁移脚本”的 Skill。
错误做法：Description 写成description: 用于处理数据库和 SQL 相关任务。结果用户只是随口问了一句“MySQL 的索引原理是什么”，AI 也强行触发了这个 Skill，试图生成一个迁移脚本，导致答非所问。
最佳实践：

黄金结构公式：[核心功能] + [具体执行动作] + [明确的触发关键词/场景]。
优化后的 Description：生成数据库迁移脚本。当用户明确要求生成、创建或更新 SQL 迁移文件（如 Flyway/Liquibase 脚本），或提到‘数据库结构变更’、‘生成 migration’时使用。不适用于解答 SQL 语法或数据库原理问题。
效果：AI 的路由机制变得极其精准，该触发时绝不漏掉，不该触发时绝不打扰。