烧了5亿token后，这是我给codex和claude做Skill上下文瘦身的新技巧！|skill|token|上下文|工作流|插件|瘦身|调用

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是把上面这次能力全覆盖的。