2026年6月29日，一个名为Ornith-1.0的开源项目被推上Hacker News首页，标题写着「self-improving open-source models for agentic coding」。不到24小时，几百条评论涌入，从技术分析到社区吐槽，吵成一片。
而争论的起点，一个叫DeepReinforce.AI的团队在博客里写了这样一段话：他们不再靠人类手工设计训练框架来教AI写代码，而是让模型自己去生成那个框架。
会搭脚手架的模型
如果你看过建筑工地，你一定见过「脚手架」——工人站在上面砌墙，墙砌好了，架子拆掉。AI训练里也有类似的东西，叫做harness或scaffold：一套固定的流程告诉模型「先读题、再搜索、再写代码、再测试」，然后根据测试结果打分，分高的方向被强化。
大多数编程AI用的都是人类工程师预先设计好的同一套脚手架。它的好处是稳定可控，代价是僵化——同一个流程可能对修bug有效，对从零写项目却是拖累。
Ornith-1.0做了一个改动：把脚手架从「固定设施」变成了「学习对象」。
训练过程分两步。第一步，模型拿到一个编码任务和之前用过的脚手架，然后自己提出一个改进版。第二步，用改进后的脚手架去生成代码答案。如果答案通过了测试，奖励信号会同时强化这两步——模型同时学会了「怎么解这道题」和「什么样的解题策略更有效」。
反复循环之后，脚手架不再是死的，而是随着任务类型的不同自动分化：面对bug修复，模型可能进化出一套先读测试用例再定位的策略；面对从零建项目，可能出现先搭框架再逐模块填充的策略。这些策略不是工程师手写的，是模型自己在强化学习中摸索出来的。
团队管这叫「self-scaffolding」（自搭脚手架）。论文《EvoTrainer》也提出了类似思路——让训练侧的诊断工具与模型策略协同演化。Ornith-1.0把这个思路做成了可用的开源产品。
图：Ornith-1.0 自改进训练流程。模型在强化学习中同时优化「设计脚手架」和「解决任务」两条路径。来源：deep-reinforce.com
三把锁防作弊
一个显而易见的风险是：如果模型可以自己设计脚手架，它完全可能学会「抄近道」——直接读测试文件里的正确答案，或者硬编码输出预期结果，跳过真正的编程过程。
团队用了三层防线来应对。第一层是物理边界：测试环境和工具接口被锁定，模型改不了。第二层是程序化的监控器：任何尝试读取禁止路径、修改验证脚本的动作都被标记，该轮得分为零。第三层是一个冻结的LLM审查官：如果模型的解法虽然在形式上通过了测试，但本质上是钻空子——比如靠复制环境里的示例代码来蒙混——审查官会否决掉。
三层防线对应三种不同层级的作弊可能：环境级、行为级、意图级。这个设计思路本身比具体的实现细节更有参考价值。
数字之外
在基准测试上，Ornith-1.0-397B（旗舰版，约3970亿参数）在Terminal-Bench 2.1上拿了77.5分，在SWE-Bench Verified上拿了82.4分。这两个分数都超过了Claude Opus 4.7（分别为70.3和80.8），但低于更新的Claude Opus 4.8（85和87.6）。35B版本的表现尤其有意思：64.2的TB-2.1分数，不仅远超同级的Qwen 3.5-35B（41.4），甚至超过了Qwen 3.5-397B（53.5）。
图：Ornith-1.0-397B 基准测试对比。旗舰版在两个核心 benchmark 上均超过 Claude Opus 4.7。来源：deep-reinforce.com
不过，这些数字应该带着几个前提来读。
首先，HN用户simonw指出，「self-improving」这个说法描述的是训练过程，不是模型的使用方式——你下载的权重不会自己在你的电脑上进化。kennywinker更直接：「We ran the model to train the model → ‘self-improving’。」
其次，多位用户质疑这是一次「benchmaxxing」——一种专门针对基准测试做优化的策略。用户S0y评论道：「These are simply benchmaxxed versions of either Qwen or Gemma 4.」v3ss0n的态度更尖锐：「Self-Improving bullshit. It is just Qwen 3.5 finetune benchmaxxed. Nothing spectacular.」
但也有用户替Ornith说话。ricardobayes写道：「This is the first Qwen fine-tune that is not immediately rejected by the local LLM community, and in some cases even being recommended.」另一位用户dofm提到一个有趣的观察：Ornith「更倾向于主动执行网页搜索，这在它自己的方式里很迷人。」
juliangoldsmith则对基准测试本身的可靠性提出了质疑：Ornith的榜单把Kimi K2.6和K2.7排在了底部，甚至低于35B的Ornith；Gemma 4 26B的排名却远高于GLM-5.2。「这些结果不怎么说得通。」
还有一个容易被忽略的细节：Ornith-1.0是一个推理模型（reasoning model），回复以<think>…</think>块开头，然后才给出最终答案。多位测试者发现，在不提供工具访问的情况下，这种推理倾向会导致大量幻觉——NitpickLawyer对此的反应是：「测试一个明确标注为agentic的模型却不给它工具，这本身就很荒唐。」
编程AI的三条路线
如果把当前的AI编程工具放在一张地图上看，大致能看到三条路线在并行推进。
第一条是「云端全栈智能体」，代表是Devin和Claude Code。这些产品把AI包装成一个完整的虚拟工程师——你开一个issue，它自己去读代码库、写方案、提交PR。它们的核心壁垒不全在模型本身，更在工程化的环境集成和交互设计。
第二条是「编辑器的副驾驶」，代表是GitHub Copilot和Cursor。这些工具嵌在IDE里，不试图取代你的工作流，而是在你敲键盘的时候补全、建议、纠错。它们拼的是低延迟和上下文感知能力。
第三条是「开源模型+本地部署」，Ornith-1.0和Qwen系列的编程精调版都属于这个阵营。它们的价值主张是：你不需要把代码库上传到任何人的服务器，不需要按月付费，不需要接受任何使用限制。代价是你要自己搞定硬件和部署。
Ornith-1.0的特殊之处在于，它在第三条路线上尝试引入第一条路线才有的「自主性」——通过自搭脚手架，让模型在写代码的同时摸索更有效率的解题策略。至于这个尝试是否成功，目前来看，只能说方向有趣、验证尚早。
开源的一面
不管争议如何，Ornith-1.0做对了一件事：它公布了完整权重，MIT许可证，全尺寸覆盖——9B Dense（单张80GB GPU可跑）、31B Dense、35B MoE和397B MoE。支持vLLM、SGLang、Ollama、llama.cpp等多种部署方式，256K上下文窗口。在AI编程工具越来越封闭的当下，一个能本地运行、自由修改的编程模型本身就具有一定的对冲价值。
当然，9B版本也需要80GB显存的GPU，这意味着大部分消费级硬件（即使是高端显卡）仍然跑不动。用户giancarlostoro的评论说出了很多人的无奈：「the dense 9B fits on a single 80GB GPU. Us mere mortals cannot use this.」
自搭脚手架的思路能否成为一个稳定的技术方向，还需要更多独立验证和时间来检验。但有一点是确定的：让机器学会搭建自己的学习脚手架，这条路的逻辑并不荒唐——人类工程师的成长过程本身也是一种不断升级自己工具和方法论的过程。如果这条路最终走通，它带来的影响可能远超任何一个基准测试的排行榜。
本文的素材来自公开信息和社区讨论。如果你对这个话题有更深入的一手经验，欢迎指出文中的不足。