随着 skill 的爆火各种全家桶型的 skill 层出不穷superpower、speckit、grill-me … 这些 skill装的时候是感觉更聪明了但是用起来却是又慢又不稳定本文就从 Claude Code 执行机制和上下文工程聊聊为什么会出现这种臃肿 Skill 让 Agent 使用体验变差且应该删掉这些全家桶型 skill01 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、写文件、发子 agentVerify 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 自己的核心 prompt16.8k token8.4%几乎固定系统工具内置 Read / Edit / Bash / Task 等工具的 schema35k token17.5%——这是最大的一块一个字都还没干时就在那了MCP 工具声明外挂 MCP server 的工具 schema18k token9.0%自定义 agent 声明690 token0.3%memory 文件项目级 user 级 CLAUDE.md、/memory长期记忆索引4.7k token2.3%Skill 元数据每装一个 skillname description 就常驻在系统提示词末尾目前只装了 30 个合计只有 2k token1.0%对话消息用户输入、工具调用的入参和返回、模型输出18.5k token9.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 成本模型Level什么时候加载Token 成本内容L1 元数据启动时永远加载每个 skill 几十100 tokenYAML frontmatter 里的name和descriptionL2 SKILL.md 正文被触发时加载官方建议 5k token 以内skill 的完整说明书L3 资源 / 脚本用到才读未读则 0附加的 reference 文件、示例、可执行脚本这套加载机制让装了很多 skill和用了很多 skill 变成两件不同的事只要没触发 skill 只需要花元数据 token加载原理如 Anthropic 官方的架构图agent 侧只装配 skill 名字和 descriptionskill 的完整目录躺在文件系统里用到时靠 bashcat加载进来Anthropic 文档里给了一个 pdf-processing skill 的加载过程会话启动时context 中多了 skill 的元数据pdf-processing用户输入 prompt“帮我从这个 PDF 抽文本并总结”Claude 匹配到 skill跑bash: cat pdf-processing/SKILL.md将该 SKILL.md 正文加入上下文判断是否加载 reference 文件如果这次不需要填表就不读forms.md模型主动决定是否加载 reference 文件最后按 SKILL.md 的指令完成任务从上面的例子中可以看到Claude Code 是根据 description 去匹配输入的 prompt来决定要不要触发 skill 的Thedescriptionis 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 为什么应该删掉臃肿 Skill4.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 个子 skillskill 按目录分类例如 deploy/、testing/、docs/让 Claude 更容易识别相关的 skill05 怎么管理 Skill大部分臃肿 skill 的存在都是在替代一件本该由你做的事把任务讲清楚5.1 定期治理 skillsskill 不是只创建就好了还需要维护定期清理/skills删除长时间没触发过的 skill慎装打包全家桶型 skillsuperpower、大型端到端 skill 这类元数据成本和触发歧义会同时拖累所有 skill能拆就拆能用 subagent 隔离的就用 subagent 子上下文独立用完即抛能用一次性 prompt 讲清的就不做成常驻 skilldescription 写窄不写宽越具体模型越少误触按目录分组按功能目录组织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 5只是对模型的一次松绑留出更多的 context 空间所以删掉臃肿 skill 不是为了省 token是为了把判断权从模型的猜测里拿回来skill 越少你和模型之间的沟通越清晰Loop 就越稳定Claude Code 的开发者 Boris Cherny 说Build the loop. Stay the engineer两个人可以搭出一模一样的 loop却得到完全相反的结果一个用它加速自己已经理解的工作另一个用它逃避理解工作本身Loop 分不清区别你能07 参考资料Agent Skills Overview platform.claude.comThe new rules of context engineering for Claude 5 claude.com/blog跟着 AI 大厂的口味写提示词 为什么该删掉那些臃肿的 Skill
随着 skill 的爆火各种全家桶型的 skill 层出不穷superpower、speckit、grill-me … 这些 skill装的时候是感觉更聪明了但是用起来却是又慢又不稳定本文就从 Claude Code 执行机制和上下文工程聊聊为什么会出现这种臃肿 Skill 让 Agent 使用体验变差且应该删掉这些全家桶型 skill01 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、写文件、发子 agentVerify 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 自己的核心 prompt16.8k token8.4%几乎固定系统工具内置 Read / Edit / Bash / Task 等工具的 schema35k token17.5%——这是最大的一块一个字都还没干时就在那了MCP 工具声明外挂 MCP server 的工具 schema18k token9.0%自定义 agent 声明690 token0.3%memory 文件项目级 user 级 CLAUDE.md、/memory长期记忆索引4.7k token2.3%Skill 元数据每装一个 skillname description 就常驻在系统提示词末尾目前只装了 30 个合计只有 2k token1.0%对话消息用户输入、工具调用的入参和返回、模型输出18.5k token9.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 成本模型Level什么时候加载Token 成本内容L1 元数据启动时永远加载每个 skill 几十100 tokenYAML frontmatter 里的name和descriptionL2 SKILL.md 正文被触发时加载官方建议 5k token 以内skill 的完整说明书L3 资源 / 脚本用到才读未读则 0附加的 reference 文件、示例、可执行脚本这套加载机制让装了很多 skill和用了很多 skill 变成两件不同的事只要没触发 skill 只需要花元数据 token加载原理如 Anthropic 官方的架构图agent 侧只装配 skill 名字和 descriptionskill 的完整目录躺在文件系统里用到时靠 bashcat加载进来Anthropic 文档里给了一个 pdf-processing skill 的加载过程会话启动时context 中多了 skill 的元数据pdf-processing用户输入 prompt“帮我从这个 PDF 抽文本并总结”Claude 匹配到 skill跑bash: cat pdf-processing/SKILL.md将该 SKILL.md 正文加入上下文判断是否加载 reference 文件如果这次不需要填表就不读forms.md模型主动决定是否加载 reference 文件最后按 SKILL.md 的指令完成任务从上面的例子中可以看到Claude Code 是根据 description 去匹配输入的 prompt来决定要不要触发 skill 的Thedescriptionis 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 为什么应该删掉臃肿 Skill4.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 个子 skillskill 按目录分类例如 deploy/、testing/、docs/让 Claude 更容易识别相关的 skill05 怎么管理 Skill大部分臃肿 skill 的存在都是在替代一件本该由你做的事把任务讲清楚5.1 定期治理 skillsskill 不是只创建就好了还需要维护定期清理/skills删除长时间没触发过的 skill慎装打包全家桶型 skillsuperpower、大型端到端 skill 这类元数据成本和触发歧义会同时拖累所有 skill能拆就拆能用 subagent 隔离的就用 subagent 子上下文独立用完即抛能用一次性 prompt 讲清的就不做成常驻 skilldescription 写窄不写宽越具体模型越少误触按目录分组按功能目录组织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 5只是对模型的一次松绑留出更多的 context 空间所以删掉臃肿 skill 不是为了省 token是为了把判断权从模型的猜测里拿回来skill 越少你和模型之间的沟通越清晰Loop 就越稳定Claude Code 的开发者 Boris Cherny 说Build the loop. Stay the engineer两个人可以搭出一模一样的 loop却得到完全相反的结果一个用它加速自己已经理解的工作另一个用它逃避理解工作本身Loop 分不清区别你能07 参考资料Agent Skills Overview platform.claude.comThe new rules of context engineering for Claude 5 claude.com/blog跟着 AI 大厂的口味写提示词