Constitutional Spec-Driven Development: Enforcing Security by Construction in AI-Assisted Code Generation
本文介绍了宪法规范驱动开发（Constitutional Spec-Driven Development），这是一种将机器可读的安全约束嵌入到规范层的方法，旨在通过在 AI 辅助代码生成中实现“通过构造实现安全”（security by construction），并证明该方法在保持开发者开发效率的同时，减少了 73% 的安全缺陷。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下，你正在雇佣一名极其快速、才华横溢但略显鲁莽的学徒程序员。这个学徒（即 AI）只需听取你的描述，就能在几秒钟内写出一个可以运行的计算机程序。然而，由于这个学徒过于专注于让程序“跑起来”，他们经常会忘记锁门、藏好钥匙或加固墙壁。在过去，你会先盖好房子，然后再雇佣一名安全检查员来寻找漏洞并进行修复。但当你的学徒能在 10 秒钟内盖好一栋房子时，检查员根本跟不上进度，甚至在检查开始之前，房子里可能就已经布满了陷阱。
这篇论文介绍了一种全新的工作方式，称为宪政驱动规约开发（Constitutional Spec-Driven Development）。你可以把它想象成在学徒动手写下第一行代码之前，先给他们一份**“宪法”**。
核心理念：“宪法”
在政治中，宪法是一套治理国家的不可逾越的规则。你不能仅仅通过一项法律就宣布“每个人都必须贫穷”，如果宪法规定“每个人都有权利”。
在这篇论文中，作者建议我们给 AI 一份**“软件宪法”**。这不仅仅是一个像“要小心”这样模糊的建议。它是一本严格的、机器可读的规则手册，规定了：
- “你必须锁好每一扇门（身份验证）。”
- “你绝不能把钥匙放在垫子下面（禁止硬编码密码）。”
- “你必须在放行任何人之前检查其身份证件（授权）。”
AI 被告知：“你可以建造任何你想建造的东西，但你不能违反这些规则。”如果 AI 试图编写违反规则的代码，系统会立即拒绝，迫使 AI 在代码完成之前就进行正确的重写。
类比：“氛围编程” vs. “护栏”
论文将当前利用 AI 快速编写代码的趋势称为**“氛围编程”（Vibe Coding）**。
- 氛围编程： 你说，“给我做一个银行 App，”AI 瞬间就吐出了代码。它能用！但它可能在墙上留了一个洞，让任何人都能偷走钱。
- 宪政驱动规约开发： 你说，“给我做一个银行 App，”但你在交给 AI 任务的同时，先递给它一份**“宪法”。AI 构建 App，但它必须在设定的护栏**之内进行构建。如果它试图建造一扇没有锁的门，护栏就会立刻将其关上。AI 必须不断尝试，直到那扇门装上了锁。
实验：盒子里的银行
为了证明这种方法的有效性，作者构建了一个银行微服务（银行软件中处理账户和资金的一小部分）。他们选择了银行作为案例，因为如果你在处理银行业务时出错，人们会损失真实的资金，且银行会面临巨额罚款。
他们做了两件事：
- “氛围”方式： 他们让 AI 在没有任何规则的情况下构建银行 App，仅仅要求它“让它跑起来”。
- “宪法”方式： 他们给了 AI 那本严格的规则手册（宪法），并要求它构建同样的 App。
结果
结果非常显著：
- 更少的漏洞： “宪法”版本的安全性漏洞比“氛围”版本少了 73%。
- 更快达到安全状态： 团队实现安全版本 App 的时间缩短了 56%。通常情况下，团队在 AI 编写完代码后，需要花费数周时间来修复安全漏洞。而有了“宪法”，代码在编写过程中就是安全的。
- 向老板证明： 系统自动创建了一张地图，清晰展示了哪一行代码遵循了哪一条规则。这就像是为安装的每一个安全锁都开具了收据，这对银行审计人员来说非常有用。
修复了什么？
论文列举了 10 种特定的“安全漏洞”（例如 SQL 注入，即黑客通过欺骗数据库，或弱密码）是“宪法”所能预防的。
- 示例 1： AI 试图使用简单的文本字符串来编写数据库查询。这就像是在便签纸上写下银行账号。宪法说：“不行！请使用安全的参数化查询。”于是 AI 对其进行了修正。
- 示例 2： AI 试图将用户的密码记录（Log）在一个文件中，以便于“追踪”。宪法说：“严禁记录密码。”于是 AI 从日志中删除了密码。
- 示例 3： AI 允许任何人查看任何账号。宪法说：“你必须检查用户是否拥有该账号。”于是 AI 添加了校验逻辑。
“经验教训”
作者总结了关于如何使用这种方法的几个重要心得：
- 要具体： 不要只说“要安全”。要说“使用 bcrypt 哈希算法，成本设定为 12”。AI 需要精确的指令。
- 不要过载： 如果你一次性把整本 50 页的规则手册都交给 AI，它会感到困惑。更好的做法是，只给它与当前特定任务相关的 3 到 5 条规则。
- 保护规则手册： 宪法本身也是一个攻击目标。如果黑客能诱导 AI 修改宪法，使其变成“无需密码即可进入”，那么整个系统就会崩溃。因此，宪法文件必须像保险库一样受到严密保护。
总结
这篇论文认为，我们不应该等到 AI 写完代码后再去修复安全问题。相反，我们应该将安全规则融入到流程的第一步。通过给 AI 一份**“宪法”**，我们迫使它通过“构建即安全”的方式来编写软件，而不是靠运气实现安全。它将安全从一项“事后修补”的琐事，转变为蓝图设计中“必须具备”的核心部分。
注： 本论文严格侧重于用于软件开发的这种方法论，特别是通过使用银行案例来演示安全性的提升。它并不声称这些结果适用于医疗处理、物理安全设备或其他非软件领域。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。