6.75%——这是qwen3-coder-next首次尝试生成购物商场后端API数据类型的成功率。100次里有93次产出无效的结构化输出，接近全军覆没。
这个数字放在行业背景下不算意外。NESTFUL（EMNLP 2025）测过GPT-4o，嵌套工具调用序列的准确率只有28%。JSONSchemaBench（ICLR 2025）用1万个真实场景模式测试约束解码框架，最困难的那些覆盖率仅3%到41%。BoundaryML更激进，直接断言结构化输出会主动削弱模型推理能力——强塞JSON格式会让模型变笨。
共识很明确：函数调用（function calling）对付扁平、简单的模式还行。遇到递归嵌套或深层结构复杂度，业内基本放弃。
但如果你想让AI输出可确定——能解析、能验证、能循环修正直到收敛——结构化输出没有替代品。自由文本无法机械验证，自然语言无法编译。没有结构就没有反馈回路，没有反馈回路就没有保证。
所以Wrtn Technologies没资格放弃。他们必须让函数调用在那种被行业判死刑的复杂递归模式上跑通。
从6.75%到99.8%：不是换模型，是套马具
AutoBe是他们的答案。这是一个开源AI智能体，接收单轮自然语言对话，输出完整后端——需求分析、数据库模式、API规范、端到端测试、实现代码。
把那个6.75%的模型接上去，结果如何？最终编译成功率：99.8%+。五个Qwen模型全部达标。
关键不是更好的模型，不是更聪明的提示词。是一套马具——类型模式约束输出，编译器验证结果，结构化反馈精确定位错误位置和原因，让大语言模型自我修正。
概率模型外面包一层确定性循环。模型之外的工程，而非模型内部，造成了差距。
五阶段流水线：4种AST、4层编译器、自愈循环
AutoBe的架构像一条精密装配线。五个阶段跑过四种抽象语法树（AST）类型，配备四层编译器，自愈循环系统化地纠正大语言模型的错误。
第一阶段消化自然语言需求，吐出结构化规格。第二阶段把规格转成数据库模式。第三阶段生成API规范。第四阶段产出测试用例。第五阶段落地实现代码。
每个阶段都有编译器把关。不是简单的语法检查——是类型级别的验证，确保输出符合预定义的约束。出错就回退，定位，反馈，重试。循环直到通过。
这套机制让模型从"一次性赌运气"变成"迭代式逼近正确"。
Typia：把TypeScript编译器变成模式工厂
整个系统的核心叫Typia。它让TypeScript编译器分析源代码中的单个类型，自动生成模式、解析器、验证器、反馈生成器——全部自动化。
Qwen 3.5的0%到100%的翻转，具体机制就在这里。
传统做法是人手写JSON模式，或者靠模型自己猜。Typia换个思路：用编译期的类型信息，在构建阶段生成运行时需要的全部基础设施。模式不是猜出来的，是从类型系统里编译出来的。
这意味着反馈可以精确到字段级别。"第三层嵌套的对象数组，第7个元素的price字段类型不匹配"——这种粒度的人话反馈，让模型知道往哪改。
没有这套反馈生成器，模型像在黑暗里射箭。有了它，每次迭代都离靶心更近。
beyond后端：任何有确定性验证器的领域
第四章把镜头拉远。这套模式只适用于后端吗？
半导体设计有确定性验证器——电路仿真可以精确判定时序是否满足。化工流程有确定性验证器——物料平衡方程可以判定配比是否可行。建筑结构有确定性验证器——有限元分析可以判定应力是否超标。控制系统有确定性验证器——李雅普诺夫稳定性判据可以判定收敛性。
凡工程领域存在确定性验证器的地方，这套"概率生成+确定性验证+结构化反馈"的模式都可能复制。
不是替代专家判断，是把专家的验证能力编码成可自动调用的基础设施，让模型在试错中快速收敛。
为什么这个故事属于Qwen Meetup
最后一章回答一个反直觉的问题：小模型不是弱点，是马具系统最好的QA工程师。
大模型能力强，容错空间也大，容易掩盖马具的缺陷。小模型脆弱，一碰就碎，反而逼你把约束、验证、反馈做到极致。如果马具能让小模型从6.75%爬到99.8%，换大模型就是性能冗余，换任何模型就是可迁移的工程资产。
Wrtn Technologies的Jeongho Nam在分享末尾留了道开放式问题：当验证器比生成器更可靠成为常态，我们设计AI系统的方式，会不会从"堆模型能力"转向"堆验证基础设施"？
热门跟贴