Skills 渐进式加载原理拆解，Skills原理、实现与应用到最佳范式

从Prompt开始，讲透Skills的原理、实现与应用

你有没有过这种体验？

辛辛苦苦调了一套“代码审查 Prompt”，AI 终于输出得像模像样了。第二天换个项目，又得重头来一遍——复制、删改、调试，搞完发现上次调出来的那个“最优版本”早就不知道散落在哪个聊天记录里了。

这不是你 Prompt 写得不够好。而是你正在用“口头交代”的方式管理一套本该模块化的知识资产。

2025年下半年，Anthropic 干了一件有意思的事：不是发布更大的模型，而是开源了一套叫Agent Skills的能力机制。这个举动本身就是一个信号——大模型工程化的重心，正从“拼模型参数”转向“拼能力组织方式”。

一、Skills 的推导：从“中台思维”到“公共 Prompt”

要理解 Skills 不是什么神秘的新发明，不妨先看一个熟悉的软件工程概念：中台。

中台的核心理念用两个字就能概括——复用。把订单、支付、用户这些公共能力抽离出来做成独立模块，不让每个业务线重复造轮子。

那问题来了：架构可以这样玩，Prompt 为什么不行？

回想一下你的日常 Vibe Coding：同样的代码规范、同样的上线检查清单、同样的“这段 SQL 为什么报错”排查路径，你大概已经重复说过不下十次了。某种意义上，你打字的速度，就是 AI 帮你干活的瓶颈。

于是，一个朴素的动机就浮现了：把那些高频、稳定、可复用的“口头禅”提前封装好，用的时候一键加载。这就是 Skills 的原始雏形——公共的 Prompt 就是 Skills。

沿着这个思路往下走，一个更系统的认知框架就自然成形了：既然软件开发的完整流程（设计→开发→测试→运维）是固定的，那 Skills 也可以按这个框架来归类——设计阶段的 Skills、开发阶段的 Skills、测试阶段的 Skills……分区存放，各司其职。好的经验和方法就能覆盖到软件工程的整个生命周期。

但这只是第一步。真正让 Skills 成为一门“工程学”而非“技巧学”的，是它背后的设计哲学。

二、Skills 的设计哲学：恰好，而非更多2.1 长 Prompt 的“暗成本”

在 Skills 出现之前，想让 AI 按照团队规范干活，最直接的做法就是：把所有规则塞进 System Prompt。

问题是这套做法没法长大。

假设你团队有四套常驻规则——代码规范（1200 Token）、上线 SOP（2000 Token）、安全检查清单（800 Token）、数据库规范（1500 Token）——加起来就是 5500+ Token。注意，这不是一次性成本，是每一轮对话都要付。用户只是随口问一句“这个接口怎么写”，模型也得先把一整本“上线流程手册”吞下去。

更麻烦的是，上下文越长，模型越容易犯一个经典毛病——Lost in the Middle：当信息分布在几千 Token 之间时，模型对中间位置的关注会明显衰减。你精雕细琢的第 7 条安全规则，恰好就落在那个“中间地带”，被悄悄忽略了。

这就是长 Prompt 的“暗成本”：规则明明写了，Token 明明花了，模型却没完全照做。

2.2 答案：渐进式披露

Skills 给出的解法不复杂，但很聪明：不是让 AI 知道更多，而是让它在恰当的时间知道恰当的事。

具体怎么做？分层缓存。模型不是一上来就把所有 Skill 的完整内容吞进上下文，而是分三步走：

这个三步走的核心设计，在 Skills 的术语里叫渐进式披露（Progressive Disclosure）。

• Level 1（元数据层）：模型启动时只加载每个 Skill 的 name 和 description，大约 50 个 Token。模型只看“目录”，知道有哪些技能可用。
• Level 2（核心指令层）：当用户的任务和某个 Skill 的描述匹配时，模型才读取完整的 SKILL.md 正文。
• Level 3（资源层）：脚本、参考文档、模板等重型资源，只有在执行阶段才按需加载。

实测数据显示，在处理长链条业务流程时，这种架构能把上下文 Token 消耗降低 60%-80%，同时显著提升指令遵循准确率。

这套设计带来三个实质性收益：

第一，常驻负担极低。10 个 Skill 的元数据加起来不过 500 Token，跟 10 份完整 SOP 的 20000 Token 相比，差距巨大。

第二，注意力更聚焦。模型只需要读和当前任务强相关的那份 Skill，不会因为信息过载导致 Lost in the Middle。

第三，成本与质量兼得。Skill 里可以引用再多的 references 和 scripts，不触发就不占上下文。这意味着 Skill 的信息密度可以极大，而实际对话成本依然可控。

三、什么是 Skill——以及它不是什么3.1 一句话定义

Skill 不是模型微调，不是新工具，不是某个神秘的插件机制。

它本质上就是一份自然语言写成的操作手册，以文件夹为单位组织，核心文件是 SKILL.md。里面写着：什么场景触发我、触发之后按什么顺序做、输出长什么样。模型会在相关任务命中后按需加载它。

但仅仅知道定义还不够。到了真正落地的时候，大家最容易混淆的往往不是“Skill 是什么”，而是“它和 Prompt、MCP、Function Calling 分别管什么”。

3.2 Skill、Prompt、MCP、Function Calling 的分工

这四个词经常一起出现，也最容易被当成一回事。拆开来看其实很清楚：

Prompt：表达当前这次请求的意图。适合承载“这次要做什么”“补充要求”，不适合长期背着一整套稳定流程。

Function Calling：定义工具调用的规范——工具叫什么、参数怎么传、返回什么格式。解决的是“调用格式”问题，不负责流程逻辑。

MCP（Model Context Protocol）：解决连通性问题。把数据库、文件系统、监控平台以统一协议接给模型。负责“能做什么”，不负责“按什么顺序做”。

Skills：把团队经验和领域知识组织成可执行流程。负责“怎么做”和“按什么标准做”。

换个更生活化的说法——

• Prompt= 你给同事下达的当前任务
• Function Calling= 告诉同事“这个工具长什么样、参数怎么填”
• MCP= 办公室里统一的插座标准，让你能随时插上打印机、投影仪
• Skills= 团队沉淀下来的操作手册

它们不是替代关系，是分工关系。MCP 负责“接进来”，Skills 负责“组织起来”。一个强大的 Agent = 通用模型 + MCP 连接外部工具 + Skills 提供操作流程。

3.3 与“长 Prompt 文件”的根本区别

有人会说：“这不就是把 Prompt 存成 Markdown 文件嘛？”表象接近，但机制有本质不同。

传统的 Prompt 文件每次对话都要全量加载，不管这次任务用不用得上。而 Skills 的分层设计决定了：不相关的技能只占一行元数据。更重要的是，Skills 允许你在正文中引用独立的 references/ 文件夹和 scripts/ 脚本——这些重型资源不触发就不进上下文，但一旦需要，信息密度远超你手工能写进 Prompt 的任何东西。

这意味着你可以把一份 Skill 做成“SOP 大礼包”：SKILL.md 写执行流程，references/ 放规范细节，scripts/ 放确定性计算任务。模型按需层层展开，而不是一上来就吞下全部。

四、一次 Skill 调用的完整链路

很多人第一次接触 Skills，会下意识觉得：“我建了 10 个 Skill，模型就多了 10 个工具。”实际上不是这么回事。

下面是一条典型的 Skill 调用链路（不同产品细节可能有差异，但核心逻辑趋同）：

整个过程的核心在于：模型先知道“有什么”，再决定“要不要用”，最后才去读“具体怎么做”。真正占上下文的大块内容，是触发之后才进入视野的。

这也是为什么 Skills 比“无限堆 Prompt”更适合工程化——它不是把 Prompt 写得更长，而是把那套长期稳定、需要跨项目复用的东西从每次对话里拆出来，做成一个随时能按需调用的独立模块。

五、如何写出一个真正可用的 Skill

知道原理只是第一步。动手写的时候，最容易踩的坑是——把 SKILL.md 写成 README：先讲背景、再讲历史、再写安装说明，最后才提一丁点执行要求。

对人友好，对模型低效。

SKILL.md 最重要的任务只有两个：什么场景用我 + 用我时怎么做。

5.1 description 决定触发效果

模型能不能正确触发一个 Skill，很大程度上看 description 写得怎么样。

差的写法：

description: 分析系统日志。

这个描述过于宽泛，什么“分析”、“什么系统”、“什么日志”都没说清，误触发率会很高。

好的写法：

description: 诊断 SpringBoot 生产环境的运行时异常，包括解析 Java 堆栈、定位 OOM、分析接口超时和 Full GC 问题。当用户粘贴错误日志，或提到“系统报错”“接口超时”“频繁 Full GC”时触发。

好的描述至少回答三件事：处理什么问题、用户大概会怎么说、不处理哪些泛化场景。最后这一点尤其重要——很多 Skill 的问题不是“不够强”，而是边界没写清，什么活都想接，输出反而变得不稳定。

5.2 正文聚焦规则，而非常识

模型已经知道什么叫“代码审查”，但不知道你们团队的特殊要求——先看安全还是先看性能？支付逻辑要不要单独标记？输出用 H2、表格还是分级清单？

这些东西，才是 Skill 里最值钱的部分。

正文应该直接写：执行顺序、优先级、必须检查的点、输出格式。不用铺垫。

5.3 确定性操作交给脚本

凡是容易出错又需要确定性的操作——时间格式转换、格式校验、特定 API 调用——统统交给 scripts/。

在 SKILL.md 里写一句“如果需要校验配置格式，执行 scripts/validate_config.py，基于结果继续分析”就够。模型负责理解场景和组织流程，脚本负责算那些不该模糊处理的东西。

5.4 写出“不适用场景”比写背景更重要

正文末尾补一小段“什么情况下不要用这个 Skill”，往往比多写一页背景介绍更能提升稳定性——日志不完整时不直接下结论、涉及生产删改时先要求确认、纯概念解释类问题不触发排障 Skill。

边界清晰，输出才稳定。

六、什么样的任务值得做成 Skill

不是所有事都值得单独封装。

适合做成 Skill 的场景：你已经重复解释过 3 次以上、流程边界稳定、你希望跨项目复用、你希望团队成员的 AI 都遵守同一套标准。代码审查规范、SQL 排障流程、发布前检查清单、故障复盘模板——这类长期稳定、高频重复的流程，最适合沉淀为 Skill。

不适合的场景：一次性任务、变化频繁的规则、模型本来就能轻松完成的简单小事、维护成本比复用收益还高的事。

好用的 Skill 是怎么来的？不是设计出来的，是“痛”出来的。因为一个让人头疼的问题反复出现，你才会花精力去总结流程、提炼规则、固化脚本。也正是因为它是从真实痛苦中长出来的，这个 Skill 才经得起实际检验。舒适区里设计出来的 Skill，往往看起来很美，用起来泛泛。

七、一个最小可用的 Skill 示例

如果你现在就想动手，这是最小能跑的版本：

---name: code-reviewerdescription: 对后端代码进行结构化 Code Review，重点检查安全风险、逻辑错误和可维护性问题。当用户要求 review 代码、检查代码质量、分析潜在 bug 时触发。## 审查顺序1. 先检查安全问题2. 再检查逻辑正确性3. 最后检查可维护性和可读性## 必查项### P0：安全问题- SQL 拼接- 密钥硬编码- 未鉴权接口### P1：逻辑问题- 空指针风险- 并发安全问题- 边界条件缺失### P2：质量问题- 函数过长- 重复逻辑- 命名含混## 输出格式每个问题按以下格式输出：- 严重级别- 问题描述- 原因- 修改建议

这个版本并不复杂，但已经具备基本的实用性。往下迭代，可以补上 references/ 放详细规范，scripts/ 放格式校验，以及几个示例输入输出帮助模型稳定产出你想要的格式。

写完别急着宣布“可用”，更稳的做法是找 5 到 10 个真实任务做回放，重点看三件事：该触发时有没有触发、不该触发时有没有误触发、输出是否稳定遵守了顺序和格式。

如果总是误触发，说明 description 写得过泛；如果总是触发不出来，说明用户说法覆盖得不够全；如果已触发但执行不稳，往往是正文里的顺序、边界或脚本调用条件还不够明确。

至于用哪个工具来做 Skills——如果你是个人开发者想快速上手，Claude Code 提供了原生的 Skill 管理能力，Cursor 也支持 @skill 语法直接调用，都是零门槛起步的好选择。企业级场景下再考虑通过 Agent SDK 接入 API 做二次封装。

八、不止是工具，更是可迁移的知识资产

如果你把 Skills 只当成“省 Token 的技巧”，就低估了它的真正分量。

在 Skills 出现之前，经验几乎无法低成本复用。张三年初调通的那条 SQL 排障逻辑，即便沉淀成了文档，等李四年中遇到类似问题，大概率还得自己从头走一遍。

但 Skills 时代不一样了。因为 AI 能直接“理解”并执行自然语言写成的流程，任何一个能用文字描述的经验，都可以做成一份 Skill，跨项目、跨团队、甚至跨公司复用。

这才是 Skills 最深远的影响：让团队知识第一次有机会像代码一样，被模块化、被版本化、被共享、被迭代。

这同时也带出了一个更根本的启示——在 AI 时代，系统设计正在从面向人转向面向 AI。一份数据，既要有给人看的好懂版本，也要有给 AI 直接调用的结构化版本。这两件事同等重要。

九、Skills 的生态已经不只是 Anthropic 一个人的事

说个时间线你可能会有感觉——

2025年10月16日，Anthropic 在 Claude Code 中首次推出 Agent Skills，最初只是编码场景的实验性功能。

2025年12月18日，Anthropic 将 Agent Skills 以开放标准的形式正式发布。

接下来 48 小时内，Microsoft 和 OpenAI 先后宣布跟进支持。

到了 2025 年底，OpenAI Codex 已支持通过 $.skill-name 语法直接调用 Skills，或让模型根据 prompt 自主选择合适的 Skill。GitHub Copilot 也正式将 Skills 集成到其 Agent 能力中。Cursor、Codebuddy 等主流 IDE 工具也陆续提供原生支持。

2026年初，Anthropic 发布了 30 多页的《Skill 创建指南》，系统讲解如何设计能力模块。这不是简单的 API 更新说明，而是一份工程体系化的设计手册。当模型厂商开始教开发者“如何设计能力单元”，说明一个趋势已经形成：大模型能力正在进入结构化阶段。

这也意味着，Skill 正在从某个工具里的配置技巧，逐步变成可迁移的工作流资产。今天你在 Claude Code 里建的 Skill，明天换到 Cursor 或 GitHub Copilot 上，大概率也能直接用。

十、第一步从哪里开始？

不必一上来就做“全能 Skill”。更好的起点很朴素：选一件你上个月已经重复说过 3 次以上的事。

比如“帮我按团队标准做 Code Review”“上线前帮我过一遍检查清单”“遇到 SQL 慢查询时按固定步骤排查”。

然后先做最小版本——新建文件夹、放一个 SKILL.md、写清楚 name 和 description、把执行顺序和输出格式写进去。先别追求大而全。一个能稳定触发、稳定输出的窄 Skill，比一个边界模糊的万能 Skill 有价值得多。

如果你一时不知道从哪入手，也可以反过来操作——下次用 AI 解决完一个问题之后，别急着关对话框，加一句：“请你把我刚才这段对话里隐含的工作流程总结成一个 Skill。”让 Agent 自己帮你完成第一轮归纳。

选好切入点之后，一个实用的梳理框架是：实体、流程、规则三步走。

先想清楚这个场景涉及哪些“实体”（数据库表结构？文件目录？配置项？）；再梳理正常流程是什么、异常路径怎么处理；最后落成具体规则——先做什么、优先级怎么排、输出按什么格式。问清楚这三个问题再动手写 SKILL.md，会比你直接上去码字高效得多。在 Claude Code 里，你还可以用内置的 skill-creator 直接生成模板骨架，几行命令搞定框架搭建，把精力集中在规则定义上。

写完之后的验证也很关键。用过去积累的几个真实 case 跑一遍，观察每次是否按预期触发、输出结构是否一致、边缘情况是否被覆盖。跑不过去的地方就是 SKILL.md 里还需要加强的地方。如果你习惯用 VS Code 或 Cursor，直接在项目根目录创建 .skills/ 文件夹，把 SKILL.md 放进去，@skill-name 语法即可调用，和日常工作流无缝衔接。

结语

如果你已经开始觉得 Prompt 越写越长、越写越累，那多半不是你不会写 Prompt，而是你已经走到了该把一部分知识从 Prompt 里拆出来的阶段。

Skills 的意义不止是省一点 Token。它更重要的价值在于：让团队知识第一次有机会像代码一样，被模块化、被版本化、被共享、被迭代。

当第一个 Skill 真正稳定运行起来，你会明显感觉到：自己优化的已经不再只是某一句提示词，而是在搭建一套能够持续沉淀、持续复用的 AI 工作方法。