当开发者把 AI 接入一门训练语料极少的小众语言，代码生成不再是“写完跑一下”的游戏，而变成一场围绕编译器反馈、测试覆盖与性能度量的持续验证工程。
据掘金平台发布的一篇工程复盘文章，开发者在使用 AI 辅助从零实现 MoonBit 拼写检查库时，累计产出 7,350 行实现代码与 3,323 行测试代码，并在开发过程中记录了 43 个典型问题。文章称，所有数字均来自真实项目，且可通过仓库中的命令复现。
小众语言里的 AI：默认状态是“不认识”
作者提到，最初让 AI 生成 MoonBit 代码时，模型给出了一段看似合理但并不符合 MoonBit 语法的 import 写法，导致一次编译输出 24 个错误，而这些错误全部源于同一处写法。
文章援引一篇已被 IEEE TSE 录用的论文（arXiv 2606.16827），将 MoonBit 归类为 “no-resource language”，即大模型几乎没有见过该语言的训练数据。在 McEval-Hard 零样本测试中，MoonBit 的 pass@1 表现极低；论文还指出，即便使用 1,370 万 token 的 MoonBit 语料继续预训练，效果也只能提升到约 15%。
MoonBit 官方博客在发布官方代码智能体 Pilot 时也曾承认，由于缺乏 MoonBit 专用训练数据，模型第一次并没有产出正确输出，需要通过自动调用工具链获得精确反馈后，才能修复并优化代码。
编译器能拦住的：语法、类型与过期 API
在该项目中，开发者让 AI 实现一个 Hunspell 兼容的拼写检查库，覆盖 .aff / .dic 格式解析、词缀形态学、拼写判定和建议生成。过程中遇到的第一类问题，主要是 AI 按 Rust、Python 等常见语言的直觉写 MoonBit。
例如，模型会写出在其他语言中常见、但在 MoonBit 中不被接受的用法，包括 self 的使用习惯、inspect 与 @debug.debug_inspect 的差异、not(x) 与 !x 的差异、StringView::to_string() 与 to_owned() 的差异，以及 x.is_none()、substring 等已废弃用法和多行字符串不能直接作为调用参数等。
这类问题通常能被 moon check 直接拦截。开发者总结称，MoonBit 工具链反馈较为精确，错误码、行号和 moon explain 的解释都比较到位，因此“AI 生成 → 编译器判定 → 修正”的循环可以快速运转。
编译器拦不住的：Unicode 语义、测试错位与性能退化
更棘手的是那些编译通过、甚至测试全绿，但实际行为仍然有问题的情况。
文章列举了一个典型例子：MoonBit 中 String 是 UTF-16 code unit 序列，length() 返回的是 code unit 数量，char_length() 才对应码点；get_char(i) 按 code unit 索引，如果切在代理对中间会返回 None；只有 to_array() 才按码点返回 Char。
这意味着，如果 AI 按照常见语言习惯处理字符串，遇到 emoji 或非 BMP 汉字时就可能算错，但编译器不会报错。对此，开发者为相关函数补充了专门测试，用测试来兜住语义正确性。
性能问题则更进一步。作者在项目收口时重新测试 README 中的性能数字，发现文档写的“直接命中 0.34 µs/词”，实测却变成了 0.75 µs/词，项目性能下降了 2.31 倍。
排查时，作者先排除算法路径，再用同一台机器、同一条命令，对真实 en_US 词典自带的 49,568 个词计时，并通过 git stash 回退到改动前做 A/B 对照，最终定位到两处问题：纯函数被放在循环里，导致重复付出成本。修复后，性能恢复到原有水平。
作者指出，这类问题无法通过 moon check、moon test 或符合率测试发现，因为它们验证的都是“对不对”，而不是“贵不贵”。
连测试本身也可能出错
除了性能退化，作者还发现自己长期引用的一个符合率数字本身就有问题。
测试套件中有一个 .good 文件，记录“必须被接受”的词，其中 16 行本身含有空格。由于测试脚本使用 paste 按位置把输入流和判定流拼接在一起，含空格行一旦发生错位，后续配对全部偏移，导致这 16 行无论引擎答对还是答错，都被记成失败。
修改统计方式后，结果提升了 1.9 个百分点，差值恰好对应那 16 行。也就是说，引擎本身没有变化，但测试方法低估了真实表现。
作者由此总结：“跑出来的数字”比“想出来的结论”更可靠，但“跑的方法”本身也需要被怀疑。
从代码生成到验证工程：低资源语言的 AI 工作流
这篇复盘的核心结论并不是“AI 不能写 MoonBit”，而是低资源语言中使用 AI 的关键，在于如何设计工作流。
在 Python 或 TypeScript 等语料充足的语言中，开发者可以让 AI 先生成一大段代码，再运行观察结果；而在 MoonBit 这类低资源语言中，开发者必须假设模型写出的每一行都可能有问题，并依赖编译器快速指出错误位置。
但编译器只能判断“哪一行是错的”，不能判断“哪一行是对的但很贵”，也不能判断“测试是否在测错误的事情”。因此，完整的验证流程不只是把编译器接进回路，还要把度量接进回路，并对度量方法本身保持怀疑。
目前，该项目已将 43 个踩坑记录整理在 docs/MOONBIT_GOTCHAS.md 中，供其他使用 AI 编写 MoonBit 代码的开发者参考。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/ai-sheng-cheng-7300-xing-moonbit-dai-ma-hou-bian-yi-qi-neng
