便宜模型能不能替你把一份需求文档翻成能跑的代码？
上周 arXiv 挂了篇论文，测的就是这件事。编号 2609.18052，9 月 16 号提交，两位作者，Adikari 和 Herath。7 页，7 张图。
结论不好看。
实验是这么做的。三个模型，Gemini Flash 3、GPT-5.4 mini、Claude Haiku 4.5，都是各家最便宜那一档。任务 992 道算法题。输出格式统一规定成 Java Spring Boot 的 service 方法，签名和传输对象都有硬模板。
模型和 agentic 工具交叉出四种组合，再乘两种 prompt 写法，一共八种配置。
两个约束得单独拎出来。禁止迭代修改，一次生成定生死。明令不许硬编码答案。后一条堵的是最省事的糊弄路子，前一条堵的是试错。
然后看数。
生成的 7593 个方法先按八个类别分好。分类依据是它到底干了什么才把答案交出来。分完全部部署跑一遍，跑出 7936 次请求，再跟分类结果对回去。
结构层面几乎全过。签名对，对象对，该有的都有。这一层的检查不管值是从哪来的。
问题出在值上。38.4% 的方法，返回的那个值根本不是算出来的。
交出来的答案里，正确的只有 12.9%。
这里得补一句，别把分母读错。12.9% 是拿"交出来的答案"当分母算的，不是拿 992 道题当分母。
我看到这儿停了一下。12.9% 单独看只是个坏消息。把它和"结构几乎全过"放在一起，才是这篇论文真正想说的东西。
还有一条更反直觉。按类别拆开看，交答案的频率和正确率反着走。真正做了计算的那批，最少交答案。可它们交出来的，正确率是 19.3%。
反过来读。最爱给你答案的那一批，就是没算的那一批。
这就有点麻烦了。一个没算的方法，不报错，不抛异常。签名工工整整，方法体看着也像那么回事。它只是往返回值里填了个东西。
普通人用它，最顺手的验证动作是跑一遍看报不报错。
这一步恰好抓不到它。它跑得通。
八道题的题干还被从 prompt 里拿掉了，专门看输入不全会怎么样。这一块我没细看，先不提。
所以这条我收进来，不是因为"便宜模型不行"这个结论。这话听着顺气，听完没什么用。
它有用的地方，是把"AI 写的代码要检查"这句正确的废话，换成了一个能动手的方向。
检查它有没有真的算。
一个粗糙但够用的办法：把输入换个数量级，看输出跟不跟着变。不跟着变的，后面基本不用看了。这招抓不住全部情况，但能抓住这一类。
补一句边界。这篇只测了便宜那一档，贵的一档没测。所以它证明不了贵模型也这样。反过来也一样，别拿它去给贵模型洗地。
它也不是在说 AI 写不了代码。它说的是，把需求翻成代码这件事，现在还不到能撒手不管的时候。
我的看法是，这类错误不会因为模型便宜才出现。模型被训练成要交出一个答案，格式上还得像样。真没算出来，它也会往里面填点什么。
再补一句论文自己列的限制。作者挺老实：一次配置只跑一轮生成，测试脚手架覆盖不全，计时只有单次，分类是在句法层面做的。还有一条最要紧的，语料污染。
992 道算法题，模型训练的时候很可能见过。
见过还这样。这个推论是我加的，不是论文的结论，但我觉得它站得住。
另外那个八分类的分类法，我只看懂一半。它怎么区分"没算"和"算了但算错"，我没完全吃透，先放这儿。有兴趣的自己找来读，读完愿意回来给我讲讲的，更欢迎。
这期只收这一条。
上面这条你要是试过、或者觉得我讲错了，欢迎告诉我。讲错的我补，没讲清的我改。
本周就这些，下周见。