一项 2026 年的 Sonar 调查显示，88% 的开发者认为 AI 生成的代码正在增加技术债，而规范驱动开发（spec-driven development）的支持者认为，严谨的规范步骤可以遏制这种偏差。
为什么这个问题很重要
当人类收到模糊的任务单时，会提出澄清性问题。相比之下，AI 智能体会根据自己的最佳猜测来填补空白，并交付看起来看似合理的代码。这种“正确”的错觉代价高昂：同一项 Sonar 调查报告称，超过一半的受访者曾见过代码通过了基础检查，但却隐藏了细微的缺陷。这些缺陷会堆积成技术债，迫使后期进行重构，减慢功能交付速度，并推高维护预算。
规范驱动开发是什么样的
规范驱动开发 (SDD) 颠覆了当前的顺序。团队不再是向 AI 模型输入简短的用户故事，而是编写一份详细的、智能体可执行的规范，并将其保存在与代码相同的版本控制系统中。规范成为了单一事实来源——它记录了意图、边缘情况、性能预期以及 AI 模型必须遵守的任何约束条件。
这一过程并不是取代人类的设计工作，而是将其代码化。通过将决策从开发者的记忆转移到具体的文档中，人类和未来的 AI 智能体都可以追溯某段代码为何表现出某种行为。起草规范需要前期的投入，但后期调试模糊的 AI 输出所花费的成本要高得多。
改变工作流
产品待办列表 (Product backlog) – 保持条目简短，仅捕捉意图和高层级的验收标准。该列表继续驱动优先级排序。
Sprint 规划 (Sprint planning) – 团队讨论总体目标并达成 Sprint 目标，但在规范准备就绪之前，他们会暂缓详细的实现工作。
Sprint 期间 – 认领任务的人编写一份精确的、机器可读的规范。规范列出了输入格式、预期输出、错误处理以及任何非功能性需求。由于规范受版本控制，评审人员可以像评审代码一样对规范进行评论、建议修改并批准变更。
完成的定义 (Definition of Done) – 在质量门禁中增加“规范已评审并批准”。在规范通过与实现代码相同的评审标准之前，代码不算完成。
看板 (Kanban) 适配 – 插入两个新列：“规范已起草 (Spec Drafted)”和“规范已批准 (Spec Approved)”。工作项现在的流转顺序为：待办列表 → Sprint 目标 → 规范已起草 → 规范已批准 → 进行中 → 已完成。这种视觉上的变化使原本不可见的协作步骤变得显性化。
已经强制执行规范的工具
GitHub Spec Kit 和 AWS Kiro 等平台已经增加了门禁，要求在开始任何 AI 代码生成之前必须提供需求文档。它们并不取代 AI 模型，而是让“死板”的智能体与人类意图保持一致。通过将规范设为前提条件，这些工具在不破坏现有 CI/CD 流水线的情况下实现了自动化的转型。
可能面临的阻力
批评者认为，编写规范会给本就快速迭代的敏捷节奏增加摩擦。反驳的观点是：编写规范所花费的时间，通常只是后期调试因模糊提示词而产生的 AI 代码所花时间的零头。
另一个担忧是，随着需求演进，规范可能会过时。版本控制集成解决了这个问题：对规范的任何更改都会创建一个新的提交，触发评审，并迫使团队重新评估相关的代码。在实践中，像对待代码一样对待规范可以保持文档的时效性。
下一步值得关注的方向
虽然目前仍处于早期采用阶段，但势头已显而易见。随着 AI 代码生成器变得越来越强大，对精确、机器可读意图的需求只会不断增长。
核心结论： 将模糊的提示词转化为具体、经过评审的规范，虽然感觉像是一个额外的步骤，但它将“猜测”转化为了“负责任的决策”。