MiMo的120亿，Codex的15小时，CC的30个Agent,搞定OpenAI的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/_build
npm install
npm run fetch -- --concurrency=2 --delay=250
npm run mirror -- --force --scope=home,api,codex --delay=1000
npm run mirror:use-cases
npm run mirror:nav
npm run search
npm 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、JavaScript、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 这个打工人的工资：
如果让你来做，这些文档全部翻译好大概需要消耗多少时间和 Tokens？
它的结论如下：
按合理做法估算，也就是**只翻译可见文本节点，不把整页 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和时间估算：
| 方案 | Token 预算 | 时间 |
|---|---|---|
| 只翻译，不严格 QA | 3M-5M tokens | 4-8 小时 |
| 翻译 + 结构校验 + 英文残留扫描 + 局部返工 | 5M-8M tokens | 1 个工作日左右 |
| 高质量翻译 + 重点页面人工/视觉抽查 + 大页分块优化 | 8M-12M tokens | 1-2 个工作日 |
我继续试探：
我觉得慢点没关系，但是它这个太乱了，我有点不放心。
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 太稳了，以后它就是我 O 哥。
接下来一切交给 O 哥！
希望顺利完成！
最后大概一小时不到搞定了！
然后 O 哥帮我校验了一下翻译质量：
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%！
然后我人工扫了一眼，发现有一个页面明显大量英文没有翻译。
只能再麻烦 O 哥帮我查看一下，它的结论是：
找到根本原因了。
这些列表项的 HTML 结构是 <strong>标签</strong>: 正文…,冒号在 <strong> 外面,所以正文文本节点以 ": " 开头。而 shouldTranslate 里有一条:
if (/^[,.;:|]/.test(value)) return false;
它把所有以 : , . ; | 开头的文本整段跳过了——本意是滤掉纯标点碎片,却误杀了"标签: 一大段正文"里的正文。这是提取规则的 bug,既没进 segments 也就从未被翻译。
这不止影响这一页。我先扫全站看影响范围。
影响范围很大:
1931 个实质英文文本节点、横跨 218 个页面被这条规则误杀。
这些都是被内联标签(<strong>/<a>/<code>)切开后、以标点开头的正文片段,从未进入翻译流程。
这个提取脚本是 GPT5.5 写的，当然也有可能是从 MiMo 那边迁移过来的。
屎山代码的传承！一代又一代！
问题一旦反复，就会消耗大量的精力！现在呢就是消耗大量的 Tokens！
软件工程永远是一个复杂的工程。
最后经过几个工具和模型的轮番上场，终于把翻译这个事情完成了 99%！
Opus4.8+GLM5.1 和 GPT5.5+MiMo 的对比，是不是很让人震惊？
样式和布局与官网是一模一样的，还原度极高。不看地址栏，根本分不清是官网还是镜像。
目前看了一下，还有一些细节需要修复，但是我已经有点疲惫了！
英文文档 100% 可用，中文文档大部分都可用，我就先存档、上传、发布了。
做个总结
这个问题，其实在我，是我轻敌了。
我以为翻译很简单！但是没想到页面结构的复杂性。
比如代码区域、嵌套区域、转义标签、链接、注释、英文提示词，包含多种名词、专有名词，有些是必须翻译的，有些是不能翻译的。
直接让 MiMo 自己创建了翻译规则，然后 GPT5.5 又在它的基础上修改，Opus4.8 又得顺着之前的基础改！
一旦第一步走错了，没有选择最优路径，后来者就很容易在这个错误的方向越走越远，时间成本越来越高，账单越来越长！
还好我 O 哥有魄力，立马就把卡点给解决了！
最后再给大家一个数据：
这是 GLM 5.1 完成所有翻译的消耗情况，只消耗了 1.43M；
现在再回过头来对比一下 Codex 的 GPT5.5+MiMo 和 Opus4.8+GLM5.1 的时间和 Tokens 的差异，会有惊人的发现！
GPT5.5 大概用了 3 个 5 小时周期，按它的高分，周配额消耗完也搞不完，MiMo 用了 140 亿 Credits，翻译结果混乱。
Opus4.8 用了半个 5 小时周期，GLM 大概 1 百万多 Tokens！
同样的一件事情，同样叫大模型，最后在成本和效率上的差距，真的是天差地别！
我测过很多模型，最让我生气的是：不但不提升效果，反而浪费时间，然后影响心情！
我的真香定律是：能选的话，永远选最聪明那个！
大量文档处理，没有好的方案，实在是太烧钱了。
我的沉默成本已经无法收回了，大家一起用吧：
目前已经把最强的两个平台 Claude 和 OpenAI 的文档全部搞定！包含英文原版和中文翻译版！
关于作者
tony
某人