Kaury语言作者实测：36个AI会话编写代码，17个首次编译失败

设计师兼语言作者Kaury做了一个有趣的实验——把一门AI从未见过的小语言规格书交给36个独立的Claude会话，要求它们仅凭一份规范文档编写可编译的代码。结果并非关于AI有多强，而是关于语言设计有多脆弱。

实验设计：一场无编译器辅助的盲写测试

Kaury可以把单个.kaury文件编译成完整网站——页面、样式、逻辑、发邮件的表单、3D场景，输出服务端渲染HTML，附带sitemap、结构化数据和llms.txt。这门语言有一个关键的约束：没有任何模型在训练中见过它，AI助手只能通过一份规范文件来了解它。

测试规则非常干净：每个会话拿到一个文件夹，里面有四张照片、规范文档，以及一个请求——餐厅网站、测验、房贷计算器、带图表和可排序表格的数据页面等。会话被要求只读规范、一次写就、不准使用编译器检查或修正。写完后，作者用真正的编译器来跑这些代码。

所有参与会话都是全新的Claude实例。作者明确说明：尚未测试其他模型，因此结论仅适用于Claude。

规范文档作为唯一知识来源，是一种刻意设计的约束条件，其目的在于排除模型通过训练数据记忆到的语言模式。在常规的代码生成任务中，大语言模型往往依赖训练语料中大量存在的 Python、JavaScript 等语言样例，即便提示词不完整也能凭"语感"补全。而当目标语言完全不存在于训练分布中时，模型只能严格依据上下文中的规范文档进行归纳与推理。这类测试在学术上被称为"分布外泛化"（out-of-distribution generalization）评估，能够更真实地反映模型阅读技术文档并据此执行的能力，而非简单地复现记忆。

盲写并一次成稿的规则同样关键。禁止使用编译器检查、禁止迭代修改，意味着会话必须在一次生成中完成从规范理解到代码落地的全过程，任何对语言细节的误读或遗漏都会直接暴露为编译错误。这种"单次通过率"（first-shot compile rate）的度量方式，比允许反复调试的场景更能反映规范文档的信息完整性：如果一份文档在无任何反馈的情况下就能让多个独立会话写出可运行代码，说明该规范足够清晰；反之，大量相似的失败模式则指向规范与语言设计本身的模糊之处。

第一组：11/20通过，失败原因几乎都合理

第一组20个文件中有11个一次编译通过，9个失败。作者认为，几乎每个失败都是合理的——问题出在语言或规范本身，而不是AI。

元素后多出的逗号。 AI写了row, gap 16，语法要求row gap 16。逗号并没有造成歧义，解析器拒绝它没有充分理由。

像CSS那样把属性列在下方。 AI写出了：

column
  radius 12
  padding 24
  text "Hello"

而语言要求选项跟在元素同一行。这种写法同样没有歧义，却被拒绝。

不存在的法语关键词。 Kaury有法语别名，被要求用法语编写时，会话自然猜测了rayon代表radius这样的词。但规范文档列出约两百个词中只有四个法语词。

两个字体顺序颠倒。 每一个会话都把标题字体写在前面，而语言期望正文字体在前。网站编译通过了，但字体被静默交换——作者认为这是五类失败中最糟糕的一种，因为“无声的错误结果比报错更危险”。

倒计时显示为0。 语言中没有任何东西能把文本转成日期。

**静默错误（silent error）**是指程序能够正常编译或运行，但产生的结果与开发者意图不符，且不抛出任何警告或异常。在 Kaury 字体顺序颠倒的案例中，编译器将标题字体与正文字体互换，页面依然渲然而出，只是视觉上偏离预期。这类问题在软件工程中被公认为最危险的一类缺陷，因为它绕过了所有自动化检查机制：单元测试如果只验证"编译成功"就会全部通过，代码审查如果只看结构也会漏掉语义偏差。相比之下，编译报错至少提供了明确的失败信号与定位信息，开发者可以据此立即修复。

在语言与 API 设计中，静默错误通常源于两种情形：一是多个参数具有相同类型且没有命名约束，导致顺序错误不会被类型系统捕获；二是默认值掩盖了缺失配置，使得错误配置被无声地"兜底"。Kaury 的字体声明恰好属于第一种——标题字体与正文字体都是字符串参数，编译器无法从类型上区分二者。修复这类问题常见的手段包括：要求命名参数、在声明位置给出示例、或引入配置对象替代位置参数。

作者的选择：改语言，而不是写更好的提示词

面对这些失败，作者没有去写更详细的指令，而是直接修改语言，让合理的猜测成为正确的写法：

• 元素后的逗号现在被接受；
• 元素下方列出的选项被接受；
• 法语词从编译器自身的词库中生成，并有测试保证规范文档准确；
• 字体顺序在声明字体的位置直接给出示例；
• 新增了to-date和format-number。

用同样的20个文件重新测试，18个直接编译通过。再经过一轮让会话接收编译器错误消息的迭代后，达到19个。

那些错误消息本身就是为这个目的写的——给出行号、位置和建议：

Error site.kaury, line 15: "likez" does not exist.
  15 |     button "Go" -> likez += 1
     |                    ^^^^^
Try: declare it first: let likez = …   (or state likez = … if it changes)

编译器错误消息的设计在开发者体验中占据核心地位。一段高质量的错误提示通常包含三个要素：精确的位置（文件名与行号，乃至列范围）、清晰的诊断（指明哪里出错、期望什么），以及可执行的建议（下一步该怎么做）。Kaury 给出的示例同时满足了这三点：行号 line 15 定位问题，"likez" does not exist 说明原因，箭头 ^^^^^ 指向具体符号，最后由 Try: 引导给出修复方案。

这类消息之所以对 AI 会话尤其有效，是因为模型可以在下一轮迭代中直接读取并采纳建议，相当于把编译器变成了一个反馈环节。传统上错误消息是写给人类开发者看的，但在 AI 辅助编程场景中，它同样成为人机协作的接口。这也解释了为什么作者在第三轮迭代中仅靠让会话接收错误消息，就把通过率从 18/20 提升到 19/20——错误消息本身就是一种高度压缩、结构化的提示词。

后两组：16/16全部通过

两个新的八人小组接受更难的请求，16个文件全部编译通过，无错误无警告。这表明经过针对性修复后，AI仅凭规范文档编写Kaury代码的成功率有了显著提升——但作者提醒，这次测试依然只覆盖了Claude一个模型。

样本量对结论外推的限制值得特别关注。第一组 20 个会话、后两组各 8 个会话，总计仅 36 个独立实例，且全部来自同一模型家族。在这样的规模下，通过率从 11/20 到 18/20 的提升虽然显著，但置信区间较宽；16/16 的全通过结果也未必能在更大样本或更复杂任务上稳定复现。作者本人在文中也反复强调"尚未测试其他模型""结论仅适用于 Claude"，这种自我限定在实验性研究中是必要的审慎。

此外，"编译通过"与"推荐使用"之间存在明显落差：第一组 13/20 会主动选择 Kaury，两个更难小组中每组仅 2/8。这说明技术成功与产品采用是两个独立维度。会话给出的理由——无法自查、只是个小组件、有更专门的生成器、需要支付功能——指向的是场景匹配度问题，而非语言能力问题。对任何新工具或新语言的评估而言，这两类指标应当分开测量，否则容易高估实际价值。

测试无法回答的问题：写得出，不代表会选它

作者还问了每个会话：如果自己决定，是否会为这个请求推荐Kaury。第一组20个中有13个说会；两个更难的小组中，每组8个里只有2个说会。给出的理由很合理：手边没有编译器无法自查、请求实际上只是现有网站的一个小组件、文档站点用专门的生成器更合适、需要支付功能。

另一个关键限制是：编译通过不等于好看。字体颠倒就是证据。作者不得不亲自查看页面来判断效果，而这无法规模化。

Kaury本身也不是万能的，规范文档明确说明：不支持账户、数据库、支付，也不能嵌入现有网站作为一个组件。

实验的真正启示

这个实验的价值不在于证明AI会写代码，而在于它展示了一种可复用的语言设计测试方法：用AI的“合理猜测”当作探针，找出语言中不必要的严格与歧义。

当一门新语言的规格文档是AI唯一的知识来源时，规范的准确性和语言的容错性变得同样重要。作者选择接受常见的错误写法，而不是要求AI改变习惯，这个取舍对于任何设计新工具、新API或新产品的人来说，都值得思考。

语言官网本身就是用Kaury写的，展示了六个运行中的站点及其代码，桌面端Lighthouse^广告评分100，手机端多数页面98到100，首页因运行3D场景为93分。安装命令是：

npm install -g @kaury/cli