为什么需要 Skills 这个东西

用 Claude Code 或者 Cursor 写了一段时间代码的人大概都有同一种感受：模型本身没问题，它的通用能力常常让人惊讶，但一旦要它按公司内部的流程办事——比如按团队的 commit 规范写一条 commit message、按特定的 PPT 模板出一份项目周报、按财务系统的字段填一份报销单，它就突然变回一个刚入职三天的实习生。它不是不会写，而是不知道这边是怎么干这件事的。

这个"懂通用能力但不懂组织上下文"的鸿沟，就是 Anthropic 在 2025 年 10 月开始填的坑。他们给出的答案叫 Agent Skills。

时间线

2025 年 10 月 16 日：Skills 诞生

Anthropic 工程博客发了一篇标题直白的文章，《Equipping agents for the real world with Agent Skills》，署名 Barry Zhang、Keith Lazuka、Mahesh Murag。文末附了一句"who all really like folders"，几乎算得上这个项目的精神原型。

文章把 Skill 定义得很朴素：一个 Skill 就是一个文件夹，里面有一个 SKILL.md，外加可选的脚本、参考文档和资源文件。SKILL.md 开头是一段 YAML frontmatter，至少要有 name 和 description 两个字段。agent 启动时会把所有已安装 Skill 的 name 和 description 预加载进系统提示词，判断哪个任务该触发哪个 Skill。

这个设计的灵魂是渐进式披露（Progressive Disclosure），分三级：

  • 第一层是 metadata。所有 Skill 的 name + description 常驻上下文，模型需要的只是一份目录，知道有哪些能力可选。
  • 第二层是 SKILL.md 正文。命中某个 Skill 时才读进来，理想长度 500 行以内。
  • 第三层是 bundle 进来的其他文件（references/、scripts/、assets/）。只在真正需要的时候按需加载，脚本甚至可以直接执行而不用先读进上下文。

官方举的例子是 PDF Skill。Claude 本身很会读 PDF，但不太会填 PDF 表单。填表的细节逻辑放在单独的 forms.md 里，Claude 只有在真要填表时才去读。抽取表单字段这种确定性操作则写成一个 Python 脚本放进 scripts/，Claude 直接执行就行，比让模型用 token 一个字段一个字段对着 PDF 抠要便宜得多。

同一篇文章里还埋了一句话：

Looking further ahead, we hope to enable agents to create, edit, and evaluate Skills on their own.

这句话后来兑现了一半，就是下面要讲的 skill-creator。

2025 年 12 月 18 日：Skills 升级为开放标准

时隔两个月，Anthropic 把 Agent Skills 升级为开放标准，规范站点 agentskills.io 上线。Skills 从一个 Claude 产品的内部机制，变成了一个跨平台的文件格式标准。

Simon Willison 在 当天的博客 里给了一个挺精准的概括：这个规范小得可以几分钟读完，且有意留白。比如 metadata 字段直接写"客户端可以用来存储规范未定义的其他属性"，allowed-tools 字段被明确标记为 experimental。主页上打出来的采用方名单有 OpenCode、Cursor、Amp、Letta、goose、GitHub、VS Code，一天之后 OpenAI Codex 也加了进去。

这家公司一年里先是把 MCP 做成了事实标准，接着又把 Skills 做成了事实标准，在刻意扮演行业基础设施制定者的角色，而不是把这些东西攥在手里做护城河。

2026 年 3 月 3 日：skill-creator 的重做

真正让 Skills 好用起来的那一脚是半年后踢的。2026 年 3 月，Anthropic 更新了官方的 skill-creator，也就是那个"帮你写 Skill 的 Skill"，并发了一篇标题明确的博客《Improving skill-creator: Test, measure, and refine Agent Skills》。因为这一版变化幅度够大，社区直接把它叫做 Claude Skills 2.0。

这一版没有再造新概念，只解决了一个具体的老问题：Skill 写出来以后，过去几乎没有办法判断它到底有没有起作用。常见场景是这样的：写一个 Skill，随便跑两个 prompt 试试，觉得差不多就收工了。几周后模型小版本更新，或者自己改了两行 SKILL.md，某天突然发现输出变差，但很难定位是哪一步引入的回归，因为根本没有 baseline。

新版 skill-creator 把软件工程那套东西搬了进来，加了三件事。

2026 版 skill-creator 到底改了什么

Eval：从凭感觉到能对比

写完 Skill 草稿以后，skill-creator 会主动让作者凑 2~5 个真实的测试 prompt，然后对每个 prompt 同时跑两份，一份加载了当前 Skill，一份裸跑 Claude。跑完之后脚本会把结果聚合成一个 benchmark（pass rate、耗时、token 消耗，带上均值和标准差），再打开一个浏览器里的 eval viewer 左右对照地展示两份输出。

这里有一个关键细节：baseline 的选择是自动切换的。创建新 Skill 时 baseline 是不加载任何 Skill 的裸 Claude；迭代已有 Skill 时，skill-creator 会先把旧版本快照到 skill-snapshot/ 里，然后用旧版本当 baseline。这样每次迭代都能看到"比上一版进步了多少"，而不是只跟裸模型比。

assertion 是可选的。文件转换、数据抽取、固定流程的代码生成这种有确定答案的任务适合写断言；写作风格、设计这种主观任务就不必强上断言，直接让人看输出即可。官方源码里还埋了一条建议：能用脚本验证的就写脚本而不是肉眼看，脚本可以跨 iteration 复用，比人眼可靠。

Blind A/B：让另一个 Claude 当裁判

这是给要求更严的用户准备的。比如改了一版 Skill，想知道新版是不是"真的更好"而不是"我觉得更好"，skill-creator 可以把两份输出隐去来源，交给一个独立的 Claude 实例评判，让它自己挑出赢家并给出理由。

这个机制在实践里可以用来对比四种组合：有 Skill vs 没 Skill、旧版 vs 新版、两个做同一件事的不同 Skill、同一个 Skill 在两个不同模型上。它依赖 subagents，所以目前只在 Claude Code 和 Cowork 里可用，Claude.ai 没有。

Description Optimization：用 train/test split 防止过拟合

这一块是我觉得最见功力的地方。

Skill 描述这件事有个长期被低估的事实：描述写得不好的时候，Skill 的逻辑照样在，但模型根本不会触发它。触发机制完全走 description 字段，模型只看那段描述决定要不要激活。Anthropic 自己在文章里承认，Claude 天然有一种"低触发倾向"——即使 Skill 对当前任务明显有用，它也经常跳过不用。所以 skill-creator 里反复强调 description 要写得有点推力。

2026 年这版 skill-creator 把 description 调优做成了自动循环。先让 Claude 生成 20 条真实风格的 prompt，一半应该触发、一半不应该触发。"不应该触发"的那些是故意写得有迷惑性的，关键词沾边但其实要干的不是一回事。用户在浏览器里审阅这份 prompt 集，可以改、可以删、可以加。

20 条 prompt 会被切成 60% 训练集 + 40% 保留测试集。用的是机器学习里经典的 train/test split，目的就是防止描述过拟合到训练 prompt 上。对当前描述在训练集上跑的时候，为了对抗模型行为的随机性，每条 prompt 跑 3 次，2/3 以上命中才算触发成功。然后看哪些该触发没触发、哪些不该触发却触发了，让 Claude 基于失败样本写一个新版本的描述。最多迭代 5 轮，每轮都能看到之前所有版本，并被明确告知不要和前面几版重复，逼着它尝试实质不同的写法。

最后选 winner 的时候，用的是测试集分数而不是训练集分数。这一条是整个流程里最关键的防过拟合设计。训练集分数最高的那个版本，可能只是把训练 prompt 记住了，未必能泛化。

Anthropic 在自家 6 个内置文档类 Skill 上跑了这个优化循环，其中 5 个的触发率都有改善。description 这种看起来很"软"的东西居然能用 ML 手法来系统优化，工作量和回报的比值相当划算。

最新的 Skill 构建方法论

把 2026 年这版 skill-creator 源码（GitHub 仓库 anthropics/skills）和官方 best practices 文档 结合起来看，已经能提炼出一套相对稳定的方法论。

SKILL.md 不是容器，是目录

新手最常见的毛病是把所有知识往 SKILL.md 里塞，写出一个 2000 行的巨无霸，然后奇怪 Claude 为什么调用得这么慢。500 行是一个被反复提到的上限，官方 best practices 给的是"5000 单词以内"的更宽松说法，两个口径差不多等价。

真正的写法是把 SKILL.md 当目录用：

  • 主流程、判断分支、写作风格这些每次都要看的东西放在 SKILL.md 本体
  • API 文档、长案例、扩展语法这些只在某些分支才用到的东西放 references/*.md，从 SKILL.md 里按需指向
  • 确定性计算、文件操作、格式验证这些代码能做得更准的放 scripts/
  • 输出要用到的模板、字体、图片放 assets/

当 Skill 要支持多个变体，比如一个 cloud-deploy Skill 同时覆盖 AWS、GCP、Azure，就按变体拆分 reference 文件，SKILL.md 只负责选型逻辑。Claude 只读它真正需要的那个 reference，剩下的根本不进上下文。

Description 写"什么时候该触发"，不写"它能做什么"

这是一个在各种教程里被反复强调、但依然最容易写错的字段。

本地那份 writing-skills 的 SKILL 文档里记了一个踩坑经验：如果在 description 里概述了 Skill 的工作流程，Claude 可能直接按 description 里的概述执行，而不去读 Skill 正文。原话是一个代码审查 Skill，description 里写了"进行代码审查"，结果 Claude 做了一次审查，但 Skill 正文里写的是分阶段的两次审查。等把 description 改成纯粹的触发条件（“当执行带独立任务的实施计划时使用”），不再描述流程，Claude 反而老老实实读 Skill 正文，按正文的流程走了两次审查。

背后的逻辑其实简单：description 是工作流的捷径，当它能独立工作时，模型就不再读正文了。所以写 description 有个反直觉的纪律：描述触发条件，不要描述流程。官方公式是：

What it does + Use when [trigger phrases] + Key capabilities

写完描述后用 skill-creator 的 description optimization 跑一轮，能把触发准确率再往上拉一截。

Eval-driven：把软件工程的那套抓过来用

这是 2026 版 skill-creator 真正在推的范式转变。核心动作不是"评估 Skill"，而是把评估作为默认开发环节。完整的循环长这样：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
写 SKILL.md 草稿
  ↓
整理 2~5 条真实 prompt 进 evals/evals.json
  ↓
同一回合内并发跑 with-skill 和 baseline 两套
  ↓
启动 eval-viewer，人对着 diff 留反馈
  ↓
读 feedback.json，做下一轮修改
  ↓
新建 iteration-N+1/ 目录，重跑
  ↓
直到反馈都为空或者用户满意
  ↓
（可选）跑 description optimization
  ↓
打包成 .skill 文件交付

每一轮的结果（输出、timing、grading、benchmark）都落在 <skill-name>-workspace/iteration-<N>/eval-<ID>/ 下，可追溯、可对比。下一轮带上 --previous-workspace 参数跑时，viewer 里能看到每个 case 的上一版输出和上一版反馈。这种对照关系让迭代感非常像打磨代码，而不是修改文档。

举几个具体场景能看清这套循环到底在干嘛。Anthropic 官方在博客里展示过 pptx 生成 Skill 的迭代：第一版让 Claude 生成 PPT，标题字号和正文字号经常打架，表格里列宽也常常塞不下最长的那条数据。他们把"生成一份包含三栏对比表的销售周报"这类 prompt 放进 evals，跑完之后 viewer 里左边是旧版本输出的 PPT 截图、右边是新版本，人一眼就能看出来是不是真的改好了。改到第三轮，作者才发现字号问题不该在 prompt 里用文字描述解，而是应该在 scripts/ 里写一个 autofit_table.py，用 python-pptx 拿到实际列宽自动调整——这就是后面"跨测试用例发现通用脚本"那节要展开的意思。再比如 brand-guidelines Skill 的迭代，一开始作者靠肉眼看输出是否符合品牌色，后来发现同一套测试 prompt 跑五次会给出五种不同的"几乎符合"，干脆把 assertion 写成一个脚本：抽取生成图里的主色做 Delta E 比对，超过阈值就判失败。脚本一写，benchmark 就从"主观打分"变成了"可以每版自动跑的回归测试"。

这套循环另一个更隐蔽的用途是抓模型升级带来的 regression。同一个 Skill 在 Claude 小版本升级后行为常常悄悄漂移：以前 100% 命中的触发词可能降到 80%，以前会按步骤跑两轮审查的现在只跑一轮。如果没有 benchmark 留档，这种偏移几乎不可能被注意到，因为每一次输出看起来都还是"差不多能用"。有了上一版本快照做 baseline、有一组固定的 eval prompt 在手，换模型的第一天就能直接重跑一遍，哪些 case 退化了、退化在哪一步，在 viewer 里一目了然。这也是为什么 Anthropic 把旧版本自动快照这件事做成默认行为——它把"跨模型回归测试"从一个需要专门建设的能力变成了免费午餐。

社区复现这套循环时，最常见的误区是把"评估"理解成"打分"。skill-creator 源码里的 grading 其实只是副产品，主产品是那份带 diff 的 viewer：一条 prompt 的两版输出并排放着，能让作者在 30 秒内判断"这一版是不是朝着期望的方向走"，比任何总分都直观。真正成熟的用法是一天里迭代五六次，每一次都快速扫一眼 viewer，留一两条具体反馈（比如"第 3 条 case 生成的 docx 里列宽还是不够"），然后让 skill-creator 基于反馈自动生成下一版 SKILL.md。打磨 Skill 的节奏从此跟打磨代码高度相似：小步改、跑测试、看 diff、再小步改。

改进时不要过拟合到几个测试用例上

这是 skill-creator 源码里最意味深长的一段（来自 Improving the skill 部分，我翻译并略作转述）：

我们在写的是要被用一百万次甚至更多的 Skill。你和用户反复在几个例子上迭代，只是因为这样推进得快，用户对这几个例子门儿清，评估起来也快。但如果这个 Skill 只在这几个例子上好使，那它就没用。与其往里加一堆细抠小细节的修正，或者堆一大坨压迫性的 MUST，不如跳出来试试不同的隐喻、不同的工作模式。反正试一次很便宜。

再往下还有一条：

如果你发现自己在写全大写的 ALWAYS 或 NEVER、或者非常僵化的结构，这就是一个黄牌信号。如果可能，换成解释原因的措辞，让模型理解为什么这件事重要。今天的 LLM 是聪明的，它们有不错的心智理论能力，给一个好的 harness，它们能超越死记硬背，真正把事情做成。

这段话值得展开讲。全大写的 ALWAYS / NEVER / YOU MUST 看起来像是在加强约束，实际效果和作者的预期几乎是反的。至少有三个层面的问题。

一个层面是它是早期模型的历史遗产，在新模型上会过度触发。2023 年那会儿 GPT-3.5 指令遵循弱，温和的 “please follow this rule” 它常常就当没看见，用户只好写 YOU MUST NEVER EVER OUTPUT JSON OUTSIDE THE TAGS 来吼一嗓子，这才有响应。到 Claude 4.5/4.6、GPT-5 这一代，模型已经能读出"语气"。Anthropic 自己的 prompting best practices 里给了一条明确建议：过去写 “CRITICAL: You MUST use this tool when…”，现在直接写 “Use this tool when…” 就可以了。Gabriel Anhaia 在 一篇 2026 年的实证对比 里同样观察到，上一代为了对抗"欠触发"而设计的吼叫式 prompt，在 Claude Opus 4.5/4.6 上会变成"过度触发"——模型把敌意语气当成敌意上下文，反而更容易拒答、更容易刻板复述规则、更容易在输出里原样回吐一遍那条 NEVER。社区有一个挺形象的说法叫 compliance theater（合规戏）：模型不是在照规则做事，是在表演自己看到了规则。

另一个层面是僵化的命令式措辞会遮蔽它自己要保护的意图。最典型的场景是例外处理。你写 NEVER call the production API without a dry-run，听起来很严密，但如果某一类任务本来就没有 dry-run 接口、或者正在跑的就是 dry-run 校验的测试流水线，模型面对这条规则要么硬套（去调一个不存在的 dry-run 接口），要么干脆跳过整个流程以示"遵守"。反过来，如果你写的是 Prefer to dry-run first so we can surface schema mismatches before touching prod data; if no dry-run exists, print the intended payload and ask the user to confirm，原因和兜底都讲清楚了，模型在遇到你没想到的情况时自己会对齐。Anthropic 官方 skill-creator 源码里给出的反例就是这一类：ALWAYS use tool X 在工具 X 暂时不可用时会把任务锁死，而 Use X because it gives structured output; if X fails, fall back to Y and note the degradation 就能让模型在维持你本意的前提下继续工作。

还有一个很容易忽略的层面是它会让 description 和 SKILL.md 正文打架。这篇文章前面提到过作者自己踩的那个坑：一个代码审查 Skill，description 只写了一句"进行代码审查"，正文里却写了"分两轮审查"，结果 Claude 按 description 的概述跑了一轮就停了。ALWAYS / NEVER 往往也是这样被注入的——作者在 SKILL.md 开头塞一块 YOU MUST ALWAYS... 的大写块，本意是"我这里特别重要你要看完"，但因为它读起来像一个自洽的小闭包，模型反而真的把它当结论用了，底下正文那套更细的流程根本没被读进来。换成 Why two-pass review matters: first pass catches correctness, second pass catches style consistency. See below for the full protocol. 之后，模型才会老老实实往下读。

所以这条"黄牌信号"的本意不是"不许严厉"，而是：严厉不是靠字号和标点实现的，是靠把"为什么严厉"讲清楚实现的。Skill 的写法应该更像写给一个新同事的 onboarding 文档，解释清楚"为什么"，然后信任对方的判断力；而不是写给一个只会执行规则的机器，恨不得把每一种可能的走神都用大写锁死。真正需要机器级强制的约束（比如"不要把生产数据库密码写进日志"），也不该押在 prompt 上，而是在执行层做下游校验——prompt 从来不是合同的执行引擎。

跨测试用例发现通用脚本

还有一个很好用的经验法则：跑完 eval 以后读每个 subagent 的 transcript，看它们是不是都独立写了类似的辅助脚本。如果 3 个测试 case 的 subagent 都分别写了一个 create_docx.py 或 build_chart.py，这就是个非常强的信号，这段代码应该被抽出来放进 Skill 的 scripts/ 里，写一次，以后每次调用直接用。这种模式可以省掉大量"每次重新发明轮子"的开销，对于高频被调用的 Skill 尤其明显。

Skill 太多会把上下文窗口撑爆，怎么办

半年下来，我一直有一个挥之不去的不安感：Skill 越写越多之后，每次会话一开始上下文就先被一大堆 description 占掉了。这件事不是错觉。

Anthropic 的官方口径给了这个问题一个名字——progressive disclosure 的第一层。每个 Skill 的 YAML frontmatter（主要就是 name + description）会在会话初始化时一股脑进系统提示词，让 Claude 能看到"我手头有哪些能力"。官方的参考数字是每个 Skill 大概 100 token（name 几个 token，description 一到两句话）。按 Claude 200k 上下文窗口算，100 个 Skill 也就是 10k token，占 5%；500 个约 50k，占 25%；到 1500 个左右会把上下文打穿。这套设计的卖点就是"只加载名字和描述，正文按需拉取"，看起来很性感。

但真实使用里有两个事情会让这个理论数字变得不好看。

一个是 Skill 经常和其他全局上下文抢坑。Claude Code 用户的 session 里还有 CLAUDE.md、custom agents、subagent 定义、MCP tools——它们都是"进会话就常驻"的。2026 年 2 月社区在 anthropics/claude-code 仓库开了 issue #22613，标题直接就叫《Feature request: lazy-load agent descriptions and skill names to reduce context usage》。作者测过一个典型重度用户的配置：13 个 GSD agents 在描述里吃掉约 5000 token，27 个 gsd:* skill 再吃 800 token，其他自定义 agent 再加 1000 token，加上 CLAUDE.md，一次空会话起手就 20%+ 上下文已经没了，还没说一句话。

另一个是实测里的感知比理论数字更糟。一位叫 bswen 的开发者 在 2026 年 3 月写过一篇实测：他装了 45 个 Skill，首次响应延迟从 3 秒飙到 8 秒，多文件操作反复撞上下文上限。他清到 15 个之后，首次响应回到 3 秒，复杂任务不再中途失忆。社区里跟他呼应的另一条高赞 Reddit 评论说得更直白：“that startup scan at 100 tokens per skill kills you if you install more than 30.”

所以 20~50 这个经验上限不是拍脑袋的，它大致对应 2~5k token 的 startup 开销——这个量级用户基本感知不到；超过 50 以后感知会迅速非线性恶化，不仅仅是多吃了 token，更重要的是剩下的可用上下文在真正写代码时会频繁告急。

你那个"让模型决定何时加载"的构想，确实是业界正在走的方向

你的不安感是对的，这也不是你一个人的疑惑。这个问题在社区里有一个通用说法叫 skill context bloat（技能上下文膨胀），围绕它已经形成了几条比较清晰的思考路径。你提到的"预先告知本次项目会用到的 Skill 范围、但什么时候进上下文由模型决定"，几乎是其中最主流那一条的翻版。

现在正在被讨论或实际落地的方案大致有三类，按侵入程度从低到高排：

第一类：项目级 scope（已经可用）。 Claude Code 支持在项目根目录放一个 .claude/ 目录，里面只装这个项目需要的 Skill，以及在 CLAUDE.md / .claude/config.json 里显式声明启用/禁用清单。全局 ~/.claude/skills/ 里放"日常驾驶员级"的通用 Skill（代码审查、commit 规范之类），项目目录里放领域专属 Skill（某框架的脚手架、某业务的模板）。这已经是你构想的一部分——提前告知"这个项目要用哪些"，让进入这个项目时 description 池子就只有这一批。好处是立刻就能用，代价是完全依赖人来划定范围，如果项目很大或者跨域，仍然会遇到池子本身就膨胀的问题。

第二类：lazy-load description（feature request 阶段）。 Issue #22613 里提的方案是最贴近你原话的：系统提示词里只注入 Skill 的名字（或者一个极短的 tag 列表，比如 pptx, docx, pdf, brand, ...），description 正文不进。模型在判断要不要用某个 Skill 时，先发一个"看一下这个 Skill 的 description"的内部调用再读进来。等价于给 progressive disclosure 再加了一层——从"两级"变成"三级甚至四级"：纯名字 → description → SKILL.md 正文 → bundle 资源。这正好对应你说的"由模型决定什么时候加载进来"。这个 issue 当时被 Anthropic 关了（没给明确时间表），但同样的诉求在 OpenCode、Cursor 的 Skills 实现里以类似形态出现，说明大家判断都差不多：静态全量注入 description 这件事，是 progressive disclosure 没做彻底的遗留问题。

第三类：skill router / skill pack（社区实验阶段）。 更激进一点的玩法是在系统提示词里根本不放具体 Skill，只放一个"路由 Skill"——它的 description 大意是"当用户提到写 PPT 就去 ~/.claude/skills/pptx/ 看、提到品牌规范就去 brand-guidelines/ 看"。真正的 Skill 池被扁平化成路由表里的一条条 tag → path，router 根据用户 prompt 的语义让模型自己去拉正文。GitHub 上已经有几个这个方向的尝试（SZoloth/skill-pack、alirezarezvani/claude-skills 的 bundle 机制等），它们其实就是把你构想里"模型决定何时加载"这件事落到了一个工程化的代理层。缺点也很明显：多了一跳，首次命中的延迟会比静态注入稍高；但当 Skill 规模到 200+ 级别时，这点延迟换来的上下文腾挪空间是绝对划算的。

这三类方案并不互斥。实际落地里一个成熟团队往往同时用：日常 10~15 个最常用 Skill 全局常驻（第一层的极简版），项目级目录里装 20 个领域 Skill（第一类），再用一个轻量 router 把团队私有的 100+ Skill 分域挂在背后（第三类）。

MCP 那边踩过同样的坑，给了一个参考答案

Skill 遇到的这个问题，MCP 一年前就先踩过一遍，它的解法值得借鉴。

MCP 的 tool 一开始是全量注入：每个 MCP server 的所有 tool schema 都在会话一开始就进系统提示词。用户接入多个 MCP server 以后很快撑爆——一个只装了 GitHub、Jira、Postgres、Slack 四个 MCP server 的配置，schema 就能占到 15k+ token。社区后来推的解法叫 dynamic tool discovery：模型先只看到"你有这些 server 可以用"（每个 server 一两行说明），要用的时候再 list_tools 拉具体 schema。

对照下来你会发现，Skill 的 progressive disclosure 和 MCP 的 dynamic tool discovery 解的其实是同一个问题的两个面：前者是"知识/流程"的按需加载，后者是"工具/API"的按需加载。两边都在往同一个方向收敛——任何常驻上下文的东西，只要规模会线性增长，就必然要做分层、做懒加载、做显式 scope。Reddit 上有人总结过一句话挺贴切：Skills are progressively disclosed, but MCP tools load all-at-once——这句话已经有点过时了，因为 MCP 也在补课，但它抓住了本质：上下文窗口不是柜子，是工作台，什么时候把工具拿上来是个调度问题，不是收纳问题。

落到实操的几条建议

综上，给 Skill 数量管理一个相对可落地的 checklist：

  • 分层装。最常用的 10~15 个装全局，项目专属的装 .claude/skills/，长尾的单独放一个 ~/.claude/skills-backup/ 备用但不启用。
  • 写 description 要像写好一条路由规则，不要像写简历。触发条件比能力描述重要，写得精准才能避免模型"误伤"去加载正文。
  • 定期做 startup token 审计。bswen 文章里那个 shell one-liner（ls ~/.claude/skills | wc -l 乘以 100）就够用。突破 3000 token 就该清了。
  • 大到一定规模就上 router 或者按 workspace 切 profile。Claude Code 已经支持 .claude/config.json 里显式 enabled/disabled 清单，这是目前最轻量的 scope 手段。
  • 关注 Anthropic 和 Claude Code 在 2026 年后续 release notes 里关于 lazy description loading 的动向——这件事几乎肯定会在官方层面兑现，只是时间问题。

所以回到你那个原始的不安：它不是一个杞人忧天的感觉，而是一个业界已经明确承认的结构性问题，并且正在朝着你直觉上指向的方向（让模型决定何时加载哪些 Skill）演进。你只是比官方路线图早到了几个月。

一些其它的零散经验

除了上面的 Skill 数量问题，半年用下来还有一些零散但值得提的经验：

  • 新模型发布后重跑 benchmark。上一代模型能 100% 命中的 Skill，在新模型上行为未必一致。skill-creator 的 benchmark 基础设施天生就是为跨模型回归测试准备的。
  • 必要的确定性操作一律写脚本。Anthropic 自己的 PDF Skill 以前让 Claude 根据散文指令去填未填写的表单位置，效果很差，后来把坐标抽取逻辑写成脚本，问题直接消失。脚本对某件事的一致性是散文指令给不了的。
  • 版本化你的 Skill。在 frontmatter 里加一个 metadata.version 字段，benchmark 出问题时能快速对齐到具体版本。
  • Skill chaining 是一个隐藏的力量点。在一个 Skill 的 SKILL.md 里明确写"完成 X 以后，调用 ai-writing-guard Skill 检查一遍"，Claude 真的会链式触发下一个 Skill。这样复杂工作流可以拆成一堆职责单一的小 Skill 堆在一起，而不是写一个巨大的 SKILL.md。

参考资料