前面说了 GPT-6 Astra 发布后要调整用法，今天来点实际的

如果你刚换到 GPT-6 Astra，第一反应可能是：怎么 Token 掉得这么快？

先别急着给任务补更多规则。很多时候，问题出在旧配置和旧习惯还停留在上一代模型的用法上。下面四件事，值得先检查。

1. 打开实验性上下文管理

如果客户端提供这个选项，可以检查 Codex 的实际配置文件，看看是否有下面这段：

[features.context_management]
experimental_mode = true

它解决的是一个很具体的问题：同一项任务跨过上下文窗口后，能不能继续保留笔记、历史消息和工具结果。

这里有个边界要记住：它是同一任务的上下文管理，不等于会自动翻遍你所有的历史对话。配置写入成功，也不代表当前运行中的客户端已经立即生效，有时需要新建任务，甚至重启客户端才能确认。

可以把下面这段交给 Codex，让它先检查再改，不要自己凭印象改配置：

请检查本机 Codex 的有效配置及功能支持情况，找到实际使用的 config.toml（通常位于 ~/.codex/config.toml），在 [features.context_management] 下设置 experimental_mode = true。若已开启则保持不变；需要修改时，先创建可恢复且不覆盖旧备份的备份，再幂等修改，避免重复配置表，并保留其他设置。完成后校验 TOML、回读配置，分别说明“配置是否已写入”“运行时是否已确认生效”，以及是否需要新建任务或重启客户端。若当前客户端或登录方式不支持，请明确说明。

提示词里最有用的不是那句 experimental_mode = true，而是“先确认实际配置文件、备份、幂等修改、回读验证”。这样能少踩几个配置被写错的位置、重复添加区块的坑。

2. 把 Skills 和 AGENTS.md 瘦身

这两类文件很容易越写越长。过去为了让模型少犯错，大家会把所有规则都塞进去；模型升级后，重复规则、过度详细的流程和无条件触发的技能，反而会挤占上下文。

可以让 Codex 按这个顺序处理：先盘点，再备份，最后改。

请先只读盘点当前项目实际继承的全局和项目级 AGENTS.md，以及已启用的用户 Skills。先查看入口、描述、长度和引用关系，再按相关性审读，不要一次加载全部正文。完成备份后，合并重复规则，精简触发描述，收窄误触发；把模式专属流程、长示例和模板移到参考文件，并保留明确的按需读取入口。保留权限边界、验收标准和失败停止条件，不要为了省 Token 擅自降低质量。完成后验证语法、引用、关键流程，并回读源文件。

改完后重点看三件事：

Skill 的描述是否只在真正相关的任务里触发；
AGENTS.md 有没有要求每个小改动都做完整仓库审查；
长篇示例和特殊流程是否已经移到需要时才读取的参考文件。

不要把所有规则都删掉。涉及生产环境、密钥、删除操作、外部发布和测试边界的内容，应该留下，而且要写得具体。

3. 日常任务别一上来就拉满智能程度

按这条内容的实际用法，普通任务用“中”或“高”就够了；复杂任务再上“极高”或“最高”。“Ultra”不应该成为默认档位。

可以简单理解为：

改一个小文件、整理文字、补一个测试：中或高；
跨多个模块排查问题、做架构调整：极高；
需要长时间推理、反复验证的复杂任务：最高。

档位越高，不一定就越快，也不一定更省。小任务如果开到最高，常见结果是思考和验证都变重，花费增加，但交付物并没有变好。

还有一点容易被忽略：任务描述里要写清楚“做到哪里算完成”。例如：实现功能、运行相关测试、修复由本次改动导致的失败，然后停下。模型知道结束条件，通常比一句“继续深入”更省上下文。

4. 速度调回正常

如果你的目标是完成任务，而不是观察模型逐字思考，速度设为正常通常更实用。

速度越快，输出越容易显得热闹，但过程里可能夹杂重复解释、无关测试和过多中间话。速度调慢并不等于能力更强，速度调快也不自动等于效率更高。最终要看：同样的任务，花了多少 Token，是否真的完成，返工了几次。

我会优先采用这个组合：普通任务用中或高，速度正常；复杂任务才提高智能程度，同时给出明确的范围、验收条件和停止点。

一次性检查清单

你可以把下面几件事一起交给 Codex，但让它先盘点，别直接覆盖：

请检查当前 Codex 的配置、AGENTS.md 和已启用 Skills：
1. 确认是否支持 [features.context_management]，支持时检查 experimental_mode 是否已开启；
2. 统计 AGENTS.md 与 Skills 的入口、描述长度、重复规则和无条件触发项；
3. 提出并实施安全范围内的精简，修改前创建不覆盖旧备份；
4. 保留生产环境、密钥、删除、外部发布、测试和权限边界；
5. 修改后校验 TOML/Markdown，回读源文件，说明哪些内容已写入，哪些运行时效果尚未确认。

这四步的共同点，是先减少无效上下文，再决定要不要提高模型档位。别把“Token 消耗快”简单归咎于模型本身，也别用一份更长的提示词去解决一份已经过长的配置。

GPT-6 Astra 的具体开关、档位名称和登录支持，仍然要以你当前客户端实际显示的内容为准。配置改动前备份，涉及项目规则时保留回滚路径；这两条比任何“省 Token 技巧”都重要。