写在前面：DSL已死，DSL万岁？
上周Hacker News上有个帖子炸了，标题就是"How a new DSL may survive in the era of LLMs"。53分，19条评论，不算多，但讨论质量出奇的高。评论区里有个老哥的回复我印象特别深：“One thing I’d add to this list: lots and lots of examples. Coding agents are absurdly good at understanding and adapting examples.”
这话说到点子上了。
我做DSL编译器快十年了，从Xtext到ANTLR，从内部DSL到外部DSL，踩过的坑能写一本《DSL劝退指南》。但LLM这玩意儿一出来，我一度觉得DSL这行当要完——谁特么还学你的破语法？直接跟AI说人话不就行了？
结果呢？现实给了我一巴掌。
LLM不是DSL的终结者，是DSL的催化剂
先说说为什么LLM反而让DSL更值钱了。
1. LLM需要约束，DSL就是最好的约束
LLM生成代码的问题，用过的人都懂——幻觉多、格式乱、逻辑跳跃。你让它写一段Python，它可能给你混入不存在的库函数。但如果你让它输出一段YAML配置呢？错误空间瞬间缩小了90%。
这就是DSL的核心价值：用形式化约束，把LLM的无限可能压缩到可控范围。
我们团队去年做了一个实验。让GPT-4直接生成Kubernetes部署配置，错误率大概在40%左右——各种不存在的字段、错误的缩进、逻辑矛盾。但当我们提供了一段自定义DSL的Schema加上5个few-shot例子后，错误率直接降到8%。
8%啊兄弟们。虽然还不完美，但至少能用了。
2. 代码即训练数据——你的DSL正在喂饱未来的LLM
这有个反直觉的点：如果你的DSL成功了，生成了大量高质量代码，这些代码会成为下一代LLM的训练数据。然后呢？LLM会变得更擅长你的DSL。这是一个正反馈循环。
William Cotton那篇文章里也提到了这一点：“If a new DSL succeeds in attracting users and generating code, that code becomes training data for the next generation of LLMs.”
所以问题来了：你是想让LLM学会你的DSL，还是想让LLM取代你的DSL？
答案是前者。如果你的DSL解决的是真实问题，LLM学会了它，意味着更多人可以用自然语言调用你的DSL能力。这不是替代，是放大。
新DSL生存的五个实操步骤
好了，不扯虚的。下面是我从实际项目中总结出的五条硬核建议。
Step 1: 先别写编译器，先写示例集
这是最反直觉但最重要的一步。
大多数DSL项目死在哪？死在没人用。为什么没人用？因为学习成本太高。
LLM时代不一样了。用户不需要读你的文档，他们只需要给LLM几个例子，LLM就能学会你的DSL。所以你的首要任务是构建一个高质量的示例库，而不是先把编译器做到完美。
具体怎么做：
- 准备50-100个真实场景的DSL代码示例
- 每个示例配一段自然语言描述
- 覆盖边缘情况——LLM从边缘案例中学到的东西比从常规案例多得多
我见过一个做配置DSL的团队，他们的文档写了200页，但LLM生成的代码准确率只有30%。后来他们砍掉了一半文档，换成30个精心设计的few-shot示例，准确率飙到了75%。
文档是给人看的，示例是给LLM看的。现在谁才是真正的用户？你自己品。
Step 2: 给DSL装上"实时反馈回路"
LLM生成DSL代码最大的问题是什么？不是语法错误（这好修），而是语义错误——代码合法，但逻辑不对。
解决方法是：让你的DSL可执行、可验证、可反馈。
看这张表：
| 反馈机制 | 延迟 | 对LLM的价值 | 实现难度 |
|---|---|---|---|
| 语法检查 | <10ms | 低 | 低 |
| 类型检查 | <100ms | 中 | 中 |
| 模拟执行 | <1s | 高 | 高 |
| 真实环境执行 | 秒级 | 极高 | 极高 |
我们团队的做法是：DSL编译后立即在沙箱中执行，把执行结果（包括错误信息和输出）直接返回给LLM。这样LLM就能根据反馈自我修正。
这玩意儿救了我们好几次。有一次LLM生成了一段数据处理DSL，语法完全正确，但跑出来的结果全是null。如果没有实时反馈，这种bug你查一天都查不出来。
Step 3: 工具链 > 语言本身
说实话，你的DSL语法好不好用，在LLM时代已经没那么重要了。重要的是你的工具链。
LLM需要的不是你的DSL标准，而是：
- Schema定义：JSON Schema、Protobuf、或者你自己的类型系统
- 验证器：能快速检查DSL代码是否合法
- 格式化器：DSL代码的标准化输出
- 调试器：能把DSL执行过程可视化
一个朋友跟我吐槽：“我们花了一年设计DSL语法，结果LLM根本不care，它只在乎能不能拿到Schema和示例。”
痛，太痛了。
Step 4: 拥抱"LLM-first"的设计哲学
设计DSL时，不要把人类开发者作为唯一目标用户。LLM也是你的用户，甚至可能是主要用户。
这意味着：
- 语法一致性：避免特例和例外，LLM对一致性非常敏感
- 显式优于隐式：不要依赖上下文推断，把所有信息写清楚
- 可预测性：相同的输入应该总是产生相同的解析结果
我见过一个DSL，设计得很优雅，但充满了各种"语法糖"——缩写、省略、隐式类型转换。人类开发者觉得"真香"，但LLM生成的结果一塌糊涂。为什么？因为LLM理解不了那些"不言而喻"的规则。
Step 5: 构建LLM插件，而不是只写文档
这是2026年最被低估的DSL推广策略。
别指望开发者去读你的DSL文档。你要做的是：
- 为VS Code/Cursor写一个LLM插件，让用户在IDE里直接通过自然语言生成DSL代码
- 为LangChain/LlamaIndex写一个工具调用接口
- 提供一个REST API，让LLM可以通过function calling调用你的DSL
我们团队做了个VS Code插件，用户只要选中一段文本，按Ctrl+Shift+P，输入"Convert to DSL"，就能自动生成DSL代码。这个插件上线后，我们的DSL采用率翻了3倍。
常见问题FAQ
Q: LLM为什么在时间相关任务上表现不好？
A: 这不是DSL能解决的问题，但DSL可以规避这个问题。LLM对时间序列、时序逻辑的理解确实很差——这是模型架构的固有限制。解决方案是在DSL中内置时间处理原语，把时间逻辑从LLM的"语言理解"转移到DSL的"形式化执行"。比如，不要让LLM自己处理时间戳转换，而是提供@time("2026-06-16T13:00:00Z")这样的DSL原语。
Q: 如何提高LLM生成DSL代码的准确率？
A: 多示例提示（multishot prompting）效果最好。我们的经验是：5-10个精心设计的few-shot示例，效果堪比微调。具体来说，每个示例要覆盖一个不同的使用场景，并且要包含边缘案例。另外，把DSL的Schema用JSON Schema格式提供给LLM，能显著提升输出质量。
Q: 离线LLM能处理DSL吗？
A: 可以，但有限制。离线LLM（比如本地部署的Llama 3）没有网络访问能力，所以你的DSL工具链必须本地可用。好消息是，一旦你把DSL的Schema和示例打包到模型上下文中，离线LLM的表现跟在线模型差别不大。坏消息是，离线模型通常上下文窗口较小，你塞不了太多示例。
Q: 如何让LLM理解DSL中的结构化数据？
A: 两种主流方法：一是用JSON/YAML作为DSL的序列化格式（LLM对JSON的理解出奇的好），二是提供TypeScript类型定义（LLM训练数据中TypeScript占比很高）。我们推荐前者，因为JSON Schema的可验证性更强。
最佳实践总结
| 实践 | 做什么 | 不做什么 | 优先级 |
|---|---|---|---|
| 示例集 | 准备50+精心设计的few-shot示例 | 不要只写文档不写示例 | P0 |
| 反馈回路 | 实现语法检查+模拟执行+结果反馈 | 不要只做语法检查 | P0 |
| 工具链 | 提供Schema、验证器、格式化器 | 不要只提供编译器 | P1 |
| 设计哲学 | 一致性、显式化、可预测性 | 不要过度设计语法糖 | P1 |
| LLM插件 | 写VS Code插件、REST API | 不要只写PDF文档 | P2 |
最后说两句
Reddit上有人问：“Different LLMs really make that much of a difference?”
答案是：巨大。
我们在GPT-4、Claude 3.5、Llama 3上测试了同一个DSL，GPT-4的准确率最高，Claude次之，Llama 3最低。但这不是重点。重点是：不管你用哪个模型，DSL都能显著提升输出质量。
LLM时代，DSL不是死路，是活路。但前提是——你得按新规则来玩。
别跟AI抢饭碗，给它造工具。这才是DSL的生存之道。