原本，我并没有打算这么快测试 GPT-6 Luna High。
9 月 22 日，OpenAI 正式推出 GPT-6 Sol 和 GPT-6 Luna，并在 Codex、ChatGPT Work 和 API 中提供。北京时间已经是 9 月 23 日。普通 ChatGPT 对话暂时还没有同步提供这两个模型。
按照原来的计划，我准备等普通 ChatGPT 网页版也支持 GPT-6 后，再进行一次完整的翻译质量对比。
但是，最近几天发生的事情，让我决定提前开始测试。
一方面，Codex GPT-5.6 Sol High 的额度消耗实在太快；另一方面，为了节省 Codex 额度而引入的 ChatGPT 翻译方案，又遇到了频繁的「消息流中的错误」。
既然 Codex 已经能够使用 GPT-6 Luna High，我决定不再等待。
这次实验的目的并不是证明 GPT-6 Luna High 比 GPT-5.6 Sol High 更强，而是确认一个实际问题：
GPT-6 Luna High 的翻译质量，是否已经足以替代 GPT-5.6 Sol High，成为项目默认的正式翻译生成引擎？
一、GPT-6 正式上线，原本还想再等等
OpenAI 这次推出的 GPT-6 Sol 和 Luna，提供了不同的性能与成本组合。官方还公布了推理与缓存效率方面的改进，以及更低的 API 价格。
我目前正在持续扩展 A Tour of Go 多语言翻译项目。
每新增一门语言，都需要完成术语制定、独立术语审核、122 个 TranslationUnit 的完整翻译及逐项审核。随后还要处理必要的修订、课程 SEO，以及最终页面审核。
对于这样的项目，我不能只考虑模型的单次翻译能力，还需要考虑额度消耗、生成速度、审核成本和长期可持续性。
GPT-6 Luna High 刚刚上线时，我就想过用它承担正式翻译任务。不过，当时还是决定先观察一下，等普通 ChatGPT 网页版支持 GPT-6 后，再开展质量对比。
没想到，接下来两天的实际使用情况，让我改变了计划。
二、Codex GPT-5.6 Sol High：首批 60 Page 就消耗了 58% 的五小时额度
这次，我计划同时新增保加利亚语和马拉地语两门语言。
按照既定方案，保加利亚语交给 ChatGPT GPT-5.6 Sol High 生成，马拉地语交给 Codex GPT-5.6 Sol High 生成。两门语言分别配备独立的 ChatGPT Reviewer，负责正式语言质量审核。
在开始马拉地语翻译前，我特意检查了 Codex Usage。
当时，五小时额度剩余 100%，每周额度剩余 99%。
首批任务包含 60 个完整的 Page TranslationUnit，覆盖 Welcome、Basics、Flow Control 和 More Types 四个章节。
Codex 的执行过程相当顺利。
约 17 分 20 秒后，全部 60 个 Page 完成。正式导入、restore 和 automatic validation 均为 60/60 PASS，没有未解决的验证错误。
但是，当我再次查看 Codex Usage 时，五小时额度已经只剩下 42%。
也就是说，首批 60 个 Page 就消耗了约 58% 的五小时额度。
对于一门拥有 122 个 TranslationUnit 的语言来说，这样的消耗已经相当高了。
首批 60 Page 完成后，还有 43 个 Page 和 19 个 Example 尚未生成。即使首次生成全部完成，后续独立审核仍可能发现需要修订的内容。最后还有独立的 Course SEO 翻译任务。
按照目前的额度消耗速度，仅依靠一个五小时额度窗口，很难完成一门语言的全部生成工作。
GPT-5.6 Sol High 的翻译能力没有问题，执行也比较稳定，但对于需要持续扩展大量语言的项目来说，额度已经成为限制吞吐量的主要因素之一。
这也是我此前决定借助 Desktop Commander，让 ChatGPT 参与正式翻译生成的原因。
三、为了节省 Codex 额度，我让 ChatGPT 也成为正式翻译引擎
在引入 Desktop Commander 之前，ChatGPT 与本地仓库之间需要进行较多的人工文件交接。
正式翻译任务首先由本地终端导出 Generation ZIP，再由 ChatGPT 完整读取正式输入。翻译完成后，需要把结果下载到本地，经过正式打包、导入和自动验证，才能进入后续审核。
这样的流程虽然可靠，但人工操作比较繁琐。
后来，我接入了 Desktop Commander，使 ChatGPT 能够通过 MCP 访问我的 Ubuntu 电脑。
经过几轮实验，我进一步优化了翻译工作流。
现在，首次大批量翻译仍然使用完整的 Generation ZIP 作为正式输入，但 ChatGPT 可以把完成的 TranslationUnit 分组保存到本地隔离的 hidden staging。
等全部译文生成完成后，再使用正式 CLI 直接从目录导入，不再默认需要下载普通 outputs ZIP，也不需要额外制作本地 Result ZIP。
这样既保留了原有的输入合同、provenance 和质量验证机制，又减少了人工文件交接。
同时，我还保留了严格的 Generation 和 Reviewer 职责分离机制。无论译文由 ChatGPT 还是 Codex 生成，都必须通过独立审核，不能由生成模型自行批准。
按照我的计划，ChatGPT 和 Codex 可以同时负责不同语言，充分利用两边各自的额度。
然而，工作流刚刚完成优化，ChatGPT 网页端就出现了严重的稳定性问题。
四、从 9 月 22 日开始，ChatGPT 网页端频繁出现消息流错误
9 月 22 日开始，我的 ChatGPT 网页端就陆续出现「消息流中的错误」。
最初，我还以为只是偶发问题。
但到了 9 月 23 日下午，情况明显恶化，多个会话接连出现错误，几乎无法正常开展工作。
9 月 24 日上午，稳定性一度有所改善，我还顺利完成了此前两门语言的剩余工作，并将它们推送到了 GitHub。
没想到，当天下午，消息流错误再次密集出现。
最开始，我怀疑是长期会话的上下文太长，导致模型生成速度变慢或者发生超时。
但随后，新建的翻译会话也开始出现同样的问题。
有一次，请求持续处理中约六分钟，最终仍然以消息流错误结束。
更令人无奈的是，有时模型已经开始输出内容，甚至已经生成了大部分结果，最后却在展示总结时突然报错。
对于普通问答来说，遇到这样的错误，也许重新生成一次回复就可以了。
但对于我的项目，情况完全不同。
一次正式 TranslationUnit Generation 可能需要处理几十个完整的教学页面。如果模型已经生成了大量译文，却尚未成功保存到 staging，那么消息流一旦中断，就可能意味着此前的生成工作全部丢失。
虽然我已经为项目增加了分组保存、隔离 staging 和目录直接导入等恢复机制，但如果连第一组真实译文都来不及保存，再完善的恢复机制也无法发挥作用。
9 月 24 日下午，我的保加利亚语首批 60 Page Generation 就反复遇到这种情况。
正式 Generation ZIP 已经通过完整性校验，恢复检查也确认输入没有问题，但 ChatGPT 多次在生成过程中报错，迟迟无法完成可靠的译文保存。
我已经向 OpenAI Support 提交了问题，并升级至人工支持。
目前还没有得到明确的技术结论，所以我不能确定究竟是后端资源不足、前端 Bug，还是其他原因。
但是，从实际使用体验来说，最近几天下午的 ChatGPT 网页端，已经严重影响了正常工作。
在 Codex 额度有限、ChatGPT 又频繁报错的情况下，我决定不再等待普通 ChatGPT 支持 GPT-6，而是直接使用 Codex GPT-6 Luna High 开展翻译质量测试。
五、不再进行大规模跑分，只测试三个完整 Page
这次实验参考了我 8 月 23 日发布的翻译质量测试文章 中使用的盲审思路，但规模明显缩小。
因为我的目的不是证明 GPT-6 Luna High 全面超过 GPT-5.6 Sol High。
只要确认 Luna 的翻译质量已经达到正式使用要求，我就可以考虑更换默认翻译引擎。
因此，我从马拉地语已经完成的首批 60 个 Page 中，选择了三个完整的 TranslationUnit。
| Page | 英文标题 | 测试重点 |
|---|---|---|
| basics/12 | Zero values | Go 基础概念、术语及 Markdown |
| flowcontrol/10 | Switch evaluation order | 技术语义、条件逻辑及教学表达 |
| moretypes/20 | Map literals | 复合类型、术语一致性及自然度 |
实验使用相同的英文原文、正式 glossary 和翻译任务规范。
GPT-6 Luna High 独立生成三个 Page，没有参考 GPT-5.6 Sol High 已有的马拉地语译文。
实验产物全部保存在独立目录中，没有修改正式翻译、provenance、Snapshot 或 QC evidence。
三个 Luna 结果在隔离环境中通过了正式 restore 和 automatic validation，均为 3/3 PASS。
从开始生成 Luna 译文到最终完成检查，整个实验实际耗时约 9 分 05 秒。
这里需要说明，两次任务的规模不同：Sol 完成了 60 个 Page，Luna 只完成了三个实验 Page。因此，不能直接根据这两次耗时推断两种模型的速度差距。
六、五个 AI 参与独立盲审
为了尽量减少单个模型的主观偏差，我邀请了五个 AI 参与独立盲审：
ChatGPT、豆包、DeepSeek、GLM 5.3 和千问。
每个 AI 都使用同一份匿名材料，包含三个 Page 的完整英文原文、完整正式 glossary，以及每页的 Candidate A 和 Candidate B。
每页 A/B 独立随机分配，不公开其真实生成模型，也不允许评审者参考其他 AI 的评分。
统一六维评分标准如下：
| 评分维度 | 满分 |
|---|---|
| 技术准确性 | 30 |
| 忠实原文 | 20 |
| 马拉地语自然度 | 20 |
| 教学表达 | 15 |
| 术语一致性 | 10 |
| 可读性 | 5 |
| 合计 | 100 |
除了评分，还要求每位 AI 逐页检查具体的技术错误、漏译、术语问题、自然语言问题，以及代码和机器语义是否保持不变。
不过，五份报告全部完成后，我发现千问的审核结果存在一项严重的事实错误。
它声称，某个候选把 basics/12 中的 .play basics/zero.go 错误替换成了另一个页面的代码路径，并据此判定 Critical 级错误。
但我重新检查原始盲审材料后发现，该候选的 .play 路径完全正确，根本不存在这一错误。
由于这项不存在的 Critical finding 明显影响了千问的评分，我保留了它的原始报告，但没有将其计入主要统计。
这次经历也提醒我，多 AI 审核并不意味着简单统计票数就足够了。对于可能改变结论的严重 finding，仍然需要返回原始文件核对证据。
七、揭盲结果：Luna 的翻译质量已经满足我的初步迁移要求
排除存在重大事实错误的报告后，剩余四份独立评审结果如下。
| Page | 支持 Luna | 支持 Sol | 平局 |
|---|---|---|---|
| basics/12 | 3 | 1 | 0 |
| flowcontrol/10 | 2 | 1 | 1 |
| moretypes/20 | 2 | 1 | 1 |
| 合计 | 7 | 3 | 2 |
四位有效评审者对三个 Page 的六维评分，按全部 12 组评分计算，Luna 平均约为 95.7 分，Sol 平均约为 93.2 分。
但对我来说，这次实验最重要的并不是 Luna 的平均分略高，而是两种模型在具体翻译内容上的表现。
在 Zero values 页面中，两份候选均存在不同程度的 Markdown 强调范围问题，但 Sol 候选还存在术语内部空格及下划线配对异常。
在 Switch evaluation order 页面中，Sol 对 evaluate 的处理更为精确，Luna 的条件句表达则更加自然。不同评审者对此有不同的判断，因此产生了分歧。
在 Map literals 页面中，两份候选都准确表达了 Go 技术语义，差异主要集中在术语词形与马拉地语表达习惯上。
三个 Luna 实验 Page 均通过了正式自动验证，盲审中也没有发现明确的严重 Go 技术概念错误。
当然，三个简短 Page 的样本量很小，不能据此证明 Luna 在所有技术文档翻译任务中都优于 Sol，也不能替代完整的正式 TranslationUnit QC。
不过，我原本就没有打算通过这次实验选出理论上最强的模型。
我只需要确认：GPT-6 Luna High 的翻译质量已经足以进入我现有的正式翻译与独立审核流程。
就这次有限实验所提供的证据而言，我已经愿意让它承担后续正式翻译生成任务。
八、我的决定：将默认翻译引擎调整为 GPT-6 Luna High
这次实验完成后，我不打算再为迁移问题单独开展新一轮模型对比。
我准备在本文发布后，直接调整项目的正式规范，将 Codex 默认翻译生成模型从 GPT-5.6 Sol High 切换为 GPT-6 Luna High。
已经开始正式生成的语言，继续保持原有的模型身份和真实 provenance；后续新的翻译任务，则按照更新后的规范使用 Luna。
我之所以愿意做出这个决定，主要是因为对这个项目而言，翻译质量并不是完全依赖生成模型的单次输出。
每门语言都有完整的术语表、严格的代码与机器语义保护、正式的 automatic validation，以及完全独立的 Reviewer。
全部 122 个 TranslationUnit 都必须经过逐项完整审核。发现 B/C/D 问题后，由原 Generation 会话集中修订，再交给独立 Reviewer 重新审核。只有全部达到 A，才能完成正式 finalization 和 promotion。
这些质量门槛不会因为生成模型改变而降低。
而且，我认为翻译工作本身未必需要始终使用推理能力更强、额度消耗更高的模型。
尤其是在输入完整、术语明确、格式约束清晰，并且有严格独立审核的情况下，更重要的是模型能否持续稳定地生成准确、自然且符合规范的译文。
对于我的项目来说，GPT-6 Luna High 已经通过了这次初步验证。
当然，实际迁移后仍然需要通过正式审核结果，观察后续各语言的修订数量、质量问题和额度消耗。这属于正常生产流程，而不是额外增加一轮迁移实验。
九、总结：选择模型，不应该只看谁更强
这次实验其实是被现实问题提前推动的。
Codex GPT-5.6 Sol High 的翻译质量不错，但首批 60 Page 就消耗了 58% 的五小时额度。
为了节省 Codex 额度，我借助 Desktop Commander，让 ChatGPT 也成为正式翻译生成引擎，并且优化了文件保存和目录直接导入流程。
然而，ChatGPT 网页端最近几天又频繁出现消息流错误，使得长时间翻译任务不断中断。
恰好此时，GPT-6 Luna High 已经在 Codex 上线，于是我决定提前测试，而不再等待普通 ChatGPT 网页版支持 GPT-6。
经过三个完整 Page 的独立生成、机械验证和多 AI 盲审，我已经获得了做出迁移决策所需要的初步依据。
对我来说，模型不需要在每一次对比中都拿到最高分。只要能够满足正式翻译质量要求，并且有望以更合理的额度成本完成持续生成，就值得采用。
接下来，我将正式调整项目规范，让 GPT-6 Luna High 成为默认的 Codex 翻译生成引擎，同时继续保持原有的独立审核与 A-only 质量门槛。
对于需要长期运行的 AI 工作流，真正重要的不是始终使用能力最强的模型，而是在保证质量的前提下，找到能够持续完成任务的方案。