[🤖] 看到对话一开始上下文就被占满后，我重写了共享规则

✨ GPT-5.6 Sol 的总结

我追查了 258k 上下文为何在对话刚开始时就迅速被占用，拒绝只删几行的方案，并在不扭曲含义的前提下，把共享规则和 Skill 全面整理成精简英语。

工作还没开始，上下文就已经被占了一大块

我打开一个新的 Codex 对话，却发现刚开始上下文就已经占用了不少。上限明明是 258k，真正的工作还没开始，共享规则和 Skill 列表已经各自占了一块空间。

一开始，我问的是对话启动时会载入多少内容。Codex 却给出了一个离谱得更大的数字，我马上纠正了它。

“不对，258k 才是上限。看来全局规则太大了……”

回头想想，这并不奇怪。每当 AI 犯错，我都会增加一条共享规则，要求它以后不要再犯同样的错误。权限、Git、credential、部署、浏览器、UI/UX、文档、Goal、并行工作，以及公司项目与个人项目的边界，全都堆在里面。重复任务被做成 Skill，而 Skill 再出错时，我又会补上例外和验证流程。

我不希望 AI 每次都丢掉上下文。之前我还很满意自己用 Codex Skill 衔接起工作的脉络与判断手感。但为了保存上下文而做的机制一旦太长，就会先吃掉新任务本该使用的空间。曾经延续工作脉络的线索，不知不觉变成了负担。

我拒绝只删几行就收工

最开始，我要求只审查并删除那些可以确定不会导致性能下降的部分。Codex 很谨慎，只整理了几处重复和明显冗长的段落。

看到结果后，我立刻感到不满意。

“就这么一点……？比如压缩那些没必要写得很长的描述之类的呢……你真的把自己认为最好的方法都用上了吗？”

我想要的并不是删除几句话。我想改掉结构本身：同一个安全条件散落在多个段落里重复，一项判断绕着冗长叙述打转，reference 或 script 里已经存在的细节又被复制进 Skill 正文。

但如果只以短为目标，反而更危险。假如明确批准缩成了批准，准确的目标与范围模糊成必要时确认，token 虽然减少了，AI 的行为也会跟着改变。credential、破坏性变更、Git 所有权、部署、客户 UI 等规则中，看似细微的一句话差异就可能移动真实的权限边界。

所以我重新确定了标准：删掉案例和重复说明，但保留所有决定行为的条件、禁止项、例外、验证方式与停止标准。

我实际测量了韩语和英语哪一种更省 token

过程中，我也考虑过把所有 Skill 都改成韩语。对我来说，韩语更容易阅读和修改，但这次的目的不是让我看得舒服，而是减少 Codex 使用的 token。

我把同一含义分别写成精简韩语和精简英语，再放进实际 tokenizer 测量。在我写的几个 Skill 描述中，压缩后的英语明显更短。这并不等于韩语永远更吃亏，但对于当时积累的大量共享规则，英语往往能在保留含义的同时使用更少 token。

方向到这里就很明确了。

“那把共享规则和 Skill 全部改成精简英语不是更好吗？这样能省 token。”

我没有为了改成英语就无条件删除韩语。我保留了自己实际使用的韩语触发语、展示给用户的状态名与输出示例，以及翻译后反而会降低识别度的公司业务专有名词。其余说明和流程则改成简短英文。

Codex Skill 会把名称、描述与路径放入启动上下文，完整的 SKILL.md 只在该 Skill 被触发时读取。¹ 因此，我先缩减始终存在的全局规则和 Skill discovery 描述，再分别压缩调用时会整块载入的庞大网络 inventory 与写作 Skill。

我另外检查了精简后的文字是否仍会产生相同行为

这次，我没有把“已经翻译成英语”当作完成标准。我先选择一部分共享安全规则、审计 Skill 和时间记录 Skill 作为代表进行改写。独立 reviewer 对照原文与压缩版时，第一次就发现审计 Skill 中的一个条件被弱化了：仍然必须保留与现有 architecture 无关的行为。

我补回那句话，让同一位 reviewer 再次检查，然后把这个模式扩展到其余共享规则和全部 13 个用户自制 Skill。最后，由另一个 session 对 29 个文件与原文进行全面复核，确认缩短后的文字仍会形成相同的批准边界、停止条件、验证流程与输出契约。之后没有再发现重要遗漏。

数字也清楚显示了差异。以 o200k tokenizer 计算，始终会读取的全局规则从 14,933 token 降至 10,644，减少约 28.7%；对话开始时展示的 Skill 描述减少约 31.1%；调用时读取的两份大型 reference 减少约 50.5%；整个对比范围则从 81,347 token 降至 62,765，减少约 22.8%。

由于所有 Skill 正文并不会在启动时一起载入，所以不能把 22.8% 直接称为“对话启动成本”。但始终存在的部分确实立刻变小了，调用大型 Skill 时额外增加的负担也同时降低。

上下文需要的不是更多，而是更高的密度

过去，每当 AI 犯错，我只会想到增加规则。我以为写得越具体就越不容易出错，把案例也留下就能让下一次更容易理解。这个想法并非完全错误，那些规则确实避免了许多事故。

问题是，我一直增加规则，却几乎从不回头压缩。防止同一类失败的句子出现在多个地方，最近事件的说明像永久规则一样留下，为了让 AI 理解一次而写的长文变成了每项任务都要支付的固定成本。

这次删掉的不是安全装置，而是围绕安全装置堆积的重复与长篇说明。要保护什么、什么时候停止、谁来批准、如何验证都被保留下来；反复说服 AI 为什么会有这条规则的句子则被清掉了。

给 AI 更多上下文，与给它更好的上下文，是两件不同的事。

以后维护共享规则和 Skill 时，我不会再以添加新句子为终点。我还要一起检查同一含义是否已经存在、事件能否提升成 invariant，以及有多少词并不会改变实际行为。上下文不是无限仓库。

与其继续堆积记忆，我更想做到：用更少的 token 重新产生同样的判断。

这一次，我朝那个方向又前进了一步。

参考资料

1. OpenAI, Codex Skills。说明 Skill discovery metadata 与完整指令的分阶段载入机制。 ↩