为什么我进行了这次实验
每个人都会发布比较 Claude Sonnet 4.6 和 Opus 4.6 的基准测试表。只需简单搜索，你就能找到几十个。但基准测试衡量的是模型在标准化任务上的表现——它们无法告诉你，当你凌晨 2 AM 埋头于混乱的代码库中尝试交付一个功能时会发生什么。
我想回答一个更简单的问题：在我作为开发者每天进行的实际任务中，Opus 4.6 何时能体现其 5x 的价格溢价？
因此，我设置了一个受控实验。在三周的时间里，我让两个模型运行每一个编程任务——相同的 prompts，相同的代码库，相同的评估标准。我跟踪了成本、输出质量、完成时间以及所需的后续修正次数。
账单大约为 $500。以下是我学到的所有内容。
实验设置：我如何组织测试
我直接使用 Claude API，并为两个模型设置了相同的系统 prompts。没有包装器，没有助手，没有特殊配置——只有原始的 API 调用，以便进行干净的比较。
测试的模型：
- Claude Sonnet 4.6 (claude-sonnet-4-6) — $3 输入 / $15 输出每百万 tokens
- Claude Opus 4.6 (claude-opus-4-6) — $15 输入 / $75 输出每百万 tokens
方法论：
- 每个任务使用相同的 prompt，并在同一小时内发送给两个模型
- 每个任务根据以下维度评分：正确性、代码质量、完整性和所需的后续 prompts 数量
- 所有任务均取自真实项目——没有合成基准测试
- 我为每个维度的每个模型打分，分值为 1-10
定价数据直接来自 Anthropic's official pricing page。速度测量来自 Artificial Analysis benchmarks。
场景 1：调试异步代码中的竞态条件
任务： 一个 Node.js 应用程序出现间歇性故障，数据库写入顺序错乱。该 bug 仅在负载下出现。我给两个模型提供了相关的源文件（约 8K tokens 的 context）和错误日志。
Sonnet 4.6 结果： 在两次交流内识别出 Promise 链中缺失的 await。建议将写入操作包装在事务中。干净、正确的修复。
Opus 4.6 结果： 在第一次交流中就识别出了相同的根本原因，但做得更多——它标记了我在相邻模块中未注意到的第二个潜在竞态条件。它还解释了为什么该 bug 是间歇性的（并发连接下的 event loop 时序问题），并建议使用写入队列进行结构性修复。
胜出者：Opus 4.6
区别不在于发现 bug。两者都发现了。Opus 发现了第二个 bug，并提供了防止未来问题的架构背景。这与 Anthropic 报告的 Opus 4.6 具有更好的调试技能以及捕捉自身错误的能力相符。
成本： Sonnet $0.12 | Opus $0.58
场景 2：为 REST API 构建 CRUD 端点
任务： 在一个使用 TypeScript、Prisma ORM、通过 Zod 进行输入验证以及具有适当错误处理的 Express.js 应用程序中，为“projects”资源生成一整套 CRUD 端点。
Sonnet 4.6 结果： 在单次响应中生成了所有五个端点（创建、读取单个、带分页的读取全部、更新、删除）。输入验证正确，错误处理稳健，TypeScript 类型准确。可以直接粘贴并测试。
Opus 4.6 结果： 生成了相同的五个端点，结构几乎完全一致。添加了略微详细的注释。还包含了一个我没有要求的身份验证 middleware 建议。
胜出者：Sonnet 4.6
输出在功能上是相同的。Sonnet 更快、更便宜，并且没有用未经请求的架构建议填充响应。对于像 CRUD 生成这样定义明确、范围固定的任务，Opus 额外的推理深度除了增加成本外没有任何作用。
成本： Sonnet $0.08 | Opus $0.41
场景 3：将单体组件重构为更小的部分
任务： 一个处理用户个人资料的 600 行 React 组件——包括表单状态、API 调用、权限检查和渲染逻辑——需要拆分为更小的、可测试的部分。我提供了完整的组件及其测试文件。
Sonnet 4.6 结果： 将组件拆分为四个部分：一个容器组件、一个表单组件、一个权限 hook 和一个 API hook。合理的分解。然而，它漏掉了更新测试文件中的两个导入路径，并且权限 hook 有一个微妙的状态管理问题，没有对回调进行 memoizing。
Opus 4.6 结果： 拆分为五个部分，分离得更干净。它创建了一个专门的类型文件，正确更新了包括测试文件在内的所有导入，并且权限 hook 经过了适当的 memoized。它还指出原始组件在 effect 清理中存在潜在的内存泄漏并进行了修复。
胜出者：Opus 4.6
这就是差距变得真实的地方。带有依赖跟踪的多文件重构正是 Opus 4.6 在 MRCR v2 上获得 76% 分数（多文件推理和代码审查）转化为实际价值的场景。Sonnet 的方案需要两轮修正。Opus 在第一轮就交付了正确结果。
成本： Sonnet $0.22 (包括修正) | Opus $0.95
场景 4：为现有代码编写单元测试
任务： 为一个具有多个边缘情况的支付处理模块编写全面的单元测试——包括过期卡、余额不足、网络超时、部分退款和货币转换。
Sonnet 4.6 结果： 生成了 14 个测试用例，涵盖了我描述的所有场景。测试结构良好，具有清晰的 describe/it 块。Mock 设置正确。包含了两个我没有明确提到的边缘情况（空金额、负金额）。
Opus 4.6 结果： 生成了 16 个测试用例。结构相似。添加了一个集成风格的测试，验证了完整的端到端支付流程。测试描述略显冗长。
胜出者：平局 (Sonnet 4.6 在性价比上胜出)
两者都生成了出色的测试套件。Opus 增加了两个额外的测试，但它们并没有实质性的提升。对于测试生成，Sonnet 以 5x 更低的成本交付了同等质量。除非你正在测试极其复杂的业务逻辑，否则 Sonnet 是正确的选择。
成本： Sonnet $0.09 | Opus $0.47
场景 5：编写技术文档
任务： 为内部 SDK 生成 API 文档——包括方法签名、参数描述、返回类型、使用示例以及 12 个公共方法的错误处理指南。
Sonnet 4.6 结果： 干净、组织良好的文档。每个方法都有描述、参数表、返回类型、示例和错误部分。格式全程保持一致。
Opus 4.6 结果： 几乎相同的文档。Opus 在最后添加了一个“常见模式”部分，展示了方法如何组合在一起——这很好，但并非请求的内容。
胜出者：Sonnet 4.6
文档是 Sonnet 的简洁性实际成为优势的一项任务。正如开发者比较这两个模型时所指出的，Opus 有时会在简单任务上添加不必要的解释，浪费 tokens 和时间。对于文档，你想要清晰和完整，而不是冗长和哲学化。
成本： Sonnet $0.14 | Opus $0.72
场景 6：对 Pull Request 进行代码审查
任务： 审查一个 400 行的 Pull Request，该 PR 为一个 API 添加了缓存层。我希望两个模型都能识别 bug、建议改进并标记安全问题。
Sonnet 4.6 结果： 发现了三个问题——更新时缺少缓存失效、由于缓存无限制增长导致的潜在内存泄漏，以及添加 TTL 的建议。良好且可操作的反馈。
Opus 4.6 结果： 发现了相同的三个问题，外加两个——缓存键生成中的计时攻击漏洞，以及一个微妙的问题：在缓存填充期间并发请求可能返回陈旧数据。建议使用特定的模式（带有分布式锁的 read-through 缓存）来修复并发问题。
胜出者：Opus 4.6
在安全相关代码上进行代码审查是 Opus 领先的另一个领域。计时攻击漏洞是真实存在且不明显的。这与来自开发者的报告一致，他们发现当故障跨越大型架构表面时，Opus 表现尤为强劲。
成本： Sonnet $0.11 | Opus $0.53
场景 7：快速原型开发新功能
任务： 使用 WebSockets 构建一个实时通知系统——包括服务端 handler、客户端 hook 和一个带有动画的通知组件。优先级是时间，而非完美。
Sonnet 4.6 结果： 在单次响应中交付了可运行的实现。WebSocket handler、自定义 React hook 和通知组件协同工作。动画是基于 CSS 的且很平滑。小问题：没有重连逻辑。
Opus 4.6 结果： 输出质量相似，但包含了重连逻辑和指数退避策略。还添加了心跳机制。由于 token 速度较低，生成时间大约延长了 30%。
胜出者：Sonnet 4.6
对于原型开发，速度比完整性更重要。Sonnet 更快的输出生成速度（每秒约 47 tokens，而 Opus 为 40 tokens）意味着更紧凑的迭代循环。Opus 添加的重连逻辑很好，但我原本也会在第二轮迭代中添加。原型开发奖励快速、足够好的输出。
成本： Sonnet $0.10 | Opus $0.48
场景 8：架构决策
任务： 我们需要为一个微服务项目在 monorepo 和 polyrepo 结构之间做出选择。我提供了团队规模、部署要求、CI/CD 约束和业务边界。我要求两个模型分析权衡并推荐一种方法。
Sonnet 4.6 结果： 提供了扎实的优缺点分析。根据团队规模推荐了使用 Turborepo 的 monorepo。合理但有些通用。
Opus 4.6 结果： 在给出建议之前提出了三个澄清问题——关于部署频率、跨服务数据依赖以及团队是否有 monorepo 经验。在我回答后，它提供了一个细致的分析，建议采用混合方法：对共享库和紧耦合服务使用 monorepo，对具有不同发布周期的独立部署服务使用单独的 repos。它还概述了从当前结构的迁移路径。
胜出者：Opus 4.6
Opus 处理模糊性的能力更好。正如多份开发者报告所证实的，Opus 会提出更好的澄清问题，并做出更合理的假设。对于处理复杂架构决策的高级工程师来说，这种行为可以节省数小时的来回沟通。
成本： Sonnet $0.07 | Opus $0.62
最终计分板
以下是每个模型在所有八个场景中的表现，按输出质量以 1-10 分制评分：
| 场景 | Sonnet 4.6 | Opus 4.6 | 胜出者 |
|---|---|---|---|
| 调试竞态条件 | 7 | 9 | Opus |
| CRUD 端点 | 9 | 9 | 平局 (Sonnet 在性价比上胜出) |
| 组件重构 | 6 | 9 | Opus |
| 单元测试编写 | 8 | 8.5 | 平局 |
| 技术文档 | 9 | 8 | Sonnet |
| 代码审查 (安全) | 7 | 9 | Opus |
| 快速原型开发 | 9 | 8 | Sonnet |
| 架构决策 | 6 | 9 | Opus |
Opus 4.6 胜出：4 个场景 (调试、重构、代码审查、架构) Sonnet 4.6 胜出：2 个场景 (文档、原型开发) 平局：2 个场景 (CRUD 端点、测试编写)
但计分板隐藏了这一部分：当考虑到成本时，在 8 个场景中有 6 个 Sonnet 4.6 是更正确的选择。 它得分明显较低的两个场景（重构和架构）是大多数开发者每周做几次，而不是每天做几十次的任务。
成本现实
在三周的测试中，账单如下：
| 模型 | 总支出 | 完成任务数 | 每个任务平均成本 |
|---|---|---|---|
| Sonnet 4.6 | ~$80 | 127 个任务 | $0.63 |
| Opus 4.6 | ~$420 | 127 个任务 | $3.31 |
Opus 每个任务的平均成本是 5.25x。对于相同的一组任务，Sonnet 以 19% 的成本交付了 90% 的质量。
如果我采用混合方法——日常任务使用 Sonnet，仅在涉及重构、调试和架构的 20% 任务中使用 Opus——我的总账单将大约是 $160 而不是 $500。在几乎没有质量损失的情况下，这减少了 68% 的成本。
这与生产部署报告一致：采用混合路由模式，将 80-90% 的请求发送给 Sonnet，仅将关键任务升级给 Opus，可以节省 60-80% 的 API 成本。
基准测试无法体现的三个模式
1. Opus 更擅长说“等等，我需要更多信息”
在模糊的 prompts 上，Sonnet 倾向于选择一个合理的默认值并直接开始。Opus 会暂停并提问。这对于架构工作非常有价值，但对于你只想让它做个选择然后继续的日常任务来说稍微有点烦人。
2. Sonnet 更擅长字面地遵循指令
当我给出详细规格时，Sonnet 完全按照我的要求构建。Opus 有时会“改进”我没要求改进的东西——添加抽象层、建议模式、包含超出范围的边缘情况。对于你追求合规性而非创造性的任务，Sonnet 胜出。
3. 质量差距随 context 长度增加而扩大
对于 context 在 10K tokens 以下的任务，我几乎感觉不出模型的区别。一旦 context 超过 30K tokens——大型重构、多文件审查——Opus 变得明显更加连贯。这与 Opus 4.6 在 MRCR v2 上获得 76% 分数（长 context 下的多文件推理）一致。
基准测试数据（供参考）
对于那些想要看数字的人，以下是截至 2026 年 3 月的关键基准测试：
| 基准测试 | Sonnet 4.6 | Opus 4.6 |
|---|---|---|
| SWE-bench Verified | 79.6% | 80.8% |
| GPQA Diamond | 74.1% | 91.3% |
| MRCR v2 (长 context) | ~18.5% (4.5 时代) | 76% |
| 速度 (tokens/sec) | ~47 | ~40 |
| 最大 context | 1M tokens | 1M tokens |
| 最大输出 | 64K tokens | 128K tokens |
来源：Anthropic model overview, Artificial Analysis, Claude 5 benchmark analysis
SWE-bench 的差距只有 1.2 个点。但 GPQA Diamond 差距（科学推理）是巨大的——17 个点。而 MRCR v2 差距（长 context 多文件工作）才是真正的实际区别所在。
我的建议：决策框架
经过 $500 和三周的测试，这是我的决策树：
在以下情况下使用 Sonnet 4.6：
- 任务定义明确且有清晰要求
- 你正在从头编写新代码（端点、组件、脚本）
- 你需要快速迭代速度（原型开发、探索性编码）
- 你正在生成测试或文档
- Context 长度在 20K tokens 以下
- 预算有限或正在处理高请求量
在以下情况下使用 Opus 4.6：
- 任务涉及具有复杂依赖关系的多文件重构
- 你需要模型在提交设计之前分析权衡
- 你正在大型代码库中调试不明显的问题
- 你正在审查安全关键代码
- Context 长度超过 30K tokens 且连贯性至关重要
- 错误答案的代价超过了模型调用的成本
在以下情况下使用两者（混合路由器）：
- 你正在构建具有混合任务复杂性的生产系统
- 你希望通过 Sonnet 获得 60-80% 的成本节省，并以 Opus 作为处理难题的安全网
对于构建开发者工具的团队——我们在 ZBuild 采用了这种混合方法的版本——路由器模式已成为 2026 年的行业标准。
我会做出哪些改进
如果我再次运行这个实验，我会增加第三个维度：测量每个模型达到生产就绪输出所需的后续 prompts 数量。我的直觉告诉我在复杂任务上这会更强烈地偏向 Opus，因为它在多文件工作上的首轮准确率始终更高。
我还会测试开启 extended thinking 的 Opus，据报道这会提升其本已强大的调试和架构推理能力。
底线是：所有的工作都先从 Sonnet 4.6 开始。你会很快知道什么时候任务需要 Opus。需要它的任务是特定的、相对罕见的，并且具有足够的价值来证明其溢价。
来源
- Anthropic — Introducing Claude Opus 4.6
- Anthropic — Claude Models Overview
- Anthropic — Claude Pricing
- Artificial Analysis — Claude Sonnet 4.6 Performance
- Claude 5 — Opus 4.6 Benchmark Analysis
- Bind AI — Sonnet 4.6 vs Opus 4.6 for Coding
- Emergent — Claude Sonnet vs Opus 2026
- DEV Community — Opus 4.6 vs Sonnet 4.6 Coding Comparison
- Macaron — Claude Opus 4.6 for Code Review
- Apiyi — Opus 4.6 vs Sonnet 4.6 Comparison Guide
- Medium — Tested Sonnet 4.6 vs Opus 4.6 for Vibe Coding