Opus 4.7 vs 旧版 Opus 4.6 vs 新版 Opus 4.6
大家都说 Opus 4.6 变笨了。随后 Opus 4.7 在测试中途发布，所以我把两个问题都端到端跑了一遍：新的 Opus 4.6 还能匹配 3 月 19 日的 Opus 4.6 吗？4.7 是否真的更好？
三个 Opus 快照，28 个历史 Zod 任务，三个实验臂的测试通过率完全一样，都是 12/28。只看原始通过率，这次升级看起来是平的。越过测试门槛后，各实验臂的差异足够明显，所以更有用的心智模型是：Opus 4.7 在方向上更好，但不是类别意义上的更好。
Opus 4.7 看起来是一个更有纪律性的编码者，而不是一个根本上更聪明的编码者。
成本、token 和墙钟时间方面：4.7 的单任务成本低于 3 月的 4.6（$8.11 vs $8.93），总 token 更少（44.0M vs 49.1M），完整 28 任务运行也更快完成（1h 30m vs 1h 36m）。新的 4.6 是最便宜的实验臂，但它要多花 2.3 倍时间，产出更松散、更不等价的补丁。
我正在构建 Stet，它会在通过/失败之外，从等价性、足迹、工艺和纪律性几个维度给这些运行打分。Zod 被选作一个具体、真实的 repo，而不是高层级基准测试；我在内部 repo 上也见过类似形态。
方法
对每个任务：从 Zod 中采样一个已合并 commit 作为基线，在 Claude Code 中运行每个 Opus 快照来复现相同变更，然后在测试通过率之外，对每个补丁进行以下评分：
- 等价性 —— 无论测试是否捕捉到，补丁是否解决了预期问题？
- 代码审查通过 —— 二元判断：补丁看起来是否值得合并？
- 足迹风险 —— 补丁与已接受变更相比有多发散？越低越好。
- 工艺（0–4）—— 简洁性、连贯性、意图性、健壮性、清晰度。
- 纪律性（0–4）—— 指令遵循、范围纪律、diff 最小化。
评分说明：评审模型是 gpt-5.4，三个实验臂都使用相同的 rubric 版本。每个补丁独立评分：评审只看到补丁和任务，不看到实验臂标签或模型名称。没有双评审校准，所以应把绝对分数视为方向性信号；跨实验臂差值才是更值得信任的部分。
4.7 改变了什么
对于编码智能体工作，观察到的最大变化不是原始任务完成率，而是补丁形态。Opus 4.7 看起来更有纪律性：它避免了失控会话，避免了高足迹补丁，也更常产出被等价性评分器判断为与人工变更对齐的补丁。
取舍是触达不足。Opus 4.7 值得在你自己的 repo 上测试，但不要期待简单的通过率跃升。改进主要体现在足迹和对齐上，而不是通过的可见测试数量上。
头条结果
三个实验臂通过的测试完全相同。4.7 唯一没有领先的维度是二元代码审查门槛，3 月 19 日那次运行更常通过（11 vs 7）；新的 4.6 单任务成本略低。
很多人说 4.7 更贵。在这个切片上并不是这样：$8.11/任务，相比 3 月 4.6 的 $8.93；总 token 为 44.0M，相比 49.1M。新的 4.6 是最便宜的实验臂（$6.65，35.6M token），但它要花 2.3 倍时间产出更松散、更不等价的补丁；这点省钱换来的是更差的输出。
其他地方，也就是等价性、足迹风险、可发布外观补丁的可维护性、平均任务时间，4.7 都是三者中最强的。
新版 Opus 4.6 是最弱的实验臂：等价性更低、足迹风险更高、任务耗时更长。尽管它花了 2.3 倍时间，但输入 token 比 3 月运行少了约 28%。无论底层发生了什么变化，输出都是更松散的补丁，而且思考得更少。
足迹风险是最清晰的信号
足迹风险问的是补丁是否比已接受变更更大，或更发散。这是我最信任的差值：4.7 的相对下降超过 2 倍，而且是在比 rubric 分数更连续的尺度上测得的。
Count of patches per risk bucket. Opus 4.7 is the only arm with zero high-footprint patches.
Opus 4.7 没有高足迹补丁。新版 Opus 4.6 更常做出触及代码多于必要范围的变更。
等价性
等价性问的是补丁是否解决了预期问题，而不只是可用测试是否捕捉到它。4.7 的补丁与人工编写的 Zod 变更更加等价，这与它更贴近代码库标准和人的意图相一致。
Rubric 分数
两个 0–4 rubric：review（只在通过二元代码审查门槛的补丁上运行）和 discipline（在每个补丁上运行）。
在 review 上，模式并不是“4.7 一律更正确”。更接近的说法是：当 4.7 产出一个看起来可发布的补丁时，这个补丁往往更干净、更可维护；可维护性差值（2.00 → 2.46 → 2.85）是 review 区块里最大的差距。
在 discipline 上，4.7 在每个维度上领先，这与足迹风险结果一致：补丁更紧凑、更贴合任务。范围纪律（+0.31 到 +0.45）和 diff 最小化（+0.32 到 +0.37）是相对两个 4.6 实验臂最大的差距。
工艺均值，也就是 0–4 上的简洁性、连贯性、意图性、健壮性、清晰度，在各实验臂之间都处于约 0.1 以内（2.86 / 2.84 / 2.93），所以在 n=28 下应视为与噪声一致。唯一的分隔点是意图性，它从 2.98 → 3.27 → 3.58 上升：4.7 的补丁读起来更有目的性。
数字之外，评分器叙述在不同实验臂上的聚类也不同。
三者共有的弱点。 静默 fallback 分支会隐藏根因，而不是传播诊断：把未知 precision 当成 unrestricted，给只含 null 的 tuple 发出空 anyOf，给未映射类型打印原始英文标签，递归上限命中时返回原对象。调用点上的类型系统逃生舱：as any、内联 _zod intersection、整表达式 SafeParseResult cast，用这些来替代收紧底层边界。
旧版 Opus 4.6。 鲜明标志是：不该有的管线铺设。为相邻想法添加了字段和 helper，但从未被消费：ProcessParams.parent、Sizable.verb、一个 Identity 类型、一个只有单个调用方的 ~validate 方法。注释掉的草稿代码留在生产文件中。在带有 Deno 和 Node 镜像表面的任务上，有些能干净镜像，另一些则留下过期的 deno/lib。
新版 Opus 4.6。 破坏性标志是：签入生成产物。Vendored node_modules/.pnpm 树、node_modules/.bin/attw、.pytest_cache、编译出的 .pyc 文件；某个任务里补丁膨胀到 2.6 GB。差点命中的公开字符串："draft-04" 写成 "draft-4"，本应是 patch release 却把版本号 bump 到 4.2.0，未被要求却添加了 recheck 依赖。在平行 locale 表面上重复 lookup table（希伯来语 TypeLabels/parsedType/Origins/ContainerLabels；西班牙语 TypeNames vs parsedType）。
Opus 4.7。 4.6 弱点的镜像。补丁紧紧留在任务直接暗示的一个或两个文件内；不会出现无关重构。弱点是范围过窄：多点位重构被收窄到单个示例位置（本应覆盖 v3+v4 helpers 的断言移除只触及四个 v3 点位；OpenAPI-3.0 null 修复处理了 tuple 分支，却把 primitive 和 union case 留下）。局部逃生舱，比如 Writeable cast，取代了让 generic constraint 感知 readonly。智能体能可靠遵守“不要执行代码审查”这类元指令，并保持新 API 表面为 additive，而不是替换已有 alias。
补丁为什么失败
按照测试通过门槛，三个实验臂都在同样的 28 个任务中的 16 个上失败。原因的聚类方式不同：
The pass rate is identical. The failure shape is not. Opus 4.7 never runs out the clock, and its patches drift from wrong problem toward looks right, tests disagree.
有两点很突出。4.7 从不会耗尽时间：它完成了每个任务。而且“等价补丁，但测试仍失败”这个桶在 4.7 上几乎翻了三倍（3 → 8），同时“非等价”这个桶缩小了大致相同的幅度。4.7 的失败转向了看起来正确但测试不同意：更多补丁被独立审查者判断为等价于已接受变更，更少补丁完全错过意图。
对这个变化要有所保留。它可能意味着 4.7 确实写出了更干净的补丁，但仍漏掉了测试套件捕捉到的细微义务；也可能意味着等价性评分器对紧足迹补丁比对大范围补丁更宽容。下面的触达不足模式与第一种解读一致，但这是一个值得审计的信号。
Opus 4.6 输在何处：广度。 两次 4.6 运行都反复错过需要并行更新 Node 和 Deno 的任务中的 Deno 镜像，让 localization pass 保持部分状态（希伯来语和西班牙语消息保留旧措辞或未翻译标签），并错过被要求的 API 表面：共享的 NEVER export、mini-schema 支持、整族断言移除。新的复跑还增加了非受迫性错误：提交 vendored node_modules 树、错误的发布目标字符串，以及与预期 release 不匹配的版本 bump。
Opus 4.7 输在何处：触达不足。 当 4.7 失败时，它停在狭窄的局部修复上：任务要求四个相关 inference 变更时，它只更新 ZodMiniType.check；应用 tuple-local 的 OpenAPI workaround，却留下 union-with-null 语义；用 Writeable cast 绕过 readonly discriminated union，而不是让类型感知 readonly。补丁对它们触及的内容来说干净且低风险，只是触及得不够。
三者共同点 是少数结构性困难点：能保留嵌套 inferred type 的 deepPartial，不会静默接受超限 case 的递归 cutoff，能把 parent link 一直带到 finalization 的 refinement clone，mini schema 上感知 predicate 的 refine，以及完整的希伯来语 localization pass。这里的失败不是推理或纪律性问题，而是任务结构问题。
结论
对于这个 Zod 切片，Opus 4.7 在方向上更好，但不是类别意义上的更好。
它没有通过更多测试，通过二元代码审查门槛的补丁更少，而新的 4.6 在单任务成本上略胜一筹。
不过，它在足迹风险上明显胜出（补丁紧凑度超过 2 倍），并且在等价性、纪律性、可发布补丁的可维护性、任务时间上领先。失败模式也同步变化：错题式补丁更少，失控会话更少，但更多情况是在狭窄修复上停得太早。心智模型是：一个更有纪律性的编码者，而不是一个根本上更聪明的编码者。
4.7 值得你在自己的 repo 上认真看一看。即使测试通过数量持平，补丁质量和与意图的对齐也会有实质性移动。
Zod 是一个 TypeScript schema library。你的 repo 会不一样；这恰恰就是要在你的工作上测量，而不是只看公共基准测试的原因。这就是 Stet 的用途。