我现在怎样控制
Skill 和 Token
我的做法不复杂：少装、按需调用、长任务留一份简短状态。
刚开始用 Codex 时，我把“文件多、聊天长、Skill 多、Token 多”混成了一件事。其实它们不是一回事。分开以后，很多焦虑自然就没了。
- Token：模型处理和生成内容时使用的计量单位，不是固定的“对话次数”。
- 上下文：Codex 当前工作时能参考的信息，有容量上限。
- 项目文件：保存在硬盘上，只有被读取时才会进入当前工作。
- 对话历史：消息和工具结果越长，通常需要处理的上下文也越多。
Skill 不是越多越强
Skill 的名称和简介可能参与能力发现；真正被选中的规则和相关文件会进入工作上下文。实际影响取决于运行方式，不能简单说“装一个 Skill 就一定浪费很多 Token”。
更实用的办法是：常用的留下，重复的合并，暂时不用的先不装。复杂任务需要专门工作流时再调用，简单修改就直接做。
长任务不要只靠聊天记录
项目做几天甚至几周时，我会保留一份很短的状态文档：现在做到哪里、已经确认什么、下一步是什么、有哪些风险。新任务先读它，比反复翻整段聊天更可靠。
上下文应该保留决定和证据，不必保留每一次试错的全部过程。
我做了一个小工具帮助检查
codex-token-audit 是我自己的开源项目，不是 OpenAI 官方工具，也不是使用 Codex 的必需品。它用来发现重复规则和可能闲置的配置；真正删除或修改之前，仍然要人工确认并备份。
最后只记住三句话
- Skill 按任务装，不按数量装。
- 规则要短、明确、没有冲突。
- 长任务用状态文档接力，重要结果必须验证。