高强度使用 GPT-6 Astra 3 天， 9 条使用经验 & 省 token 小技巧分享给你

GPT-6 Astra 发布后，疯狂地使用它开发了 3 天，好用是真的好用，但是也是真的费 token，20x 的账号，一周的额度一天都快干没了。下面是一些我使用的心得和测试出来的省 token 小技巧。

AI 开发目前最大的瓶颈就是没法产生闭环：代码写完了，跑不跑得通、页面点起来对不对，最后还是得人来验。Astra 增强的恰恰是 Computer Use，尤其是长链路的电脑控制。我现在的做法是，在任务描述里直接把验收标准写进去：「改完后启动服务，打开浏览器走一遍 xxx 流程，截图确认，失败就自己修」。它会真的去开终端、开浏览器、点按钮、看报错、回头改代码，直到跑通为止。这一步把「写 → 验 → 修」的循环从人手里拿走了，也是我觉得 Astra 最值钱的地方。

2）定位 Agent 错误链路

在开发过程中，agent 难免会犯错，产生幻觉，如果直接纠正，那么大概率下次还是会出现一样的问题，所以我一般都会去看看它到底是为什么会犯错。之前在长对话里，上下文一压缩，早期的报错和推理过程就丢了，AI 自己都找不到问题出在哪。但 Astra 换了一套上下文处理方式：不再把历史对话压成一段有损摘要，而是跨上下文窗口保留可检索的笔记，早期的报错信息、失败过的方案、之前的测试结果都还能翻回来。现在我直接问它「你第一次改 xxx 的时候依据是什么」，它能把当时的判断链路拉出来，很轻松就能定位到根因（通常是：读错了某个文件、假设了一个不存在的接口、或者被某条过期的 AGENTS.md 规则误导），然后把修正写进 AGENTS.md 或对应的 Skill 里，让 Agent 不再犯同样的错误。

3）按需切换思考档位

Astra 一共有 5 个思考档位：low、medium、high、xhigh、max（注意 none 已经不支持了，API 会直接拒绝）。档位不改变单 token 价格，只改变它「想多久、烧多少 token」。

三种切换方式：

~/.codex/config.toml，全局默认：

Ini, TOML

model = "gpt-6-astra"
model_reasoning_effort = "medium"   # low | medium | high | xhigh | max

单次任务临时指定：

Bash

codex -m gpt-6-astra --reasoning-effort xhigh "重构 payment 模块的重试逻辑"

会话中途用 /model 切换，不用重开对话。

官方给的建议是：agentic coding 和 research 用 medium，复杂 debug 用 high，xhigh 只在你自己的评测能证明有收益时才用。我的实际感受是：档位越高，它探索得越广（跑更多命令、读更多文件），对「漏掉一条相关路径就要再来一轮」的任务很值；但对一眼能看明白的任务，high 和 low 给出的结果几乎一样，只是多花了一倍时间和三倍 token。

4）基于官方文档优化你的 Skills

Astra 执行指令极其较真，以前留下的老护栏现在反而碍事。所以之前的把大段规范塞进每轮必读的主文件已经不适用 Astra。我们可以手动进行删减优化，也可以直接使用官方的指引进行优化，我们可以约束它的过度测试偏好，让它奔着最小改动去，模型变聪明，之前的约束会影响它更好的工作。

省 token 小技巧

1）默认使用 Astra low

日常开发其实 60% 的工作还是很基础的，使用 low 即可，剩下的使用 medium 完成一些比较复杂的任务，在大型功能的 code review 我才会使用 high。依据是各档位的分数和消耗对比（Artificial Analysis 智能指数）：

档位	指数	单任务成本	输出 token
low	49	$0.63	5.4M
medium	52	$1.16	12M
high	53	$1.41	19M
xhigh	54	$1.85	30M
max	55	$2.57	49M

从 low 到 medium 加 3 分花 0.53 美元，从 xhigh 到 max 加 1 分花 0.72 美元。从 low 到 max 分数只涨了 6 分，token 消耗涨了 9 倍。ChatGPT 套餐走的是套餐额度，OpenAI 没公布不同档位怎么计额，但从体感上看是按实际消耗算的，所以档位选择直接决定你的额度能活几天。

2）避免长对话

Astra 的上下文是 1.05M，很容易让人产生「反正装得下，一直聊」的错觉，但这恰恰是最烧 token 的用法：

每一轮都在重发历史：对话越长，每次请求带的输入越多，输入 token 是线性叠加的。API 上超过 272K 输入还要加价（输入 2 倍、输出 1.5 倍），套餐用户虽然看不到账单，但额度掉得同样快。
一个任务一个会话：功能做完就 /new，不要在同一个对话里从需求聊到部署。需要延续的状态写进 AGENTS.md 或让它落一份笔记文件，下个会话让它读文件而不是读聊天记录。
善用它的跨上下文笔记：Astra 自己会跨窗口留笔记，所以开新会话的代价比以前低得多，不用担心「换个对话它就全忘了」。
该压缩就压缩：长 debug 会话中途主动 /compact，或者在 config.toml 里把 auto_compact_token_limit 调低一点，让它早点收缩，而不是等塞满。

3）检查你的 MCP，Skills

这条是我实测省得最多的一条。MCP server 挂上去之后，每个 tool 的定义都会被塞进每一轮请求的上下文里，一个 server 几十个 tool，十几个 server 就是几万 token 的固定开销，每轮都在付。Skills 也类似：Codex 会把所有已安装 Skill 的 name、description、路径放进上下文，这个列表上限是模型上下文的 2%，装太多不但占额度，还会因为截断导致 description 被砍短、甚至部分 Skill 直接被省略（会有 warning）。

我的做法：

跑一遍 /mcp 看看挂了哪些 server，一周没用过的直接从 config.toml 里删掉或注释掉，需要的时候再开。
项目级 MCP 放 .codex/config.toml，别全塞在全局，做前端项目的时候没必要带着数据库 MCP。
Skills 用 [[skills.config]] 把不常用的 disable 掉，而不是删；description 精简到一两句，把触发词前置。
优先用 Astra 的 tool search 能力，让它按需检索工具，而不是把所有工具一次性摊在上下文里。

4）把多次使用的工作流沉淀为 Skills

如果执行一个流程超过 3 次，那么就应该沉淀为 Skills，这样不仅节省时间还能有效节省 token。原因很直接：一次性描述的流程，每次都要你重新打一段几百字的 prompt，它也要重新探索一遍「该读哪些文件、该跑哪些命令」，这部分探索 token 纯浪费；写成 Skill 之后，触发前只占 description 那一行的开销，触发后按 SKILL.md 里的固定步骤走，探索环节直接跳过。

我沉淀的几个：提 PR 前的自检流程、新接口的三件套（路由 + 类型 + 测试）、线上报错的排查步骤。用 $skill-creator 生成骨架，跑两次看触发是否准确，再微调 description。

最后一个个人产品分享，如果你是经常看视频，b 站和 YouTube 学习或者看播客的朋友，强烈推荐浏览器插件 Lumi：B站和 YouTube 视频双语 + AI 总结 + AI 对话助手，详细可以去：https://islumi.com/ 浏览

使用心得

1）完成测试闭环