原文把 DeepSeek 的 128K 上下文比作一本 300 页的书，比喻很直观，但看完还是没法动手：真正让 DeepSeek 去总结一本 300 页的文档时，API Key 从哪来、Base URL 填什么、模型 ID 去哪里查，原文都没有说。这篇就用 TaoToken 把这件事完整跑通——先到 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 创建 Key，再在支持自定义 Base URL 的 AI 编程工具（Claude Code 或 Codex）里把 DeepSeek 指到 https://taotoken.net/api，最后上传一份长文档做总结，看返回结果和 Token 计数。TaoToken 只统一接入 Key 和 Base URL，DeepSeek 的 MoE 与推理逻辑不变。
1. 先把「300 页的书」换算成 Token，才知道总结时该看什么
1.1 一页书大约吃多少 Token
Token 是模型自己的切分单位，既不是字数也不是页数。中文大约 1 个字对应 1 到 1.5 个 Token，但一页书排版差异很大：一行 30 字、一页 30 行的中文书约 900 字，相当于 1200 Token；公文、论文的行间距更大，一页可能只有 300 到 400 字，约合 450 Token。128K 上下文按 131072 Token 计算，如果这本书平均每页 450 Token，正好对应大约 290 页，这正是「128K 相当于一本 300 页的书」这个比喻的由来。换成排版密集的书，128K 大概只够读 130 页左右。
知道这个换算关系之后，验证「128K 长文档总结」就有了明确口径：只丢一篇 30 页的文档是热身，不能证明 128K 的能力。要验证长上下文，至少准备一份 150 页以上、带章节结构的 PDF，让它分别总结开头、中部、结尾的内容，并且抽查一个只出现在后半部分的细节，看模型是否真的记住了。
1.2 MoE 的「专科医生」在长文档总结时怎么分工
原文讲到 MoE 时说它有多个「专科医生」会诊，这个比喻在长文档总结时格外贴切。一份长文档内部往往是混合内容：开头是背景综述，中间是技术参数或代码，结尾是结论和引用。MoE 模型在推理时会把不同 Token 的计算任务分给不同的专家网络，所以总结长文档对模型的「路由」能力要求很高——它不是把 300 页内容平均处理，而是要把政策部分送给政策专家、把代码部分送给代码专家，最后再汇总。
明白这一点，就能判断返回质量出问题时该怪谁：如果总结只覆盖前面几十页，后面章节像是凭标题猜的，那不是 Key 或 Base URL 的问题，而是文档太杂，需要你先拆成几个「会诊议题」分别总结。TaoToken 只负责把 DeepSeek 的接入通道打通，模型内部如何选择专家、如何推理，完全保持原样。
2. 跑长文档前，把 Key、Base URL、模型 ID 三样凑齐
2.1 去官网创建 API Key
配置任何工具之前，先到 TaoToken 注册并登录。控制台里有「API Keys」入口，新建一把 Key 之后把字符串复制出来，本文后面统一用 YOUR_API_KEY 代替。注意官网落地页和接口地址是两套：落地页用于注册、创建 Key、看模型广场、看用量；真正填进工具的 Base URL 是 https://taotoken.net/api，末尾不要加 /v1。
2.2 从模型广场确认 DeepSeek 的模型 ID
DeepSeek 的模型 ID 不要凭记忆填，去模型广场搜 DeepSeek，广场当前展示的 ID 才是配置时要用的值。TaoToken 是统一接入的兼容通道，同一个模型可能有多个接入别名，也可能有原厂命名之外的 ID。填错 ID 的报错通常是 model not found，后面排障章节会专门讲。建议把三样配置先记在一个临时文件里，避免配置到一半又回网页找。
| 配置项 | 填写值 | 说明 |
|---|---|---|
| API Key | YOUR_API_KEY | 从官网控制台创建后复制 |
| Base URL | https://taotoken.net/api | 不要加 /v1 |
| 模型 ID | 以模型广场中 DeepSeek 对应条目为准 | 直接复制广场展示的 ID |
3. Claude Code 里用 DeepSeek 总结 300 页 PDF
3.1 在 settings.json 里写入环境变量
Claude Code 读取三个环境变量：ANTHROPIC_BASE_URL、ANTHROPIC_AUTH_TOKEN、ANTHROPIC_MODEL。第三个不是所有版本都强制要求，但固定写上可以避免每次对话还要手动指定模型。配置文件位于~/.claude/settings.json，在 env 段补上：
{ "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_AUTH_TOKEN": "YOUR_API_KEY", "ANTHROPIC_MODEL": "YOUR_MODEL_ID" } }YOUR_MODEL_ID 换成从模型广场复制的 DeepSeek 模型 ID。保存后重启 Claude Code，环境变量才会生效。这里最容易踩的坑是改完文件不重启，终端还拿着旧配置，后续请求仍然在走默认通道。
3.2 上传长文档并给出「分段总结 + 尾部检查」指令
启动 claude 后，把当前目录下的长文档交给它，指令要明确要求覆盖文档中段和尾部：
把 spec.pdf 按「背景、技术方案、实施计划、风险」四个部分各写一段总结，最后用三句话概括整份文档的结论。特别检查第 1 章、第 100 页附近和最后一章的内容，哪里没有读到，直接告诉我。
如果 Claude Code 无法直接读取 PDF，先把 PDF 转成 txt 或 Markdown 再拖入，也可以直接给出文件路径让工具自己判断。跑完看三个地方：总结是否包含文档中后段的信息；会话结束时的 Token 统计；下一轮对话里追问一个只出现在末尾章节的细节，确认上下文没有被悄悄丢弃。
4. Codex 跑同一份文档：config.toml 里单独定义 Provider
4.1 给 Codex 增加一个 TaoToken Provider
Codex 的配置和 Claude Code 不一样，不要把 ANTHROPIC_* 变量搬过来。Codex 读取~/.codex/config.toml，在 model_providers 块里定义一个 DeepSeek Provider，然后在顶层 model 字段指定它：
model = "YOUR_MODEL_ID" model_provider = "taotoken" [model_providers.taotoken] name = "DeepSeek via TaoToken" base_url = "https://taotoken.net/api" api_key = "YOUR_API_KEY"不同版本的 Codex 对 provider 字段支持不完全一样，如果本机版本不认 api_key 这个字段，按当前版本自带的配置说明替换成对应写法。报错时会明确提示是 provider 字段缺失还是认证字段缺失，照着改就行。核心就是：Base URL 保持 https://taotoken.net/api，末尾不要加 /v1。
4.2 用 Codex 做章节级核对
启动 codex 后，把长文档路径交给它，指令侧重「检查式总结」：要求它输出文档的章节分布、每个章节的关键结论，以及最后 20 页里出现过的数据表或结论是否完整。Codex 的回复格式更适合逐条对照原文，适合这种验证型任务。
用同一个文档在 Claude Code 和 Codex 各跑一遍，也是一种交叉验证。两边得出的章节结论一致，说明这一轮 128K 上下文真的被吃进去了，而不是模型靠标题和开头内容猜出来的。这里的「推理」也和原文描述一致：模型不是去数据库匹配现成答案，而是先抽取章节证据，再综合成总结。
5. 从 Token 计数反推这次总结有没有「把书读完」
5.1 输入 Token 和输出 Token 分开看
无论是 Claude Code 的会话摘要还是 API 返回，通常都有 usage 字段，包含 input_tokens 和 output_tokens。判断 128K 是否够用，主要看输入 Token：一篇 200 页的文档按前面的换算大约 9 万到 24 万 Token，如果输入 Token 只有 3 万，说明工具在读取阶段就截断了；如果输入 Token 在 10 万以上且总结覆盖尾部内容，才算真正跑了一次长上下文。
只看总数还不够，可以做一个比例估算：输入 Token 数除以文档页数，得到平均每页消耗的 Token。如果每页只有 100 多 Token，大概率是文档没有被完整读取，可能是工具预处理时按行截断，也可能是 PDF 转换丢了内容。
5.2 回到控制台核对用量
模型侧的数字看完了，再到 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 控制台对一下这次请求是否被记录。这一步就是原文「看用量」的落点：请求时间、模型 ID、输入输出 Token 数，都应该和工具里看到的一致。如果控制台里只有一次成功记录，而工具里显示调用了多次，一般是工具侧有缓存或重试；如果控制台里根本没有记录，说明请求根本没走到 TaoToken，多半是环境变量没生效，或者配置文件被工具忽略了。
6. 长文档总结最可能撞上的三个报错
6.1 401：先查 settings.json 里的 ANTHROPIC_AUTH_TOKEN
认证失败时，第一步检查是否真的把 YOUR_API_KEY 换成了实际 Key，而不是连占位符一起填了进去。第二步确认这个 Key 是新建且未过期的，复制时有没有多带空格或换行。第三步在终端里执行echo $ANTHROPIC_AUTH_TOKEN，确认当前 shell 确实拿到了值。改了 settings.json 之后不重启 Claude Code，是这类问题最常见的来源。
6.2 model not found：回模型广场复制 ID
模型 ID 填成记忆中的官方名，而广场里的实际 ID 是另一个别名时，就会遇到 model not found。手工猜 ID 容易继续踩坑，正确做法是回到模型广场搜 DeepSeek，复制当前展示的 ID，再替换配置里的 YOUR_MODEL_ID。如果是在 Codex 里，还要确认 provider 块名和顶层 model_provider 引用一致，拼写差异也会导致模型解析失败。
6.3 404：Base URL 是不是被「好心」补了 /v1
把 Base URL 写成 https://taotoken.net/api/v1 时，请求路径会变成 /api/v1/...，与网关路由不匹配，返回 404 的概率很高。按本文配置直接填 https://taotoken.net/api 即可，末尾不要加路径。这是接入 DeepSeek 时最容易被顺手「补全」的一处，看到 404 先检查这里，比重建 Key 更省事。
7. 验证一次 300 页 PDF 后，固定自己的检查模板
7.1 存一套可复用的长文档验证模板
跑通一次之后，把验证模板存下来：一段固定 prompt，外加一个检查清单——尾部章节是否出现、关键数字是否准确、Token 计数是否符合预期、控制台用量是否对上。下次换模型、换 Key 或换工具时，用同一套模板重跑，才有可比性。否则每次都换文档，Token 数和内容覆盖率都没有对照基准。
原文把 DeepSeek 比作「公共图书馆」，但网页版免费和 API 调用额度是两回事，实际消耗以控制台的用量记录为准。长文档总结是最吃上下文的场景，日常写代码时往往用不到这么高的上限，按需接入就好。
7.2 下一步：先试对话，再定 Coding Plan
配置保存后，先在 模型对话 里用同一把 Key 发一条测试消息，确认 Key、Base URL 和模型 ID 都没问题。若打算长期写代码，可以打开 Coding Plan 看套餐是否匹配；Key 的创建与管理在 API Keys 控制台。Claude Code 的环境变量逐项对照，见 Claude Code 接入文档。
