阿里Qwen3.5翻车93次后，他们把成功率干到了99.8%

6.75%。这是Qwen3-coder-next在生成商场后端API数据类型时的首次成功率。100次尝试里，93次输出无效。

这个数字来自Wrtn Technologies的Jeongho Nam在Qwen Meetup上的实测。他团队开发的AutoBe，一个能把自然语言对话转成完整后端的AI Agent，最初接这个模型时几乎没法用。NESTFUL（EMNLP 2025）测过GPT-4o，嵌套工具调用序列的准确率只有28%。JSONSchemaBench（ICLR 2025）用1万个真实模式测试约束解码框架，最难的案例覆盖率3%到41%。BoundaryML更激进，认为结构化输出会主动 degrade（降低）模型推理能力——逼模型输出JSON格式，反而让它变笨。

行业共识很明确：函数调用（function calling）只适用于扁平、简单的模式。递归嵌套或深层结构复杂的东西，别费劲了。

但AutoBe没得选。他们的目标是让AI输出可确定——能解析、能验证、能在循环里修正直到收敛。自由文本没法机械验证，自然语言无法编译。没有结构就没有反馈回路，没有反馈回路就没有保证。所以他们必须让函数调用在那种被行业判死刑的复杂递归模式上跑通。

结果：最终编译成功率99.8%+。五个Qwen模型全部通过。

不是模型变聪明了，是工程套了层壳

秘诀不在模型内部，在外部——一套harness（约束框架）。类型模式约束输出，编译器验证结果，结构化反馈精确定位错误位置和原因，让大语言模型（LLM）自我修正。概率模型外面包一层确定性循环。

AutoBe的架构是5阶段流水线，跑过4种抽象语法树（AST）类型和4层编译器，自修复循环系统性纠正LLM错误。Typia是这套结构的核心：TypeScript编译器从源码分析单个类型，自动生成模式、解析器、验证器和反馈生成器。Qwen 3.5从0%到100%的翻转，机制就在这里。

具体怎么运作？当LLM生成代码后，Typia立即编译验证。出错时，不是返回"错了"这种废话，而是输出精确的诊断：第几行、什么类型不匹配、期望什么、实际得到什么。LLM拿到这份"体检报告"，下一轮生成就能针对性修复。循环往复，直到通过。

小模型成了最好的QA工程师

这套方法的意外收获：小模型反而更适配。

大模型容易"过度自信"，生成冗长但结构松散的输出，验证时一堆边缘情况没过。小模型能力边界清晰，出错模式更集中，反馈-修正循环的效率反而更高。在AutoBe的测试里，Qwen3-coder-next这种"不够强"的模型，经过harness约束后，最终成功率反超了未经约束的大模型。

这就像让实习生写代码——老手可能随手写一堆"差不多能跑"的，实习生每行都战战兢兢，但配合严格的Code Review和自动化测试，最终交付质量反而更稳定。

从后端到芯片：这套模式能走多远

Nam在演讲最后把问题抛得更远。半导体、化工流程、建筑、控制系统——任何存在确定性验证器的工程领域，这套"约束-验证-反馈-修正"的模式是否都适用？

他的判断是肯定的。AutoBe在后端领域的成功，本质是借用了软件工程已有的类型系统和编译器基础设施。其他领域只要存在类似的"硬性检查点"，理论上都能复制这套harness逻辑。区别只在于：那个领域的"Typia"是什么，验证成本有多高，反馈信息能多精确。

AutoBe现已开源。Wrtn Technologies的GitHub仓库里，完整的5阶段流水线、Typia集成示例、以及那份从6.75%爬升到99.8%的完整测试日志，都可以直接拉取。

最后一个细节：Nam团队在测试日志里发现，Qwen3-coder-next最初失败的93次中，有71次是同一个错误——把可选字段（optional field）的undefined类型漏掉了。Typia的反馈生成器把这个模式识别出来后，专门给LLM补了一行类型系统的"常识说明"。之后这个错误再没出现过。