烧了5亿token后，这是我给codex和claude做Skill上下文瘦身的新技巧！

Fable5和GPT 5.6 Sol用多了就老想删Skill，

原因很简单，10天前Claude Code都把自己的系统提示语删了80%。Fable 5够聪明了，很多以前需要写死在提示词里的规则，模型自己就能判断。塞一大堆指令占上下文窗口，还不如让模型自己判断。

当天我就搓出了一个提示词，用来删像superpower这类辅助思考或者像之前辅助GPT来操作Excel的skill。但是后面我发现，一下子把所有的skill删掉还是有点太草率了。这导致我花了很多时间，将一些我觉得没用但实际上在一些项目中会生效的skill重新装回来。。。

所以我做了一个Skill瘦身的Skill，专门来解决选择困难症。

github. com/LearnPrompt/carl-skills

也可以给codex发一句话配置，

npx skills add LearnPrompt/carl-skills --skill skill-slimming -g

主要是我的Codex和Claude Code里装了300多个Skill。从写作，设计，部署、浏览器自动化、飞书读写，数据分析，iOS模拟器、视频工具。。。你能想到的方向，我基本都有对应的Skill。

全是全了，但是量了一下启动上下文才发现，一个全新会话还没说话呢，光是Skill列表就占了约9.9k token，启动上下文10.1k。关掉所有自定义Skill用safe mode启动，只有1.5k到1.7k。

差了大概8.2k到8.4k。

用人话说，模型每次开工之前要先读一遍300多个Skill的名称和描述。它还没听到我说话呢，脑子里已经塞满了我会这个，我还会那个。

然后我翻了一下自己的用量面板，还没算claude的情况，

171.1亿累计token，7月是全年用量最重的月份之一。8月4日单日峰值直接砸了9.4亿。

粗估一下，每次调用多出约8.2k的Skill上下文开销，这个开销随每一轮对话重复发送。哪怕prompt caching能分摊一部分成本，上下文窗口的占用还是在的。按照7月的使用强度粗算，光是多余的Skill列表就大概吃掉了4到5亿token的上下文空间。差不多是我峰值日的一半。

今有Claude的团队删了80%的系统提示语来释放模型的判断力，现在我也该对自己的Skill动手了。

说实话一开始我也没想到这件事能做一周多，原来以为就是过一遍清单，把不用的删掉就完了。

但是300个Skill啊，有些我自己都不记得什么时候装的了。其中很多是试用了一次就再也没碰过的，还有一些是同一个能力被不同插件重复暴露的。

而且这里有个很离谱的机制，

直接跟CodeX说盘点我们现在安装的 Skill，它其实默认会把自己插件上带的Skill也给你统计上来。那如果你在这个时候把这个Skill禁掉删掉的话，会给你的插件带来一些启动的问题。所以真的不建议一口气把自己安装的所有Skill删掉，到时候真的要一个一个安回去的。。。

简单来说，我按使用频率给Skills分了三档。

高频核心，就是我几乎每天都在用的，22个。

中频项目化，某些项目会用但不需要全局暴露的，64个。

低频归档候选，214个。

还有21个特殊的，我标记为RARE_CRITICAL（少用但重要）。这些能力使用频率很低，但一旦需要就是关键操作。比如发布、回滚、安全审查这类的。不能因为用得少就随便扔。

所以其实，300个里面真正需要全局常驻的，只有22个。

剩下的278个，理论上都不需要每次启动都让模型看到。

不过事情没这么简单。

我做完第一轮分类之后，又做了一次全量复审。这次换了个口径，不按使用频率，按「全局可发现入口」来数数量。

结果全局的还有147个。

我当时就懵了。明明已经精简到22个核心了，怎么全局还有147个？？？

花了一段时间才搞明白，22是按使用频率划出来的高频核心建议。147是后续复审里所有仍然处于全局可发现状态的Skill，虽说这数字差得有点大，但是这四舍五入怎么就不能说明我的Skill还有很大的优化空间呢？

到这里我已经意识到，靠一个CSV或者一份Markdown清单，是不可能搞定300多个Skill的复审的。

信息太多了，需要一个能搜索、能筛选、能折叠、能分类的界面。

所以我给Skill瘦身做了一个本地网页，一个黑绿配色的Skill Scope Console！

这个页面能搜索筛选，能按来源折叠，能按用途分类。

重要的是它能让我看到每个Skill的三种上下文成本，全局入口占多少token，如果我把这个Skill归档，只留下一个关键词，等我下次提到的时候再动态加载的时候占多少token，以及命中后完整Skill占多少token等等等等。

这个触发状态就是我这次精心选出来的中间态，

直接把skill删了不行，但我又不想让它放在上下文里面占地方，那为什么不只留一个触发词呢？

可能就两三个字，比方说「生成 PPT」这种我工作流里常见的词。这样我在后面的工作流只要里提到这个词，模型就会提醒我，要不要重新加载这个 skill，把它纳入到全局范围内？

到时候我可以选择单次加载，也可以选择把它全局加载回来。这样既解放了模型的智力，又不影响我原来工作流里的skill，两全其美。

做这个网站的过程中踩了好多坑，挑几个印象最深的聊聊。

来源分类是第一个大坑。一开始是按名称前缀来猜来源的。比如看到lark开头的就归到飞书，看到carl开头的就归到自己的Carl Skills。结果完全是乱放的。。。

后来我重新定了来源证据的优先级。安装记录最高，同一个插件来源其次，Github仓库路径再次，路径前缀和内容相似度再往后，成功把这300个skill按照用途，来源，低中高档使用频率，以及是Claude Code专属还是Codex专属来分类了。

我可以在可视化界面选择把一个skill从全局换到某个项目生效，从全局换到触发中间态，这上面会写清楚每个skill省了多少token。

而且我这次批量整理之后才发现，我之前为了省事，直接把一整个系列的所有的Skill安装下来，这个事情导致了我有很多Skill和功能都是重叠的。

浏览器自动化相关的Skill又是一个坑。我一开始把所有跟浏览器沾边的都归到一类，后来发现这根本不对。网页访问、浏览器自动化、Chrome调试、网页正文抽取、截图检查、登录态操作，这些是完全不同的能力，都被分类到浏览器自动化。所以我不能要求GPT把浏览器自动化的skill优化到只剩一个，这是一个大类，没有skill是把上面这次能力全覆盖的。

说到这里，聊聊Skill加载的两阶段。这是整个瘦身过程中我认为最需要强调的认知纠偏。

新会话启动时，Agent会先加载每个Skill的名称，能力说明书，这一步占的是启动上下文。当请求真正命中某个Skill时，才会读取完整的SKILL.md，这一步占的是调用后上下文。

全局Skill在每次新会话都要塞自己的名字和说明书，但是把Skill切换到触发状态之后就只露出一个极短的触发词，所以能做到每个skill都扣下来点token，单个Skill轻松省下89%的启动上下文。

讲完了原理和踩坑，说说最终产出。

我把整个治理过程打包成了一个Skill。

对，用Skill来管理Skill。套娃了属于是。

它叫Skill瘦身，这个Skill规定了一套完整的治理流程，分成五个阶段，每个阶段独立授权。管理完之后，会出一个单独的报告，告诉你现在保留的全局skill有多少。

如果你不想选择，模型会帮你判断：

1. 1.值得放在全局的skill有多少
2. 2.在项目里生效的skill有哪些
3. 3.哪些skill被打包归档做成了触发词动态加载
4. 4.以及最后你在每一次新进对话入口的时候，能够节省多少token

还有还有，这里面的skill归档建议是结合了Claude Code的/doctor指令的，

最后的最后，

截至2026年8月4日，我的环境最终状态是这样的。318个唯一Skill，全局可发现的Skill有147个，其中核心全局29个，保守全局118个。项目级14个，触发级157个。RARE_CRITICAL 24个。

实际删除0个。

对，一个都没删。

所有低频能力都只是从全局降到了项目或触发，保留了完整归档和恢复入口。60天观察期内如果再次触发，就恢复到当前项目。多项目持续高频，才建议恢复全局。

Agent的能力一个没少，模型的智力也被解放了，瘦掉的是无效的全局暴露和上下文负担。

我自己这两周最大的体会是，安装Skill很容易，一行命令就搞定。

治理Skill，反而额外花了一周多。

大家都在往Agent身上堆能力。写作，设计，数据分析等等等等，

是时候停下来想想该收起来什么了，

Claude的团队停下来了。他们删了80%的系统提示语。Fable 5够聪明了，规则堆在那里只是在占上下文。

我也停了。花了几周整理了300多个Skill的作用域。Agent够聪明了，技能清单堆在那里只是在制造噪音。

下一步应该给我的todo也瘦瘦身了，

每天打开电脑，十几个项目同时跑着，几十个想法排着队占着我的注意力。

还没开始干活，脑子里的上下文就满了。

跟我那个装了300个Skill的Agent，一模一样。

技能堆到一定数量之后，

判断力比技能本身更值钱。

我得好好重启一下。

@ 作者 / 卡尔

最后，感谢你看到这里如果喜欢这篇文章，不妨顺手给我们点赞｜在看｜转发｜评论

如果想要第一时间收到推送，不妨给我个星标

如果你有更有趣的玩法，欢迎在评论区聊聊

更多的内容正在不断填坑中……