Claude 百万 Token 上下文实战指南：从原理到最佳实践

3 月 13 日，Anthropic 宣布 Claude Opus 4.6 和 Sonnet 4.6 的 100 万 token 上下文窗口正式 GA（全量开放）。

100 万 token 有多大？换算一下：

这意味着你可以把一整个中型代码仓库、一份完整的法律合同、或者一本书一次性扔给 Claude，然后直接问问题。不需要分段，不需要检索增强，不需要手动管理上下文。

但"能用"和"会用"是两回事。这篇指南帮你搞清楚：什么时候该用百万上下文，什么时候不该用，以及怎么用效果最好。

一、核心概念：为什么百万上下文很重要？

传统做法：检索增强生成（RAG）

在百万上下文之前，处理大规模文档的标准方案是 RAG：

1. 把文档切成小块（chunk）
2. 用向量数据库存储
3. 用户提问时，先检索相关块
4. 把检索到的块+问题一起发给模型

这个方案能用，但有三个痛点：

• 检索质量决定回答质量：如果相关内容没被检索到，模型回答不了
• 跨文档推理困难：信息分散在不同 chunk 里，模型很难做全局推理
• 维护成本高：需要搭建向量数据库、写 embedding 逻辑、调参

百万上下文的优势

直接把所有内容塞进上下文窗口，让模型自己找答案。

RAG 和百万上下文不是互斥的。小于 100 万 token 的场景可以直接用长上下文；超过这个限制，或者需要实时更新的知识库，还是需要 RAG。

二、定价：真的不加价吗？

Anthropic 这次最惊人的决定是：长上下文不加价。

一个 90 万 token 的请求和一个 9000 token 的请求，每个 token 的单价一样。

但这不意味着"免费"。算一笔账：

关键洞察：即使单价不变，百万 token 的绝对成本仍然不低。一次塞满上下文的 Opus 调用就要 $5。如果你的应用每天跑 1000 次这种请求，月成本约 $15 万。

三、实战技巧：怎么用效果最好？

技巧 1：把重要内容放在开头和结尾

研究表明，大语言模型在处理长文本时存在"中间遗忘"现象（Lost in the Middle）。虽然 Claude 在这方面做了优化，但最佳实践仍然是：

[系统提示 + 任务说明]     ← 开头，最容易被记住
[大量参考文档/代码]       ← 中间，用于检索和推理
[具体问题 + 输出格式要求]  ← 结尾，最容易被记住

技巧 2：给文档加结构标记

当你把多个文档塞进同一个请求时，用清晰的分隔符：

<document name="合同A.pdf" type="legal" pages="120">
...合同内容...
</document>

<document name="合同B.pdf" type="legal" pages="85">
...合同内容...
</document>

<question>
对比这两份合同在违约条款上的关键差异。
</question>

XML 标签帮模型快速定位不同文档的边界。这比纯文本拼接的效果好很多。

技巧 3：善用 Prompt Caching

Anthropic 支持 Prompt Caching。如果你的应用场景是"固定的大文档 + 变化的问题"，可以缓存文档部分：

import anthropic

client = anthropic.Anthropic()

# 第一次请求：缓存大文档
response = client.messages.create(
    model="claude-sonnet-4-6-20260313",
    max_tokens=4096,
    system=[{
        "type": "text",
        "text": "你是一个合同分析助手。",
        "cache_control": {"type": "ephemeral"}
    }],
    messages=[{
        "role": "user",
        "content": [{
            "type": "text",
            "text": large_contract_text,  # 80万 token 的合同
            "cache_control": {"type": "ephemeral"}
        }, {
            "type": "text",
            "text": "这份合同的违约金条款是什么？"
        }]
    }]
)

# 后续请求：只付缓存读取费用，约为原始输入价格的 10%

缓存命中后，80 万 token 的输入从 $2.4（Sonnet）降到约 $0.24。

技巧 4：Sonnet vs Opus 的选择

不是所有长上下文任务都需要 Opus。

技巧 5：使用 Compaction API

对于长时间运行的 Agent（比如 Claude Code），对话越长上下文越满。Anthropic 新推出的 Compaction API 可以在不丢失关键信息的前提下压缩历史对话。

这对构建 Agent 工作流特别有用：Agent 可以在上下文快满的时候自动触发压缩，而不是粗暴地截断历史。

四、最适合百万上下文的五个场景

1. 代码仓库分析

把整个项目（或关键模块）塞进去，问：

• “这个项目的认证流程是怎么工作的？”
• “找出所有直接操作数据库的地方，评估 SQL 注入风险”
• “帮我把这个 Express 项目迁移到 Hono，列出需要改的文件”

2. 法律文档审查

一次性输入完整合同或多份合同：

• “对比 A 合同和 B 合同在知识产权归属上的差异”
• “这份合同有哪些对我方不利的条款？”
• “根据这 5 份判例，分析我们的胜诉概率”

3. 学术研究

把 20 篇论文一次性输入：

• “总结这些论文在方法论上的共同点和分歧”
• “哪些论文的结论互相矛盾？列出具体矛盾点”

4. 企业知识库问答

把内部文档（产品手册 + FAQ + 技术规格）打包输入，构建即时问答系统。不需要 RAG 基础设施，一个 API 调用搞定。

5. 多轮深度对话

百万上下文意味着你可以和 Claude 进行非常长的对话而不丢失早期的上下文。比如一个 8 小时的编程 session，它还记得你第一个小时说的架构决策。

五、踩坑记录

坑 1：不是所有任务都需要百万上下文

如果你的问题用 5 万 token 就能回答，不要塞 50 万 token 进去。原因：

• 更多的无关信息可能干扰模型的注意力
• 绝对成本更高
• 响应速度更慢

原则：给模型足够的上下文，但不要给多余的噪音。

坑 2：响应时间会变长

百万 token 的请求需要更长的处理时间。TTFT（Time To First Token）可能从几百毫秒变成几秒甚至十几秒。如果你的应用对延迟敏感，需要做好 loading 状态的 UX。

坑 3：图片和 PDF 的 token 计算

每张图片约消耗 1000-5000 token（取决于分辨率）。600 张图片可能就占满了上下文的 30% 以上。PDF 被转换成文本后通常比你预期的更长。

建议：先用 count_tokens API 预估 token 数，再决定塞多少内容。

坑 4：缓存有 TTL

Prompt Cache 的有效期是 5 分钟。如果你的应用请求间隔超过 5 分钟，缓存会失效，下一次又要全额付费。高频场景缓存省钱，低频场景省不了多少。

六、实操示例：用百万上下文分析 GitHub 仓库

这是一个实际的使用流程：

# Step 1: 把仓库代码打包成文本
find ./src -name "*.ts" -o -name "*.tsx" | \
  xargs cat > /tmp/repo-dump.txt

# Step 2: 检查 token 数
wc -c /tmp/repo-dump.txt
# 假设输出 1,200,000 字符 ≈ 约 300,000 tokens

# Step 3: 用 Claude API 分析

import anthropic

client = anthropic.Anthropic()

with open("/tmp/repo-dump.txt") as f:
    code = f.read()

response = client.messages.create(
    model="claude-sonnet-4-6-20260313",
    max_tokens=8192,
    messages=[{
        "role": "user",
        "content": f"""以下是一个 TypeScript 项目的完整源代码：

<codebase>
{code}
</codebase>

请完成以下分析：
1. 项目的整体架构（用 Mermaid 图描述）
2. 关键的设计模式
3. 潜在的安全风险（Top 5）
4. 代码质量评分（1-10）和改进建议
"""
    }]
)

print(response.content[0].text)

30 万 token 输入 + 约 5000 token 输出，用 Sonnet 的成本：$0.98。不到一美元就能对整个项目做一次全面审计。

总结

百万 token 上下文是 2026 年 AI 基础设施的一次重要升级。它不是 RAG 的替代品，而是一个新的工具。

什么时候用：文档不超过 100 万 token、需要全局推理、想避免 RAG 的维护成本。

什么时候不用：数据量远超 100 万 token、需要实时更新的知识、对延迟极度敏感。

怎么用好：结构化输入、善用缓存、选对模型、避免噪音。

这不是未来，这是现在。去试吧。

本文首发于 aieii.com，一个关注 AI 工具与趋势的中文内容平台。