Claude Opus 4.7 的 1M 上下文，什么时候最值得用？

需要加一句限定：现有资料并没有给出一个官方榜单，证明 1M 上下文的“第一任务”一定是某个具体场景。把大型代码库和 agentic coding 视为最强候选，是基于 Anthropic 对模型和用例的官方描述做出的谨慎判断 。

为什么大型代码库最容易受益

真实的软件项目里，一个 bug、一次重构或一次安全审查，很少只涉及一个函数。它可能牵扯多个模块、测试用例、配置文件、数据库 schema、接口文档、运行日志，以及前几轮修改留下的上下文。

当这些信息都相关时，1M 上下文的价值就很明显：模型可以在同一个会话里保留更多证据，而不是频繁依赖压缩摘要或人为来回补充。这与 Claude 文档中对 complex codebases 和 extensive codebases 的描述直接对应 。

对 agentic coding 来说，这种优势更突出。一个智能体式编程流程可能包括：读取文件、调用工具、接收测试输出、修改代码、再次运行测试、分析日志，然后继续迭代。Claude 的上下文窗口文档说明，在包含思考与工具调用的配置中，输入 token 和输出 token 都会影响上下文窗口限制 。而迁移指南也列出了 Opus 4.7 支持的工具调用、Files API、prompt caching 和 memory 等能力 。换句话说，流程越长、中间产物越多、上下文越相关，1M token 的工作空间就越有意义。

哪些任务最适合 1M 上下文？

三个容易误解的地方

1M 上下文不等于 1M 输出

迁移指南显示，Claude Opus 4.7 的上下文窗口是 1M token，但最大输出是 128k token 。如果你的目标是一次性生成超长文档，输出上限仍然要单独考虑。

大上下文不代表不用管理 token

没有长上下文溢价，并不等于可以不看 token 预算。Anthropic 说明，Opus 4.7 的新 tokenizer 在处理文本时，可能会使用约 1x 到 1.35x 的 token 数量，具体取决于内容；count_tokens 端点在 Opus 4.7 上返回的 token 数也可能与 Opus 4.6 不同 。对于长工作流，最好重新核算 token，而不是默认旧 prompt 的规模和成本完全不变。

不要把所有数据都塞进 prompt

1M 上下文的意义，是让你能放入更多“相关”信息，而不是把整个仓库、全部日志或未筛选资料一股脑倒进去。使用工具时，输入、输出以及与工具调用相关的内容仍会影响上下文窗口 。在 RAG 场景下，更合理的用法通常是放入更多经过筛选的高质量来源，而不是绕过检索和过滤步骤 。

一个快速判断方法

如果你的任务符合下面任意一种情况，就值得考虑 Claude Opus 4.7 的 1M 上下文：

1. 需要模型阅读、比较或修改大型代码库的多个部分，尤其是改动会跨模块、测试和技术文档 。
2. 智能体需要执行多轮步骤，调用工具、读取文件、分析测试或日志结果，然后继续改代码 。
3. 需要在同一会话中分析多个长文档、PDF 或已筛选文件 。
4. 如果把任务历史压缩成摘要会丢掉关键细节，你希望模型在决策前保留更多原始上下文。

反过来说，如果只是问一个简短问题、写一段普通文案，或修改一个很小的文件，1M 上下文通常不是选择 Opus 4.7 的核心理由。更稳妥的理解是：它是一张给大型代码库、长文档和长时间 agent 工作流准备的“大工作台”，而不是每个 prompt 都必须打开的默认模式。