北京
25个真实Bug、3个模型、225次运行。结果先摆出来：Haiku干净修复52次，Opus是54次，而Haiku的成本低了约95%。这是TokenSave公布的一组对照测量，测试对象是Claude Haiku、Sonnet和Opus。
测试方法很克制。25个Bug取自2026年8月至10月间在13个开源项目上游修复的问题，项目包括js-yaml、jsdiff、qs、PapaParse、markdown-it、marked、zod、humanize、tomlkit、more-itertools、cachetools、Python-Markdown和pyparsing。
每次运行都从修复前的那个提交开始，依赖装好，不带git历史，模型无法直接查到答案。提示词只保留Bug报告里的症状部分：发生了什么、怎么复现、应该是什么结果。原因分析和建议改法都被删掉。运行环境是Claude Code 2.1.295，无头模式，中等effort，可以读文件、改文件、跑项目测试，不能安装、不能联网。每个Bug每个模型跑3次，共225次。
评分只看模型对库源码的改动，它自己写的测试一律丢弃，然后拿维护者为该修复写的测试去跑，再加上项目原有测试，看有没有弄坏别的东西。“干净修复”的定义是：维护者的每个测试用例都通过，且没有其他测试被破坏。
25个Bug里有22个，Haiku和Opus的干净修复次数完全相同。出现差异的只有三个：
- marked，链接文本里再嵌链接：Opus三次里干净修复两次，Haiku零次，每次Haiku的运行都弄坏了这个例子的规范测试。
- markdown-it，未闭合的链接标签遮住代码段：Opus三次全中，Haiku一次。Haiku有两次修好了Bug，却弄坏了相邻的两个测试。
- js-yaml，正文只有空白的块标量：Haiku三次全中，Opus一次，Sonnet零次。
还有一个zod的Bug值得一提：需要在JSON Schema输出的多个位置处理数字型记录键。没有任何一次运行完整修好，但Opus三次运行合计通过24个测试用例中的14个，Haiku是9个，Sonnet是5个。
三个困难Bug上，所有模型的每一次运行都修好了报告里的例子，却漏掉了报告没提的同一个情况。cachetools的报告只展示了一种通过类调用缓存方法的方式，维护者还测了装饰器的其他所有变体，没有一次运行覆盖到。js-yaml的报告讲的是文件开头的BOM，维护者还测了多文档流中每个文档前的BOM，同样无人处理。Python-Markdown则是每次运行都修好了报告里的HTML注释，却弄坏了维护者关于其他内联HTML之后注释的3到5个测试。
差异是否真实存在，作者的态度很谨慎。Haiku对Opus在全部Bug上的干净修复次数，Fisher精确检验p值为0.86；以整个Bug为单位重采样，Haiku减Opus的95%区间是−11到+5个百分点。也就是说，没有证据表明Opus修得更多，但10个百分点的差距也无法排除。只看困难轮，区间是−33到0个百分点，Opus在这些Bug上可能确实更强，但10个Bug不足以定论。唯一明确显著的差异是Sonnet整体通过的测试用例比例低于Opus，配对置换检验p值为0.006。
作者给出的结论按场景分：原因离症状近的Bug，Haiku够用，干净修复次数与Opus相同，成本低约95%；牵涉多个位置的Bug，Opus更稳妥，困难轮里它弄坏其他测试的次数是Haiku的一半，5次对10次。至于报告没写出来的情况，没有模型能自己找到——困难轮里各模型有47%到60%的运行不算干净修复，这部分时间该花在人工审查上，用哪个模型都一样。
局限性也列得清楚：每个Bug每个模型3次、共25个Bug，模型差异只能当线索看；tomlkit那条下划线报告由作者自己根据上游issue写成，原issue没有复现步骤，所有模型的每次运行都通过了其29个用例中的同样20个；Windows上zod的CLAUDE.md是符号链接，未能解出，因此zod的运行没有项目指令；计时类测试不计入破坏，因为负载下会随机失败；项目是公开的，模型可能在训练中见过相似代码。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
