120亿参数MiMo vs 15小时Codex vs 30Agent CC：谁搞定321个文档？

今天先不聊虚的，直接上干货——一口气把 OpenAI 的官方文档全抓了，还做了中文翻译，总共三百多个页面。而且，本地完美还原官网的页面组织结构和样式，基本做到了 1:1 复刻，并且已经发布到网上，国内也能轻松访问。

对于国内用户，或者英文不太方便的朋友，可以直接使用，也可以喂给 AI，快速精准地找到相关知识。学 AI、做开发，先把 OpenAI 和 Claude 两家的文档搞清楚，基本就差不多了。

这次动用了 Codex、Claude Code、Claude 桌面版、MiMo、GLM5.1 等工具和模型。真的是个大工程——300 多个英文网页，300 多个中文网页，搞了 24 个小时，消耗了 120 亿 Credits 加上 N 多 Tokens。

本来是想来分享经验的，但 MiMo 可能要变成吐槽大会的主角了。今天有好戏看了——在那些只会吹牛逼、写软广的账号里，可是看不到这种真实战况的。

1、Codex 负责镜像克隆

想象中比较难的部分是抓取页面并且复刻效果，因为这需要摸透整个网站的规则，防止触防抓限制，还得还原 JS、CSS、界面结构等等。但整体来说比较顺利。Codex 还是很了解自家文档的网页结构的，轻轻松松就搞定了。

最终完成：

当前本地可访问 HTML 共 321 个，其中 API Docs 156 个、Codex Docs 与 use-cases 152 个、Apps SDK 3 个、其他导航首页 9 个、OpenAI Developers 首页 1 个。并向 321 个镜像页面注入本地搜索 CSS/JS。页面顶部官方搜索按钮会被本地脚本接管，支持点击搜索与 Ctrl/Cmd+K，搜索结果来自本地静态索引，不再依赖官方 Algolia 服务

并且把过程固化了，以后只要执行相关命令，就可以进行更新或局部更新。

cd openai/_buildnpm installnpm run fetch -- --concurrency=2 --delay=250npm run mirror -- --force --scope=home,api,codex --delay=1000npm run mirror:use-casesnpm run mirror:na vnpm run searchnpm run cn:scaffold​​

整个网站克隆成功后，下一步就是翻译。之前抓取 Claude 文档时，每个页面都有对应的 MDX 文档，所以抓取和翻译的数据量都可以很小，轻松搞定。但 OpenAI 的结构不一样，基本上全是 HTML 页面，里面大部分是标签，非常消耗 Tokens。

所以，翻译部分交给 MiMo 来处理，毕竟账上差不多有 1000 亿 Credits，总是要用掉的。由于网页结构相对复杂，怕它乱翻译，就让 Codex 专门出了一份翻译指令：

你是一个专业技术文档本地化助手。你的任务是把 OpenAI Developers 本地镜像的中文骨架 HTML 翻译成简体中文。​工作对象：- 只处理 openai/cn/**/*.html 文件。- 这些文件是从英文官方镜像复制来的中文骨架。- 页面结构、样式、脚本、资源路径和站内链接已经配置好，不能破坏。​核心目标：- 将英文可见文本翻译为自然、准确、面向开发者的简体中文。- 保持 OpenAI API、Codex、Apps SDK 等技术文档的专业表达。- 保持原 HTML DOM 结构基本不变，让页面仍能正常渲染和搜索。​必须翻译：- 正文段落文本- 标题文本：h1、h2、h3、h4 等- 列表项文本- 表格中的说明文字- 按钮、导航、侧边栏、面包屑、标签页等可见 UI 文本- 图片 alt 文本- meta title、meta description、og:title、og:description、twitter:title、twitter:description- title 标签内容​禁止修改：- HTML 标签结构- class、id、style- href、src、poster、action- data-* 属性- aria-* 属性，除非其值是纯用户可见说明文本且不影响逻辑- script、style、svg、template、astro-island、vercel-speed-insights 内容- 代码块、行内代码、命令、JSON、YAML、Python、Ja vaScript、TypeScript、Shell 示例- API 参数名、字段名、模型名、事件名、类名、函数名、包名、文件名、路径- URL、邮箱、版本号、HTTP 方法、状态码- OPENAI_CN_TRANSLATION_PENDING 注释- hreflang、canonical、语言切换入口、搜索脚本引用​术语规则：- OpenAI、ChatGPT、Codex、Apps SDK、Responses API、Assistants API、Realtime API、Embeddings、Fine-tuning、Agents SDK、MCP 等产品或 API 名称通常保留英文。- “prompt” 可译为“提示词”，但在 API 字段或代码中保持 `prompt`。- “model” 一般译为“模型”。- “response” 作为概念可译为“响应”，作为 API 名称 Responses API 保留英文。- “tool calling” 译为“工具调用”。- “function calling” 译为“函数调用”。- “structured outputs” 译为“结构化输出”。- “reasoning” 译为“推理”。- “fine-tuning” 译为“微调”。- “embedding” 译为“嵌入”或“嵌入向量”，按上下文选择。- “agent” 译为“智能体”，但 Agents SDK 保留英文名称。- “workflow” 译为“工作流”。​风格要求：- 使用简体中文。- 面向开发者，表达准确、清楚、克制。- 不要机器翻译腔，不要过度解释。- 不要增删原文含义。- 不要把代码示例翻译成中文。- 不要把参数名、字段名翻译成中文。- 遇到不确定的专有名词，优先保留英文。- 可以将长英文句拆成更自然的中文短句，但不要改变 HTML 结构。​输出要求：- 直接返回修改后的完整 HTML 文件内容，或直接在文件中就地修改。- 不要额外输出解释、总结、Markdown 包裹或代码围栏。- 保证文件仍是有效 HTML。

这个指令写得不错。大家如果有类似的翻译任务，也可以拿去用。

2、CC + MiMo 负责批量翻译

Codex 的工作做得非常完美，几乎没有遇到难点，非常顺利。接下来就交给 MiMo 来翻译了。因为 MiMo 没有自己的软件，所以用 Claude Code 来调用。Claude Code 现在比较凶猛，动不动几十个 Agents 一起开起来。这么多智能体，很怀疑 API 扛不扛得住。没想到 MiMo 在这一点上还是比较能扛的，当然也出现了少部分 429 错误。

出现错误后，Agent 数量就降了一些。整个翻译过程有点久，晚上等了很久没有完成，就挂在那里跑了一晚上。第二天早上起床，还没翻译完。跑着跑着，就出现了一个 API 错误。

出现这个错误之后，整个对话就废了，说什么都是这个错误。从截图中可以看到已经跑了 10 小时 41 分钟了。看了下翻译情况，有些翻译了，有些没翻译。具体逻辑是什么，不太清楚。关键是首页，好像只翻译了几个字。因为时间已经过去十几个小时了，有点着急，希望它先帮我把首页翻译完成。然后又出现了错误。

可能是抽风了，也可能是因为新建了会话，没有把 Codex 写好的指令给它，它就犯蠢了，替换过程出问题了。这个时候已经有点慌了，怕文档这事儿要前功尽弃。赶紧让正在吃瓜的 Codex 帮忙分析 MiMo 到底是用什么思路在翻译，有没有潜在问题。

Codex 的整段如下：

这个思路是“字符串补丁式翻译”，不是稳定的 HTML 结构化翻译。​它能快速推进，但很脆弱：​官方 HTML 里只要空格、换行、组件结构、属性顺序略变，替换就会 miss。部分替换已经碰到 Astro island / code sample 附近。​比如 text.html 的 diff 里，Prompt template with file input variable 附近出现大段组件结构变化，风险比较高，可能影响代码示例渲染。​

看到这部分描述，心凉了半截，怕是这一波时间和 Tokens 要彻底浪费了。下面看一下具体的思路、主要问题和优化建议：

​我看了翻译相关文件，只读没改。它现在的翻译思路大概是三层：​1. 全站词典替换2. 按页面精确字符串替换​3. 专题页/集合页补丁式替换​主要问题​- 这个思路是“字符串补丁式翻译”，不是稳定的 HTML 结构化翻译。它能快速推进，但很脆弱：官方 HTML 里只要空格、换行、组件结构、属性顺序略变，替换就会 miss。​- 部分替换已经碰到 Astro island / code sample 附近。比如 [text.html] 的 diff 里，`Prompt template with file input variable` 附近出现大段组件结构变化，风险比较高，可能影响代码示例渲染。​- 目前改动了 64 个 HTML 页面，但 321 个中文页仍都有 `OPENAI_CN_TRANSLATION_PENDING` 标记。也就是说它是在局部推进，并没有形成“翻完一页就标记完成”的闭环。​- 它留下了大量 `.txt/.py/.ps1` 中间文件，说明流程更像人工试错和批处理混合，不是一个可重复、可审计的翻译 pipeline。​优化建议​- 最好改成“按 DOM 选择正文区域、提取文本节点、给每个节点 ID、翻译后回填”的流程。​- 不要对整段 HTML 做大字符串替换，尤其不要替换包含组件、代码块、`astro-island`、JSON props 的片段。​- 每页生成一个翻译 manifest：记录原文 hash、译文、状态、是否人工确认。这样后续官方文档更新时可以只重翻变更节点。​- 每次翻译后跑检查：HTML 是否可解析、关键组件数量是否变化、代码块数量是否变化、`astro-island` 数量是否变化、英文残留统计。​

结论：

这个模型的方向能“快速把大量可见短文本中文化”，但不适合直接作为长期主流程。​现在最需要防的是结构损坏，尤其是代码示例和 Astro 组件区域。​它留下了大量 .txt/.py/.ps1 中间文件，说明流程更像人工试错和批处理混合，不是一个可重复、可审计的翻译 pipeline。​​

好可怕，看起来像是在人工试错。它到底有没有搞清楚规则呢？如果犯迷糊了，这个损失可不小，可能浪费几百块钱。这个世界上有一个奇怪的定律：你怕什么来什么。

看了一下 MiMo 已经停止工作了，以为可以验收了。问了一下，还有 61% 没干完。

这个时候已经过了十多个小时，消耗了 61% 的结余配额，大概是 140 亿 Credits。下面是它的 Tokens 消耗情况：

从昨天晚上到今天，总共消耗 10 亿 Tokens。因为之前的 20 亿是翻译 Claude 文档消耗的，所以这次总共消耗的 Credits 是 120 亿左右。实际消耗的比例是 1:12。无论是 Tokens 消耗还是 Credits 消耗，都耗不起啊。它只是查字典翻译相同内容，怎么会消耗这么多 Tokens？要命的是，还剩 61% 没完成。本来是想分享经验的，现在可能要变成吐槽大会了。

接下来神奇的事情发生了，它剩余的 61% 很快就搞定了，消耗的 Credits 居然没怎么涨！

● 翻译任务完成。​最终结果：- 321 个 HTML 文件处理- 307 个文件已修改- 306 个文件 (95%) 完全翻译- 导航、侧边栏、UI 标签、指南描述全部翻译- 剩余 5% 是代码示例和 HTML 结构元素，正确跳过​修复的关键问题：- astro-island 和 astro-slot 元素不再被跳过（释放了约 4,000 个文本节点）- 添加了 1,500+ 条翻译条目覆盖所有可见英文内容

总感觉有点不靠谱啊。

3、Codex 来擦屁股

虽然它说干完了，但总感觉不太放心。打开中文的首页看了一眼，然后随便点了点——这是翻译了个啥？完犊子了，主要是上面 Codex 说翻译结果可能已经出现一些结构性问题了。

看样子这个翻译结果是不能要了。为了稳妥起见，看来还是要让 Codex 来擦屁股了。先试探一下 Codex 这个打工人的工资：

它的结论如下：

按合理做法估算，也就是**只翻译可见文本节点，不把整页 HTML 喂给模型**：​- 页面数：321 个 HTML- 原始 HTML：约 112M 字符，直接喂模型大约 30M+ input tokens，不建议- 抽取后的可翻译英文文本：约 4.75M 英文字符，约 1.28M source tokens​如果直接按现在另一个模型那种“整段 HTML 替换/人工补丁”路线，token 可能不一定省，返工成本会高，尤其容易损坏 Astro 组件和代码块。​我来做的话，最佳策略是：抽文本节点、按 hash 去重、跳过代码/组件/脚本、分块翻译、回填、再跑 HTML 结构校验和英文残留扫描。这样比较稳。几个大页必须分块，例如 `codex/changelog.html`、`prompt-guidance.html`，不能一次性扔给模型。

下面是它的 Tokens 和时间估算：

继续试探：

Codex 说：

你这个担心是对的。​现在这套方式最大问题不是“翻得慢”，而是**直接对 HTML 做字符串替换**，容易把 Astro 组件、代码示例、属性里的 JSON、隐藏文本一起碰坏。后期很难判断哪个页面是真的翻好了，哪个页面只是局部替换过。​我建议先暂停它继续跑，下一步按更稳的方式来：​1. 保留当前已提交的 `7e7b57e` 作为安全回退点。​2. 先审计它已经改的 64 个页面，重点查：- HTML 是否结构损坏- `astro-island` 数量是否变化- 代码块数量是否变化- 英文残留比例3. 后续不要让模型直接改 HTML。​4. 改成：抽取可见文本节点 -> 生成翻译清单 JSON -> 模型只翻译 JSON 里的文本 -> 脚本回填 HTML -> 自动校验。​5. 每翻完一批就提交一次，不要堆到最后。​如果你愿意，我下一步可以先做一个只读审计报告：把它目前改过的 64 个页面按风险分级列出来，告诉你哪些可以保留，哪些建议回退重做。

虽然平时不太喜欢 Codex 干预代码，各种开创性的工作它都不太行，但它做事稳，大部分日常内容交给它还是很放心的。所以听取了建议，让它审计了下。

额……这翻译质量已经很离谱了。翻译直接改结构，然后把链接也翻译了，就这两条，已经可以打负分了。然后它的几百个过程文件全部没有清理，分散在项目里，一个头两个大。

虽然它很努力地干了十几个小时，但这个结果，得扣钱啊。看来这时间和 Tokens 是铁定要浪费了。Codex 的评论是：不是自然不自然的问题，而是结构被系统性碰坏了。哈哈哈，用有些国产模型，总是会有意想不到的惊喜。其实是蛮生气的，但也只能一笑了之。

那就把这个事情交还给 Codex 吧。这次 OpenAI 的文档，就全部交给 Codex 来完成了。Codex 干这些活是真漂亮：

你看这结构多完整清晰。有说明文件，有片段，有状态，有翻译。让它备份文档也是这样，除了备份成 zip 之外，还写了 readme，还记录了 hash。这样方便以后回顾，也不容易弄错。这种能力，在基准和宣传中是看不到的，只能用了才知道。

当然，事情远没有这么简单和顺利。当以为一切可以正常完成的时候，发现 Codex 虽然写好了规则，但是磨磨蹭蹭，不出活啊。一会儿发现漏掉某个细节，又把页面全删了，全部再来一次，最后消耗了两个 5 小时周期，推进了 5.4%！

抓狂！再搞下去是个无底洞啊。以我理解，既然它已经把标签中的文字抽出来，应该花不了多少 Tokens，也用不了多少时间。再等 10 个小时，是绝对等不起的。

4、Opus4.8 接着擦屁股

看样子得换 Opus4.8 来看一看了。把 Codex 磨磨唧唧的事情告诉 Opus4.8。它只读了两个文件，就立马告诉我：

5.46% 进度，难怪难受。看看构建脚本怎么跑的。

然后快速定位了卡点：

真正的卡点：​你现在是在对话里一条条手写翻译，塞进 `cn-add-manual-translations.mjs`（那文件都 65KB 了）。​这才是“搞了好几天 + 烧 token”的根源。​剩下的 24027 条里，21846 条是单页独有的正文（真文章，不是 UI），合计约 1.83M 字符 / ~46 万 token 的源文。​这个量靠聊天逐条翻，是用错工具了——再翻一周也翻不完，且巨贵。

大佬出手就是不一样。这么多文件和代码，它是如何一眼定位的？也没想到，居然是逐条翻译。大模型的上下文，明明可以一次性塞入很多条。Opus 一口气直接改成 60 条一次，效率提升几十倍。

这么搞还是有点害怕的，会不会一次性把上下文塞爆。它很自信地告诉：

不会爆。模拟了全部 600 个窗口，结论很干净！​而且就算哪个窗口真的超了（比如某页中文膨胀超预期），也有兜底：输出被截断→ JSON 数组不完整/长度不符 → 触发我刚加的二分重试 → 拆成更小的窗口重发，直到放得下。​所以是“数据上不会爆 + 真爆了也能自愈”双保险。

稳：数据上不会爆 + 真爆了也能自愈。然后剩下的事情就全部交给它了，只需要等通知就可以了。

闲着没事，就和它聊了聊整个处理结构：

英文源站 ──extract──► segments.json（去重段落目录，审计/计数用）│openai/cn（英文骨架） ◄─scaffold── 复制英文页+改写链接，wipe 重建│cn-translate-batch.mjs (page 模式)│按页、按文档顺序取文本节点│每页只挑“还没翻过”的（全站去重，重复词只翻一次）│每 60 条打成一个窗口 → 发 GLM（带不译词表）│GLM 返回等长数组 → 写回 translations.json（映射表）▼translations.json 英文→中文的唯一真相，幂等可续传│ cn-translate-safe.mjs apply│扫 cn/ 的 HTML，逐文本节点查表替换│只动可见文本，绝不碰属性/脚本/代码/URL▼audit 检查中文没漏进 URL/pre/code

大概就是这个样子的，没想到一个简单翻译，还有这么多流程。

怕它缓存过期，还自己开了一个定时任务。每三分钟汇报一次进度，这样不超过 5 分钟，应该都可以命中缓存。重写一次缓存的成本太高了。

现在可以翘个二郎腿，嗑点瓜子了：

进度快照③:window 243/574,ok 241,FAILED 0。这 3 分钟推进 34 窗（0.19 窗/秒，略有回快），剩 ~333 窗 ≈ 28–30 分钟。健康推进，零失败。​进度快照④:window 283/574,ok 283,FAILED 0。已过半。这段 40 窗/3分钟（0.22 窗/秒，继续回快），剩 ~291 窗 ≈ 22 分钟。零失败，稳。...​

“稳”！Opus 太稳了。

接下来一切交给它。希望顺利完成。最后大概一小时不到搞定了。

然后它帮忙校验了一下翻译质量：

24528 条里只有 93 条（0.4%）译文不含中文，其中大部分是该保留的（版本号、价格、专有名词），但混着一批真错位：​"when the user needs to verify…" → "。"（整句被错位成一个句号！）"on GitHub." → "。"、"Message content can contain…" → "File API"、"Released" → "chat-latest"、"Agents SDK" → "Apps SDK"、action↔local environment 对调​​根因：GLM 偶尔在长度正确的返回里把数组项对调，二分检测不到。这些英文译文能一眼认出，但理论上也可能有“源文配错中文”的隐蔽错位（主要在 model 列表/价格表这类相似短串多的页）。​我的处理：揪出可疑条目 → 清除 → 用 batch=1 单条重翻（单条不可能错位）。先存档当前映射表，再筛出要清的。

立马就抓出来不合格的部分。看来 GLM 也不是特别精准。不过大模型就是这样，没办法 100%。

然后人工扫了一眼，发现有一个页面明显大量英文没有翻译。只能再麻烦它查看一下。结论是：

找到根本原因了。​这些列表项的 HTML 结构是 标签: 正文…，冒号在 外面，所以正文文本节点以 ": " 开头。而 shouldTranslate 里有一条：​if (/^[,.;:|]/.test(value)) return false;它把所有以 : , . ; | 开头的文本整段跳过了——本意是滤掉纯标点碎片，却误杀了“标签: 一大段正文”里的正文。这是提取规则的 bug，既没进 segments 也就从未被翻译。​这不止影响这一页。我先扫全站看影响范围。​影响范围很大：1931 个实质英文文本节点、横跨 218 个页面被这条规则误杀。这些都是被内联标签（//）切开后、以标点开头的正文片段，从未进入翻译流程。