Skill蓝皮书2026

Skill蓝⽪书 2026 · v1.1 基于AgentSkillsHub 67,000+真实Skill数据的原⽣研究——不是再写⼀遍Anthropic已经讲过的Skill Spec，是去回答没⼈答过的问题：现在的Skill⽣态⻓什么样、谁活下来了、谁要饿死。 ⽬录 第1章为什么需要Skill：从Mahesh到BarryPart 1 ·基础第2章三层渐进加载：Skill的真正魔法Part 1 ·基础第3章Skill市场全景2026Part 1 ·基础第4章站在Agent⻆度设计Skill：宝⽟四条哲学的活案例Part 2 ·实战第5章迭代优化的闭环：从踩坑到⻜轮Part 2 ·实战第6章9种Skill类型× 4级分享路径Part 2 ·实战第7章五⼤框架的对标与选择Part 3 ·⽣态第8章Skill正在吞噬其他柱⼦Part 3 ·⽣态第9章Distribution：商业化三⻆少的那条边Part 3 ·⽣态第10章Verified Creator：不是花钱买的认证Part 4 · Hub实操第11章咨询撮合+企业⽬录：Service-on-Open怎么跑Part 4 · Hub实操第12章当Claude⾃⼰开始创建SkillsPart 4 · Hub实操 第1章｜为什么需要Skill：从Mahesh到Barry 本章尝试回答⼀个最基础的问题：Skill到底在解决什么？ 有两个答案。⼀个是Anthropic给的——"让Agent从通才变成专家"。这个答案是对的，但只说了⼀半。 另⼀个答案藏在2026年3⽉那个数据拐点⾥——格式化的压⼒⽐能⼒的不⾜更早形成。这⼀章会同时讲这两个。 1.1⼀个让所有⼈停下来的类⽐ 先讲Anthropic官⽅那篇Stop Building Agents, Build Skills⾥的开场类⽐。原⽂很短，我⽤中⽂复述—— 假设你开了⼀家税务事务所，要雇⼀个会计。 候选⼈A叫Mahesh。他是MIT数学博⼠，智商150，记忆⼒极强，任何公式给他⼀眼他就能推导出来。他刚毕业，没做过⼀天会计。 候选⼈B叫Barry。他是社区⼤学学历，30年税务经验，⻅过所有你能想到的客户场景：奇葩发票、跨国税务、政府稽查。他智商不算突出，但每个他遇到过的坑都记得。 你会雇谁？ 答案⼏乎所有⼈都⼀样：Barry。 不是因为Mahesh不够聪明。是因为⼀家事务所需要的是"做过同类事⼀千次的⼈"，不是"理论上应该能做的⼈"。 今天的⼤语⾔模型——Claude、GPT、Gemini——都是Mahesh。它们能在10秒内理解你公司的整个税务代码，能推导出任何公式。但它们每次对话都从零开始——上⼀个客户的案例不会帮它们做好下⼀个客户。 Skill就是给Mahesh配Barry的那本⼩本⼦。 每次开会前翻⼀下"30年经验"——这个客户是S-corp要注意什么、上个⽉IRS发的通知怎么回、客户送的那张模糊发票可能是什么税种。Mahesh还是那个Mahesh，但他现在⼿⾥有Barry的30年。 1.2 Anthropic这个类⽐的隐含假设 Anthropic这个类⽐讲得很美，但它藏了⼀个假设——"经验"可以被写成⽂字，传给下⼀个Mahesh。 这个假设对吗？⼀部分对。 能被写的那部分： "这类发票⼀律按Schedule C处理"——可以写"IRS的Letter 2205是稽查通知"——可以写"客户说'basis'的时候通常指成本基准"——可以写 不能被写的那部分： "这个客户说话吞吞吐吐，肯定有事瞒着"——很难写"这张发票⾦额不对，我闻得出来"——基本不可写"这种案⼦你得先陪客户喝杯咖啡再谈业务"——完全写不了 Barry 30年经验⾥，⼤约60-70%是可写的，剩下的是直觉、⼈情、氛围判断。 但这不是问题。因为现在的Mahesh（也就是⼤模型），连那60-70%可写的经验都没有。把能写的部分先写出来传给它，已经能让它的表现从"天才实习⽣"变成"合格中级"。 这就是Skill的第⼀个⽬标：把60-70%的显式经验，以最⼩摩擦传给下⼀个Agent。 最⼩摩擦的意思是—— 不是让每个⼈都去训练⾃⼰的模型（成本太⾼）不是让每个⼈都写⼀个完整的Agent framework（复杂度太⾼）⽽是写⼀个⽂件夹，扔进~/.claude/skills/，Claude⾃⼰会读 这就是为什么Skill的形式极简——只需要⼀个SKILL.md，带description和instructions。其他都是可选的附件。 Skill的定义：⼀个装着"可写的经验"的⽂件夹，格式简单到任何⼈有电脑就能创建，但标准统⼀到Claude能⾃⼰读懂、⾃⼰决定什么时候⽤。 1.3为什么2026年Q1才爆发 类⽐写于2024年。形式（⽂件夹+ SKILL.md）也不是新东⻄。但Skill⽣态真正爆发是在2026年Q1——单⽉创建27,720个（第3章数据）。 为什么早不爆发、晚不爆发、偏偏是2026年1-3⽉？ 答案不在Skill本身，在Runtime的成熟度。 你会发现，每⼀次之前的"能⼒扩展"尝试——插件、function、MCP——都是技术上⾏得通，但分发⾏不通。 MCP尤其痛——它是个好协议，但要让你装⼀个MCP server，你得： 1.下载源码2.配置环境3.启动⼀个独⽴进程4.把端⼝或stdio配到你的IDE⾥5.重启IDE6.运⽓好的话，⼯作了 Skill的设计是反过来的：1.把SKILL.md扔进~/.claude/skills/2.就完了 这个差异看起来微⼩，实际上决定了⽣态规模。"装⼀个MCP server要6步，装⼀个Skill要1步"——⻔槛低6倍，⽤户基数就⼤10倍以上。 真正的触发点 2025年Q4 Claude Code把skill loading做成⼀等公⺠之后，写⼀个skill和装⼀个skill的摩擦同时被压到0。 然后Cursor、Codex、Windsurf陆续⽀持同⼀个格式——格式化压⼒形成了。所谓格式化压⼒，是指"不管你原本⽤什么⼯具，你的产出都要能在这个格式⾥跑"这种隐性约束。 类似的事情在别的⾏业发⽣过： npm之于Node：2010年后写JS的⼈必须⽣产npm包Docker Hub之于容器：2015年后做基础设施的必须出Docker imageChrome扩展规范之于浏览器：2012年后浏览器插件的事实标准 Skill现在在⾛同⼀条路。2026 Q1的爆发不是偶然，是15个⽉积累之后的相变。 这也解释了为什么这本蓝⽪书写在今天——再早，⽣态太⼩，数据不具代表性；再晚，市场已经分化、赢家已定，讨论没价值。现在是Skill市场最可以被定义的窗⼝。 1.4 Skill跟其他扩展机制的区别 先澄清⼀个常⻅混淆。⼀提到"让AI更聪明"，市⾯上有5种⽅案： Skill跟其他⼏个最⼤的差异是——它承载的是"怎么做"的知识，不是"能做什么"的能⼒。 Tool告诉你"能调weather API"。Skill告诉你"遇到旅⾏计划问题，你应该先问⽤户⽇期，再查天⽓，再组合建议"。MCP给你⼀堆数据库连接。Skill告诉你"查这类客户数据，⽤customer_id⽽不是user_id，因为前者是业务唯⼀键"。System Prompt能让模型记住⼀个⻆⾊。Skill能在每次⽤到特定场景时加载特定指令，其他场景不浪费token。 ⼀句话：Tool/MCP是四肢，Skill是教练笔记。 为什么不把所有东⻄塞进System Prompt 听到这⾥有⼈会问：既然Skill是指令集，为什么不全部塞进System Prompt？ 答案是：上下⽂窗⼝是有限的。 Claude 4.5的上下⽂窗⼝是200K tokens。如果你把50个领域的指令都塞进System Prompt，⼤概消耗30-50K。问题还不只是数量—— 每⼀次⽤户对话，这30-50K都会被重复发送模型在每⼀次推理时，都要"想着"这些指令（即使当前问题跟法律⽆关，它还在浪费注意⼒cycle去考虑法律指令）成本是线性叠加的：你塞越多，每个token都在付费 Skill⽤"三层按需加载"解决了这个问题：默认只加载极轻的元数据（description，⼏⼗字），需要⽤到某个Skill时才展开它的完整指令和附件。 这⼀点是第2章的核⼼。 1.5为什么不⽤RAG 另⼀个常问的问题：RAG不也是"按需加载知识"吗？跟Skill有什么区别？ 区别很⼤： RAG是pull-based——⽤户提问→向量化→检索相似⽂档→把⽂档原⽂拼进prompt给模型看。 Skill是push-based + agent-driven——模型⾃⼰在启动时看到所有Skill的description→根据当前任务主动决定"我要激活哪个Skill"→加载那个Skill的指令。 两个差异： 1.谁决定⽤什么：RAG是系统决定（向量相似度）。Skill是模型决定（语义理解）。模型决定通常更准，因为模型知道⾃⼰真正需要什么。 2.加载的是什么：RAG加载"事实知识"（原⽂段落）。Skill加载"程序性指令"（步骤、约束、规则）。前者是"是什么"，后者是"怎么做"。 打个⽐⽅—— RAG像让员⼯随时查百科全书Skill像让员⼯带⼀本⼯作⼿册 做复杂任务的时候，⼿册⽐百科全书更有⽤。因为⼿册告诉你先做什么、然后做什么、遇到X情况怎么处理。 这也是为什么Skill特别适合Agent——Agent的本质是"在开放任务⾥⾃主决策的程序"，它需要⼿册多于需要百科。 ⼆者可以组合 最强的配置是Skill + RAG组合： Skill告诉Agent"审合同时要检查12个关键条款"其中某条款需要参考公司历史合同时，Agent激活RAG去检索相似合同Agent把RAG的检索结果代⼊Skill的决策框架 这不是假设。花叔的huashu-design（1,416 stars）⾥就有这种设计——Skill提供设计⽅法论+MCP调向量数据库查历史作品。⼀静⼀动。 1.6 Skill的"⽂件夹"隐喻 Anthropic反复强调⼀件事：Skill就是⼀个⽂件夹。不是服务、不是API、不是数据库——是⼀个你能⽤Finder打开的⽂件夹。 这个设计决定是刻意的。⽂件夹的好处： 1.Git能管——版本、diff、回滚、协作全部现成2.Google Drive / iCloud能同步——跨设备共享零成本3.Zip能打包——给同事或客户零成本4.任何⼈都能创建——不需要懂编程，打开⽂本编辑器就⾏5.AI能读——SKILL.md是Markdown，模型天⽣懂 对⽐其他技术形式—— 这不是"让Skill更简单"。是让Skill⽣态能规模化。 复杂度每上⼀档，能⽣产的作者数下降⼀个量级： 会写Markdown的⼈：数亿会写JS并发npm包的：千万级会写完整AI Agent的：百万级会写MCP Server的：⼗万级 Skill选择站在"数亿级"那⼀档。这是为什么Anthropic/skills⼀个官⽅repo能涨到12万stars——因为"我也能写⼀个"这件事是真的，不是营销词。 但⽂件夹也有成本 ⽂件夹的缺点是——没有强制结构。 你想在SKILL.md⾥写什么都可以： 写得太⻓，模型读不完description写得太笼统，模型不知道什么时候⽤它指令之间互相冲突，模型左右为难脚本没测过，Agent执⾏时报错 这就是为什么有"5种设计模式"（第3章会讲）、"Agent视⻆设计"（第4章）、"评估驱动开发"（第5章）——简单的载体需要复杂的⼯艺来填。 Skill⽣态的残酷⻓尾（第3章数据：54% 0 star），本质上就是"⽂件夹⻔槛低，内容⻔槛⾼"的直接体现。 1.7 Skill的野⼼是什么 如果只是"让Mahesh变成Barry"，Skill只是Agent能⼒的⼀个补丁。 但Skill的野⼼远不⽌此。