很多团队在把大模型接进工作流时，最开始都会走同一条路：
把规则、流程、注意事项、格式要求，统一塞进 System Prompt。
刚开始，这种做法往往很有效。
任务简单的时候，模型像一个认真听话的实习生。你告诉它“按这个格式回答”、“别忘了检查安全问题”、“提交前先跑测试”，它大概率也能照做。
但只要任务复杂度上来，问题就会出现：
* Prompt 越写越长，成本越来越高
* 规则越堆越多，模型越容易漏掉重点
* 同样一套流程，换个项目还得重新抄一遍
* 团队里每个人都在重复“喂规则”
很多人以为这是 Prompt 写得还不够好。
其实未必如此。问题在于：**把本该“模块化管理”的东西，硬塞进了每次都要重复携带的上下文里。**
问题已经不只是“提示词优化”，而是“知识组织方式”出了问题。
而 Skills，正是在解决这个问题。
## 从一个例子说起
假设你想让 AI 帮你做代码审查。最朴素的做法，是把规则全塞进 Prompt：
`你是资深后端工程师。请按以下标准审查代码：1. 检查 SQL 注入风险2. 检查空指针问题3. 检查并发安全4. 输出时按严重程度分类5. 对涉及支付逻辑的代码单独标注6. 所有建议都要包含修改方向…`
如果团队里还叠加了数据库规范、接口规范、上线流程、异常处理约束，Prompt 很快就会膨胀成几千 Token 的混合体。
问题就在这里：代码审查只是当前任务，但你却把一整套长期稳定的规范，都绑进了这次对话。
真正该单独管理的，不是“这次要 review 什么代码”，而是“团队平时怎么 review 代码”。
Skills 处理的正是后一件事。它不是把 Prompt 再写长一点，而是把那套长期有效的规则，从对话里拆出来，单独做成一份可调用的说明。
放到这个例子里，就是：
* 平时只保留一个叫`code-reviewer`的 Skill 入口
* 用户真的说“帮我 review 这段代码”时
* 再去加载`code-reviewer`的完整说明
Prompt 管当前这次请求，Skill 管那本专业手册。
这两个东西可以配合，但不该混成一团。
本文后面都在回答：哪些东西该写进 Prompt，哪些东西更适合拆成 Skill。
## 一、长 Prompt 的问题出在哪里
把所有规则塞进 Prompt，刚开始确实省事。但这套做法很难随着任务复杂度一起扩展。
### 1. 重复成本持续累积
假设一个团队有这些常驻规则：
* 代码规范：1200 Token
* 上线 SOP：2000 Token
* 安全检查清单：800 Token
* 数据库访问规范：1500 Token
* 接口设计约束：1000 Token
加起来就是 6500+ 的 Token 了，而且这不是一次性成本，而是**每轮对话都会重复支付**。
用户只是问一句“这个 SQL 为什么报错”，模型也要先吞下一整套上线流程和安全清单。这显然并不经济。
### 2. 上下文变长后更容易丢失重点
长上下文还有一个经典问题：`Lost in the Middle`。
简单说就是，当上下文很长时，模型对中间部分的关注会明显下降。你最精心写的第 7 条规范，很可能恰好在“中间地带”，于是被悄悄忽略。
最后就会出现：
* 规则明明写了
* 成本明明花了
* 但模型还是没完全照做
### 3. 复用与维护成本偏高
还有一个容易被低估的问题：Prompt 非常容易“跟着项目散落”。
今天你在 A 项目里调出一套很好的代码审查 Prompt，明天换到 B 项目，又得重新复制、删减、改词。
长此以往，团队里会出现很多相似但不完全一致的 Prompt 版本。谁也说不清到底哪个才是“标准版”。
Prompt 当然重要，但它更适合承载当前这次请求的意图，不适合长期背着一整套稳定流程往前跑。
问题自然就冒出来了：如果这些长期稳定的规则不该一直塞在 Prompt 里，那它们该放在哪里？
## 二、什么是 Skill
先说一个直观的定义：
> **一份按需调取的专业操作手册。**
平时它不占多少上下文，相关任务出现时，模型再把它拿出来看。
更正式一点说，**Skill 是用自然语言写成的领域指令包，通常存放在`SKILL.md`中，模型会在相关任务出现时按需加载它。**
但这里有一个很重要的边界要先说清：**Skill 并不是脱离 Prompt 独立存在的“新能力”**。从原理上看，它仍然属于上下文工程的一部分，只是被产品或框架做成了**可发现、可复用、按需加载**的模块化资产。
也就是说，Skill 不是在替代 Prompt，而是在把原本容易散落在聊天框里的那部分长期规则，重新组织成更适合工程化管理的形态。
但只知道这个定义还不够。到了真正落地的时候，大家最容易混淆的往往不是“Skill 是什么”，而是“它和 Prompt、MCP、Function Calling 分别在管什么”。
### 1. 本质：一份面向模型的操作说明
Skill 不是模型微调，不是新工具，也不是某个神秘的插件机制。
它是一组面向模型的工作说明：
* 遇到什么情况该用它
* 用它时按什么顺序做
* 中间要调用哪些工具
* 输出最好长什么样
### 2. 特点：按需加载
模型启动时，并不会把每个 Skill 的完整正文都塞进上下文里。通常只会先知道：
* 这个 Skill 叫什么
* 它大概处理什么问题
等任务真的命中后，才去读取完整内容。
这很像一本手册的目录页。你不需要先把整本书背下来，只需要知道哪一章在讲什么，用到时再翻过去。
### 3. 适用范围：承载稳定的领域知识
Skill 特别适合承载这几类知识：
* 经常重复
* 边界比较稳定
* 需要明确流程
* 希望团队共享
比如：
* 代码审查规范
* SQL 排障流程
* 发布前检查清单
* 故障复盘模板
* 数据抽取与清洗 SOP
本质上，Skill 就是在把团队里的隐性经验，写成 AI 也能照着执行的说明书。
## 三、Skill、Prompt、MCP 的分工关系
这几个词经常一起出现，也最容易被混为一谈。拆开来看就清楚了：
* Prompt：表达这次想做什么
* Function Calling：让模型按格式调用工具
* MCP：把外部系统统一接进来
* Skills：把流程和领域知识组织起来
换个更生活化的说法：
* Prompt 像你在给同事下达当前任务
* Function Calling 像告诉他“工具长什么样、参数怎么填”
* MCP 像统一的接口标准，负责把数据库、文件、API 接进来
* Skills 像团队内部沉淀下来的操作手册
它们不是替代关系，而是分工关系。
### Prompt：承载当前请求
用户说“帮我 review 这段代码”，这句话本身就是 Prompt。
但 Prompt 更适合承载：
* 当前任务
* 当前上下文
* 当前补充要求
它不太适合承载：
* 一大坨长期稳定的规范
* 需要跨项目复用的流程
* 团队级共享的专业知识
### Function Calling：定义工具调用
Function Calling 解决的是工具调用问题。
它关心的是：
* 工具叫什么
* 参数怎么传
* 返回什么格式
比如读取文件、执行 Shell、查询数据库，本质上都属于这一层。
### MCP：连接外部系统
MCP 解决的是连通性问题。
它有点像 AI 世界里的 USB-C。
有了它，数据库、文档系统、监控平台、设计工具都可以用统一协议接给模型。
但 MCP 并不负责告诉模型：
* 什么时候查数据库
* 什么时候去看日志
* 查完之后应该如何组织分析
### Skills：组织流程与规则
它补上的不是“连接能力”，而是“执行逻辑”。 简单说，MCP 负责把工具接进来，Skills 负责把这些工具组织成可执行的流程。这也是为什么很多团队会同时需要 MCP 和 Skills，而不是二选一。
把位置摆清楚之后，再回头看底层机制，很多看上去反直觉的地方就容易理解了。比如：为什么 Skill 不是“多一个工具”，为什么它能节省上下文，为什么它适合承载团队规则。
* * *
## 四、一次 Skill 调用的典型链路
很多人第一次接触 Skills，会下意识觉得：“我建了 10 个 Skill，模型就多了 10 个工具。” 实际上，主流实现通常不是这么工作的。
不同产品实现细节不完全一样，但主流思路很接近。下面这条链路更适合把它理解成一种**常见实现模式**，而不是所有产品都完全一致的固定规范。
### 第一步：发现可用 Skill
Agent 启动时，通常会去扫描约定目录，比如：
* `.claude/skills/`
* `.agents/skills/`
* `.github/skills/`
这些目录只是不同产品或社区实现里常见的例子，并不是一套已经完全统一的标准。它通常会先读`SKILL.md`里的元数据，比如`name`和`description`。
### 第二步：向模型暴露 Skill 元数据
模型不一定会直接看到每个 Skill 的完整正文。
更常见的是，它先拿到一份轻量级目录：
* `code-reviewer`：用于代码审查
* `slow-query-analyzer`：用于分析慢查询
* `deploy-checklist`：用于上线前检查
也就是说，模型先知道“有什么”，再决定“要不要用”。
### 第三步：模型判断是否触发
比如用户说：
> 帮我 review 一下这段代码。
模型会发现这句话和`code-reviewer`的描述高度相关，于是主动请求这个 Skill。
### 第四步：框架读取 Skill 正文
直到这一步，框架才会真正去读`code-reviewer/SKILL.md`的正文。
换句话说，真正占上下文的大块内容，是在触发之后才被带进来的。
### 第五步：模型按规则继续执行任务
到了这一步，模型才真正拿到那本“专业手册”，然后按 Skill 里的要求去做：
* 先看安全问题
* 再看逻辑问题
* 最后按约定格式输出
所以 Skills 最关键的收益，不是“多一个入口”，而是这件事：
> **把原本需要常驻的大段知识，改成触发后再进入上下文。**
这也是它为什么比“无限堆 Prompt”更适合工程化。
理解原理是一回事，但落地时更实际的问题是：知道它怎么工作之后，`SKILL.md`到底该怎么写，才不至于落成一份模型难以顺畅执行的 README。
## 五、如何写出一个真正可用的 Skill
很多人第一次写 Skill 时，很容易把它写成 README：
* 先讲一大段背景
* 再讲项目历史
* 再写安装说明
* 最后才提一点执行要求
这对人类读者或许友好，但对模型来说并不高效。`SKILL.md`最重要的任务不是“介绍你是谁”，而是：
> **告诉模型：什么时候该用我，用我时应该怎么做。**
决定效果的，主要就是下面这几件事。
### 1.`description`决定触发效果
模型能不能正确触发一个 Skill，很大程度上看`description`写得好不好。
坏的写法：
`description:分析系统日志。`
这个描述过于宽泛。
好的写法：
`description:诊断SpringBoot生产环境的运行时异常，包括解析Java堆栈、定位OOM、分析接口超时和FullGC问题。当用户粘贴错误日志，或提到“系统报错”“接口超时”“频繁FullGC”时触发。`
好的描述至少回答了三件事：
* 它处理什么问题
* 用户可能会怎么说
* 它不打算处理哪些泛化场景
最后这一点尤其重要。很多 Skill 的问题不在于“不够强”，而在于“边界没有写清”，结果是什么都想接，触发率看起来提高了，实际输出却变得不稳定。
### 2. 正文应聚焦规则，而非常识
正文最该写的，不是模型已经知道的“常识”，而是这个场景下它**必须遵守的约束**。
比如：
* 先检查什么，再检查什么
* 哪类问题优先级最高
* 哪些场景必须单独标记
* 输出按什么格式组织
模型一般已经知道什么叫代码审查，但它不知道：
* 你们团队先看安全还是先看性能
* 你们对支付逻辑是不是要提高等级
* 你们希望输出按 H2、表格还是分级清单
这些东西，才是 Skill 里最值钱的部分。
如果想再往前走一步，正文里最好补上一小段：**什么情况下不要使用这个 Skill**。
比如：
* 日志不完整时，不直接下结论
* 涉及生产删改操作时，先要求用户确认
* 纯概念解释类问题，不触发排障 Skill
这一段不必很长，但往往比多写一页背景介绍更能提升稳定性。
### 3. 确定性操作应交给脚本
凡是既容易出错、又需要确定性的操作，最好交给脚本。
比如：
* 时间格式转换
* 复杂数据提取
* 固定格式校验
* 某个 API 的严格调用方式
在 Skill 里，可以这样写：
> 如果需要校验配置格式，执行`scripts/validate_config.py`，并基于结果继续分析。
模型负责理解场景和组织流程，脚本负责做那些不该模糊处理的事。
这些原则单独看都不复杂，但如果只停留在原则层面，仍然会显得不够具体。更好的办法，还是直接看一个最小例子，把它落到一份真实的`SKILL.md`上。
## 六、一个最小可用的 Skill 示例
如果前面的讨论仍然有些抽象，直接看一个最小例子会更直观。
假设你想给团队做一个“代码审查 Skill”，最小版本可以长这样：
`—name: code-reviewerdescription: 对后端代码进行结构化 Code Review，重点检查安全风险、 逻辑错误和可维护性问题。当用户要求 review 代码、检查代码质量、 分析潜在 bug 时触发。—## 审查顺序1. 先检查安全问题2. 再检查逻辑正确性3. 最后检查可维护性和可读性## 必查项### P0：安全问题- SQL 拼接- 密钥硬编码- 未鉴权接口### P1：逻辑问题- 空指针风险- 并发安全问题- 边界条件缺失### P2：质量问题- 函数过长- 重复逻辑- 命名含混## 输出格式每个问题按以下格式输出：- 严重级别- 问题描述- 原因- 修改建议`
这个版本并不复杂，但已经具备基本的实用性：
第一，用户不需要每次都重复说“按什么标准 review”。
第二，团队里的 AI 输出会比“纯自由发挥”稳定得多。
往下再做，可以补这些东西：
* `references/`：放详细规范
* `scripts/`：放确定性脚本
* 示例输入输出：帮助模型更稳定地产生你想要的格式
讲到这里，就可以进一步追问：既然 Skill 可以这样写，那什么样的事情值得专门做成 Skill，什么样的事情其实没有必要？
## 七、什么样的任务值得做成 Skill
但也不是所有事情都值得单独做成 Skill。
### 适合沉淀为 Skill 的场景
* 你已经重复解释过 3 次以上
* 这套流程边界相对稳定
* 你希望跨项目复用
* 你希望团队成员的 AI 都遵守同一套标准
比如：
* Code Review
* 上线检查
* 故障排查
* PR 描述生成
* 数据报表处理 SOP
### 不适合专门做成 Skill 的场景
* 一次性任务
* 变化非常频繁的规则
* 模型本来就能轻松完成的小事
* 维护成本比复用收益还高的东西
归根到底：
> **重复、稳定、可复用的流程，最适合做成 Skill。**
* * *
## 八、团队协作场景下的几个关键问题
一旦 Skill 从个人提效工具变成团队通用资产，问题就不只是触发率了，至少还要看这三件事。
### 1. 多个 Skill 如何协作
真实工作流通常不是一个 Skill 就能搞定的。
比如一个需求开发流程，可能会涉及：
* 读取需求单
* 生成接口文档
* 生成代码
* 做 Code Review
* 生成 PR 描述
这时通常要在两种做法之间作出选择：
* 让模型自动决定串联哪些 Skill
* 还是在某个“主 Skill”里显式规定顺序
前者更灵活，后者更可控。
### 2. 上下文窗口仍然有限
Skills 解决的是“不要一开始把所有东西都塞进去”，但不代表上下文无限大。
如果一次对话连续触发很多长 Skill，它们的正文仍然会不断累积在消息历史里。
所以依然要注意：
* 单个 Skill 不要过长
* 重资料拆到`references/`
* 超长流程适当分阶段对话
### 3. 安全边界需要提前明确
Skill 本质上是在影响 AI 的行为。
下面这些事，必须格外谨慎：
* 不要把密钥、密码、凭证写进 Skill
* 破坏性操作要明确要求“执行前确认”
* 对不适用的场景要写清楚，减少误触发
越是要在团队里共享，越要把这些边界提前写清楚。
* * *
## 九、Skills 正在走向开放标准
到 2026 年初，Agent Skills 已经不只是某个单一产品里的小技巧，而是在朝着更开放、更可迁移的方向演进。
公开支持或兼容的产品，已经包括：
* Anthropic Claude / Claude Code / Agent SDK
* OpenAI Codex
* Cursor
* GitHub Copilot
* 一些社区实现与开源项目
这背后最值得注意的变化是：**Skill 正在从“某个工具里的配置技巧”，变成“可迁移的工作流资产”。**
不过这里也需要说得更严谨一点：现阶段更准确的表述是，**大家在理念上越来越趋同，但目录约定、元数据字段、触发方式、工具集成方式仍然存在差异**。因此，它正在走向开放生态，但还不能简单理解成“所有产品已经完全兼容同一套 Skill 标准”。
这和普通 Prompt 最大的不同就在这里。
Prompt 常常散落在聊天框里、配置里、个人笔记里。
而 Skill 更像一个真正可以被管理、共享、版本化的模块。
从团队视角看，这件事比省多少 Token 更重要。
因为它意味着：
* 团队规范可以沉淀
* AI 行为可以趋于一致
* 知识可以随着项目持续迭代
如果你认同这套思路，接下来更实际的问题就是：第一步该从哪里下手？
* * *
## 十、第一个 Skill 应该从哪里开始
如果你现在准备动手，不必一上来就做“全能 Skill”。更好的起点往往很朴素：
**选一件你上个月已经重复说过 3 次以上的事。**
比如：
* “帮我按团队标准做 Code Review”
* “上线前帮我过一遍检查清单”
* “遇到 SQL 慢查询时，按固定步骤排查”
然后先做一个最小版本：
1. 新建一个文件夹
2. 放一个`SKILL.md`
3. 写清楚`name`
4. 写清楚`description`
5. 把执行顺序和输出格式写进去
先别追求大而全。一个能稳定触发、稳定输出的窄 Skill，通常比一个边界模糊的万能 Skill 更有价值。
写完以后，也不必急着宣布“这个 Skill 已经可用了”。更稳妥的做法是，用 5 到 10 个真实任务做一次回放，重点看三件事：
* 该触发的时候有没有触发
* 不该触发的时候会不会误触发
* 输出是否稳定遵守了你写下的顺序和格式
如果一个 Skill 总是误触发，通常说明`description`写得过泛；如果总是触发不出来，通常说明用户说法覆盖得还不够全；如果已经触发但执行不稳，往往是正文里的顺序、边界或脚本调用条件还不够明确。
* * *
## 写在最后
前面一路讲下来，其实都在回答同一个问题：为什么有些规则不该继续硬塞在 Prompt 里。
如果一定要用一句话概括 Skills 的意义，我会这样说：
> 它不是 Prompt 的补丁，而是把团队知识从“临时喂给模型”，变成“按需调用的模块”。
过去很多人优化 AI 的方式，往往都是继续往 Prompt 里加东西：补规则、补格式、补边界、补例外。
但当你真的把 AI 接进日常工作流，迟早都会碰到同一个问题：规则越来越多，Prompt 越来越长，维护越来越累，输出却不一定越来越稳。
到这一步，真正该升级的已经不只是 Prompt 技巧，而是规则本身的组织方式。
看起来只是上下文管理方式变了，背后带来的却是另一套工程结果：
* 更低的常驻上下文负担
* 更强的流程复用能力
* 更容易共享的团队规范
* 更稳定的 AI 执行表现
如果你已经开始觉得 Prompt 越写越长、越写越累，那多半不是你不会写 Prompt，而是你已经走到了该把一部分知识从 Prompt 里拆出来的阶段。
Skill 的意义当然不只是省一点 Token。它更重要的价值在于：**让团队知识第一次有机会像代码一样，被模块化、被版本化、被共享、被迭代。**
当第一个 Skill 真正稳定运行起来，你会明显感觉到：自己优化的已经不再只是某一句提示词，而是在搭建一套能够持续沉淀、持续复用的 AI 工作方法。
