GPT-6 Astra：100K+ LOC 长任务、推理档位与 Fast 模式现场报告

一句话结论

在一个 100K+ LOC 的真实商业代码库中，Astra High 被作者视为实现和规划的甜点档，但超长重构与 Fast/Ultra 会很快耗尽额度，而且“大重写”最终仍未完成。

适用场景

• 适合的任务：复杂代码库中的实现、规划、UI 迭代、3D 资产生成、着色器或模组移植，以及需要长时间 Agent 执行的工程试验。

• 不适合的任务：把单个用户的订阅额度消耗外推为 API 成本，或把未完成的大重构当作成功基准。

• 适用的模型版本：GPT-6 Astra；作者还与 GPT-5.6 Sol、Terra、Luna、Fable 5.1、Opus 和其他模型作主观对照。

• 适用的客户端、Agent 或 API：Codex GUI、手机远程控制和 /goal 长时域工作流。

• 推荐的推理档位和参数：作者把 UI 分给 Light，软件解释分给 Medium，实现与规划通常用 High；其体验中 XHigh 增益不明显，Fast 额度消耗过快。这不是通用配置结论。

测试环境、输入与配置

• 项目是 miniskyline.com，自 6 月起持续由 Codex 和 Claude 迭代，作者称网站每月约有 200–300 美元捐赠收入。

• 作者不是职业开发者；代码库超过 100K LOC，几何引擎重构使用 /goal 约 70 小时。

• 第一个 Astra High 会话被明确要求不使用子代理，前 24 小时消耗约 60% 的 20x 额度；其他 UI 和优化工作消耗余量，第一次完整额度约 36 小时用完。

• 重置后切换 Astra High + Fast，同一 /goal 约 12 小时用完额度；再重置后，1 个 Ultra + Fast 和 1 个 Ultra + Standard 在不足 6 小时内把额度从约 90% 用到 0%。

• 作者没有公开模型快照、输入/输出 token、完整 rollout、提交 diff 或统一对照任务。

可复用提示词

作者公开了 3D 游戏资产任务的原始提示词；原帖引号没有闭合，以下按页面可见内容原样收录，不补写缺失部分。

Produce a GLB asset pack for a game about X. The printer must appear to work properly with all of its major hardware fully modelled and animatied where necessary. I dont want it to look fancy/modern, more junky/put together.

结果数据与观察

结论与适用边界

这份报告支持两个有限结论：High 可能是该用户在复杂实现中的实用档位；长时域大重构即使能持续推进，也可能在性能目标未达成前消耗大量额度。它不能证明 High 对所有代码任务最优，也不能证明 Fast 的 API 单任务成本一定更高。作者自己认为更有针对性的修补可能优于整套管线重写。

评论中的另一位用户报告，小步执行“Plan → Build → Plan → Build”更有效，并指出其仓库每轮只需约 40K token；原作者则说明自己为管线维护了模块化结构和依赖图。这提示复现时应把任务粒度、初始上下文和依赖图列为控制变量。

复现步骤

1. 固定同一仓库提交、模型快照、effort、服务模式、工具权限和初始上下文。

2. 把同一重构拆成“大范围 /goal”与“小步 Plan/Build”两组，记录每轮目标和停止条件。

3. 分别运行 Standard 与 Fast，不并行混用；记录额度变化、输入/缓存/输出/推理 token、墙钟时间、compaction 次数和人工介入。

4. 用相同性能验收测试比较旧实现和新实现，包括运行时间、峰值内存、正确性、非流形边和开放边。

5. 对视觉与 3D 任务保存原始输入、GLB 文件、渲染图、迭代次数和人工评分，避免只保留满意度描述。