Specification-Driven Development as the Foundation of AI-Native Enterprise Software Engineering
本文认为，尽管“氛围编程”（vibe coding）有助于原型设计，但企业级软件工程必须采用规范驱动开发（SDD）以及所提出的规范治理参考模型（SGRM），将概率性的 AI 生成转化为确定性的、可审计的系统，从而解决可靠性问题并显著降低安全缺陷和上市时间。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
AI 驱动的建筑新时代
想象一下，你正试图建造一座宏伟且复杂的城堡。在过去，你必须亲手铺设每一块砖头，仔细测量并亲自搅拌砂浆。那就是“编程”：逐行编写计算机的指令。但最近，一个神奇的新工具出现了：人工智能（AI）。这个 AI 就像一个速度极快、才华横溢的学徒，只需听从你的声音，就能建造出整面墙壁、塔楼和房间。你说：“给我造一座塔楼，”然后“砰”的一声，AI 就开始堆叠砖块了。
这种新的工作方式在人们构建软件的方式上造成了一种分歧。一方面是“氛围编程”（Vibe Coding）。这就像对着你的 AI 学徒大喊指令，然后观察结果是否看起来很酷。你不需要检查蓝图；你只需要看那座塔是否立住了，感觉是否对了。它很快、很有趣，非常适合快速实验。另一方面是“规范驱动开发”（Specification-Driven Development）。这就像在 AI 拿起第一块砖之前，先交给它一份严格、详细的书面合同。合同明确规定了塔楼必须如何建造、使用什么材料以及如何应对风暴。AI 会进行建造，但会有一位严格的检查员根据合同对每一步进行检查，然后你才会接受成果。
每个人都在问的一个大问题是：我们是只能对着 AI 大喊大叫并听天由命，还是需要那些严格的合同来建造经得起时间考验的东西？来自沙特数据与人工智能局（SDAIA）的 Mamdouh Alenezi 的一篇新论文深入探讨了这一点。它通过证据研究了哪种方法真正适用于构建需要安全性和可靠性的严肃、大规模软件。
论文的核心发现：为什么“氛围”不足以建造宏伟城堡
该论文认为，虽然“氛围编程”对于头脑风暴、学习或构建快速原型非常棒，但对于构建严肃的企业级软件来说是非常危险的。作者指出，依赖 AI 的“氛围”——仅仅观察代码运行并希望它能成功——就像是通过猜测梁柱的位置来建造摩天大楼。它可能看起来不错，但最终会崩塌。
论文指出了当你想构建大型系统时，“氛围编程”出错的四个具体方面：
- 速度陷阱： AI 的速度如此之快，以至于诱使你跳过检查它的工作。你可能会看到代码运行了一次，然后心想：“太棒了！”但论文指出，仅仅运行一次并不意味着它实际上是正确的。这就像一个魔术，第一次尝试时奏效，但之后每次都会失败。
- 纸牌屋： 当你要求 AI 构建一个小部分时，它做得很好。但当你要求它构建整个系统时，它会忘记各部分是如何衔接的。论文称之为“架构侵蚀”（Architectural Erosion）。这就像在没有总计划的情况下逐个房间地盖房子；最终，房间对不齐，门的位置也错了，整个结构变得一团糟。
- 隐藏的裂缝： 论文指出，AI 经常构建带有隐藏安全漏洞的东西。在提到的一个研究中，AI 生成的代码中约有 40% 存在安全弱点。可怕的是，使用 AI 的人们往往因为没有进行妥善检查，而误以为他们的代码是安全的。这就像 AI 造了一扇门，看起来很坚固，实际上却是纸做的。
- 债务堆积： 每当你使用 AI 而没有计划时，你都会留下一些“技术债”。这就像每次建造东西时，都在你的车库里留下一堆垃圾。最终，车库里的垃圾多到让你无法移动，以后修复它将耗费极长时间。
解决方案：“规范治理”蓝图
那么，解决办法是什么？论文提出了一个名为**规范治理参考模型（SGRM）**的新框架。把它想象成为你 AI 学徒制定的一个严格、不可逾越的规则手册。
你不再只是说“造一座塔”，而是给 AI 一个规范（Specification）。这是一个机器可读的文档，充当“事实来源”（Source of Truth）。它包含四个部分：
- 它必须做什么： 确切的功能和行为。
- 它必须达到多好： 关于速度、规模和可靠性的规则。
- “宪法”： 关于安全和防护的不可逾越的规则（例如“绝不使用这种弱锁”）。
- 结构： 各个部件如何连接。
这个系统的魔力在于一个闭环（Closed Loop）。其运作流程如下：
- 你编写严格的合同（规范）。
- AI 根据该合同尝试编写代码。
- 一个确定性验证器（一个严格、无感情的检查员）根据合同检查代码。
- 如果代码通过了每一项测试，它就会被接受。如果它违反了哪怕一条微小的规则，就会被拒绝，AI 必须重新尝试。
这个过程将 AI 随机的、“猜测”式的风格转变为一种可靠的工程过程。论文指出，这种方法将 AI 从一个混乱的魔杖转变为一个能够完美执行命令的纪律严明的工人。
数据说明了什么（以及没说明什么）
论文查阅了现实世界的案例研究，以观察这个想法是否真的有效。它发现了一些非常有前景的数据，但也谨慎地表示这些只是早期迹象，而非最终证明。
- 安全性： 在一个涉及银行应用的特定案例研究中，使用这些严格的“宪法”规则，与让 AI 在没有规则的情况下构建相比，减少了 73% 的安全缺陷。
- 速度： 另一项研究发现，使用这种严格方法的团队交付项目的速度比通常快了一倍，且首次评审的代码接受率达到了 90%。
- 代价： 论文非常诚实地指出，这些庞大的数字来自于单一的案例研究。它们就像是看到一个人中了彩票后说：“看，你可以中奖！”它暗示这些结果是真实的，但需要在许多不同的地方进行多次测试才能确定。
论文还排除了“AI 本身是问题所在”这一观点。它认为问题不在于 AI，而在于我们如何使用它。如果你配合严格的计划（规范）使用 AI，它表现出色；如果你在没有计划的情况下使用它（氛围编程），它就会制造混乱。
对未来的总结
论文的结论是，我们不应该停止使用 AI，但我们也不应该在大型项目中仅仅靠“氛围”来推进。对于小型、有趣的实验，“氛围编程”是可以的。但对于运行银行、医院和电网的软件，我们需要严格的合同。
人类工程师的角色正在发生变化。我们正在从亲手铺设每一块砖的人，转变为编写蓝图和检查工作的人。论文认为，软件工程的未来不在于让 AI 做一切，而在于利用 AI 来精确构建我们所规范的内容，确保最终结果是安全、可靠且经得起时间考验的。魔力在于计划，而不仅仅是提示词。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。