Claude Opus 4.7 的 100 万 token 上下文：真的能一次读完整个 repo 吗？

官方资料到底支持什么？

为什么 100 万 token 不等于“整个 repo 一把梭”？

代码仓库通常不是一份干净的长文档。一次真正有用的 codebase 分析，往往还需要 README、配置文件、测试、依赖清单、CI 报错、stack trace、搜索结果和工具输出。模型实际要看的上下文，是这些内容的总和。

因此，100 万 token 更适合理解为“可以容纳非常大的工作集”，而不是“任何 repo 都可以不加筛选完整粘贴”。如果仓库里有大量 generated files、vendor 目录、编译产物、巨大日志或重复文档，把它们全部放进 prompt 往往会浪费上下文，还可能挤占真正关键的代码和输出空间。

在 Opus 4.7 上尤其要注意这一点，因为 Anthropic 已提醒：新 tokenizer 可能让同一批文本使用比前代更多的 tokens，最高约 1.35x。

“保持稳定”应该怎么理解？

可以乐观，但不应把它说成绝对承诺。

Anthropic 的产品页明确把 Opus 4.7 放在 complex agentic workflows、long-running work 和 larger codebases 的使用场景中。 官方新闻稿也称它处理 complex, long-running tasks 时具备 rigor and consistency。

不过，这些资料更适合支持一个谨慎结论：Anthropic 官方将 Opus 4.7 定位为更适合长上下文、长流程和大型 codebase 任务的模型。 它们并不足以证明“任何超长文档、任何 repo、任何 agent loop 都可以一次性稳定完成”。

如果用于安全审计、CI/CD 自动修复、大型重构或长时间 agent 流程，仍应使用自己的代码仓库、测试套件和真实失败案例做验证。

想扫完整 repo，建议这样做

1. 先建立文件清单，不要直接全量粘贴

先列出仓库的主要目录、语言、入口点、测试、配置文件和近期改动，再决定哪些文件真的需要进入上下文。通常应先排除 build artifacts、generated files、vendor 依赖、巨大日志、缓存和重复文件。

2. 用 Opus 4.7 重新计算 token

不要拿 Opus 4.6 或其他模型的 token 数直接推算。Anthropic 指出，Opus 4.7 的新 tokenizer 可能让同一文本使用约 1x 至 1.35x tokens，/v1/messages/count_tokens 的结果也会不同。

3. 不要把 100 万上下文塞满

即使输入刚好放得下，也不代表任务一定能高质量完成。长代码仓库分析通常需要模型输出覆盖范围、风险列表、修改建议、测试策略或 patch；Opus 4.7 的最大输出为 128k tokens，设计任务时要为输出留出空间。

4. 大型 repo 更适合分阶段和工具化流程

Anthropic 将 Opus 4.7 定位为适合 complex agentic workflows 和 larger codebases 的模型。 对大型仓库而言，更稳妥的方式通常是：先让模型理解架构，再逐步读取关键文件、搜索引用、检查测试和错误日志，而不是一开始把所有内容一次性塞进去。

5. 要求模型明确说明覆盖范围

做代码仓库分析时，可以要求输出包括：已读文件、未读文件、主要假设、风险点、需要人工确认的部分，以及下一步测试建议。这不能保证答案一定正确，但可以减少一个常见误解：模型看过一部分上下文，并不等于它已经完整理解整个 codebase。

最终判断

Claude Opus 4.7 确实支持 100 万 token context window 和最多 128k output tokens。 Anthropic 也将它定位为适合长流程、agentic workflow 和较大 codebase 的模型。

但“能否一次读完整个 repo”不是只看上下文窗口数字就能回答。若整个 repo 加上任务上下文和输出预留仍在限制内，一次处理可以成立；若仓库太大、噪声太多，或任务需要长报告和大量修改，更可靠的方法仍是先筛选、再分批，并用实际测试验证结果。