从 Claude Code 的执行原理角度谈为什么该删掉那些臃肿的 Skill

随着 skill 的爆火，各种全家桶型的 skill 层出不穷，superpower、speckit、grill-me ... 这些 skill 装的时候是感觉更聪明了，但是用起来却是又慢又不稳定

本文就从 Claude Code 执行机制和上下文工程，聊聊为什么会出现这种臃肿 Skill 让 Agent 使用体验变差，且应该删掉这些全家桶型 skill

01 Claude Code 的执行机制

Claude Code 这类 Agent 不是最开始 GPT 那种把消息发过去等回信的聊天窗口，而是一个跑在你终端里的 Agent 进程，他能够通过命令行工具读文件、跑 bash、改代码、开子进程、翻 git log 等等操作

他跟 ChatBot 最大的区别在于：它跑起来之后不是等你下一句，而是自己不断循环，直到认为这件事做完了

1.1 三阶段循环

当你打开一个 Claude Code CLI 对话，给一个 prompt 提示词是它就进入了 agentic loop，反复经过：

• Gather context：读文件、翻记忆、查 skill 元数据、决定下一步该看什么
• Take action：调 tool、跑 bash、写文件、发子 agent
• Verify results：验证输出、检查是不是符合你的诉求，不合格就回到 Gather context 再来一遍

在这个循环中，你可以打断他提供更多上下文信息或者其他要求，最终得到他认为合理的结果，就算完成了一件事

所以 Claude Code 本质就是一个 while(true)，只不过循环体里带的是 LLM 推理和工具调用

聊天型的对话是一问一答的单次执行，你输入问题，大模型输出答案

Agentic 循环里，每一轮循环都要经过 gather context 阶段把包括 skill 元数据等已有的一切上下文信息重新塞进模型输入；每次 verify results，又要把整段执行史再看一遍

循环跑得越久，任务执行过程中背在身上的东西就越多，token 的消耗也随之增长

所以 skill 的成本不是保存在硬盘里的静态成本，而是任务执行过程中每一步都要过一遍元数据的动态成本

1.2 200K 的上下文窗口

Claude Code 目前的上下文窗口是 200K token，设置这个大小目前看这是一个工程实践得到的结果，存在这样两条硬约束：

• 注意力是 O(n²) 的：大模型推理依赖注意力机制，self-attention 要让每个 token 和其他所有 token 两两算相关性，序列长度翻倍，计算量就会变四倍；所以，窗口不能无限大的原因不是存不下，而是算不起
• KV cache 线性吃显存：生成阶段每个历史 token 的 Key/Value 向量都要常驻显存，上下文越长，单个请求占的显存越多，长上下文推理往往会先遇到显存瓶颈

skill 的元数据是常驻在这块 200K 的上下文窗口中的，和当前任务无关的 skill 元数据平白地消耗了珍贵的上下文窗口空间

02 Claude Code 的上下文窗口

2.1 窗口里到底装了什么

这是我本地一个还没有任何输入的 Claude Code 上下文窗口的构成：

• 系统提示词：Claude 自己的核心 prompt，16.8k token（8.4%），几乎固定
• 系统工具：内置 Read / Edit / Bash / Task 等工具的 schema，35k token（17.5%）——这是最大的一块，一个字都还没干时就在那了
• MCP 工具声明：外挂 MCP server 的工具 schema，18k token（9.0%）
• 自定义 agent 声明：690 token（0.3%）
• memory 文件：项目级 + user 级 CLAUDE.md、/memory 长期记忆索引，4.7k token（2.3%）
• Skill 元数据：每装一个 skill，name + description 就常驻在系统提示词末尾，目前只装了 30 个，合计只有 2k token（1.0%）
• 对话消息：用户输入、工具调用的入参和返回、模型输出，18.5k token（9.3%）——每轮都在长

可以看到还没有进行任何任务，系统工具 35k + MCP 18k 一共 53k 就已经占了整个 context 的 26%，这些工具的固定开销已经非常巨大

目前只装了 30 个 skill，元数据只占 1%，Claude 的 progressive disclosure 机制在没触发的 skill 时只花少量的名字税，但是如果 skill 数量更多元数据的消耗也是不可忽略的

咋一看光装着 skill 似乎并不贵，但在它被触发之后加载正文内容、把它的 SOP 塞进 Loop、让模型跟着它的路径走，这一系列操作将消耗大量上下文空间

2.2 为什么越长越钝

物理装得下 200K，不等于模型能均匀调用 200K，因为每个 token 分配给上下文的注意力权重是有限的

Transformer 的注意力机制有一个被反复验证的现象：Lost in the middle，即上下文首尾附近的信息模型记得清楚，而中间的大段内容常常被会被稀释

上下文越长，大模型对中段的召回精度就越低。因为你每往窗口里多塞一个无关 token，归一化处理时 softmax 的分母就多一项，真正关键的信息能分到的权重就被摊薄一点

所以，标称 200K 不等于有效 200K：越接近满窗，权重被稀释得越厉害、位置外推越吃力，能真正调用的有效上下文反而缩水

这就是为什么我们要追求留出足够的空闲上下文空间，——避免主动往 softmax 的分母里灌噪声，保证模型把注意力权重更多的分配给用户的输入，尽量把注意力权重压在跟当前任务真正相关的 token 上

Claude 自己在 context 管理上做了不少工作，主要三层：

• Prompt caching：把稳定不变的开头部分（系统提示词、CLAUDE.md）打上缓存，跨轮次复用，减少重复的 token 计费
• Auto-compact：当会话逼近上限时，自动把早期对话摘要成短文本释放空间
• progressive disclosure：按需加载，只把当前用得上的东西装进窗口，其他留在文件系统上

03 Skill 的加载机制

Anthropic 在官方文档里介绍 progressive disclosure 把 skill 的加载拆成三级，也反应了 skill 成本模型

这套加载机制 让装了很多 skill和用了很多 skill 变成两件不同的事，只要没触发 skill 只需要花元数据 token

加载原理如 Anthropic 官方的架构图：agent 侧只装配 skill 名字和 description，skill 的完整目录躺在文件系统里，用到时靠 bash cat 加载进来

Anthropic 文档里给了一个 pdf-processing skill 的加载过程：

1. 会话启动时，context 中多了 skill 的元数据 pdf-processing
2. 用户输入 prompt，"帮我从这个 PDF 抽文本并总结"
3. Claude 匹配到 skill，跑 bash: cat pdf-processing/SKILL.md，将该 SKILL.md 正文加入上下文
4. 判断是否加载 reference 文件，如果这次不需要填表，就不读forms.md（模型主动决定是否加载 reference 文件）
5. 最后按 SKILL.md 的指令完成任务

从上面的例子中可以看到，Claude Code 是根据 description 去匹配输入的 prompt，来决定要不要触发 skill 的

The description is what Claude matches your request against when determining whether to trigger the Skill, so it must say both what the Skill does and when to use it

所以，臃肿 skill 的 description 可能存在这样的问题：

• description 写得糊，模型就误触：本该用 skill A 的场景走了 skill B，就是一次错触发直接消耗大量上下文，还可能把不相关的指令注入到 loop 里

• description 写得贪，模型就会在不该用它的场景加载它：某个 skill 被描述为搞定某个类型的任何任务，管的范围太宽

04 为什么应该删掉臃肿 Skill

4.1 skill 元数据是常驻的

光装着 skill，看着其实很便宜，前面例子中 30 个 skill 的元数据合计才 2k token 只占 1%，没触发的 skill 在 context 只保留了 name + description，正文躺在磁盘上

但是，需要意识到的是 skill 元数据：

• 是常驻的：从你开始对话的第一秒到清空对话的最后一秒，每一轮都要过一遍模型，不是一次性成本
• 会因为写法失控：把 description 写的太复杂，导致 skill 元数据开销过大

4.2 触发误判

description 写得越通用，误触发的概率越高

例如，某个 skill 的 description 写成“完成任何编码相关的任务，包括分析代码、设计架构、写代码、review、部署等”，这会导致几乎让所有编码类 prompt 都加载这个 skill

一次错触发的代价：

• 加载它 5k 的 SKILL.md
• 里面可能有它自己的 SOP 步骤，被塞进 loop 里
• 这些步骤未必和你实际要做的事对齐，模型可能走进它的路径，做出来的东西是 skill 觉得该做的，但不是你想要的

这种输入的 prompt 被 skill 的说明书压过了的情况，在 review 输出之前是看不出来的潜在代价

4.3 skill 里套 skill 的雪崩

全家桶型打包 skill 的套娃模式就更夸张了

例如，我用一个包含 22 个子 skill 的整链路 skill 之后，出现如下问题：

• 上下文占用过大：加载这个 skill 以及相关 skill 已经占用了 40% 的上下文窗口；虽然 skill 是按需加载，但要做端到端交互，肯定要用到所有的 skill
• 执行断层：执行完底层的 skill 后，上层 skill 的 SOP 下一步已经遗忘，导致执行断层
• 知识漂移：执行代码 review 的时候，已经忘了前面 TRD 的内容

40% 的窗口被 skill 吃掉，剩下的还要装你实际的代码、测试输出、review 意见，注意力机制的 Loss in the middle 现象在这种上下文里放大得极其厉害

这种臃肿的 skill 违反了 Claude 的 progressive disclosure 设计初衷，它在按需加载的机制上强行做了打包必然全用的反模式设计

4.4 其他隐性成本

当 skills 过多时，模型容易混淆；一旦模型选错 skill 就会走完整的错误路径，直到然后验证输出的时候才可能意识到错误

除此之外，还有几层不容易看见的隐性伤害：

• 注意力稀释：前面多次提到，即便 skill 元数据没被触发，它们也占据了 context 的一片区域
• Prompt cache 更容易失效：系统提示词越长越复杂，缓存命中率下降，跨轮的实际成本上升
• 幻觉概率上升：模型上下文里看起来相关但不相关的东西越多，编造的概率越高
• 调试困难：一次异常输出到底是模型不听话，还是被某个 skill 的 SOP 带偏了，skill 越多越难查

怎么更好设计 skill 避免臃肿：

• description 里不要出现通用词，力求简明扼要
• SKILL.md 正文不要超过 500 行
• 目录里不要塞超过 5 个子 skill
• skill 按目录分类，例如 deploy/、testing/、docs/，让 Claude 更容易识别相关的 skill

05 怎么管理 Skill

回到最初的问题：既然机制这么清楚，为什么大家还是在装更多 skill？

我的观察是：大部分臃肿 skill 的存在，都是在替代一件本该由你做的事——把任务讲清楚

5.1 定期治理 skills

对读者最实用的一节：

• 定期清理：/skills 删除长时间没触发过的 skill
• 慎装打包全家桶型 skill：superpower、大型端到端 skill 这类，元数据成本和触发歧义会同时拖累所有 skill
• 能拆就拆：能用 subagent 隔离的，就用 subagent 子上下文独立，用完即抛；能用一次性 prompt 讲清的，就不做成常驻 skill
• description 写窄不写宽：越具体，模型越少误触
• 按目录分组：按功能目录组织deploy/、testing/、docs/，让 Claude 更容易在众多 skill 里选对

一个 skill 值不值得留下来，可以问两个问题：

• 它的 description 承诺的能力，是不是只有它能做，能不能换成一次性 prompt 讲清
• 每次触发，它 SKILL.md 里的内容是不是几乎全部都用得上，哪些应该拆出去

5.2 能 Prompt 就别做成 Skill

使用 AI 最为重要的就是提问的能力，当模型变得越来越强，Skills 的功能就会被稀释掉，模型使用还是回归到提问题本身

AI 干活等能力越来越强，人应该保留思考的能力，要会定义如何正确地让 AI 把活干完

OpenAI 的 prompting 指南中把提示词编写归结为四要素：

• 想要什么（结果）：AI 交出的成品长什么样
• 相关背景（上下文）：需要哪些信息才能做对
• 完成态（Done when）：什么信号告诉你可以停手
• 边界（不做的事）：哪些手不能伸

再加上一个可验收的检查，通过能跑的命令、能核对的数字让 AI 准确 check 自己的输出

06 结语

模型越强，越不需要你用规则捆住它

2026 年 7 月，Anthropic 审计并删掉了 Claude Code Fable 5 系统提示词的 80% 以上，基准测试没有任何可测量的性能下降 The new rules of context engineering for Claude 5open in new window，只是对模型的一次松绑，留出更多的 context 空间

所以删掉臃肿 skill 不是为了省 token，是为了把判断权从模型的猜测里拿回来，skill 越少，你和模型之间的沟通越清晰，Loop 就越稳定

Claude Code 的开发者 Boris Cherny 说：

Build the loop. Stay the engineer

两个人可以搭出一模一样的 loop，却得到完全相反的结果：一个用它加速自己已经理解的工作，另一个用它逃避理解工作本身；Loop 分不清区别，你能

07 参考资料

• Agent Skills Overview platform.claude.comopen in new window
• The new rules of context engineering for Claude 5 claude.com/blogopen in new window
• 跟着 AI 大厂的口味写提示词open in new window