AI编程如何基于SDD实现工程化落地

Vibe Coding（氛围编程）代表了AI编程的民主化趋势，而SDD（规范驱动开发）则代表了其工程化收敛。二者并非对立，而是共同构成了完整的AI原生开发光谱。

一、问题域：当“氛围编程”遇上企业级工程

2025年，Andrej Karpathy提出的Vibe Coding彻底引爆了开发者社区。这种通过自然语言描述意图，让大语言模型自主生成代码，人类只负责验收与迭代的模式，在原型验证和创意探索场景下，确实展现了惊人的生产力。然而，一旦进入企业级系统与大型团队协作的深水区，其工程化短板便迅速暴露无遗。

核心矛盾在于：AI加速了代码产出，却引入了新的复杂性。代码的规范性、可维护性、架构一致性，这些传统软件工程的基石，在快速迭代的“氛围”中变得岌岌可危。规范驱动开发（Spec-Driven Development，SDD）正是为此而生的工程化解法。它将软件工程的重心，从“代码实现”上移至“规范定义”，让人类专注于谱写“乐谱”（规范），而AI则负责精准“演奏”（实现）。

二、SDD 工具生态的四极格局

当前，SDD领域已形成四种截然不同的技术路线，分别对应着轻量演进、宪法治理、端到端闭环与组织仿真四大范式。

框架定位矩阵

OpenSpec：存量系统的“微创外科手术刀”

其核心机制在于“规格差异”（Spec Delta）。OpenSpec借鉴了文件系统的异步变更模型，通过隔离设计openspec/specs/（真理仓库）与openspec/changes/（变更暂存区），实现对遗留系统的“蚕食式”重构。

这种设计的优势非常明显：首先是令牌效率最优，AI仅需读取受影响的规格片段，而非全量代码上下文；其次是低侵入性，团队无需补齐浩如烟海的历史文档，只需局部建立规格即可驱动变更。

它的典型工作流可以概括为：/opsx:proposal生成变更提案，然后通过/opsx:apply执行。

GitHub Spec-Kit：企业级工程的“宪法范式”

Spec-Kit的核心是“开发宪法”（Constitution）与四阶段门禁机制。它通过一个constitution.md文件，建立主权式的约束框架，将LLM的概率性输出，牢牢约束在确定性的工程规范之内。

来看一个宪法示例：

## 技术禁令
- 必须使用 Tailwind CSS，严禁 CSS Modules
- 禁止 TypeScript `any` 类型
## 安全红线
- 严禁硬编码 API Key，必须环境变量注入

Amazon Kiro：端到端自动化的“双向闭环”

与Spec-Kit强调“分阶段门禁”不同，Kiro追求的是从模糊需求到代码交付的端到端自动化，其核心机制是实时双向同步与对话驱动流水线。

“双向同步”意味着代码变更会自动反向更新规格文档，确保Spec与Code始终对齐，解决了文档滞后这一老大难问题。同时，它将SDD流程原生嵌入DevOps流水线，通过自动化Hooks在每次提交时触发合宪性检查。更重要的是，它通过自然语言对话直接驱动规范生成与代码实现，大幅降低了使用门槛。

简单对比两者的工作流哲学：Spec-Kit强调人类主导的阶段推进，明确了人机分工；而Kiro则倾向于由AI主导流程推进，人类更多地扮演验收与纠偏的角色。

BMAD-METHOD：多智能体协作的“组织仿真”

BMAD-METHOD将软件开发转化为一个标准化的多智能体社会系统，其核心是21+角色智能体矩阵与文档分片技术。

其核心规划由“三人组”完成：分析师负责市场研究与可行性验证，防止无价值开发；产品经理将业务目标翻译为功能与非功能需求，输出完整的产品需求文档；架构师则负责技术选型与安全性评估，审查需求可行性。

它的技术创新点在于“文档分片”，将庞大的PRD拆分为原子化的故事文件，有效解决了长上下文下的“中间信息丢失”问题。其“派对模式”更是有趣，允许多个智能体（如架构师与开发者）进行圆桌辩论，人类则作为“战略导演”进行最终裁决。

四框架深度技术对比

ROI 与适用场景决策树

面对不同场景，该如何选择？这里提供一个简单的决策思路：

场景一：存量系统现代化
首选OpenSpec。它无需全量理解遗留代码，局部建立规格即可驱动变更，侵入性最小，如同微创手术。

场景二：强合规企业级开发
首选Spec-Kit。其宪法机制能强制执行行业安全标准，四阶段工作流提供了完美的审计追踪，适合金融、医疗等强监管领域。

场景三：追求端到端自动化与快速迭代
首选Amazon Kiro。双向同步确保文档永不滞后，自动化Hooks极大降低了人工流程负担，非常适合追求极致效率的敏捷团队。

场景四：复杂多维项目与全自动化探索
首选BMAD-METHOD。其多智能体角色能提供深度的业务思考，分片技术支持超长周期项目的管理，据称可将项目总时长缩减40-60%。

三、SDD 工程闭环：规范驱动的开发宪法

基于SpecKit的方法论，一个完整的SDD开发周期构成了一个动态闭环，而这个闭环建立在一套不可变更的核心原则（Constitution）之上。

规范阶段

目标是将模糊、感性的需求，转化为AI可读、结构化的规范（通常以Markdown为主）。这个阶段的关键在于明确“做什么”和“做到什么程度”，而非“如何做”。关键产出包括：清晰的用户故事与场景、可验证的验收标准（常用Given/When/Then格式）、业务实体定义与非功能需求（如并发、性能、安全），并且必须明确排除对实现细节的描述。

计划阶段

目标是将上一阶段产出的规范，“翻译”为可执行、可分配的工作清单。这个阶段的产出物是后续开发的蓝图，包括：模块划分与职责边界、数据模型与状态流转设计、接口契约（如OpenAPI格式），以及任务清单与规范条目的映射关系。

实现与验证阶段

AI根据任务清单产出代码，而人类工程师的角色则转变为“架构监理”。验证环节是质量保障的核心，包含三个层次：自动化测试确保场景覆盖率；静态合规扫描检查是否触犯宪法红线；最后再由人工进行业务体验确认。

反馈闭环

这是SDD可持续性的关键。来自生产环境的Bug或新需求，不应直接以“打补丁”的方式修改代码。正确的流程是：首先更新规范文档，然后让这个变更重新走一遍计划、实现、验证的完整闭环。这样才能确保规范、代码、测试三者持续对齐，避免架构腐化。

四、工程实践：SpecKit + GitHub Copilot 最小可行示例

理论说得再多，不如动手一试。以下演示如何使用SpecKit CLI快速建立一个SDD工作流。

步骤1：环境初始化

# 安装 SpecKit CLI
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
# 初始化项目
specify init Blogsite

初始化后，项目.github/目录下会生成对应SDD各环节的Prompt模板。之后，在GitHub Copilot聊天面板中，就可以通过/speckit命名空间来调用这些功能。

步骤2：制定项目宪法
在Copilot中执行/speckit.constitution，生成.specify/memory/constitution.md文件。这是项目的根本大法。

# Blogsite 开发宪法
## 架构原则
- 采用 Next.js 14 App Router 架构
- 组件化设计：UI 层与逻辑层严格分离
- 数据层使用 Prisma ORM + PostgreSQL
## 质量红线
- 所有功能必须附带单元测试（覆盖率 > 80%）
- 无类型安全检查（TypeScript strict 模式）
- 禁止直接操作 DOM，必须通过 React 生命周期
## 文档同步
- 每次代码变更必须同步更新 README 与 API 文档
- 规范文档优先于代码注释

步骤3：规范驱动迭代
假设我们现在要新增一个“文章评论”功能。

在Specify阶段，使用/speckit.specify生成产品需求文档，明确评论的嵌套层级、审核状态流转、用户权限矩阵等。
进入Plan阶段，使用/speckit.plan将需求拆解为具体的数据库Schema变更、API接口设计、前端组件实现等任务清单。
在Implement阶段，AI依据任务清单生成代码，人类工程师则重点审核其架构合规性，确保符合“宪法”。
最后是Verify阶段，运行自动化测试，覆盖主路径与各种边缘场景，如空评论、超长文本、XSS攻击防护等。

五、组织架构 implications：从“码农”到“规范架构师”

SDD带来的不仅是技术范式的变革，更是开发者角色定位的深刻升级。传统的“码农”角色逐渐向更高维的“规范架构师”或“需求工程师”转变。其核心价值不再是编写具体的代码行，而是定义清晰、无歧义、可执行的规范，并监理AI正确实现这些规范。

六、结论与展望

回过头看，Vibe Coding与SDD并非取代关系，而是互补共生的两极。前者代表了AI编程的民主化趋势，降低了创意实现的准入门槛；后者则代表了其工程化收敛，确保了大规模协作下的质量与可持续性。二者共同构成了完整的AI原生开发光谱。

在项目的不同阶段，可以灵活运用：在探索阶段，用Vibe Coding快速验证想法、构建原型；进入生产阶段，则切换到SDD，确保架构的一致性与可维护性；在漫长的演进阶段，依靠规范驱动的闭环实现持续的架构治理。

随着GitHub SpecKit、Amazon Kiro、OpenSpec等工具的日益成熟，SDD正在从前沿理论走向规模化的工程实践。对于企业技术团队而言，越早建立“规范即代码”的工程文化，就越能在AI编程的浪潮中，保持技术资产的可控性与长期竞争力。未来的胜负手，或许不在于谁写的代码更快，而在于谁定义的规范更准、更优。