今天来展示个组合技我一口气把 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/CmdK搜索结果来自本地静态索引不再依赖官方 Algolia 服务并且把这个过程给固化了以后只要执行相关的命令就可以进行更新或者局部更新。cd openai/_build npm install npm run fetch -- --concurrency2 --delay250 npm run mirror -- --force --scopehome,api,codex --delay1000 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 ->这么多智能体我们很怀疑 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 预算时间只翻译不严格 QA3M-5M tokens4-8 小时翻译 结构校验 英文残留扫描 局部返工5M-8M tokens1 个工作日左右高质量翻译 重点页面人工/视觉抽查 大页分块优化8M-12M tokens1-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 列表/价格表这类相似短串多的页)。 ​ 我的处理: 揪出可疑条目 → 清除 → 用 batch1 单条重翻(单条不可能错位)。先存档当前映射表,再筛出要清的。立马就抓出来不合格的部分看来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.8GLM5.1 和 GPT5.5MiMo 的对比是不是很让人震惊样式和布局与官网是一模一样的还原度极高。不看地址栏根本分不清是官网还是镜像。目前看了一下还有一些细节需要修复但是我已经有点疲惫了英文文档 100% 可用中文文档大部分都可用我就先存档、上传、发布了。做个总结这个问题其实在我是我轻敌了。我以为翻译很简单但是没想到页面结构的复杂性。比如代码区域、嵌套区域、转义标签、链接、注释、英文提示词包含多种名词、专有名词有些是必须翻译的有些是不能翻译的。直接让 MiMo 自己创建了翻译规则然后 GPT5.5 又在它的基础上修改Opus4.8 又得顺着之前的基础改一旦第一步走错了没有选择最优路径后来者就很容易在这个错误的方向越走越远时间成本越来越高账单越来越长还好我 O 哥有魄力立马就把卡点给解决了最后再给大家一个数据这是 GLM 5.1 完成所有翻译的消耗情况只消耗了 1.43M现在再回过头来对比一下 Codex 的 GPT5.5MiMo 和 Opus4.8GLM5.1 的时间和 Tokens 的差异会有惊人的发现GPT5.5 大概用了 3 个 5 小时周期按它的高分周配额消耗完也搞不完MiMo 用了 140 亿 Credits翻译结果混乱。Opus4.8 用了半个 5 小时周期GLM 大概 1 百万多 Tokens同样的一件事情同样叫大模型最后在成本和效率上的差距真的是天差地别我测过很多模型最让我生气的是不但不提升效果反而浪费时间然后影响心情我的真香定律是能选的话永远选最聪明那个大量文档处理没有好的方案实在是太烧钱了。我的沉默成本已经无法收回了大家一起用吧甲维斯的知识库-JarvisDocs目前已经把最强的两个平台 Claude 和 OpenAI 的文档全部搞定包含英文原版和中文翻译版