一句话看懂：Thoughtworks 杰出工程师 Unmesh Joshi 在 Martin Fowler 博客发文论证，领域特定语言（DSL）可以约束 LLM 的输出范围，弥补大模型在“前期规格说明”与“通过实现发现设计”两大核心局限，从而让 LLM 从不可控的代码生成器变为可靠的设计与实现工具。该文提出 DSL 应成为 LLM 时代的软件“单一事实来源”。
事件核心：发生了什么
2026 年 7 月 14 日，Unmesh Joshi 发表文章，系统阐述 DSL 如何解决 LLM 在代码生成中的两大根本问题：第一，大规模系统的详细设计决策无法通过一次性高层规格说明提前确定，规格只是待修正的假设；第二，真正的设计洞察必须在编码中通过反复权衡具体决策才能获得，而 LLM 一鍵生成的代码让开发者跳过了这一关键探索过程。作者提出，DSL 作为一种刻意受限的语法，专门用于表达单一领域概念——例如 PlantUML、Mermaid、SQL、Kuberentes YAML——天然适合与 LLM 协作。LLM 可以在 DSL 边界内充当“头脑风暴伙伴”帮助探索抽象设计，也可以在 DSL 建立后充当“自然语言接口”帮助快速使用 DSL 表达意图。文章以 Tickloom（一个描述分布式系统行为的领域模型及 DSL）为例展示了这一双阶段工作流：先用 LLM 辅助迭代构建 DSL，再用 LLM 通过自然语言直接生成 DSL 代码。
为什么重要
当前行业普遍面临 LLM 在专业场景下生成代码“看着对但用起来错”的信任问题。此文将问题根源从模型能力转向工程方法：不是 LLM 不够聪明，而是缺少约束 LLM 输出的清晰边界。DSL 的作用不是“限制”而是“引导”——它把 LLM 的快速生成锁定在一个可验证、可迭代、可推理的词汇与规则集合内。这一观点对 DDD（领域驱动设计）实践者、微服务架构团队以及低代码／无代码平台设计者都有直接启发：DSL 可以成为团队与模型共享的“真实来源”，让自然语言驱动的软件开发脱离“黑盒猜谜”状态，走向可审计、可协作的工程化路径。这也意味着，构建高质量 DSL 的能力可能成为 LLM 时代软件开发团队的重要竞争力分水岭。
对用户/开发者/创作者的影响
对于平台与工具开发者：DSL 的设计质量直接决定 LLM 输出可靠性。团队需要投入资源为自身领域（如云基础设施、合规策略、前端组件配置、系统测试场景）设计专用 DSL 词汇表与验证机制，而非依赖通用自然语言提示。对于企业技术决策者：在评估 LLM 落地时，不应只看模型本身的准确率，而应评估已有 DSL 生态（如 Kubernetes YAML、SQL、Mermaid 等）能否覆盖业务核心领域，并计划为内部系统定制 DSL。对于内容创作者与知识工作者：DSL 思维同样适用：为常见工作流（如报告生成、演示文稿布局）设计有限选项模板，再利用 LLM 通过自然语言填充模板，能得到远比自由提示更可控、可重复的结果。作者在文内即演示了用 LLM 生成富图表的 Powerpoint 演示文档的 DSL 方法。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
第一，该文所述“DSL 作为单一事实来源”理念是否会被主流开发工具链采纳，例如 GitHub、GitLab 或 JetBrains 集成 DSL 验证与 LLM 提示的联合工作流；第二，Tickloom 等项目是否会开源并沉淀为分布式系统测试的标准 DSL 规范——目前该模型仅作为概念示例；第三，基于 DSL 约束的 LLM 代码质量是否能在真实企业级系统中达到可审计、可测试的门槛，需要更多工程实践数据验证。考虑到 Unmesh Joshi 在分布式系统模式领域的长期影响力，该观点可能在 Thoughtworks 客户项目与分布式系统社区中率先落地。
