LLM-Assisted Repository-Level Generation with Structured Spec-Driven Engineering

本文提出结构化规范驱动工程（SSDE），这是一种利用结构化规范来克服自然语言提示的歧义性和质量局限性的范式，从而在仓库级别实现高质量、可验证的代码生成。

要点

想象一下，你正在试图教导一位才华横溢但略显粗心大意的学徒厨师，如何为一整座城市烹制一场规模宏大、结构复杂的宴会。

问题：“模糊的指令”
目前，如果你要求一位顶尖人工智能（即那位学徒）为一个完整的软件系统编写代码，你通常只会给它一段冗长的自然语言描述，例如“制作一个人们可以预订会议的网站”。这就像告诉厨师“做一顿美味的饭菜”一样。

该论文指出，虽然人工智能在切单个洋葱（编写单个函数）方面表现出色，但当被要求烹制整场宴会（整个软件仓库）时，它便会迷失方向。自然语言过于模糊。人工智能可能会猜错、遗漏步骤，或者做出看起来不错但味道不对的菜肴。更糟糕的是，由于指令模糊，很难证明这顿饭失败的原因。

解决方案：“结构化食谱书”
作者提出了一种名为**结构化规范驱动工程（SSDE）**的新工作方式。他们建议不要进行模糊的对话，而是给人工智能一本严格、结构化的“食谱书”。

在本文中，他们使用了两种类型的结构化食谱：

1. Gherkin 规范：将其视为“如果 - 那么”测试用例。与其说“让它能工作”，不如写成：“如果用户点击‘预订’，那么房间必须标记为‘已占用’。”这是一份精确行为的检查清单。
2. 领域模型：这些就像建筑蓝图或食材地图。它们展示了系统不同部分（如“用户”、“房间”和“日期”）如何相互连接。

实验：品尝测试
研究人员开展了一项试点研究。他们扮演主厨的角色，要求五个不同的人工智能模型（即学徒）为三个不同的软件系统构建“业务逻辑”（即烹饪规则）。

他们测试了不同的组合：

• 对照组：仅使用模糊的自然语言描述。
• 实验组：模糊描述加上结构化的“食谱书”（蓝图和“如果 - 那么”检查清单）。

结果：结构取胜
研究结果非常明确：

• 更高的准确性：当人工智能拥有结构化的“食谱书”（蓝图和检查清单）时，其错误率远低于仅拥有模糊描述的情况。
• “蓝图”的增益：向人工智能提供具体的代码签名（精确的食材和工具列表）以及蓝图，对其帮助最大。这就像不仅给厨师食谱，还给了它确切的面粉品牌和特定尺寸的平底锅。
• 仍有提升空间：虽然结构化方法要好得多，但人工智能仍会犯一些错误。然而，研究人员发现，超过 70% 的错误是简单且可检测的失误——例如引用了不存在的变量，或者犯了 Python 语法错误。这些错误甚至不需要测试预言机（即无需运行代码并观察输出是否符合预期）：标准的编译器或代码检查工具（linters）就足以发现它们。

未来路线图
该论文建议，要使这项工作完美运行，我们需要：

1. 增加反馈循环：不要只询问人工智能一次，而应让它编写代码，根据“食谱书”进行检查，并自动修复自己的错误。
2. 构建更好的数据集：我们需要更多此类结构化食谱书的示例，以便更好地训练人工智能。
3. 应对变化：真实软件时刻在变。我们需要教导人工智能如何只更新宴会的一部分（例如更换甜点），而不会毁掉整场宴席。

核心结论
该论文总结道，如果我们不再将人工智能视为对模糊愿望起作用的魔法棒，而是将其视为遵循严格、结构化蓝图的熟练工人，我们就能让它可靠地构建整个软件系统。这将把人工智能从“富有创意的猜测者”转变为“精确的建造者”。

技术摘要

技术摘要：基于结构化规范驱动工程的 LLM 辅助仓库级生成

问题陈述

尽管大语言模型（LLM）在生成函数级或文件级代码方面表现出高度熟练度，但当扩展到仓库级系统时，其可靠性显著下降。目前完全依赖自然语言提示的工作流存在固有的歧义性，导致沟通“有损”，并阻碍了可验证输出（例如软件测试）的生成。单纯增加自然语言指令的冗长程度，无法解决可靠的大规模代码生成与验证所必需的根本性精度缺失。作者认为，必须从非结构化的自然语言转向结构化规范，才能实现可靠、可验证且高质量的仓库级生成。

方法论：结构化规范驱动工程（SSDE）

本文提出了结构化规范驱动工程（SSDE），这是一种将结构化工件（而非自由形式的自然语言）作为主要输入以指导 LLM 代理的范式。作者开展了一项试点研究，以调查这一愿景的可行性。

实验设置

• 任务：为三个现有软件系统（Symboleo、CheECSEManager 和 MeetingGroups）生成模型 - 视图 - 控制器（MVC）业务逻辑（具体为 Python 控制器）。
• 模型：评估了五个 LLM，涵盖不同规模的开源模型（Qwen 3、Llama 3.2）和闭源模型（Claude Sonnet 4.5、GPT 5.1、GPT 5 Nano）。
• 输入配置：该研究比较了提供给 LLM 的四种上下文输入类型（均附带控制器模板）：
  1. 自然语言规范：关于系统目的和约束的自由形式描述。
  2. Gherkin 规范：定义系统行为的结构化、可执行场景。
  3. 领域模型：捕获领域概念和关系的抽象软件模型（Umple 或 Ecore）。
  4. 签名模型：从领域模型生成的类和函数签名（API）。
• 评估：
  • 定量：在生成的控制器上执行经过人工验证的 Python 单元测试套件（映射到 Gherkin 场景）。主要指标是测试通过率（TPR）。
  • 定性：人工检查生成的代码，以识别反复出现的失败模式和代码质量属性。
  • 重复：每种配置针对每个 LLM 运行 10 次，以考虑随机偏差。

关键结果

试点研究得出了关于结构化输入有效性的几项关键发现：

1. 结构化输入的优越性：与仅使用自然语言规范的基线相比，添加任何形式的结构化规范（Gherkin、领域模型或签名）都显著提高了输出质量。
2. Gherkin 的潜力：虽然结合模型的 Gherkin 规范最初显示出略低的平均 TPR（低 6.8%）和比自然语言组合更高的方差，但在 30 种特定组合中有 14 种表现优于自然语言。作者指出，经过进一步细化，这种方法有潜力超越自然语言。
3. 签名的价值：提供从领域模型生成的模型层签名（API）被证明非常有效。与使用原始领域模型相比，该配置将平均 TPR 提高了 +7.82%，并将标准差降低了 -2.47%，这表明 LLM 从明确的 API 定义中获益，优于抽象的模型语法。
4. 错误分析：超过70% 的测试失败是由可通过静态代码分析检测到的错误引起的（例如调用不存在的 API、数据类型不匹配、未验证的约束）。这表明大部分生成失败是结构性的而非逻辑性的，因此适合进行自动修正。
5. 模型性能：Claude Sonnet 4.5 表现最佳，在多种配置中实现了超过 80% 的 TPR。然而，各次运行间较高的标准差凸显了 LLM 的随机性，其中特定的错误类型倾向于在生成的控制器中一致地传播。

主要贡献

• SSDE 的提出：本文提出了结构化规范驱动工程作为一种可行的范式，旨在利用结构化工件的可验证性，弥合高层需求与仓库级代码生成之间的差距。
• 实证可行性研究：作者提供了首个试点研究，证明与纯自然语言提示相比，结构化输入（Gherkin、领域模型、签名）可以切实提高 LLM 生成的仓库级代码质量。
• 错误模式的识别：该研究对失败模式进行了分类，揭示大多数错误是结构性的且可检测，指明了自动化反馈循环的清晰路径。
• 研究路线图：本文概述了该领域的具体前进路径，聚焦于三大支柱：
  1. 提高输出质量：实施利用静态分析和动态测试的反馈循环，使 LLM 能够自我修正结构性错误。
  2. 评估现实世界影响：超越单次生成，评估代理工作流、令牌成本效益和净生产力提升（考虑维护结构化规范所需的工作量）。
  3. 适用性：开发用于部分仓库更新的以处理持续演进的技術，并将 SSDE 与多样化的建模工具及物理世界表示进行集成。

意义与主张

本文主张，SSDE 提供了一条通往高质量、可验证的仓库级代码生成的切实路径。通过从歧义性的自然语言转向结构化规范，该方法利用了几十年的软件工程知识（例如模型驱动工程、Gherkin）来指导 LLM。

作者认为，尽管 LLM 目前难以应对大规模系统，但结构化规范的整合将代码生成从“黑盒”过程转变为可验证且可维护的过程。研究表明，当前大部分生成失败并非不可逾越的逻辑鸿沟，而是可以通过自动化反馈机制解决的结构不一致性。最终，SSDE 旨在通过促进有效的人机协作来减少人工工程负担，其中工程师充当规范架构师，而 LLM 负责将其转换为实现。