今天早些时候，我刚刚发布了上一篇文章：Codex GPT-5.6 Sol High 太耗额度，ChatGPT 又频繁报错，我提前测试 GPT-6 Luna High，并决定更换翻译引擎。当时，我根据三个短篇 Marathi TranslationUnit 的独立盲测，认为 Luna High 已经具备接替旧模型的潜力，还把 Codex 的默认翻译配置调整成了它。
但文章发布后，我继续推进马拉地语的正式生产，完整的独立质量审核很快改变了我的判断。我随后又测试了 GPT-5.6 Sol High、GPT-6 Sol High 和 GPT-6 Sol Medium。这篇只记录上一篇之后的新结果和第二次决策；GPT-6 上线背景、Desktop Commander 工作流以及 ChatGPT 消息流错误的经过，不再重复介绍。
一、正式生产给 Luna High 泼了一盆冷水
上一篇使用的是三个相对简短的页面。真正让我改变主意的，是随后完成的第二批正式生成：mr-IN 的 43 个 Page，集中在 Methods、Generics 和 Concurrency 等技术内容较复杂的章节。
这批译文虽然全部通过 automatic validation，却在独立 Reviewer 的首次 QC 中得到以下结果：
| 首次 QC（43 Page） | 数量 |
|---|---|
| A：合格 | 3 |
| B：需要修订 | 2 |
| C：明显质量问题 | 37 |
| D：严重技术语义问题 | 1 |
| 需要 revision | 40 / 43 |
最普遍的问题不是个别措辞，而是许多正文反复把 glossary 已规定的 type、receiver、interface、package、channel 等 mandatory 术语直接留在英文中。更严重的是，concurrency/5 中 Go 的 select 语句，其等待条件被译反了：原文是等待某个 case 可以执行，却被译成等待某个 case 无法执行，导致 Go 的阻塞语义发生反转。
我没有立即放弃 Luna，而是让原 Codex Generation 会话根据正式反馈，重新生成 44 个 Page 和 7 个 Example，共 51 个 TU。全部修订再次通过 automatic validation，过程约耗时 50 分钟。
随后，44 个 Page 的独立 re-QC 得到 33 A、5 B、6 C、0 D。原先的技术反转已经修复，很多术语问题也解决了，但仍有 11 个 Page 需要再次修订。另有 7 个 Example 当时尚待 re-QC，不能把它们算作已通过。
所以，这里不是说 Luna 完全没有能力翻译或修复，而是它在我的这条完整生产流水线中，首次返工和后续独立审核的成本明显超出了预期。节省首次生成额度，如果换来大量 revision 和反复 re-QC，就不是真正的省钱省时。我决定停止把 Luna High 扩展为默认引擎，也不再追加 Luna Extra High 实验。
二、我原以为 GPT-6 Sol High 至少应该持平
从 Luna 的实际生产结果回到 Sol，我最初的预期其实很简单：GPT-6 Sol High 即使没有明显提升翻译质量，至少也应该接近 GPT-5.6 Sol High，而且希望它能进一步节省 Codex 额度。
于是，我重新选了三个更有代表性的完整 Page：methods/16（type switch 与密集术语）、generics/1（类型参数及 comparable 约束）、concurrency/5（select 的阻塞与执行条件）。三个模型都使用逐文件字节相同的冻结英文输入、完整 Marathi glossary 和统一翻译任务规范。生成时不提供其他模型的译文，也不提供 Luna 的 QC findings。
先不考虑评分，只看 VS Code Codex 的真实执行记录：
| 配置 | 执行耗时 | 五小时额度消耗 |
|---|---|---|
| GPT-5.6 Sol High | 8 分 37 秒 | 约 7%～8% |
| GPT-6 Sol High | 7 分 31 秒 | 约 7%～8% |
| GPT-6 Sol Medium | 3 分 49 秒 | 约 3% |
两组 High 连续运行期间，Usage 存在延迟结算，合计下降 15 个百分点，不能把某一次刷新时下降的每一个百分点都精确归给某个模型。Medium 的前后读数则较清楚。三个模型都完成了全部三个 Page，九份译文也都通过了同一套机械检查；这些检查不代表语言质量合格。
结果有点意外：GPT-6 Sol High 确实稍快，但在这次 Codex 订阅额度测试中，我没有观察到明显的五小时额度优势。真正显著降低耗时和显示额度的，是 GPT-6 Sol Medium。
这也让我重新认识了“新模型更便宜”：API 的 Token 单价与 VS Code Codex 的五小时、每周使用额度不是同一个指标。不能因为 API 定价下降，就假定订阅额度会同比下降。
三、四 AI 独立盲审：6 Sol High 没有呈现预期中的质量提升
三个模型的输出经过统一机械检查后，我按页面分别随机分配 Candidate A/B/C，将相同的完整盲审材料交给 ChatGPT、豆包、DeepSeek 和 GLM 5.3。原本还计划使用千问，但连续三次执行失败，最后保留四份完整有效报告，不再强行补足数量。
四位 AI 分别按照六维百分制审核：技术准确性 30、忠实原文 20、马拉地语自然度 20、教学表达 15、术语一致性 10、可读性 5。全部评分完成后才读取私有映射揭盲。
| 模型 | methods/16 | generics/1 | concurrency/5 | 三页均分 |
|---|---|---|---|---|
| GPT-5.6 Sol High | 94.25 | 93.50 | 93.00 | 93.58 |
| GPT-6 Sol High | 93.25 | 91.50 | 93.25 | 92.67 |
| GPT-6 Sol Medium | 89.00 | 92.75 | 93.25 | 91.67 |
看到这个结果，我确实有些意外。我原以为 6 Sol High 的技术翻译至少与 5.6 Sol High 持平，甚至可能更好。可在这三个特意挑选的复杂页面里，它的平均分反而低了约 0.91 分。
当然，三页、四位 AI 的主观评分不足以证明 GPT-6 Sol High 的整体翻译能力比上一代更差。它在 concurrency/5 上还略高一些。更准确的说法是：这轮测试没有验证我预期的质量提升，也没有显示明显的 Codex 额度节省。
另一个值得注意的结果是，四位评审都指出 GPT-6 Sol Medium 在 methods/16 首次定义处保留英文 type_switch，没有按 mandatory glossary 翻译为 टाइप स्विच。机械检查全部 PASS，仍未拦住这一语言问题，也进一步证明独立 Reviewer 不能被省略。
四、为什么最后还是倾向恢复 5.6 Sol High？
如果只看三页实验的时间与额度，GPT-6 Sol Medium 非常吸引人。如果只看模型代际，我也很希望 GPT-6 Sol High 能够同时带来质量与成本改进。
但我的项目首先是技术翻译项目。每门语言都要经过完整 glossary、122 个 TU 的独立逐项 QC、必要时的 revision/re-QC，最后全部达到 A 才能继续后续流程。我更在意原始译文准确、术语约束可靠，以及复杂 Go 语义不被译错。
GPT-5.6 Sol High 至少已有一份较好的正式生产记录：此前 mr-IN 首批 60 个 Page 的首次 QC 为 56 A、2 B、2 C、0 D。这批主要是较基础的教学页面，不应该直接与 Luna 的复杂第二批当作同难度对照，但它毕竟是真实生产证据；本次三个复杂页面的四 AI 盲审也没有推翻我对它的信心。
于是，我决定暂时将 GPT-5.6 Sol High 恢复为 Codex 正式翻译生成的默认配置。这是基于当前项目约束作出的执行决定，不是宣称它在所有语言或所有任务上都优于 GPT-6。
这个决定的代价很清楚：5.6 Sol High 完成 mr-IN 首批 60 Page 就消耗了 58% 的五小时额度，一门语言的全部首次生成很难在一个额度窗口内完成。我会接受分窗口推进，而不是为了赶进度，使用首次生成便宜、但可能制造大量 revision 的配置。
这一天最重要的收获，是把“生成一次花多少额度”改成“最终有多少完整 TU 通过独立审核，付出了多少额度与时间”。 对我来说，质量应该先于吞吐量；下一代模型或更低推理等级的性价比，也必须让正式生产数据来证明。
状态说明：上一篇发布后，仓库已经提交过 Luna High 默认配置。这篇记录的是我随后作出的调整决定；恢复 5.6 Sol High 的代码与正式规范，还需要单独执行，不能把计划写成已经完成。