还记得上次我们还在讨论如何高效消耗那16亿Token配额，费了好大劲才用了25%。结果今天早上一看，好家伙，直接重置成了满血的820亿！

不得不感叹，现在这些Token的数字真是越来越夸张了，数零都能数到眼花。要是换成真金白银该有多好啊……我估摸着，是DeepSeek那长期2.5折的促销策略，成功刺激到了MiMo的流量池？关键问题在于，这个月只剩3天了，重置加上N倍配额的组合拳，确实让人有点措手不及。

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

虽然这些Token的“单位纯度”算不上顶级，但胜在数量足够大——接下来我们的核心任务只有一个：如何在3天内高效消耗掉820亿个Token？

之前我咨询了不同AI工具，想找到快速消耗Token的方法。后来摸索着做了一个武侠百科《江湖百晓生》，但MiMo版本没法直接用；接着又尝试搭建文档网站，把Claude的API文档全部拉到本地，然后让MiMo翻译成中文版。这个任务确实挺消耗Token的，而且MiMo产出的中文内容比全英文可读性强多了。

今天就和大家聊聊这个使用场景：如何让Opus负责“高难度”任务，让MiMo负责“高消耗”任务，两者组合出击，确保不浪费任何一个Token。

1、Opus 负责高难度任务

首先让Opus搞定最复杂的部分——分析目标网站，抓取核心内容，并建立完整的架构。

以Claude官方文档站为例。数据量不小，而且全是英文（虽然有中文选项，但内容缺失严重）。抓取数据这事儿虽然不算新颖，但总会有各种坑，有些网站甚至根本无法抓取。第一步，先确认能否成功抓取——Opus反馈说没问题。

接着把完整需求铺给它：

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

Opus收到需求后，立刻进入分析模式，效率真心高——它先是并行启动了2个ExploreAgent，同步抽取了几个.md端点做验证。分析结果非常扎实：

探索完毕。整体可行性分析如下。
你的想法评估：✅ 方向正确，但有几个细节需要决策。

# 好的部分（采纳）
- .md后缀技巧已验证可用，所有页面都能拿到原始markdown
- claude/api/占位目录已预留好，与现有MyDocs结构对齐
- 先英后中分两阶段正确（先确保管线跑通再翻译）

# 需要修正的部分
- 不是纯CommonMark，是MDX：返回的.md包含、、、、等JSX组件标签，常规的markdown-it/marked无法直接渲染，需要做转换映射，否则页面会乱码
- MyDocs当前是纯手写HTML，没有md→html管线：约150-200页文档无法手写，需要建立构建脚本，一次性生成全部页面
- 侧边栏导航需要单独抓：sitemap.xml有URL但没有“Build with Claude > Messages API”的分组顺序，需要从/docs/en/intro页面抓sidebar HTML或试llms.txt

# 规模数据
- 英文文档约150-200页，原始markdown 5-15MB
- 多语言官方有11种（含中文），但官方中文质量不确定，自己翻译更可控

# 推荐的改进版方案
把整个流程脚本化（Python单脚本，~3个阶段）：
1. fetch_docs.py → 抓sitemap + 所有.md，存到claude/api/_src/en/
2. build_site.py → MDX组件→HTML映射，生成claude/api/en/*.html + 侧栏
3. translate.py → 调Claude API批量翻译_src/en/*.md → _src/cn/*.md（复用build_site.py生成claude/api/cn/*.html）

这样英文站和中文站共用一套构建逻辑，只是源md不同。几个关键决策需要你拍板……

看完它的总结，你会发现它把所有利弊、规模、方案都清晰地摆在了台面上——好的部分、需要修正的部分、方案建议，还留了几个问题等着你决策。上面已经能看到具体的决策点了。

接下来全交给Opus 4.7去执行。它制作了详细的计划文档，并开始一步步跑——执行过程中发现一个惊喜：

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

这个数据量确实有点大，一口气吃不下，而且不确定哪些文档真正有用。让它分析了一下，发现其中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) ← 
折叠
├ 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/                 
│   ├── index.html      
│   ├── intro.html
│   ├── get-started.html
│   ├── build-with-claude/*.html
│   ├── agents-and-tools/tool-use/*.html
│   ├── managed-agents/*.html
│   └── manage-claude/*.html
│
├── cn/                 
│
├── _src/               
│   ├── nav.json        
│   ├── en/*.md         
│   └── cn/*.md         
│
├── _build/             
│   ├── package.json    
│   ├── fetch.mjs       
│   ├── build.mjs       
│   ├── translate.mjs   
│   ├── components.mjs  
│   └── templates/
│       ├── page.html   
│       └── landing.html 
│
└── _assets/            
    ├── docs.css
    └── docs.js

同时创建了四个精心设计的脚本：

还贴心地准备了命令速查：

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

脚本支持指定抓取内容、根据MD文档快速构建网页、进行翻译，也能一条龙自动化跑完。考虑到翻译（LLM调用）的Token消耗比较大，它先留空了——毕竟它不想浪费自己的Token。

到这里Opus的任务完成：

总共修改了20万行内容，目标网站分析报告、执行报告、汇总报告全部就绪。源代码也全部写好了，尤其是MDX→HTML的转换器都部署到位。只要一个命令就能把所有MD文档转成HTML页面，快速搭建一套纯静态的Claude文档中文镜像站。有了这些基础，后续只要是Claude相关的问题，AI就能精准响应了。

2、MiMo 负责高消耗任务

接下来轮到MiMo上场了。问题已经很清楚——Opus已经把结构全部搭好，文档也放在了cn目录下。MiMo只需要做一件事：读取这些文档并进行翻译。

实际操作用到了JCode：把cn这个目录拖到小图标上，直接打开Claude Code的界面。模型和API配置已经自动搞定。然后告诉它：“帮我读取所有文件，把英文文档翻译成中文”——之后就彻底不用管了，它会自动读取、判断、管理多个智能体并行翻译。

花了几个小时，几百个文档全部翻译完成。消耗了大约几个亿的配额，16亿中的25%就此搞定。

这套组合拳的效果相当不错。现在的AI能力已经非常强大，唯一缺的就是准确、更新的知识。构建一个专为自己或AI适配的知识库，变得格外重要。正好匹配上那永远花不完的Token——各种文档捞一波，做成中文版。英文MD文档给AI调用，中文网页方便自己查阅，完美。

未来有计划把这个完整的文档库分享出来，目前还只是一个想法，内容仍在打磨——这种事情急不来，只能慢慢来。