GPT6 Astra 的几点小建议
前几天，GPT-6 Astra 上线了，我马上开了。
正好手上有个小程序「AI 徐公雷达」要优化，我就把任务交给了 Astra。
结果呢？
一个任务做下来，1 个小时，100 刀的额度已经少了约 10%，是真的贵。
其实，对于我们日常的工作，大部分不需要用到 GPT-Astra，5.6 其实已经足够了。
如果你也在用 Astra 干真实项目，下面这几条是我最近重新整理的习惯。
具体能省多少，还是得看你手上的任务。
但下面这些坑，能少踩一个算一个。
推理强度别一上来就拉满
第一条，别把 Max 当默认值。
推理档位越高，模型会花更多时间把问题想全。
遇到架构设计、复杂 bug、跨模块重构，这很值。
但只是改一段文案、找一个文件、补一个明确的分支判断，还让它先来一轮深度规划，就有点像让总设计师去拧螺丝。
我的做法是，先从能完成任务的较低档位开始。
任务边界清楚，先让它直接干。
第一次没做对、验收没通过，或者发现影响范围比想象中大，再升一档。
比如改完发现同一个问题横跨了几个模块，或者两轮修复后测试还在同一个地方失败，这时再让 Astra 多想一会，通常比第一轮就开 Max 划算。
这样做，至少每次升档都有理由。
OpenAI 对 Astra 的建议也是类似思路：它支持 low、medium、high、xhigh 和 max，应按任务需要提高推理强度，而不是默认拉到最高。
第二条，先分清任务里哪些地方真的需要判断。
复杂的需求拆解、技术方案、跨模块取舍、高风险改动，交给 Astra 没问题。
但搜索文件、整理日志、改格式、跑固定命令、局部重命名，这些简单工作，直接用 Luna 或者 Terra 就可以了。
没必要让 Astra 每次都重新读完整个项目，再郑重其事地下手。
把最会动脑子的同事留给难题，别让他一天都在搬箱子。
长任务先拆开，子 Agent 也别乱开
第三条，长任务先写一张任务说明单。
不用写成几十页 PRD。
把这次要完成什么、准备改哪里、哪些地方不能碰、最后怎么验收，写清楚就够了。
我一般就写四行：目标、范围、边界、验收。
短一点没关系。
关键是让下一个执行者知道，什么算完成，什么不在这次范围里。
这样 Astra 先把方向想明白，后面执行的人拿到的是具体任务，不是从零开始猜你的意图。
任务做了一半要换 Session，也别把几十轮聊天记录原封不动塞过去。
我现在更愿意只交接五样东西：目标、改动文件和 diff、失败日志、还没解决的问题、下一步验收项。
上下文不是越长越稳。
很多时候，越长越容易把模型重新带回已经试过的路。
第四条，子 Agent 不是开得越多越省。
三个模型同时读项目、各写一遍方案、再互相审查，token 很容易先花在“大家都在了解情况”上。
只有任务之间真的能拆开，而且每一块都有独立验收，才值得并行。
比如一个 Agent 查日志，一个 Agent 跑测试，一个 Agent 只读审查 diff，这样的分工比较清楚。
如果三个 Agent 都在做“先读完整仓库，再想一个方案”，那就先别开了。
这不是并行。
这是三个人一起开会。
主 Agent 负责难判断的地方。
子 Agent 做明确、可检查的小活。
搞不定再升级。
这个顺序，比一开始就让所有人上 Astra 实在得多。
AGENTS.md 是边界，不是操作说明书
第五条，Astra 上线后，顺手检查一下你的 AGENTS.md 和 Skills。
Astra 对规则文件更敏感，这是官方专门提过的点。
如果一边写着“自主完成”，另一边又写着“每一步都必须先问我”，它越听话，越可能卡在那里。
我之前也喜欢把经验都往全局规则里塞。
结果规则越来越长，项目一换，很多细节反而成了旧说明书。
现在我只让全局 AGENTS.md 管长期有效的边界：安全、验证、协作习惯。
这次具体改什么、怎么改、验收什么，跟着当前任务走。
该放项目里的放项目里。
该做成 Skill 的做成 Skill。
规则文件短一点，不代表交代得少。
只是把长期有效的原则和这次临时的做法，放回各自该在的位置。
规则的作用，是让 AI 不越界，不是替 AI 把每一步都想完。
第六条，方向不对就尽早打断。
不要等它写完一大段方案，再让它从头重来。
你可以直接补一句：刚才的方向不用了，保留已确认的目标，新的要求是……
再说清楚这条新要求覆盖了哪一条旧规则。
及时纠偏，通常比重新开一个 Session、再把背景解释一遍省得多。
如果上下文被污染了，也可以用 codex 的这个切换到新聊天功能，它可以从当前聊天指定位置切换出来一个分支。
验收写在前面，审查也要限范围
第七条，小改动先写完验收项，再让它动手。
比如这次只是改一个页面，就把构建、类型检查、关键路径截图这些写在任务里。
通过就交付。
失败了，再决定是补上下文、升推理档位，还是把问题交回 Astra。
这个顺序很重要。
先有检查，再有“要不要升级模型”的决定。
不要让模型自己说“已经修好了”，你就信了。
AI 写完代码不算完成。
跑过该跑的检查，才算。
OpenAI 的文档也提醒过，Astra 可能会为小改动做过宽的测试。完成标准写清楚后，通过就收束；只有冒出新问题，再扩大检查范围。
写在最后
GPT6-Astra 体验下来，还是挺不错的，比之前更加讲人味了，就是 Token 烧得猛。
但小任务别用它，用 Terra 或者 Luna 就够了。
如果你想系统学 Codex，我也把公众号里的相关文章按“从基础到实战”整理了一下。
可以先从这三篇开始：
- 《让 Codex 少走弯路：一份全局 AGENTS.md 的取舍》
- 《让 Codex 同时开工：一份 Git worktree 的取舍》
- 《我做了一个 Codex 重置雷达小程序：5 个坑，6 步复盘》
这篇讲的是“怎么少烧冤枉额度”，放在这个系列的效率篇。后面我还会继续补充 Skills、自动化和配置模板，把 Codex 从第一次任务到稳定协作，整理成一套完整教程。
另外，如果你也经常用 Codex，又总想知道有没有新的 Reset 公开信号，可以试试我做的「AI 徐公雷达」。
我是徐公，我们下次见～