Theo 测试 Claude Opus 4.8 与 Claude Code 工作流

Anthropic 发布了 Claude Opus 4.8，同时推出新的 Claude Code 功能。测试一天后，我认为它在一些编程和交互任务上有明显改善，但也遇到了熟悉的问题。我的评价基于视频中的版本和实验，并不是对目前所有可用模型的比较。

发布材料引用了编程及其他基准上的强劲分数。我质疑应该从 SWE-bench Pro 推断多少，因为任务历史、验证和提示词都可能影响结果。基准是所测配置的有用证据，但单凭排行榜无法确定哪个模型适合所有项目。

我检查的基准提示词称测试文件改动已处理，并要求最小化源代码改动，同时建议编写复现脚本。我认为这种设置可能抑制智能体编写项目测试。这是对该配置的批评，并不证明基准禁止所有形式的验证。

我还讨论了 DeepSWE，此前展示的配置中 GPT-5.5 得分为 70%，Opus 4.7 为 54%。我是 DeepSWE 背后公司 DataCurve 的投资者，这对理解我的热情很重要。分数反映该基准选择的任务和运行框架，不同设置可能改变结果。

DataCurve 向我分享了 Opus 4.8 的初步结果。在所述比较中，首次 Claude Code 运行略低于 Opus 4.7；另一次 mini-swe-agent 运行约为 63%，展示的 GPT-5.5 配置为 70%。这些是不同运行框架下的初步测量，不能证明分数变化的原因。

我展示了 Cursor 基准，其中列出多个推理强度设置的任务成本和分数。在这份快照中，最高设置下的 Opus 4.8 比 4.7 便宜，而低强度设置更贵；接近的分数也存在不确定性。特定测试中的价格和排名不能推广到所有使用方式或后续版本。

我尝试了新项目、现有仓库分析和语言之间的迁移。模型总体表现不错，澄清问题简洁而有用。有时它给出的选项太窄，但我喜欢能够补充自己的上下文。这些是我的个人工作体验，而不是受控研究。

为了做个有趣的测试，我制作了 Slot Slop，一个随机选择智能体运行框架、模型和推理强度的终端界面。它的闪烁效果刻意做得很夸张。应用经过多轮来回才完成；在我尝试的工具中，Claude 更适合制作这种复杂终端表现，但这只是单个经验性比较。

随后我让 Claude 把项目从 TypeScript 迁移到 Rust。由于原先的终端库无法以相同形式使用，智能体重写了部分实现。结果在我的演示中能够运行，但我觉得它有些更迟滞。

Claude Code 的推理强度选择器中有 ultracode 选项，画面将其显示为 xhigh 加 workflows。工作流可以把工作拆分给并行智能体和验证步骤。更多并行处理可能有助于某些大型任务，但也带来协调和用量成本，需要与结果一起衡量。

根据我的账户经历，在每月 100 美元的订阅档位下，一次密集运行约 23 分钟就耗尽了五小时使用额度。我升级后继续，但遇到了登录或恢复中断。订阅额度不同于单次请求的 API 账单；实际限制和条款可能变化。

我展示的第三方用量工具显示，这次运行约有 66.1 万个输出 token，原始 token 价值估算约为 168 美元。这只是估算，不一定是订阅中实际支付的费用。视频里后续总额出现前后不一致，因此不应当作当天成本的可靠账目。

我看到多个智能体尝试编辑同一个文件，还出现了工具调用失败。大型并行运行可能造成工作重叠、消耗 token，并留下难以审查的拉取请求。这是我在本次运行和其他大型生成改动中的体验，并不证明每个多智能体工作流都会如此。

也有积极结果。中断的会话恢复后，我让它审查 Lakebed 项目，觉得反馈有用，其中包括我已经知道的问题。它还帮助拆分了一个大型 JavaScript 文件。这是我对质量的评价；AI 审查并不能保证项目安全或完整。

在我使用的配置中，我需要手动告诉 Claude Code 阅读 AGENTS.md。我也更喜欢这次实验中它编写的 TypeScript；相比之下，我认为一些 GPT-5.5 输出加入了不必要的检查。这是对工作流程和风格的观察，不是关于任一工具的普遍结论。

我的用量追踪显示出现了无法解释的变化：继续使用后，后一次报告总额反而低于前一次。因此尤其不能把这些显示数字当作精确账单。不同估算工具、缓存和统计周期都可能产生令人困惑的数字。

Anthropic 展示了调查彻底程度和诚实性的评估。图中 Opus 4.8 在特定评估里没有观察到草率调查导致的失败，并标有不确定性区间；这不能证明模型永远不会犯此类错误。我还讨论了一个只适用于其测试条件的诚实性指标。

我的实际体验则有好有坏。构建 Slot Slop 时，模型对 Claude Code 命令行选项作出错误说法，没有按我预期查阅文档。它还反复用一种陷入停滞的方式测试交互终端界面，直到我介入。这些例子不能推翻评估，但说明我为什么仍会核实输出。

我将此与自己使用 GPT-5.5 的经历比较：我觉得它有时会过度关注上下文中较早的指令；我也看到 Opus 出现类似行为。这些都是特定对话中的观察。两种工具都可能误解上下文，因此用户应检查改动，并在需要时重置或澄清任务。

Anthropic 将 Opus 4.8 描述为幅度不大但可感知的改进，并谈到正在研发成本更低及能力更强的模型。我把它理解为公司当时宣布的方向，而不是某个模型会在特定日期发布的保证。

我讨论公告当时的标准模式和快速模式价格，并抱怨自己所用配置中快速模式的计费方式。这些数字和订阅条款会随时间变化；如果要作出购买决定，应查看供应商当前价格和自己的方案，而不是依赖这段历史视频。

动态工作流旨在把复杂请求拆成子任务，让智能体并行运行，检查结果后再汇总。提到的潜在用途包括全仓库审查、迁移和清理。这描述的是预期流程，并不保证智能体完全独立、检查充分或发现的问题全部正确。

Claude Code 团队的一张示意图展示协调者如何把工作交给实现、验证和修复智能体，再汇总结果。我理解它对可拆分工作的吸引力，但在我自己的迁移比较中，更直接的 Codex 运行更快，产出的代码在我看来也相当。这是非正式比较，推广范围有限。

我担心的是，为了稍微提高解决困难问题的机会，可能需要投入多得多的算力。对于合适的任务，尤其是检查能够独立运行时，并行工作流仍可能值得使用；但我会衡量额外时间、成本和质量，而不是假定智能体越多就一定越好。

我的总体印象是，尽管一些基准结果有好有坏，Opus 4.8 仍比前代有所改进。我不预计它会立刻取代我偏好的 GPT 工作流程，但认为已经使用 Claude 的人可以考虑尝试。这些偏好和产品细节都属于视频录制时的情况。

最后我开玩笑说，取消订阅也许会碰上下次发布。更认真地说，模型发布和使用条款变化很快，合适的选择取决于每个人可以自行评估的任务、预算和工作流程。