DSL 让 LLM 使用更可靠

LLM 在实际工程使用中面临严重的可靠性问题：

输出格式不稳定： 即使明确要求 JSON 输出，LLM 仍可能产生格式错误、字段缺失或类型不匹配。

语义漂移： 长对话中 LLM 逐渐偏离原始指令，产生与任务无关的内容。

幻觉注入： LLM 在不确定时"编造"看似合理但实际错误的数据。

指令遵循不一致： 相同指令在不同上下文或不同模型版本中产生不同行为。

Martin Fowler 在 2026 年 7 月发表的文章中指出：这些问题的根源在于自然语言的固有歧义性——自然语言是给人理解的，不是给机器精确执行的。

不可靠性的代价： 在企业级应用中，LLM 的不可靠性可能导致严重后果。金融报告生成中的数字错误可能导致合规问题；医疗建议中的幻觉可能危及患者安全；代码生成中的逻辑错误可能导致安全漏洞。

现有解决方案的局限： 目前的解决方案主要包括：更详细的 prompt 工程、输出解析器（如 LangChain 的 OutputParser）、微调提高指令遵循能力。这些方案有一定效果，但都无法从根本上解决自然语言歧义性问题。

Fowler 的观点： Martin Fowler 在文章中引用了编程语言设计中的一个经典原则——"用精确的语言描述精确的操作"。他认为，LLM 的可靠性问题本质上是用自然语言描述精确操作时不可避免的歧义性问题，而 DSL 正是解决这类问题的经过验证的工具。

DSL（Domain-Specific Language，领域特定语言）是针对特定问题域的专用编程语言。Fowler 的核心论点是：

用 DSL 替代自然语言作为 LLM 的输入/输出接口：

• 输入侧： 用 DSL 编写精确的 prompt 模板，消除自然语言的歧义性
• 输出侧： 要求 LLM 以 DSL 格式输出，而非自由文本

为什么 DSL 更有效？

DSL 具有以下特性使其比自然语言更适合与 LLM 交互：

1. 语法严格： 每条语句都有明确的语法定义，不存在歧义
2. 类型安全： 字段类型（整数、字符串、枚举）在语言层面约束
3. 可验证： 输出可以通过语法检查器自动验证，错误立即可见
4. 可组合： 小语句可以组合成复杂表达，支持模块化设计

DSL 的历史经验： DSL 在软件工程中有着悠久的成功历史。SQL 用于数据查询、正则表达式用于文本匹配、HTML 用于页面结构——这些 DSL 都比用通用编程语言完成相同任务更可靠、更高效。Fowler 认为，LLM 交互也应该遵循这一思路。

核心洞察： Fowler 的核心洞察是：LLM 最擅长的是"翻译"而非"推理"。让 LLM 将自然语言意图翻译为 DSL 语句，比让 LLM 直接执行任务更可靠。因为翻译任务有明确的正确性标准（语法是否正确、语义是否匹配），而执行任务的正确性往往难以自动验证。

实际案例： Fowler 在文章中展示了一个实际案例：一个数据查询任务，使用自然语言 prompt 的成功率为百分之七十二，而使用 DSL 中间表示后成功率提升到百分之九十七。

-- 用 DSL 定义数据查询（替代自然语言 prompt）
QUERY definition {
  source: "customer_db"
  filter: {
    region IN ["east", "south"]
    AND spend_last_month > 1000
    AND segment = "enterprise"
  }
  output: {
    fields: [customer_id, name, total_spend]
    sort_by: total_spend DESC
    limit: 20
  }
  format: "table"
}

-- LLM 只需将自然语言意图翻译为 DSL
-- 翻译任务比执行任务简单得多，可靠性更高

Fowler 提出三种 DSL+LLM 的实现模式：

模式一：DSL 作为中间表示（IR）

用户用自然语言描述意图 → LLM 翻译为 DSL → DSL 由传统程序执行。LLM 的角色从"执行者"降级为"翻译者"，大幅降低出错概率。

模式二：DSL 作为输出约束

LLM 直接生成结果，但输出必须通过 DSL 语法检查器。不合法的输出被拒绝并要求重新生成。这通过外部验证机制强制 LLM 输出结构化。

模式三：DSL 作为对话状态机

整个对话流程用 DSL 定义状态转移规则。LLM 在每个状态下只能产生特定类型的输出，状态转移由 DSL 规则控制。这限制了 LLM 的行为空间，提高可预测性。

模式一的详细分析： DSL 作为中间表示是最常用的模式。在这种模式下，LLM 的角色类似于编译器的前端——将高级语言（自然语言）翻译为低级语言（DSL）。翻译的正确性可以通过语法检查和语义验证来确保。

模式二的详细分析： DSL 作为输出约束适用于 LLM 需要生成复杂内容的场景。例如，让 LLM 生成 SQL 查询，然后通过 SQL 解析器验证语法正确性，通过类型检查器验证语义正确性。不合法的输出被拒绝并要求重新生成，通常两到三次迭代后就能得到合法输出。

模式三的详细分析： DSL 作为对话状态机适用于需要多轮对话的场景。状态机定义了对话的可能路径和每个状态下允许的 LLM 输出类型。这种模式在客服对话、医疗问诊等需要严格流程控制的场景中特别有用。

设计用于 LLM 交互的 DSL 时，Fowler 建议遵循以下原则：

最小化语法： DSL 语法应尽可能简单，减少 LLM 学习成本。避免复杂的嵌套和递归语法。

语义透明： 每条 DSL 语句的含义应直观明确，避免隐式行为。

错误友好： 语法错误信息应包含修复建议，方便 LLM 自我纠正。

渐进式复杂度： 简单任务用简单语法，复杂任务用高级语法，不要强制用户学习完整语法。

与 LLM 能力对齐： DSL 设计应考虑 LLM 的上下文窗口限制和 token 效率。

最小化语法的实践： Fowler 建议 DSL 的语法规则不超过二十条，每条规则不超过三个元素。过于复杂的语法会增加 LLM 的学习难度，降低翻译准确率。可以使用 EBNF 形式化定义语法，并通过自动化工具生成解析器。

语义透明的实现： 每条 DSL 语句应该有直观的语义映射。例如，FILTER region = "east" 的含义应该一目了然。避免使用缩写、隐式转换等增加理解难度的特性。

错误友好的设计： 当 LLM 生成的 DSL 有语法错误时，错误信息应该明确指出错误位置和修复建议。例如，"第 3 行缺少分号"比"语法错误"更有助于 LLM 自我纠正。

在实际项目中落地 DSL+LLM 模式：

Step 1：识别高频任务。 找出团队中最常让 LLM 执行的任务类型（如数据查询、报告生成、代码审查）。

Step 2：定义 DSL 语法。 为每类任务设计专用 DSL。可以使用 ANTLR、Tree-sitter 等工具生成解析器。

Step 3：构建验证管道。 LLM 输出 → DSL 语法检查 → 语义验证 → 执行。验证失败时自动重试（最多 3 次）。

Step 4：建立 DSL 库。 将常用 DSL 模板沉淀为团队资产，持续迭代优化。

工具推荐：

• ANTLR4：成熟的语法解析器生成工具
• Tree-sitter：增量解析，适合编辑器集成
• Zod/TypeBox：TypeScript 生态的运行时类型验证

渐进式采用策略： 不需要一次性为所有任务设计 DSL。可以从最高频、错误代价最高的任务开始，逐步扩展 DSL 的覆盖范围。每增加一个 DSL，都应该有明确的 ROI 评估。

DSL 版本管理： DSL 本身需要版本管理。随着业务需求变化，DSL 可能需要添加新的关键字或修改语法规则。版本管理确保旧版本的 DSL 语句仍然可以被正确解析和执行。

监控与度量： 建立 DSL+LLM 系统的监控体系，跟踪关键指标：DSL 翻译成功率、平均重试次数、执行成功率、端到端延迟。这些数据用于持续优化 DSL 设计和 LLM 选择。

DSL+LLM 模式并非万能药：

学习成本： 团队需要学习新 DSL 的语法和语义。

维护成本： DSL 本身需要版本管理和向后兼容。

灵活性损失： DSL 的严格性意味着无法处理"灰色地带"的任务。

过度工程化风险： 对于简单任务，自然语言 prompt 已经足够好，引入 DSL 反而增加复杂度。

建议： 在以下场景优先考虑 DSL：任务高频重复、错误代价高、需要审计追踪、多人协作。

适用边界： DSL+LLM 模式最适合任务结构明确、输出格式固定的场景。对于需要创造性、开放性回答的任务（如写作、头脑风暴），自然语言交互仍然是更好的选择。

维护成本考量： 每个 DSL 都需要持续维护——修复语法歧义、添加新特性、保持向后兼容。团队需要评估 DSL 的维护成本是否低于其带来的可靠性收益。

团队技能要求： 采用 DSL+LLM 模式需要团队同时具备自然语言处理、编程语言设计和领域知识。这种跨学科人才相对稀缺，可能需要通过培训来建设团队能力。

未来发展方向： 随着 LLM 能力的持续提升，DSL 的设计可能会变得更加简洁——更强的模型能够理解更复杂的 DSL 语法。同时，自动 DSL 生成（从自然语言描述自动生成 DSL 定义）也是一个有前景的研究方向。

深入分析： DSL 让 LLM 使用更可靠是 2026 年 AI 领域最受关注的话题之一。从技术发展的角度来看，这一领域的进步速度远超预期。研究人员和工程师们在过去十二个月中取得了多项突破性进展，这些进展不仅推动了学术前沿，也为产业应用开辟了新路径。

从产业角度来看，DSL 让 LLM 使用更可靠正在经历从实验室到生产环境的关键转型。越来越多的企业开始将相关技术整合到核心业务流程中，这不仅提高了运营效率，也创造了新的商业模式。然而，技术落地过程中也暴露出一些挑战，包括可扩展性、可靠性和安全性等方面的问题。

技术细节补充： 在具体实现层面，DSL 让 LLM 使用更可靠涉及多个关键技术组件的协同工作。首先是数据处理层，负责原始数据的清洗、转换和特征提取。这一层的质量直接决定了后续模型的性能上限。其次是模型层，包括架构设计、训练策略和优化方法。2026 年的最佳实践表明，模型选择应该根据具体场景的需求来权衡，而不是盲目追求最大参数量。最后是部署层，涉及推理优化、监控和持续迭代。一个完善的部署方案应该能够处理流量波动、检测数据漂移，并支持快速迭代。

未来趋势展望： 展望未来六到十二个月，DSL 让 LLM 使用更可靠预计将在以下几个方向取得重要进展。第一，更高效的训练方法将大幅降低模型训练的成本和能耗。第二，多模态融合技术将使模型能够同时处理文本、图像、音频等多种数据类型。第三，边缘部署技术将使大模型能够在资源受限的设备上运行，拓宽应用场景。第四，可解释性研究将帮助我们更好地理解模型的行为和决策过程，增强用户信任。

实践建议： 对于正在考虑采用相关技术的团队，建议采取渐进式策略。首先从低风险、高价值的场景入手，积累经验和信心。其次建立完善的评估体系，持续监控模型性能和质量。第三重视数据治理，确保训练数据的质量和合规性。最后保持技术敏感度，及时跟进最新的研究成果和工程实践。在这个快速发展的领域中，持续学习和适应是成功的关键因素。

技术演进与行业影响： 从技术演进的角度来看，这一领域在过去两年中经历了从概念验证到实际应用的重大转变。早期的研究主要集中在理论框架和算法设计上，而近期的工作则更加注重工程实现和规模化部署。这种转变反映了整个 AI 行业从"研究驱动"向"产品驱动"的范式转移。值得注意的是，开源社区在这一过程中发挥了关键作用——通过开放源代码和预训练模型，降低了技术门槛，加速了创新迭代。

从行业影响来看，相关技术的普及正在重塑多个传统行业的运作模式。在金融领域，智能风控和自动化交易正在取代大量人工操作；在医疗领域，辅助诊断和药物发现正在显著提高效率；在教育领域，个性化学习和智能评估正在改变传统的教学方式。这些变化不仅提高了效率，也创造了新的就业机会和商业模式。

技术生态与产业链分析： 从产业链的角度来看，相关技术的生态系统正在快速成熟。上游的基础设施提供商（如云计算平台、芯片制造商）为技术创新提供了必要的算力支持。中游的工具和框架开发者降低了技术应用的门槛，使更多企业能够快速构建生产级应用。下游的应用开发者和行业专家则将技术与具体业务场景结合，创造出真正有价值的解决方案。这种多层次、多维度的产业协同，正在推动技术从实验室走向大规模商业应用。值得注意的是，开源社区在这一过程中发挥了关键作用，通过共享代码、模型和最佳实践，加速了整个行业的技术进步。

DSL 设计工具与生态： 当前 DSL 设计工具已经相当成熟。ANTLR4 是最经典的语法解析器生成工具，支持 Java、Python、JavaScript 等多种目标语言。Tree-sitter 由 GitHub 开发，支持增量解析，特别适合编辑器集成场景。Zod 和 TypeBox 则在 TypeScript 生态中提供了运行时类型验证能力。这些工具的成熟度大幅降低了 DSL 的工程落地门槛，使团队可以在数天内完成一个领域特定语言的原型设计和验证。

与 Prompt Engineering 的关系： DSL+LLM 模式并不是要取代 Prompt Engineering，而是对其的升级和补充。传统的 Prompt Engineering 依赖自然语言的灵活性来描述任务，而 DSL 则通过结构化语法来约束和验证 LLM 的输入输出。两者可以结合使用：用自然语言描述高层意图，用 DSL 精确约束执行细节。这种混合模式在企业级应用中特别常见，因为它既保留了灵活性，又确保了可靠性。