DeepSeek代码智能暴涨4倍？一个验证循环的秘密

让一个大模型的代码能力凭空翻四倍，需要的不是更大的训练集群，也不是更贵的显卡。需要的只是一个你觉得”好像很简单”的小东西——验证循环。

IronBee 团队最近发了一篇博客，讲的是怎么给 DeepSeek 加了一个验证层（verification loop），然后它的代码智能直接飙到了接近 Opus 的水平，成本只要后者的七分之一。这不是吹的，不是”感觉上变强了”，是实打实的 benchmark 数据。

为什么加个验证就有用#

大模型写代码这件事，本质上是一个”猜”的过程。它根据你前面说的话、上下文里的提示，猜下一段代码应该长什么样。猜得准的时候很惊艳，但猜错的时候也错得离谱。

传统思路是：猜不准？那就训练一个更大的模型。更多参数、更多数据、更长的训练时间。这条路走到今天，边际效应已经很明显了——砸进去的钱越来越多，智能的提升越来越小。

IronBee 的思路完全相反：不是让模型变得更聪明，而是给它的输出多加一道质检。具体来说，当模型生成一段代码之后，不是直接交给你用，而是让另一个验证模块去跑一遍这段代码，检查它能不能编译、能不能跑通测试、逻辑有没有漏洞。如果检查不通过，就回到模型重新生成，直到通过为止。

这个过程就是”验证循环”。看起来简单，实际效果惊人。

团队在 SWE-Bench 上跑了测试。SWE-Bench 是目前最主流的代码能力评估基准，让模型去修真实的 GitHub issue——不是那种”写一个冒泡排序”的玩具题，而是真实的开源仓库里的实际 bug。

加了验证循环之后，DeepSeek 的分数从原本的 20% 左右直接跳到了接近 50%，而 Opus 的分数大约在 45-50% 这个区间。算笔账：训练一个 Opus 级别的模型需要多少成本不用我说了，而验证循环带来的推理阶段额外计算量，换算成 API 调用费用，大约是 Opus 的七分之一。

七分之一的成本，一样的效果。这不是渐进式改进，这是路线之争。

验证循环当然不是银弹。它有个很致命的假设：你得知道”正确答案”长什么样。

对于代码任务，这个假设基本成立——测试用例就是答案。编译过不过、测试跑不跑得通，这都是自动可验证的。但对于写作、翻译、创意生成这类没有标准答案的任务，验证循环就不好使了——谁来设计那个”验证器”？

另一个问题是延迟。每次验证不通过就要重来，意味着生成时间可能增加好几倍。对于需要实时响应的场景（比如 IDE 里的代码补全），这种方式基本不可用。但对于 CI/CD 流水线、代码审查、bug 修复这些”给它多点时间也没关系”的任务，验证循环的性价比高得离谱。

DeepSeek 这次的尝试，给整个行业提了个醒：提升模型能力的方法，远不止”堆算力”这一条路。有时候，最聪明的优化不在训练阶段，而在推理阶段的那个”小小”的质检环节里。

来源：Hacker News | Medium