清华那个32B的“循证”模型，我拿自己的陈年仓库压了一周才敢下结论

上周我做了一件有点较劲的事：把一批上半年就该修、但一直没人愿意碰的历史bug，交给了一个开源模型。

不是Claude，不是GPT，也不是Qwen的主推版本。

是清华深圳国际研究生院刘厚德、王立博团队开源的VeriLoop Coder-E1，中文名“循证”。

这个名字起得有点意思。写代码的AI满大街都是，但敢把“循证”两个字挂在名号上、还拿评测榜单说话的，不多。我把它量化版拉下来，在自己真实的旧仓库里压了一周，有些话现在可以说说了。

先交代背景：那批bug，人看了也头疼

我们这边一直在做面向OPC创业者的小工具和小型SaaS。技术栈很杂，有几个仓库是早期接单攒下的，从Python到老版本Node再到几段陈年Go，什么都有。

问题在于：这批仓库能跑，但没人敢动。

有几处bug隐藏得很深，不是语法错，也不是接口挂，而是特定边界条件下数据对不上。客户那边偶尔报一次，我们查两天，修一处，又会冒出新问题。后来团队默认的策略就是——先拖着，等下一次重构再说。

但重构永远不来。OPC创业团队就这样，人力永远被新需求推着走，历史欠账只能越积越高。

好，现在问题摆出来了：不是“写个新功能”，而是修旧代码，还要保证不修坏。这种活，恰恰是最不适合让普通模型“闷头写”的。

为什么我当时选了它

8月中旬，Hugging Face那份开源模型现状报告又把Qwen推到了台前。阿里千问过去6个月全球累计下载量突破30亿次，超过Meta、超过Google，开源生态里确实算最大的基础之一。这本身值得关注，但对OPC创业者来说，下载量不等于交付质量。

我真正在意的，是榜单背后有没有“验证”这个变量。

VeriLoop Coder-E1在公开软件工程基准评测里的成绩，我抄一遍具体数字：SWE-bench Verified 85.20，SWE-bench Pro 62.38，Terminal-Bench 2.0 76.40，Deep SWE 33.63。

这几个分数，外行看着可能无感。解释一句就懂了：SWE-bench Verified是业界公认的“真实软件工程修复”硬榜，考的不是写代码有多快，而是能不能在真实仓库里把问题修掉、并且测试全过。

更值得玩味的是它的对比口径。截至7月27日，跟DeepSeek-V4-Pro、MiniMax-M3、GLM-5.2、Kimi-K3、Qwen3.6-27B这些版本放在一起比，在32B及以下开源模型里，它前三项第一，深度学习环境这项第二。

32B以下，本地能跑，数据不出机房，这对很多OPC创业者来说意味着一个非常现实的落地场景：敏感客户代码不需要上传给闭源API。

还有一个细节我印象很深：官方模型仓库当时下载量只有763次，但两个社区量化版本下载量分别到了16120次和8541次。

官方只有700多，社区却有2万4千多人动手了。这说明什么？

说明真正干活的人，早就开始找“能在自己机器上跑起来”的版本。量化，才是落地的第一道门槛。

怎么用的：我没有让它“写代码”，我让它“先证明”

把VeriLoop拉到本地以后，我没有急着扔需求进去。

我挑了一个最头疼的历史bug：一个订单导出功能，在金额包含多位小数、同时有折扣和汇率换算时，偶尔会差了0.01或者0.02。这种差几分钱的问题，财务对账时非常要命，但极端难查。

第一天，我只给它两样东西：那个仓库的局部环境，和一组我在过去半年里攒下的失败测试用例。

然后我提了一个要求：别先给我方案，先让测试把这个case跑红。

这其实是我从VeriLoop的设计里反推出来的用法。它的核心不是“生成代码然后祈祷”，而是每一轮生成都要经过测试验证，通不过就分析原因、修正，再验证，直到产出可靠代码。

第一轮，它给了一个看起来非常合理的patch，把我以前的改法又包装了一遍。测试跑下来，还是红。

第二轮开始不一样。它没有继续在原来的修补思路上打转，而是回到测试失败的输出里，把一个我一直忽略的浮点精度初始化点挖了出来。

第三轮，它没有再动那个初始化点，而是调整了计算顺序和中间量的类型。测试第一次全绿。

那一刻我有点后背发凉。

不是因为它多聪明，是因为它不靠灵感，靠证据。这跟我见过的大多数“代码生成”完全是两种东西。

结果如何：边界更清晰了，但神话没有发生

一周下来，那批bug里，它能稳定收敛、测试全过的，大约占到六成多。剩下的，要么是业务逻辑太绕、测试用例本身写不清楚，要么是涉及跨仓库、跨服务的历史包袱。

诚实说，它不是一个“扔进去就全治好”的神模型。

它的核心价值在另一个层面：它逼着每一次修改都必须先过验证，而不是先给我一个能看的diff。这件事本身，就是绝大多数团队最缺的流程纪律。

这个结论，也让我重新审视了这一周模型圈的几条动态。

Anthropic这边，因为担心即将推出的Astra模型可能触及“关键网络安全能力阈值”，主动放缓了模型扩展速度，暂停了最新模型两周的RL训练。连Claude这样的一线玩家都在自我刹车，这在过去是不可想象的。Claude Code也在频繁更新，Computer Use、Skills API、Files API全面可用，新增了浏览器操作工具。

OpenAI这边的信号更直接：CFO说最迟2027年完成上市，本季度整体年化营收增长35%，企业级业务年化营收增长50%，AI编程与办公产品周活跃用户突破2000万。数字放在那里，闭源商业化的压力一点没小。

Mistral发布了Agentic Search，用五工具的多步检索循环，解决长文档里“找到信息再验证信息”的问题。字节跳动Seed基础模型团队也在8月中旬做了一轮组织架构调整，成立Pretrain Data、Horizon RL、Product Posttrain-Work等专业组。

把这些放在一起看，我的判断很明确：大模型这轮的竞争，已经从“会不会写”转向了“能不能交付，并且交付得稳”。Qwen用30亿下载量证明了开源生态的规模，VeriLoop用32B以下榜首证明了验证闭环的可行性，这俩其实是同一件事的两面。

换作你，能抄什么作业

这件事给OPC创业者和coding开发者的启发，我觉得可以分成三层。

第一层，先给自己立个规矩：没有测试的修改，不许上线。

听起来像废话，但真用起来，大部分团队的“测试”只是摆设。VeriLoop这种模型的价值，不在于它替你写了测试，而在于它把验证当成了工作流的一部分，而不是收尾动作。你可以不用它，但你得有一个机制，让代码先证明自己，再谈合并。

第二层，建一张“模型池”，谁负责什么，心里有数。

我们内部现在有个粗糙但好用的排班逻辑：

• 需要反复验证、修复历史bug的，先上VeriLoop这类循证模型，数据不出本地，安心；
• 日常新功能开发、代码生成，用Claude Code或者GPT企业版，它们的工程化生态更成熟；
• 长文档检索、跨来源验证，Mistral的Agentic Search可以单独排上用场；
• GUI操作、多模态识别，Qwen-UI-Agent和Qwen3.5那一脉值得盯着。

不要指望一个模型通吃。OPC创业者最该有的能力，是知道什么任务派给什么模型，以及为什么。

第三层，榜单分数要会看，别只盯总分。

VeriLoop的官方下载量只有700多次，社区量化版却有2万多人用，这个反差本身就是个信号：真正决定一个模型能不能落地的，不是新闻稿里的排名，是你能不能在自己的设备上跑起来、能不能塞进自己的流程。32B以下这个标签，对本地部署、隐私敏感的项目，价值比“总分第一”大得多。

至于Gemini、Grok、Llama、Gemma、文心一言、星火、百川、Step、Phi、Yi、Skywork这批，这一周没有让我想单独打开的重大变化，但模型池里它们的位置没有动。我从来不会因为谁热就换掉谁，关键变量只有一个：它在我的落地场景里，能不能稳定交付。

最后说一句直给的话。

今天还在比“谁的模型能写更多行代码”的人，已经跑错赛道了。真正能让一个小团队活下来的，不是生成得快，是交付得多、返工得少。验证这件事，过去被我们当成了流程的尾巴，现在它正成为流程的起点。