DeepSeek V4 Flash实操测试：50个真实PR任务表现相近

两种测试框架，同一个模型，两项任务之差。

我们在 octomind 和 opencode 上用 DeepSeek V4 Flash 跑了 50 个真实 PR 任务——同一模型、同一 prompt、网络隔离。结果 45/50 对 43/50，judge 评分相差三分，每个任务花费都是三美分左右。模型已经强到与测试框架解耦；现在拉开差距的是谁能把任务跑完。

模型不会制造戏剧性

两周前我们发了一篇同模型 A/B 测试，结论是测试框架决定一切：octomind 解出 24/25，opencode 只有 19/25，成本还是两倍。我们刚用 DeepSeek V4 Flash 重跑了这个实验，用更严格的基准、两倍的任务量——模型拒绝制造任何戏剧性。45 对 43。

在 50 个真实 pull request 上（来自 C++、JavaScript、PHP、Python 和 Rust 合并修复），deepseek-v4-flash 在 octomind 解出 45/50，在 opencode 解出 43/50——同一模型、同一 system prompt、网络隔离，两边每个任务花费约三美分。模型已经强到与测试框架解耦。测试框架还能证明的东西，只剩它有多经常能把任务完成。

我们跑了什么：真实 Bug，不是谜题

octobench 的 case 不是合成谜题。每一个都是真实的 bug 或功能——维护者真实合并过的、在父 commit 上重放、由项目自己的 held-out 测试加上 0–100 分的 judge 评分来评判。五十个 case，每种语言十个。

自 glm-5.2 那次运行之后，我们重建了方法论，因为第一版有个能开卡车过去的漏洞：基准来自合并的 PR，而没有什么能阻止 agent 去读那个已合并的 PR。早几轮 opencode 在 49 个 case 中有 13 个从 raw.githubusercontent.com 抓取上游修复然后照抄。octomind 的默认 role 更隐晦但精神上更糟糕——它命令 agent 去 websearch 上游 issue 并"精确镜像其方法和 API 契约"。在一个由合并 PR 组成的基准上，这等于让它去读答案。

所以这次跑得很干净：两套测试框架共用一份 system prompt，从 octomind 的 role 蒸馏而来，剥离了 client 特定的部分。同步脚本会在两者出现 drift 时让构建失败。没有通往答案的路径。两套 client 都禁用了 web search 和 web fetch；setup 完成后 GitHub 从 agent 容器内不可达。同一模型、同一 endpoint——官方 deepseek-v4-flash 在 api.deepseek.com，octomind 里是 deepseek:deepseek-v4-flash，opencode 里是 deepseek/deepseek-v4-flash。有一个测量备注改变了我们对结果的解读：我们最初用的是第三方 token-plan endpoint，中途切换到了官方 API。官方 endpoint 每个请求快约 3 倍。之前我们记在"client 慢"账上的很大一部分，其实是 provider 慢。

两项任务、三个 judge 点之差。做个校准：我们在这套基准上测量的 judge 噪声约 1.7 分，所以差距是真实的但大约是噪声底线的两倍——不像 glm 那次跑出了五项任务的差距。成本则基本持平。

新版 Flash 数字

官方 V4 Flash 于 7 月 31 日上线，这个 release 是真家伙：DeepSeek 自己的 GA 数字显示它在 agentic 基准上击败了 V4 Pro 预览——Terminal Bench 2.1 达 82.7、DeepSWE 达 54.4、Toolathlon verified 达 70.3——这一切来自一个 284B 总参数、13B 激活参数的 MoE 模型和 1M token 的上下文窗口。翻译到真实 PR 工作上：每次 landed fix 耗时 12 分钟、花费三美分，通过的 case 平均 judge 分约 94，两套框架皆然。不需要盯着、不需要排查神秘超时。对于维护者工作中那 90% 的常规部分，这个价格下的这个模型就是一个已解决的问题。

而这里才是有趣的部分——它与测试框架解耦了。glm-5.2 那次跑出了同一模型在两个测试框架间五项任务的差距。V4 Flash 落在了两项任务之差。两项。一部分原因是模型自带了更强的自律：减少了浪费的读取、减少了提前庆祝、更不需要一个 supervisor 来督促它诚实。一部分原因是这个基准对两套 client 都更严格了——我们封死了答案，而这对 octomind 的默认 role 打击不亚于对任何人 web access 的打击。我们把考试难度提高了，差距反而缩小了。两件事同时成立。

一个天花板，五堵墙

octomind 失败的五个 case 与 opencode 失败的五个完全相同：yaml-cpp 的二进制 emit 风格、pino-pretty 的控制字符剥离、commonmark 的 fence tabs、rustls 的扩展放错位置，以及 React 隐藏的水合 hang。跨测试框架出现完全相同的墙，这就是模型盲点的样子——不是测试框架的人为产物。这些都是组合密集型的修复，模型无论如何 prompt 都一直漏掉同级的路径或 per-message 规则。对 pino-pretty 做了四次插桩重跑，全都漏掉了同一个同级路径。这是模型的问题，不是引导的问题。对 86–90% 这个 band 的诚实解读：最后 10% 是模型质量结束、其余一切开始的地方。

测试框架仍然决定的是完成度：octomind 没有独有的失败。opencode 多丢的两场都是从未落地的完成：Guzzle 的 cookie 前缀，opencode 花了 17 分钟失败，octomind 4 分钟通过；Monolog 的 trace 长度，opencode 3 分钟放弃，judge 分只有 36，而 octomind 2 分钟落地 94.67。

React 那个 case 是同一个故事的最大声版本。那是一个设计如此就会 hang 的 bug——每个错误尝试都会阻塞而不是失败——而且在一个巨型 repo 上。opencode 在 63 分钟、394 步后停手，分数 36.67。octomind 磨了 271 分钟、1,322 步——同样花 0.32 美元——才到一个能过 67 个隐藏测试中 66 个的修复。我们把它记为失败，因为它确实是，但 judge 给这个 near-miss 打出了 41.67。（有一次运行在 213 分钟时因 provider 配额错误死掉，从恢复的 session 继续跑完的。）

这就是终局化：不是运气更好，是更拒绝提前放弃。把 React 这个异常值去掉，octomind 平均每个 case 约 7 分钟，opencode 约 9 分钟。

但代价是真实的。octomind 写出的 output token 是 opencode 的 2.6 倍——150 万对 57.3 万。它话更多。在 React 规模 repo 上，它细粒度的工具循环遇上每次调用的大上下文是真实的速度天花板；更粗粒度的步长和上下文精简是我们自己接下来的待办清单。能完成一切的测试框架仍然会在字数上让你付出代价。

天花板与地板论点

模型设定天花板。测试框架设定地板。glm 跑完之后我们写过模型质量是入场费，测试框架才是拉开差距的地方。V4 Flash 把这个观点收紧成更精确的表述：模型强到这个程度会把所有人的天花板抬高——挑你喜欢的模型，测试框架之间天花板几乎不动。测试框架决定的是你实际多经常够到它，以及最后 5% 是落地还是到 63 分钟被宣布完成。

glm-5.3 刚刚发布

同一基准，下一个问题。昨天 Zhipu 发布了 GLM-5.3：基础模型与 5.2 相同，增益全来自 post-training。Zhipu 声称比 5.2 在 coding 上提升 50%，称之为最强开源 coding 模型。现在已通过 their coding plan 可用。开源权重承诺约两周后上线，要过安全审查。这对我们来说比大多数 release 都重要，因为 glm-5.2 是开启这个故事的那个模型。第一次跑，octomind 里的 glm-5.2 击败了跑 claude-opus-5 的 Claude Code（24/25 对 23/25，63 美元对 82 美元，3.6 小时对 6.7 小时）——而且是付全价的：那次跑经过了没有 prompt caching 的 endpoint，所以每轮都以标价重新购买完整上下文。所以下一次跑顺理成章。glm-5.3 对 glm-5.3 对 glm-5.2，在同一封闭 50-case 基准、两套测试框架、答案锁死的情况下。宣称的 50% post-training 跳跃正是供应商基准喜欢而真实 PR 会细细审视的那种数字。而底下还有一个更尖锐的问题：V4 Flash 刚刚证明强模型能把测试框架差距缩小到两项任务。如果 5.3 真的比一个已经击败 Opus 的模型还要好那么多，地板会随着天花板一起上升吗——还是最后 10%会完全留在原地？值得一探究竟。

复现步骤和每个 case 的原始产物已 pin 在本文描述的 commit 上。GLM-5.3 对 5.2 是下个日程，同一封闭基准上 Claude Code 和 Codex 列紧随其后。