标签： Codex
-
A Tour of Go 法语版在约 9 小时内完成上线后，我没有立即开始下一门韩语，而是先继续完善新增 locale 的执行流程。这一轮优化不再重复讨论“如何建立一套标准流程”，而是进一步减少已经可以机械化的重复操作：新增 locale init 初始化能力、自动生成语言骨架与状态文件、完善首次 production 自动化与 production identity、精简命令执行成本，并建立 Deferred Issues 机制记录已经真实发现但暂缓处理的问题。目标不是减少 Quality Check、Final Review 或 production acceptance 等质量 gate，而是把人的时间更多留给真正需要判断的翻译质量和生产风险。
-
最近几天 Codex 的额度机制连续发生变化。前一次额度自动完全重置后，因为我知道下一次正常的周额度恢复日期还有一段时间，所以一直在主动控制消耗，甚至从 GPT-5.6 Sol 轻度逐步调整到 GPT-5.6 Terra 中、Terra 轻度，并减少一些不必要的 Codex 使用。 昨天休息前，我的周额度大约还剩 44%。没想到今天早上再次查看时，5 小时额度和周额度又全部恢复到了 100%。 自动重置当然是好事，真正让我觉得可惜的是：如果能够提前知道今天还会再重置一次，那么昨天其实完全没有必要如此节省，那部分即将失效的剩余额度本可以转换成更多实际工作效率。 另外，我从新闻中得知 Codex 用户可能获得一次可以自行决定何时使用的完全重置机会，并最终确认自己的账户已经到账。为了减少以后再次出现类似情况，我又创建了一个 Codex 重置预告监控：平时继续正常控制额度，一旦出现可信的 Reset 信号，再临时切换到更积极的使用策略。
-
2026 年 8 月 26 日，我在 Codex 第一周的第一个 5 小时使用周期中连续记录了三次剩余额度。通过对比「5 小时剩余额度」和「一周剩余额度」，可以估算出：一个完整的 5 小时额度大约相当于一周总额度的 15%。为了以后不再反复计算，我把使用规则简化成三个数字：5 小时看 10%，一天看 12%，15% 是 5 小时极限。 后续只需要观察 Codex 界面中的周额度变化，就可以快速判断当前使用速度是否合适。
-
2026 年 8 月 25 日，我继续验证通过 BeWild 购买的 ChatGPT Plus 3 个月套餐第 3 次续订情况。与 7 月 25 日第二个月成功续订不同，这一次 OpenAI 明确提示付款失败，原 PHP 982.14 账单未完成支付。等待 BeWild 客服超过 1 小时后，最终确认是用于向 OpenAI 自动续费的付款方式失效，随后未完成部分退款 ¥150.69。我重新购买 3 个月套餐，新订单一度任务失败，但通过“继续任务”最终完成。OpenAI 原 PHP 982.14 账单随后作废，并生成新的 US$20 已支付账单。等待系统同步后，ChatGPT Plus 恢复正常，并显示下一次自动续订时间为 2026 年 9 月 26 日。本文完整记录 BeWild 3 个月套餐第三个月自动续订失败、退款、重新订阅和 Plus 恢复的全过程。
-
A Tour of Go 日语版 ja-JP 正式上线后，我没有立即开始第三门语言，而是先复盘第二门语言从开发、翻译、质量审核、projection、production 部署到公网验收的完整过程，并将此前依赖临时分析和上下文记忆的环节固化为正式规范。项目新增 NEW_LOCALE_RUNBOOK.md 和 LOCALE_SURFACE_REVIEW.md，明确新增 locale 的统一入口、TranslationUnit 之外的完整语言质量审核、Rendered Surface Acceptance、首次生产部署与日常维护部署边界，以及 glossary 作为全站术语权威来源的职责，为后续第三门及更多语言建立可重复执行的标准化扩展流程。
-
A Tour of Go 多语言翻译项目的第二门社区语言 ja-JP 于 2026 年 8 月 24 日正式完成生产上线。日语版覆盖 103 个课程 Page 和 19 个 eligible Example，共 122 个 TranslationUnit，全部经过 automatic validation、Quality Check、Final Review 与 promotion，并完成公共 UI、课程目录、独立生产部署、Cloudflare Free、共享静态资源、Playground、SEO 与真实浏览器验收。Google Search Console 已成功处理 ja-JP sitemap 并发现 105 个公开网页。这次上线也真正验证了项目从 zh-CN 扩展到第二门语言的完整多语言架构。
-
本次重新评估 A Tour of Go 的 TranslationUnit 翻译方案，根本原因不是单纯比较模型能力，而是 ChatGPT 作为批量翻译引擎在实际工作中出现持续稳定性问题，即使从 ZIP 交付简化为 JSON，翻译任务仍可能卡住。实验使用 5 个正式 TranslationUnit、完整 zh-CN glossary、protected token、独立随机匿名和 Engineering Gate，对 ChatGPT GPT-5.6 High、Codex GPT-5.6 Sol High 与 Extra High 进行四模型匿名评审。结果显示，ChatGPT High 的外部评审平均分为 96.67，Codex High 为 95.73，Extra High 为 95.87，三者已进入相近的高质量梯队，而 Extra High 并未表现出稳定优势。综合翻译质量与本地批量执行能力，后续默认翻译引擎准备调整为 Codex GPT-5.6 Sol High，ChatGPT 则重点用于统一 Quality Check，并以所有 TranslationUnit 最终达到 A 作为质量验收目标。
-
在完成 A Tour of Go 简体中文 103 个课程页面后，我继续验证如何把现有约 94 分的工程性翻译质量进一步提升到 96～97 分。最初重点研究 minimal-protect，希望通过减少 protected token、保留更多原始上下文改善 GLM-5.2 译文，但后续对 157 个 protected token 的信息损失审计、Static Context 实验以及重复请求测试均未显示稳定质量优势，因此优化重点从 Protection Policy 转向 Translation Engine。本轮选取 methods/24、concurrency/7、concurrency/11 三个代表页，由 ChatGPT、Codex Sol 和 GLM-5.2 独立生成最终译文，再交给 ChatGPT、DeepSeek、GLM-5.2 和豆包进行 12 次匿名质量评审。ChatGPT 获得 8/12 第一名，即使排除自身作为评审模型后仍获得 5/9 第一名。现阶段不会立即覆盖已有 103 页，而是准备进一步验证自动化 ChatGPT retranslation staging，在统一 validator 和页面验证基础上评估是否值得全量重译。
-
A Tour of Go 简体中文 103 个正式发布页面完成自动翻译和结构校验后，我又进行了一轮完整的发布前正文质量审计。最终 87 页无需修改，14 页列为 C 类建议修订，2 页列为 D 类必须修订，共返修 16 页。本文记录这次审核如何区分可读性问题与技术误译，以及人工修订仍然必须经过同一套 validator 校验的过程，包括 methods/19 因少保留一个行内代码结构而被自动拒绝的代表案例。
-
在推进 A Tour of Go 多语言翻译项目的发布前正文审核时，我尝试将 ChatGPT 直接连接 GitHub，让它能够读取 go-tour-i18n 仓库中的真实源码和译文。本文记录实际连接与授权过程，以及连接完成后 ChatGPT 与 Codex 在项目中的新分工：ChatGPT 负责直接读取仓库、分析和审核，Codex 继续负责仓库级修改、测试与提交，从而减少过去需要手工转发仓库内容的中间环节。