一小时 vs 两分钟：编程体验从来不只是模型的事

slug

claude-code-vs-codex-context

type

Post

status

Published

date

May 4, 2026

一个 12 倍的差距

那是个普通的下午。

我在改一个项目里的功能，需求很普通——就是一个增删改查的逻辑调整，传统软件工程师手敲也就十来分钟的事。我先用了 Claude Opus 4.7，挂着我精心配置的一整套 Skill 和 MCP，按下回车，等。

它开始 plan，开始 read 文件，开始大段地拆解需求、给方案、列计划，开始一段段地尝试。一小时过去，效果没达到我预期。我看了看它的轨迹：每一步都没有明显错，但每一步都"假模假式"地端着——就像一个被训练得太规范的实习生，明明只是要改一个 if 分支，他先把整个项目的上下文梳理一遍，再给出三种实现方案的对比，再小心翼翼地动那一行。

我关了它，打开 Codex，挂上 GPT-5.5。我甚至没开 Plan 模式，就口述了一句我想要的效果。它精准 get 到了我要做什么，两分钟后改完，再加一遍 Code Review，五分钟收工。

12 倍的速度差。我的第一反应是写一篇标题党：《GPT-5.5 编程碾压 Opus 4.7》。

后来我没写。因为我去翻了一遍 benchmark，发现自己的判断站不住脚。但这次实测带出来的问题很有意思——它指向一个很多人没注意到的事实：编程体验从来不只是模型的事。

第一反应是错的

写文章前我先做了功课，把 Opus 4.7 和 GPT-5.5 在公开 benchmark 上的表现摊开看。结果跟我的体感是反的。

GPT-5.5 是 OpenAI 4 月 23 日发布的 frontier model，在 agentic 任务上确实强。Terminal-Bench 2.0 上拿到 82.7%，而 Opus 4.7 只有 69.4%。OSWorld-Verified 上 GPT-5.5 78.7%，Opus 4.7 78.0%。在"模型自主操作终端、调用工具、跨应用完成任务"这种长链路 agentic 场景，GPT-5.5 是当下的 SOTA。

但你只看 coding 类 benchmark，结论就反过来了：

SWE-bench Verified：Opus 4.7 拿到 87.6%

SWE-bench Pro：Opus 4.7 是 64.3%，GPT-5.4 是 57.7%（Anthropic 官方数据）

CursorBench：Opus 4.7 70%

在 CodeRabbit 的 PR 评审实测里，Opus 4.7 被评为"我们测过最锐利的代码评审模型"

更微妙的是，BenchLM 把 GPT-5.5 和 GPT-5.3 Codex 拉出来对比，发现在 coding 维度上 GPT-5.3 Codex 平均反而比 GPT-5.5 更强（63.1 vs 58.6），Vibe Code Bench 上差距更明显。也就是说，GPT-5.5 这次升级的强项主要在 agentic 和 computer use，纯 coding 不是它的发力方向。

那为什么我的实测给我"GPT-5.5 碾压"的体感？

答案是：我的实测里测的根本不是"模型 vs 模型"。我测的是一整个 stack——模型 + harness + 我自己装的那一堆 Skill 和 MCP。这三层任何一层有问题，体感差距都可能放大到看起来像"模型差距"。

编程体验的三层结构

我开始这么思考问题：当我用一个 AI 编程助手写代码时，最终决定我体验的不是单一变量，而是一个乘积。

Model：底层那个 LLM 本身。Opus 4.7、GPT-5.5、Gemini 3.1 Pro 等等。这一层管"基础推理能力""代码理解能力""工具调用准确率"。

Harness：模型外面套的那层 agent 框架。Claude Code、Codex CLI、Cursor、Continue 等等。这一层管"系统 prompt 怎么写""context 怎么压缩""反思循环跑几遍""tool 调用粒度多大"。

Context：当次对话注入到模型上下文里的所有信息——你的代码、对话历史、附加的 Skill、挂载的 MCP、规则文件、文档。这一层管"模型这次能看到什么""它的注意力被引向哪里"。

这三层是乘法关系，不是加法。任何一层乘个 0.3，最终体验就是 0.3 倍。Benchmark 测的主要是第一层——给模型一个干净的 context 和标准化 harness，让它单挑某个测试集。但你日常在 IDE 里用的是三层乘起来的产物。

我那次实测里，三层全都不一样：

维度	Opus 4.7 那次	Codex (GPT-5.5) 那次
Model	Opus 4.7	GPT-5.5
Harness	Claude Code	Codex
Context	5 个 Skill + 4 个 MCP（含 Superpower）	完全裸跑，连 Plan 模式都没开

三层全变，最后归因给"是 GPT-5.5 比 Opus 4.7 强"——这是经典的 confounding variable，控制变量错了。

下面把每一层拆开看。

Harness 层：模型外面的那层壳

很多人没意识到，Codex CLI 和 Claude Code 不是同一类东西的两个品牌。它们是两套独立设计的 agent harness。

一个 LLM 本身只会做一件事——给它一段 token 序列，它预测下一个 token。要让它真的能"修改代码""执行命令""读文件"，得在外面套一层壳：定义系统 prompt、定义可用工具、定义反思循环、定义当 context 长了之后怎么压缩、定义出错时怎么 retry。这层壳就是 harness。同一个底层模型，套不同 harness，行为可以差出十倍。

Anthropic 在 Opus 4.7 发布时把 Claude Code 默认的 effort level 调成了 xhigh——这是介于 high 和 max 之间的新档位，意味着模型会用更深的 reasoning chain、更多的反思步骤来处理任务。这个默认值对于"复杂的多文件重构""跨仓库的迁移任务"是合理的，但对于一个 CRUD 修改，它就是杀鸡用牛刀。

Codex 这边的设计哲学正好相反。CodeRabbit 在 GPT-5.5 实测里观察到一个现象，他们用的原话大意是：这次明显感到 GPT-5.5 更快、更精简、更直接，倾向于做小而可行的改动而不是大范围重写。这个"风格"很大一部分不是模型本身的，是 OpenAI 在 Codex 里专门调过 prompt scaffolding 的结果——他们牺牲了一部分 verbose 的解释能力，换来了在 coding 工作流里的"短平快"体感。

OpenAI 自己在 GPT-5.5 发布博客里说得很直白：在 Codex 里他们做了"针对性 tuning"，让 GPT-5.5 用更少的 token 输出更好的结果。也就是说 ChatGPT 里的 GPT-5.5 和 Codex 里的 GPT-5.5 行为不完全一样，差的就是那层 harness。

我自己在 Codex 里的体感非常直接：连 Plan 模式都不开，就口述一句需求，它能精准捕捉到我想要什么，然后迅速拆解、迅速 patch、迅速完成。这种"裸跑就够强"的状态让我有点惊讶——它意味着这一代 Codex + GPT-5.5 的 stack 默认配置已经被打磨到了一个极致的水平，以至于额外的 augmentation 反而是多余的。我后来甚至给 Codex 也准备了几个 MCP 和 Skill，到现在都没真正上线——因为我发现裸跑就够用，加上去反而担心打扰它原本的判断节奏。

把这个洞察反过来用就是：当你用 Claude Code 做一个简单任务体感不好时，第一个该问的不是"是不是该换模型"，而是"是不是该把 effort level 降下来""是不是该换一个更轻量的 harness""是不是该把附加的 Skill 临时关掉"。

Context 层：Skill 和 MCP 不是免费的

这一层是我那次实测里最被低估的变量，也是我现在最想跟你聊的部分。

我的 Claude Code 里挂了 5 个 Skill 和 4 个 MCP。数量看起来不多——比起一些堆了几十个工具的极端配置，我这套算克制的。但接下来的复盘让我意识到：这一层的伤害不是数量决定的，是性质决定的。

具体到我那次。我挂的 Skill 里有一个叫 Superpower，设计目的是帮模型做项目级的拆解和长程规划。这个 Skill 本身没问题，在合适的场景里它非常好用——比如要从零开始搭一个新模块、要做一次跨多个文件的重构、要规划一周的开发节奏，这种场景下你巴不得有人帮你把任务拆成树形结构。

但它的存在本身就是一种 prime——在 context 里告诉模型"这是一个需要拆解、需要规划、需要分阶段执行的任务"。模型不知道我这次只想改一行，它从你装载的工具里反推任务性质，推断出"既然用户挂了项目级拆解工具，这次任务想必也是项目级的"，于是它就走了项目级的路径——开始大段思考、大段规划、大段对比方案。

MCP 这边同理。我挂的几个偏重型——Notion、Supabase、几个自定义工具。每个都在告诉模型"你可能需要查文档，你可能需要操作数据库，你可能需要调用另一个 agent"。这些"可能"在简单场景下没必要被激活，但只要它们在 context 里，模型就在考虑它们存不存在调用的必要——多一次决策，少一次直接动手。

为什么这个机制成立？因为模型在 context 里看到的不是孤立的工具列表，而是一个整体氛围的暗示。同样一句"修改 CRUD 逻辑"，扔进一个"挂了项目级拆解 Skill + 重型 MCP"的环境，和扔进一个完全裸跑的环境，模型推断出的任务规格完全不一样。这不是 token 占用的问题——5 个 Skill + 4 个 MCP 的 token 开销并不夸张。这是任务感知偏差的问题：模型根据它能看到的工具反推任务的难度等级。

回到我那次。任务是一个 CRUD 修改——我心里清楚要改什么、要改在哪。但模型只能从 context 推断我想要什么级别的服务。Superpower 在那里告诉它"考虑做项目级规划"，几个 MCP 在那里告诉它"考虑外部信息检索"，再加上 Claude Code 默认的 xhigh effort——三个信号叠加，模型合理地推断："这一定不是个普通需求，得严肃对待。"

它就严肃地对待了——花一小时认真做规划、反思、阶段性验证。每一步都没错，但每一步都为一个本不需要这种规格的任务服务。

Codex 那边为什么快？因为我用 Codex 是完全裸跑的——没挂额外 Skill，没挂 MCP，连 Plan 模式都没开。模型 context 里没有任何"该认真起来"的暗示，它就按"快速完成 coding 任务"的默认行为来跑，我口述一句它就 get 到了，两分钟搞定。

这里有个反直觉的点值得记住：装多少工具不是关键，装的工具暗示了什么任务规格才是关键。装工具就像给员工配头衔——给一个要写五行 SQL 的实习生配一个"项目总监"的职务，他不会因此更高效，反而会启动一套他以为这个职务应该启动的流程。模型也一样。一个为长程项目设计的 Skill，挂在那里就是一个隐形的"任务规格升级"开关。

Model 层：4.7 反而印证了 Context 层的关键性

把前两层先放一边，回到模型本身。Opus 4.7 在我那次任务里是不是也有锅？

我原本以为有。但去翻了 Anthropic 官方的迁移文档之后，我发现这个判断大概率是错的。

Anthropic 在 4.7 的发布说明里明确写了几条核心行为变化：4.7 比 4.6 更字面化执行指令、不会主动推断你没提的需求、响应长度会按任务复杂度匹配（而不是默认拉长）、默认更少调用工具、整体语气更直接更少铺垫。这是一组反过度工程化的设计——Anthropic 至少在意图上，是把 4.7 训练得更克制、更不啰嗦。

那为什么我的体感还是它"假模假式地端着"？

因为 4.7 那个"按任务复杂度匹配响应长度"的机制有一个隐含前提：模型对任务复杂度的感知是准确的。如果模型把一个简单 CRUD 感知成了项目级任务，它就会按项目级任务的规格来响应——大段拆解、多轮反思、慢慢推进。这不是模型在偷懒，是它在精确执行它感知到的任务规格。

塑造模型任务感知的，正是 Context 层。Superpower 在那里告诉它"这是要做项目级拆解的"，几个重型 MCP 在那里告诉它"这是个跨系统任务"，xhigh effort 在那里告诉它"要深度思考"——三个信号叠加，模型把一个 if 分支修改感知成了项目级任务，然后按项目级任务的标准认真执行了一小时。

也就是说，模型本身基本没犯错。它甚至比 4.6 更精确地匹配了它感知到的任务规格——问题是它感知到的规格本身就是错的，而错误的感知不来自它，来自我塞给它的 context。

把这个想清楚之后，"模型谁强谁弱"这个问题就更不重要了。真正重要的是：任何按 context 调节自身行为的现代模型，都会被错位的 context 误导。4.7 在这里是一个特别清楚的样本——它"按任务复杂度调节响应"的机制越精确，错位 context 的代价就被放大得越严重。差额几乎全部来自我自己装的那一堆。

那次具体发生了什么

把三层放在一起复盘那次失败：

我让一个会精确按 context 推断任务规格的模型（Model 层），跑在一个把 effort level 默认拉到 xhigh 的 harness 里（Harness 层放大），上下文里挂着一个为项目级拆解设计的 Superpower Skill 和几个偏重型的 MCP（Context 层诱导：这次任务很大，得拆）。

三个信号同方向叠加，最终行为是：模型把一个其实很简单的任务感知成了项目级任务，然后认真地按项目级任务的标准执行了一小时。

这不叫模型不行。这叫我用错了配置。

一个更准确的类比：你不会说"奔驰 S 级在小区里穿梭比五菱宏光慢，所以五菱宏光比奔驰强"。你会说，奔驰是为高速长途设计的车，开进小区它的优势没有用武之地。Opus 4.7 + Claude Code + 重型 Skill 配置，是为长程复杂工程设计的"重武器"。我那次拿这个配置去打一个 CRUD 修改，配错了场景。

方法论：什么时候装，什么时候不装

这次踩坑之后我形成了一个简单的判断框架，可能对你有用。

装 Skill 和 MCP 的合理场景：

任务跨多个外部系统，比如要查 Notion 文档、读 Supabase 数据、再生成代码

长程任务，需要模型在多轮对话里保持一致的行为约束

团队协作场景，需要模型的输出符合特定规范

模糊任务，需要模型自己摸索方向，这时反思和 plan 是有价值的

反过来，应该轻装上阵的场景：

你心里已经有明确的方案，模型只是替你打字

任务局部，单个文件、单个函数级别的改动

时间敏感，你只是想快速试一下某个想法

任务简单到你能口头描述清楚每一步

我现在 Claude Code 里其实保留了完整的 Skill 配置，但额外维护了一个"轻量 profile"——一个把 Superpower 这种重型 Skill 和重型 MCP 全部关掉的别名，专门用来干那些短平快的活。这个简单的切换让我之前那种"明明很简单却跑半天"的体感几乎消失了。

一些更深的反思

写到这里其实可以收尾了，但还有几点想说。

第一，"哪个模型在 coding 上更强"这个问题本身可能是 ill-defined 的。 我们日常用的从来不是"模型"，是"模型 + harness + context"的整体 stack。OpenAI 把 GPT-5.5 + Codex 当成产品而不是单卖模型，是有道理的——他们在卖一个调好的 stack，不是底层 LLM 本身。Anthropic 把 Claude Code 跟 Opus 4.7 一起推也是同样逻辑。当我们说 X 比 Y 强时，得搞清楚比较的是哪一层。

第二，benchmark 和真实体感经常不一致，但通常不是 benchmark 错了。 是 benchmark 测的东西和你日常用的东西不在同一个 stack 配置上。SWE-bench Verified 用的是干净的、标准化的环境，没有你自己堆的 Skill 和 MCP。当你把现实环境搞复杂之后，benchmark 数字不能直接迁移到你身上。

第三，单次实验的方差很大，我这篇文章里的那次实测不是科学结论，是一次有信息量的踩坑。 同样的任务我可能跑五次 Opus 4.7，三次会顺利，两次会卡住；GPT-5.5 在 Codex 里也会有失败的时候。我没法从一次实验就断言谁强谁弱。能确定的只有：那次差距的主要原因是我自己的配置错位，不是模型谁碾压谁。

第四，关于"碾压论"这种叙事。 AI 领域最近一年充斥着"X 模型把 Y 模型按在地上摩擦"的标题。这种叙事爽，但通常误导。真实情况几乎总是"在某些场景下 X 占优，在另一些场景下 Y 占优，且差距远小于标题党宣称的"。下次看到这种文章，先问一句：是模型的差距，还是 stack 的差距？是单次的方差，还是稳定的趋势？

第五，一点对 4.7 的失望我得诚实说出来。 撇开 stack 配置的话题不谈，单论模型本身的日常使用体感，我觉得 Opus 4.7 是不如 4.6 的。这是一个很主观的判断——公开 benchmark 上 4.7 在 SWE-bench Verified（80.8% → 87.6%）、SWE-bench Pro（53.4% → 64.3%）等多个维度都是升级，所以我没法把它说成客观事实。但日常用下来，4.7 那种"用力过猛又抓不住重点"的感觉，4.6 反而更少。

我的一个不负责任的猜测是：Anthropic 现在重心在训 Mythos——他们最强的模型，SWE-bench Verified 拿到 93.9%，比 4.7 高出整整 15 个点。也许在 Mythos 吃掉了大部分算力的前提下，4.7 只是一个"让大家先将就用"的版本——可能是蒸馏的，可能是匆忙微调的，总之没拿出训练新一代旗舰模型时该有的资源去精雕细琢。

这个猜测我没有任何实锤，纯属用户视角的揣测，欢迎被打脸。但作为付费用户，体感上的退步是真切的。Anthropic 当然有权选择把资源压在 Mythos 上，毕竟商业上要做高端区隔；但把 4.7 推到台前作为公众可用的最强模型，同时让人有"感觉在凑数"的体验，这不算好的产品策略。

我从这次踩坑里得到的最大收获，不是知道了 Codex 这次很猛——而是意识到，我一直把"配置"当成单纯的加法（功能越多越好），其实它是乘法（错配会让其他维度的优势归零）。下次再让 Opus 4.7 改一个 CRUD，我会先把项目级的 Skill 关掉，让它轻装上阵。

但话说回来——我得诚实说，这次更新我体感上是更偏爱 Codex + GPT-5.5 这条路线的。不是因为模型本身更强，是因为它的 stack 整体调得太顺手了。裸跑就够，不用我费心配置；反应直接，不用我反复修正方向；速度快，不打断我的思路。这种"开箱即用"的精致，本身就是一种产品力。Anthropic 这边模型本身是过硬的，但要让它体感跟上，需要使用者更懂得"什么时候该装，什么时候不该装"——这是一道更高的门槛，对应的也是一种更高的天花板，但对于"我只想快速干完这件事"的日常场景，门槛带来的摩擦是实打实的。

至于"GPT-5.5 把 Opus 4.7 编程碾压"这个标题——我没写，因为它不真。但"我让 Opus 4.7 改个 CRUD 折腾了一小时，原因不在模型；这次 Codex + GPT-5.5 的更新真的让我惊艳"——这是这次想说的。