3天烧掉820亿Tokens！MiMo与Opus组合拳实战全攻略

June 13, 2026

3天烧掉820亿Tokens！MiMo与Opus组合拳实战全攻略

前脚刚把 MiMo 送的 16 亿配额磨掉 25%，早上一刷新，账户余额直接拉满到 820 亿——这数字膨胀得我数零都数了好几遍，恍惚间甚至想问问能不能折现成人民币！

这波操作属实离谱，数字一个比一个夸张。

更劲爆的是，MiMo 同步宣布了 API 永久降价，降幅高达 99%！

具体的细则还没来得及深究，但第一反应是：这是冲着 DeepSeek 那个永久 2.5 折去的吧？两家明显在较劲啊。

话又说回来，不管动机是什么，对用户而言都是实打实的利好。卷价格、卷规模、卷能力，这种行业竞赛越多越好！

唯一的遗憾是，这个月就剩三天了……额度重置加上 N 倍叠加，这波操作的时间窗口真叫人哭笑不得。

cc1fbe83-4fb9-4217-9c01-9078760db048-crop

虽说是“纯度”不高的 Tokens，但这个体量摆在这儿，实打实地能用。问题随之而来——三天时间，820 亿到底怎么烧？

上一次我分享过一个思路：去问不同的 AI，怎样才能快速耗尽 Tokens。后来我按照它们的建议做了一个武侠知识库《江湖百晓生》，不过 MiMo 生成的版本效果一般，没能用起来。

接着我又另辟蹊径，做了一个文档网站——把 Claude 的整套 API 文档全部拉取到本地，然后让 MiMo 翻译成中文文档。

这个方案消耗 Tokens 的效率非常高，而且 MiMo 的翻译质量居然还过得去，比起硬啃全英文原始文档舒服太多了。

今天就重点复盘这个实战场景，顺带记录一下我是如何利用 Opus 4.7 + MiMo 这套组合拳来搭建整个网站的。

核心思路很明确：优质 Tokens 攻坚，普通 Tokens 铺量，二者各司其职，一个子儿都不浪费。

一、Opus 主攻高难度任务

第一步，让 Opus 啃掉最硬的骨头——网站分析、内容抓取、架构搭建。

先看一眼 Claude 官方文档站点：

整个网站数据体量不小，基本是全英文状态。虽然官网提供了中文选项，但翻译覆盖度差得远，不少页面残缺不全。

数据抓取这个活儿表面看是老手艺，实际上不同网站的防护策略五花八门，有些站点根本扒不动。所以第一步我先试探了一下是否能顺利拿到数据。

Opus 的回应是：没问题，看得到。

确认可行之后，我开始抛出完整需求：

我计划在当前项目目录下创建一个 `claude/api` 文件夹，用来搭建一套 Claude API 文档的本地化资料库。  
  
我的目标是把官网上的 Claude API 文档，按照网页原本的菜单结构下载到本地。这个网站有一个很方便的特点：每个页面都可以通过在网页地址后面添加 `.md` 后缀，直接获取对应的 Markdown 文件。  
  
因此，我希望先基于官网的菜单列表和页面结构，把这些 Markdown 文档下载下来，并按照原网站的层级关系保存到本地。默认下载英文版本，也就是 `en` 版本。  
  
在英文原版文档整理完成之后，我还希望基于英文版再生成一套中文版本，也就是 `cn` 版本。中文版的目录结构应该和英文版保持一致，只是内容翻译成中文。这样可以方便后续对照、维护和学习。  
  
最终，我希望基于这些本地 Markdown 文件，制作一个类似官网的本地文档网页。这个网页可以把 Markdown 转换成 HTML，并保留文档结构、导航菜单、标题、代码块、表格、链接等内容，方便我在本地查阅和学习。

Opus 拿到需求后立刻展开了分析，思路相当清晰：

1. 探索当前 MyDocs 项目结构，看看你已有的 md→html 框架长什么样（能不能复用）  
2. 验证 claude.com 文档站的 .md 接口和目录结构（导航树的获取方式）  
3. 估算文档规模和翻译成本  
  
我并行启动两个 Explore agent，再亲自抽取一两个 .md 端点验证。

分析结论也颇具含金量：

探索完毕。整体可行性分析如下：  
  
你的想法评估：✅ 方向正确，但有几个需要决策的细节  
  
# 好的部分（采纳）  
  
.md 后缀技巧已验证可用，所有页面都能拿到原始 markdown  
claude/api/ 占位目录你已经预留好了，与现有 MyDocs 结构对齐  
先英后中分两阶段是对的（先确保管线跑通再翻译）  
  
  
# 需要修正的部分  
  
不是纯 CommonMark，是 MDX：返回的 .md 文件包含 <Card>、<Tip>、<Steps>、<Tabs>、<CodeGroup> 等 JSX 组件标签。常规的 markdown-it / marked 不能直接渲染，必须做转换映射（mapping 到 styled <div>），否则页面会显示乱码标签。  
MyDocs 当前是纯手写 HTML，没有 md→html 管线：hermes-agent 那套是模板，但 ~150-200 页文档不可能手写。需要建一个构建脚本（fetch .md → 解析 MDX → 输出静态 HTML），一次性生成全部页面。  
侧边栏导航需要单独抓：sitemap.xml 有所有 URL，但没有 "Build with Claude > Messages API" 的分组顺序。需要从 /docs/en/intro 页面抓 sidebar HTML 或试 llms.txt。  
  
# 规模数据  
  
英文文档约 150-200 页，原始 markdown 5-15 MB  
多语言官方有 11 种（含中文），但官方中文质量不确定，自己翻译可能更可控  
  
# 推荐的改进版方案  
  
把整个流程脚本化（Python 单脚本，~3 个阶段）：  
  
fetch_docs.py    → 抓 sitemap + 所有 .md，存到 claude/api/_src/en/  
build_site.py    → MDX 组件 → HTML 映射，生成 claude/api/en/*.html + 侧栏  
translate.py     → 调 Claude API 批量翻译 _src/en/*.md → _src/cn/*.md  
                  （复用 build_site.py 生成 claude/api/cn/*.html）  
这样英文站和中文站共用一套构建逻辑，只是源 md 不同。  
  
在写最终方案到文件之前，几个关键决策需要你拍板：

这个总结相当到位，涵盖了对思路的肯定、需要修正的盲区、数据规模评估和改进方案，最后还把决策权交还给我。紧接着 Opus 列出几个关键问题等我确认：

上图里完整记录了我的选择和答复。拍板之后，就全权交给 Opus 4.7 了。它先是产出了一份详尽的执行计划文档，然后按步骤开始落地。

执行过程中它发现了一个意料之外的情况：

英文文档全量是 1541 页，远超我初估的 150-200。  
先验证 MDX 渲染再决定要不要全量。看一眼源文件结构：  
...

这个数据量属实夸张，我没办法一口气吃下，而且不确定全部文档是不是都有用。让 Opus 帮忙分析后得知，其中有 1197 篇属于不同语言的 SDK 文档，对我来说暂时用不上，就先跳过了。

最终抓取结果的汇总如下：

# 汇总（sitemap 1541 · 已抓 381 · 未抓 1197）  
  
# Part 1 — 已抓（按 tab / group）  
  ├ Tab: Messages (72) — 10 个 group 完整展开  
  ├ Tab: Managed Agents (30)  
  ├ Tab: Admin (25)  
  └ Tab: Resources (263)  ← 含 REST API endpoints 全部  
  
# Part 2 — 未抓（1197，9 SDK × 133）  
  ├ Python SDK (133)       ← <details> 折叠  
  ├ TypeScript SDK (133)  
  ├ Java SDK (133)  
  ├ Go SDK (133)  
  ├ Ruby SDK (133)  
  ├ C# SDK (133)  
  ├ PHP SDK (133)  
  ├ CLI (133)  
  └ Terraform (133)  
  
# Part 3 — 后期补抓指引（含代码模板）

最终成功抓取 381 个页面，整个过程异常顺滑，没有遇到任何报错，也没有触发频率限制。Claude 官网跑在 Mintlify 平台上，不清楚它的反爬机制到底什么强度，但 Opus 就是轻描淡写地搞定了。

它帮我搭建好的目录结构如下：

claude/api/  
├── index.html                       语言切换入口（en / cn 卡片）  
│  
├── en/                              ← 构建产物：英文站  
│   ├── index.html                   英文落地页（tab 卡片列表）  
│   ├── intro.html  
│   ├── get-started.html  
│   ├── build-with-claude/*.html  
│   ├── agents-and-tools/tool-use/*.html  
│   ├── managed-agents/*.html  
│   └── manage-claude/*.html  
│  
├── cn/                              ← 构建产物：中文站（结构镜像 en）  
│  
├── _src/                            ← 源 markdown（进 git，不上线）  
│   ├── nav.json                     抓取得到的导航树  
│   ├── en/*.md                      上游原始 MDX  
│   └── cn/*.md                      中文版（初期为英文占位）  
│  
├── _build/                          ← 工具链  
│   ├── package.json                 Node 依赖清单  
│   ├── fetch.mjs                    抓取脚本  
│   ├── build.mjs                    MDX → HTML 构建器  
│   ├── translate.mjs                中文骨架生成器  
│   ├── components.mjs               MDX 组件 React 实现  
│   └── templates/  
│       ├── page.html                文档页外壳  
│       └── landing.html             落地页外壳  
│  
└── _assets/                         ← 浏览器加载的样式与脚本  
    ├── docs.css  
    └── docs.js

同时配备了四个核心脚本，各司其职：

脚本	输入	输出	适用场景
`fetch.mjs`	`platform.claude.com` HTTP	`_src/en/*.md` + `_src/nav.json`	需要刷新上游内容时
`build.mjs [lang]`	`_src/<lang>/*.md` + `nav.json`	`<lang>/*.html` + landing	修改了源文件、模板或样式后
`translate.mjs`	`_src/en/*.md`	`_src/cn/*.md`	fetch 之后一次性执行
`inventory.mjs`	sitemap.xml + `nav.json`	`docs/claude-docs-url-inventory.md`	fetch 后想看完整 URL 清单

还贴心地附上了一份命令速查表：

cd claude/api/_build  
  
# === 抓取 ===  
node fetch.mjs                                                    # 默认: 11 页 allowlist (开发用)  
node fetch.mjs --tab=messages                                     # 单 tab 全部 (~72 页)  
node fetch.mjs --tab=managed-agents                               # ~30 页  
node fetch.mjs --tab=admin                                        # ~25 页  
node fetch.mjs --tab=resources                                    # ~38 页 (不含 EXTRAS)  
node fetch.mjs --all                                              # 4 个 tab sidebar 全部 (~155 页)  
node fetch.mjs --all --with-extras                                # ↑ 再 + EXTRAS (sitemap 补抓) = 381 页  
  
# 调节速率（默认 concurrency=3 delay=150ms）  
node fetch.mjs --all --with-extras --concurrency=2 --delay=250  
  
# === 构建 ===  
node build.mjs en        # 输出 en/*.html  
node build.mjs cn        # 输出 cn/*.html  
  
# === 中文骨架（仅复制，无 LLM）===  
node translate.mjs  
  
# === 一条龙：fetch + build en + scaffold cn + build cn ===  
npm run all  
  
# === 重新生成 URL 清单（汇报工具，不抓取）===  
node inventory.mjs       # 输出 docs/claude-docs-url-inventory.md

通过这些脚本，既可以精准抓取指定范围的内容，也能快速把 Markdown 文档编译成网页，还能驱动翻译流程，甚至可以一条龙全自动跑通。

有意思的是，Opus 考虑到翻译环节的 Tokens 消耗会非常大，所以它选择功成身退——把翻译任务的框架搭好、源码写齐，但把实际执行留给了我。它显然不想挥霍自己的 Tokens 配额。

于是它的活儿到这里就告一段落：

总计修改了 20 万行内容！目标网站的分析报告、执行报告、汇总报告全部齐全。源码自然也全部就位，特别是 MDX 到 HTML 的转换器，写得非常扎实。

现在只需要一条命令，就能把所有 Markdown 文档一键编译成静态 HTML 网页，轻松构建一个完全离线的 Claude 中文文档镜像站。

有了这套资料库，以后只要是 Claude 相关的问题，AI 就能给出精准到可怕的答案了。

二、MiMo 接手高消耗任务

核心骨架已经搭好，接下来轮到 MiMo 登场了。

问题的边界被 Opus 4.7 划定得极其清晰——全部结构都已就位，所有待翻译的英文文档静静躺在 cn 目录下。

我要做的只剩一件事：让 MiMo 读取这些文档并完成翻译，仅此而已。翻译完毕后再跑一下 Opus 留下的构建脚本，网页就自动生成了。

具体操作非常简单，打开 JCode：

把 cn 目录直接拖到 Xiaomi 图标上，Claude Code 就启动了：

模型和 API 相关参数已经自动配好了，完全不需要手动调整。

接下来下达指令简洁得离谱：“帮我读取所有文件，把其中的英文文档翻译成中文”。

然后就可以撒手不管了。它会自动遍历文件、自主判断策略、并行调度多个智能体协同翻译，整个流程一气呵成。

几个小时后，几百份文档全部翻译完毕，一笔勾销了几个亿的配额——正好把之前 16 亿中那 25% 的消耗任务给填上了。

这套组合拳打下来，体验相当不错！

三、总结

现阶段的 AI 能力已经非常强大，真正稀缺的是新鲜且准确的知识供给。所以为自己（也为 AI）搭建一个专属知识库这个方向，绝对值得投入。

恰好现在 Tokens 充裕得不像话，不如趁机把各种优质文档一次性“捞”到本地，全部转成中文版本。英文 Markdown 源文件给 AI 做知识注入，翻译后的中文网页留给自己阅读查阅，一举两得。

我也在筹划把完整的文档库分享出来：