[🛠] 多语言博客 Codex Goal 为什么花了 13 小时以上

✨ GPT-5.5 的摘要 　

记录推进 Codex Goal，将 hyuk.blog 从 /en/ 英文版扩展到 8 个 locale 运营标准的过程，以及翻译质量、语言切换、浏览量共享、p 规则和使用量成本的重新整理。

一开始我以为只要选 /en/ 就够了

最初的问题很简单。

en.hyuk.blog 会更好吗？
/en/ 会更好吗？

综合考虑 SEO、GitHub Pages 运营、原文与译文的连接、浏览量共享，以及未来要扩展的语言结构之后，结论是 /en/。

这个博客并不是要把英文版当成完全独立的产品来运营。它是以韩文原文为基准，再附上翻译的结构。这样的话，在同一个域名里分出语言 URL，并用 hreflang 连接起来会更简单。

但事情并没有到此结束。

一旦选择 /en/，首页、About、分类、搜索、sitemap、language switcher、浏览量、翻译质量，以及以后文章 push 的方式，全都开始一起移动。

问题不是翻译文件，而是 collection 边界

英文文章不能混进 _posts。

在 Jekyll 里，_posts 会进入 site.posts。如果把英文文章混进去，韩文首页、feed、pagination、related posts 都会悄悄吃进英文文章。表面上只是多了一篇文章，实际上整个博客索引都被污染了。

所以翻译文章按 locale collection 分开。

_posts/...         -> /daily-review/.../
_en_posts/...      -> /en/daily-review/.../
_ja_posts/...      -> /ja/daily-review/.../
_zh_hans_posts/... -> /zh-Hans/daily-review/.../

第一个教训很明确。

多语言博客不是添加翻译文件，而是划清 collection 边界。

当时的 Goal 归档

这项工作从 2026 年 6 月 7 日开始，一直持续到 2026 年 6 月 8 日。

一开始看起来只是加一个英文版。但 Goal 很快扩大成这样。

把 hyuk.blog 转换成以 ko 为默认 locale，并支持 en、ja、zh-Hans、es、pt-BR、fr、id 扩展 locale 的可运营多语言博客。
不只是翻译，还要对齐 UI、routing、SEO、sitemap、search、language switcher、浏览量共享和 today dedupe。
从 Tadak Bible 宣传、作品集价值、基督教人口和扩展性的角度选择语言。
不使用付费翻译 API。
翻译采用最新 GPT worker/subagent 标准。
不信任低质量本地翻译结果。
韩文原文未确认前不翻译。
修改文章并执行 p 时，也同步 active locale 翻译。
build 不在每个翻译 batch 后运行，而是在最后按需要确认。

Goal 本身并不是错的。

问题是它没能缩小成执行标准。状态报告、检查项目和翻译范围不断贴上去，最后变得太大。

翻译质量狠狠打了一次

最先失去信任的是翻译。

一开始我以为批量翻译很多文章就行。结果样本里出现了把 prompt 指令原样混进正文的文件。

Return only the translated content. Do not add notes or fences.

这不是几句不自然的问题，而是生成路径本身不可信。

所以我重新抽样判断：低质量翻译是该检查后抢救，还是直接重新生成。结论是重新生成。Ollama、Argos 这类本地翻译结果很难达到公开文章的信任标准。比起生成速度，更重要的是由什么模型生成，又通过了什么门槛。

留下来的标准很清楚。

翻译先看信任路径，再看完成率。
原文确认前不翻译。
公开文章翻译不能用低质量本地 MT 糊过去。

语言切换和浏览量也一起动摇了

英文页面可以直接打开。

但用户找不到韩文/英文切换。

最初我把 English / Korean 放进普通菜单里。HTML 里有，但用户看不到。移动端更糟。所以标准变明确了：语言切换不是菜单项，而是 global control。

浏览量也没有说起来那么简单。

英文文章不是另一篇文章，而是同一篇文章的翻译。/daily-review/x/ 和 /en/daily-review/x/ 不能使用不同的浏览量 key。所以 HTML 的 data-page-view-path、客户端 JS 和 Cloudflare Worker 都改成按去掉 locale prefix 后的 canonical path 统计浏览量。

这里的事情也变大了。只改 Worker 代码并不够。还需要用 Wrangler CLI 部署，而且 dry-run 里也看到了 D1 DB binding 可能缺失的信号。所以我把 Worker entrypoint 和 D1 binding 固定到 wrangler.toml 这个 repo 配置里，确认 binding 存在后才部署。

特别重要的是 today dedupe。

同一篇文章先用韩文读，再切到英文，today 不能增加两次。只要 canonical page 相同，dedupe key 也必须相同。

为什么 Codex Goal 达成花了 13 小时以上

这并不是说纯开发时间本身就是 13 小时。

问题在于，挂在 Codex 里的 Goal 到达完成状态花了 13 小时以上。

这不只是因为工作量大。有些判断一直在摇摆。

我同时抓着全量翻译和检查不放。“全部生成后再检查”还是“边生成边检查”，标准在中间摇摆。没有先确认 worker 模型就相信翻译质量，结果出现坏翻译后又要重做。

原文确认前就翻译也是问题。

公开韩文文章还在变，先做的翻译当然会错位。结果就是重写原文、丢掉已有翻译、再翻译一次。

build 的判断也摇摆了。

如果每个翻译 batch 后都跑 build，工作就不会结束。build 是重要检查，但不是每次都要重复的仪式。必须先锁定原文和翻译范围，再在最后按需要检查。

p 的含义也很晚才明确。

现在，只要涉及 post 修改，p 就不是简单 commit/push。它意味着先把已确认原文的 active locale 翻译同步好，再 push。

使用量也是成本

这次翻译工作不是只要避开付费 API 就结束的问题。

前一天刚付费的 Pro x20 周使用额度，在两天内从 100% 降到了 50%。

这次消耗是盲目并行生成翻译、重做失败翻译、原文改变后再次翻译的判断成本。没有使用付费翻译 API，不代表成本为 0。模型使用量、时间、注意力和检查疲劳全都是成本。

所以以后必须先锁定这些。

原文确认
翻译范围
检查方式
build 时点
push 标准

这五个不清楚，多语言工作很快又会膨胀。

这次留下的运营标准

这次留下的标准比功能本身更重要。

语言 URL 在同一个域名内拆分。
翻译文章放在 locale collection 中。
翻译先看信任路径，再看完成率。
原文确认前不翻译。
语言切换必须是始终可见的 global control。
浏览量和 today dedupe 以 canonical page 为基准。
post 执行 p 时也要同步 active locale 翻译。
build 不按 batch 跑，而是在最后按需要确认。
Goal 必须缩小成执行标准，而不是变成长状态报告。

加上英文版当然重要。

但更重要的产物，是让博客在多语言状态下继续运营的标准。

学得很贵。

但这是必要的标准。