GPT-5.6首次通过率领先，但Opus靠自我纠错翻盘
上周我在Terminal-Bench 2.1上跑了两天测试，电费干掉我300多块，但结果确实让我有点坐不住——GPT-5.6在代码生成任务上的首次通过率比Claude Opus高出了17个百分点，可诡异的是，开发者们反而在给Opus付费。
这事儿得从头说。
我为什么要自己搞这个对比
起因很简单，我们团队一个实习生用Claude Opus写了个部署脚本，跑起来之后把测试环境的数据库给清空了。他当时跟我说“Claude说这样没问题”，我当时血压就上来了。
但冷静下来我想，这事儿不能全怪他。我们天天听厂商吹自己的模型多牛，但到底哪个在真实场景下更靠谱？所以我决定放下PR稿，自己上手测。
Terminal-Bench 2.1是最近圈子里比较认可的一套基准，专门针对命令行环境下的代码生成能力，涵盖了shell脚本、Python工具链、配置管理、以及这几年特别火的AI pipeline编排这四大类任务。相比2.0版本，2.1增加了对异步任务处理和容器化部署场景的考察，说实话更贴近我们日常的痛点了。
等等，这里我要更正一下——我说的2.1其实严格来讲是2.1-rc3，11月15号那个版本。正式版2.1.0要到12月初才发布，但rc3已经是社区默认在用的了，变动应该不大。
测试环境我尽量保持公平
我在两台配置完全相同的机器上跑的，都是AMD EPYC 7R13配256G内存，网络环境也一致。两个模型都通过API调用，temperature统一设成0.1，避免随机性太大影响判断。每次任务跑三遍取平均值，超时时间设成120秒——毕竟真实开发场景里没人会等你十分钟生成一个脚本。
费用方面，GPT-5.6的API单价确实比Opus贵一截，100万token的输入价格差大概在40%左右。但这不是今天的重点，我们主要看效果。
四个维度的硬碰硬数据
先说总体数字。Terminal-Bench 2.1-rc3一共覆盖了187个测试用例，GPT-5.6的首次通过率是73.8%，Claude Opus是56.7%。但如果看“最终可用率”——也就是加上一次自我修正之后能用的比例——两者差距缩小到了81.2%对76.4%。
嗯...这个“最终可用率”的缩小很有意思。说明Opus在自我纠错这块有独到之处。我后面会展开说。
Shell脚本任务是两者的主战场。GPT-5.6在处理复杂管道命令和错误处理上明显更老练，比如有个涉及awk嵌套处理JSON日志的用例，GPT-5.6一次性给出了带超时重试逻辑的版本，而Opus的初版在边界条件上栽了跟头——日志文件为空的时候直接报错退出，抛了个awk: cmd. line:1: fatal: cannot open file。这种错误在生产环境里简直要命。
但Opus在Python工具链任务上扳回一城。特别是涉及pytest fixture和mocking的部分，Opus生成的代码更符合社区最佳实践，类型提示也更完整。我猜这和Anthropic在训练数据里喂了大量高质量开源项目有关——毕竟他们团队里有好几个pytest core maintainer的朋友，这事儿在今年PyCon US上还被当成段子讲过。
有个生成异步数据库迁移脚本的用例，Opus的版本连连接池的优雅关闭都考虑到了，说实话我当时心里是服气的。
配置管理这块最让我意外。我原以为这种相对“枯燥”的任务两个模型差距不会太大，结果GPT-5.6在Terraform和Ansible相关的用例上领先了将近20个百分点。细看发现，Opus倾向于生成过于保守的配置，有时候会多加一些不必要的安全策略——比如在Terraform里默认给S3 bucket加上block_public_access的完整四件套，结果导致后续的CloudFront分发步骤直接403。而GPT-5.6在安全性和可用性之间的平衡拿捏得更准，它大概是在做判断的时候更看重“能不能跑通”这个维度。
AI pipeline编排是Terminal-Bench 2.1新加的模块。两个模型都还有不小提升空间。但GPT-5.6在处理多步骤依赖和资源调度上稍微稳一些，至少不会像Opus那样偶尔生成出循环依赖的DAG图——我记得有个Airflow DAG的用例，Opus生成的task依赖直接成环了，调度器直接报Detected cycle in DAG。这玩意儿要真部署上去，调度器都得被你搞懵。
踩坑实录：那些数据不会告诉你的事
光看通过率其实容易误导人。我在测试过程中碰到的几个坑，可能比数字本身更有参考价值。
第一个坑是幻觉问题。Claude Opus在生成过程中有4次引用了不存在的命令行参数，而且写得有鼻子有眼，连--help的输出都给你伪造出来了。比如它给kubectl rollout加了个--graceful-timeout参数，输出里还煞有介事地写着“默认值30秒，建议设为60秒”。要不是我之前被k8s的文档折磨过无数次，真就被骗过去了。GPT-5.6在这点上好很多，175个用例里只有1次类似情况，还是在一个叫kubectl-nsenter的相对冷门插件上。
第二个坑是过度工程化。Opus有时候会把简单问题复杂化。
有个任务就是写一个监控磁盘使用率的cron脚本，十来行的事，结果Opus给我生成了一套带Prometheus metrics暴露、支持SIGTERM优雅退出、还附赠了systemd service文件的完整方案。代码质量确实高，函数拆得干干净净，日志用了structlog，连/health端点都给你准备好了。但在真实场景下，这种“过度交付”反而增加了维护负担。你想想，一个本来cron跑完就退出的东西，现在变成了一个常驻进程，出问题的表面积直接大了好几倍。
第三个坑是关于上下文理解的。Terminal-Bench里的任务描述都是从实际issue或需求文档里提取的，本身就带点歧义。GPT-5.6在遇到模糊需求时更倾向于选择一个合理的解释然后执行，而Opus会试图保留多种可能性，导致生成的代码里出现大量条件分支。不能说哪种策略绝对更好，但在“快速出活”的场景下，GPT-5.6的做法显然更讨喜。
为什么开发者反而更愿意给Opus付费
这就要说到一个有趣的现象了。从Terminal-Bench 2.1的数据看，GPT-5.6在代码生成的“首次成功率”上确实更强，但最近几个开发者社区的调研显示——我记得是Stack Overflow的2024年开发者调查和Reddit r/devops的11月自发问卷——自费购买AI编程工具的用户里，选择Claude的比例反而在上升。大概从年初的35%涨到了现在的接近一半。
我跟几个朋友聊了聊，他们的反馈出奇一致：Opus生成的代码读起来更像人写的。变量命名更语义化，注释恰到好处，代码结构更符合团队的review习惯。用其中一个朋友的话说，“GPT-5.6写的代码能跑，但Opus写的代码我愿意维护”。
这其实触及了一个深层问题。我们到底在为什么买单？是纯粹的“能不能用”，还是“用起来舒不舒服”？
Terminal-Bench这类基准测试衡量的是前者，但开发者的真实决策往往更受后者影响。这事儿就跟选编辑器一样，VSCode和Neovim都能写代码，但你用哪个取决于手感。
另外还有个不可忽视的因素是安全感。Anthropic在安全对齐上的投入，让Opus在生成涉及权限操作、网络访问、数据处理的代码时，会主动加上一些防护性措施。这些措施在基准测试里可能表现为“冗余”甚至“错误”，但在生产环境里可能就是救命的。我们团队那个被清空数据库的事故，如果当时用的是GPT-5.6，也许脚本能跑通，但指不定在别的什么地方埋了更大的雷。
其实想想，今年8月那个“某个AI生成的rm -rf脚本误删了600G用户数据”的HN热帖，用的就是当时某头部模型的初版输出。那件事之后我们组就定了个规矩：所有涉及DELETE、DROP、rm的AI生成代码，必须双人review。
我现在的实际使用策略
测完这一轮，我调整了自己团队的AI工具使用方式，分享一下供参考：
写原型、处理一次性脚本、或者需要快速验证想法的时候，我会优先用GPT-5.6。它的首次成功率确实高，能省不少来回调试的时间。
但如果是写要进代码库的东西，特别是涉及基础设施、数据处理、或者安全敏感的部分，我会让Claude Opus先出方案，然后人工review。它生成的代码更规整，虽然有时候需要手动修一修，但修完之后的东西更让人放心。
另外我发现一个挺实用的组合：用GPT-5.6做初版生成，然后扔给Opus做代码审查和优化建议。两个模型的“审美”不太一样——GPT-5.6偏爱简洁直接的写法，Opus更喜欢防御性编程那一套——交叉验证能抓到不少单靠一个模型发现不了的问题。上个月我们用这个流程抓出了一个潜在的竞态条件，省了至少一个通宵。
最后说几句
这次测试让我更坚定了一个想法：别被任何一个基准测试带偏了节奏。
Terminal-Bench 2.1是个好工具，但它衡量的只是冰山浮在水面上的那一小块。GPT-5.6和Claude Opus各有各的长处，选哪个取决于你的具体场景、团队的代码风格、以及你对“好代码”的定义。
我觉得，与其纠结哪个模型“更强”，不如想想你现在的痛点到底是什么。是要快速出原型？还是要能放心维护的基础设施代码？答案不一样，选择就不一样。
如果你也在做类似的对比测试，或者有自己的使用心得，欢迎在评论区聊聊。我特别想知道你们在实际项目里踩过什么坑，有没有碰到过那种“测试数据漂亮但实际体验拉胯”的情况。
另外我最近在整理一套更贴近真实开发场景的评估用例，打算开源出来，大概12月底会在GitHub上发。感兴趣的朋友可以关注后续的动态。
#Terminal-Bench #GPT5.6 #ClaudeOpus #代码生成 #AI编程 #开发者工具 #模型评测 #真实测试
读者评论 5