自研的DSL没有经过专门训练，会不会效果不好

直接给结论：你的直觉很准，自研 DSL 没进过大模型的预训练语料，确实存在上下文学习成本和弱模型掉点严重的问题；但在主力大模型上，它的实际生成稳定性反而比原生 JSON 更高。 具体可以从底层机制、真实翻车率和工程补救三个层面来看： 1. 为什么没训练过也能用：借壳了模型最熟悉的 Python / JS 赋值语法 OpenUI Lang 并没有发明一套反直觉的新符号，而是直接借用了模型在海量代码语料里早就练熟的“按行变量赋值 + 函数位置调用”结构，比如写成 root = Stack([header chart] "row")。 对前沿大模型来说，只要在 System Prompt 里塞入约 7000 Token 的语法说明和组件签名，靠上下文学习就能直接对齐。 更重要的是，JSON 在生成复杂界面时有高达十几层的花括号嵌套，模型自回归生成时稍微走神就会漏括号，或者因为太啰嗦撞上输出长度上限被截断；而按行赋值的扁平结构把树状嵌套拆成了平铺的单行语句，在 Claude Opus、GPT-5 这类模型上，它连续 5 次生成全成功的稳定率（94.4%）反而明显高于基于 JSON 的 Vercel json-render（83.3%）。 2. 没经过预训练的真正代价：模型能力一旦降级，位置传参就会暴雷 缺少预训练肌肉记忆的短板，主要暴露在两处： 第一是每次请求都要固定交一笔约 7000 Token 的 System Prompt 税（虽然靠 Prompt Caching 可以打折，但依然占上下文注意力）。 第二是对小模型极不友好。在第三方的跨模型盲测里（关掉自动修复裸跑），OpenUI Lang 在旗舰模型上单次可渲染率接近 100%，但一旦切到 26B 级别的开源小模型（如 Gemma-4-26B），连续 5 次生成的全过率直接从 94.4% 腰斩到 50%。 观察报错分类会发现，小模型并不是不会写这套语法（语法解析错误为 0），而是死在 Schema 参数错位和引用断裂上。因为 OpenUI Lang 为了省 Token 砍掉了属性名、改用按位置传参，没有了键名做语义锚点，小模型在数第几个参数填什么类型时很容易数乱，或者在前面引用了某个子组件变量、写到后面却忘了定义。 3. 工程与商业上的阳谋：用“专用微调小模型 Autofix”给主模型擦屁股 Thesys 团队自己非常清楚靠 Prompt 无法彻底消灭那 7% 左右的引用断裂和参数越界，所以他们没有去微调昂贵的通用主模型，而是训了一个专门懂这套 DSL 的低延迟修复小模型（Autofix）放在网关里。 主模型只管用最快速度流式吐 DSL，网关边收边跑本地 AST 校验，一旦抓到未定义变量或类型越界，在推给前端之前直接由修复小模型毫秒级改好。 这也恰好构成了他们的商业闭环：如果用标准 JSON，开发者自己在本地写个正则或 JSON Repair 就能凑合修；正因为自研 DSL 带来了极致的速度和 Token 压缩，同时伴随着小概率的 Schema 错位，他们官方网关里那个“专门微调过的 Autofix 模型”就成了企业上生产环境时绕不开的付费护栏。