很多团队在把大模型接进工作流时，最开始都会走同一条路：
把规则、流程、注意事项、格式要求，统一塞进 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-reviewer
description: 对后端代码进行结构化 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 慢查询时，按固定步骤排查”
然后先做一个最小版本：
新建一个文件夹 放一个 SKILL.md写清楚 name写清楚 description把执行顺序和输出格式写进去
先别追求大而全。一个能稳定触发、稳定输出的窄 Skill，通常比一个边界模糊的万能 Skill 更有价值。
写完以后，也不必急着宣布“这个 Skill 已经可用了”。更稳妥的做法是，用 5 到 10 个真实任务做一次回放，重点看三件事：
该触发的时候有没有触发 不该触发的时候会不会误触发 输出是否稳定遵守了你写下的顺序和格式
如果一个 Skill 总是误触发，通常说明 description 写得过泛；如果总是触发不出来，通常说明用户说法覆盖得还不够全；如果已经触发但执行不稳，往往是正文里的顺序、边界或脚本调用条件还不够明确。
写在最后
前面一路讲下来，其实都在回答同一个问题：为什么有些规则不该继续硬塞在 Prompt 里。
如果一定要用一句话概括 Skills 的意义，我会这样说：
它不是 Prompt 的补丁，而是把团队知识从“临时喂给模型”，变成“按需调用的模块”。
过去很多人优化 AI 的方式，往往都是继续往 Prompt 里加东西：补规则、补格式、补边界、补例外。
但当你真的把 AI 接进日常工作流，迟早都会碰到同一个问题：规则越来越多，Prompt 越来越长，维护越来越累，输出却不一定越来越稳。
到这一步，真正该升级的已经不只是 Prompt 技巧，而是规则本身的组织方式。
看起来只是上下文管理方式变了，背后带来的却是另一套工程结果：
更低的常驻上下文负担 更强的流程复用能力 更容易共享的团队规范 更稳定的 AI 执行表现
如果你已经开始觉得 Prompt 越写越长、越写越累，那多半不是你不会写 Prompt，而是你已经走到了该把一部分知识从 Prompt 里拆出来的阶段。
Skill 的意义当然不只是省一点 Token。它更重要的价值在于：让团队知识第一次有机会像代码一样，被模块化、被版本化、被共享、被迭代。
当第一个 Skill 真正稳定运行起来，你会明显感觉到：自己优化的已经不再只是某一句提示词，而是在搭建一套能够持续沉淀、持续复用的 AI 工作方法。
