3天烧掉820亿Tokens!MiMo与Opus组合拳实战全攻略
3天烧掉820亿Tokens!MiMo与Opus组合拳实战全攻略
前脚刚把 MiMo 送的 16 亿配额磨掉 25%,早上一刷新,账户余额直接拉满到 820 亿——这数字膨胀得我数零都数了好几遍,恍惚间甚至想问问能不能折现成人民币!

这波操作属实离谱,数字一个比一个夸张。
更劲爆的是,MiMo 同步宣布了 API 永久降价,降幅高达 99%!

具体的细则还没来得及深究,但第一反应是:这是冲着 DeepSeek 那个永久 2.5 折去的吧?两家明显在较劲啊。
话又说回来,不管动机是什么,对用户而言都是实打实的利好。卷价格、卷规模、卷能力,这种行业竞赛越多越好!
唯一的遗憾是,这个月就剩三天了……额度重置加上 N 倍叠加,这波操作的时间窗口真叫人哭笑不得。

虽说是“纯度”不高的 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 做知识注入,翻译后的中文网页留给自己阅读查阅,一举两得。
我也在筹划把完整的文档库分享出来:

现阶段还停留在想法层面,内容也远远没有打磨好。不过这种事急不得,只能一步一个脚印慢慢来。等准备好了,再和大家见面。