AI编程的未来：规格驱动开发

AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

"AI，帮我写代码"这个口号在过去两年中引发了开发者社区的一场体验革命。

突然之间，用自然语言生成可运行的模块不再是幻想。你只需写一个提示词，就能获得UI、API甚至测试用例。这催生了"氛围编程"（vibe coding）：将开发变成与模型的实时对话，极大地缩短了从想法到实现之间的距离。

但当我们把目光从"个人原型"转向"工程项目"、团队协作和长期可维护性时，氛围编程的根本缺陷便暴露无遗。

与此同时，一种更加系统化、以工程为重心的范式——规格驱动开发（Specification-Driven Development，SDD）——正在兴起。凭借其卓越的控制力、可验证性和可扩展性，SDD正成为将AI编程引入生产级应用的必由之路。AWS的Kiro就是这一实践的典范，明确将"规格"定位为从原型到生产的桥梁。

在这里，我将通过问题分析、对比论证、实际证据和实践建议，剖析为什么工程级AI编程需要SDD，并阐述Crevo对这一实践的视角。

1、"氛围编程"的魅力与核心缺陷

魅力（为什么如此流行）

• 极低门槛： 自然语言即可产出可运行的结果。这提供了快速反馈循环，非常适合快速概念验证（POC）。
• 高速原型构建： 在早期阶段，"氛围编程"能以惊人的速度构建出可用于演示的原型，大幅节省人力。

核心缺陷（为什么不适合工程化）

• 语义漂移与不确定性： 模型在解读模糊需求时会做出大量假设。输出结果经常与团队意图不一致，且难以确保边界条件和错误处理被覆盖。
• 可解释性/可审计性差： "氛围编程"的输出通常是"黑箱"代码片段。它缺乏来源归属、设计决策或验收标准，使团队几乎无法进行审查或审计。
• 知识僵化风险： 当代码和设计没有同步到机器可读的规格中时，这些知识要么留存在人脑中，要么散落在PR评论中，很容易因人员流动而丢失。
• 技术债务与维护成本： 短期来看很快，但长期来看会产生大量隐性技术债务，尤其是在依赖自动生成代码的大型系统中。
• 协作冲突： 不同团队成员各自与模型"氛围编程"生成的代码，如果没有统一标准，会导致风格、接口和测试覆盖率的碎片化。

这些并非微不足道的实现细节，而是对工程可持续性的核心威胁。现实世界的生产系统不可能靠一次又一次"碰运气式的提示词"来维护。

2、什么是规格驱动开发（SDD）？核心价值

SDD的基本逻辑简单而深刻：将"规格"作为协作和自动化的中心唯一事实来源。

在SDD工作流中，自然语言或产品需求不会直接驱动代码。相反，它们首先被转化为结构化、可验证、可执行的规格（包括需求、验收标准、API契约、测试场景、设计要点等）。然后，自动化代理和/或人员基于该规格生成代码、测试和部署。

SDD的核心优势：

• 一致性与可验证性： 实现可以自动与规格进行对照检查。测试直接基于规格的验收标准，显著减少错误。
• 可审计性与可追溯性： 每个实现点都有规格参考。变更被记录下来，便于追溯决策并确保合规。
• 可复用性与模块化： 结构良好的规格可以在多个项目中复用，提高工程效率。
• 团队友好协作： 规格充当沟通契约。设计、产品、工程和QA团队可以共享同一事实来源，减少沟通成本。

这些并非抽象的理想，而是可维护性、可扩展性和合规性的直接、实际需求。正如 dev.to 上对SDD的初步评论所指出的：SDD引入了前置规格成本，但它是将AI辅助开发从"原型工具"提升为"生产工具"的关键因素。

3、为什么亚马逊押注SDD作为解决方案

AWS（及其生态系统中的工具，如Kiro）正将SDD作为应对氛围驱动开发混乱的务实答案。Kiro的方法值得关注，因为它将这一理念转化为工程化的产品功能：

1. 从提示词到规格： 它将自然语言提示词转化为结构化文档，如 requirements.md、design.md 和 tasks，作为生成的基础。
2. 代理与钩子： 它使用代理自动执行任务、运行测试和更新规格，保持实现和规格的同步。
3. 审查与护栏： 它允许用户在自动化继续之前审批关键变更，防止模型盲目修改生产代码。
4. 与现有代码库集成： Kiro可以读取项目上下文并从现有代码中推断约束，提高生成输出的质量。

多家媒体和实测评测指出，Kiro之所以获得关注，是因为它解决了氛围编程与工程化之间的脱节——将"快速生成"与"工程质量"连接起来。实测报告也明确指出：没有规格，AI生成难以扩展到生产环境；Kiro通过规格驱动执行解决了这一问题。

简言之：Kiro并不反对代码生成，它的目的是赋予生成以纪律。

4、回应质疑：SDD的"前置成本"是否不可接受？

质疑一："SDD需要先写规格，会拖慢开发速度。"

回应： 这是一个"短期投入、长期回报"的选择。正确的SDD不是要写大量死板的文档。它是关于使用工具来自动化规格生成，将前置劳动转化为一次性建模成本，然后由机器来维护。许多组织宁愿在前端多投入一些，也不愿在生产行中支付高昂的维护成本。此外，GitHub和AWS的工具链已经在向自动化规格编写方向发展，降低了这一门槛。

质疑二："如果模型误解了规格怎么办？"

回应： 这正是SDD的核心所在。它不是盲目信任模型的理解能力，而是让模型将其理解输出为可验证的单元（明确的验收标准、示例、边界测试），然后使用自动验证来约束最终结果。这形成了一个闭环：意图 → 规格 → 生成 → 验证 → 修正。 这比依赖提示词试错要可控得多。

5、实践建议：如何将SDD引入你的工作流

以下是为希望将"氛围编程的速度"与"SDD的工程质量"相结合的团队提供的可操作步骤。

保留"氛围"入口，但"立即结构化"输出：

允许开发者使用自由格式的自然语言生成原型。但工具（或平台）必须自动将这些对话转化为结构化的规格草案（包含验收标准和示例）。这样，原型不会是一次性的——它立即进入一个受治理的、基于规格的循环。Kiro的模式就是一个完美示例。

强制执行"可验证的规格单元"：

每个功能必须至少附带一个可执行的验收测试或明确的边界用例。测试既是规格的一部分，也是模型输出的自动验证器。

采用轻量级规格模板和迭代流程：

不要让规格变成沉重、繁琐的文档。使用模块化模板（需求、API契约、示例请求/响应、关键用例），并将它们纳入版本控制和代码审查流程。

建立双向同步：实现 → 规格：

实现中的变更应触发写回规格的流程，或至少标记不一致之处（例如通过CI检查或代理钩子）。这确保规格是"活文档"，而非"写完即忘"的文档。Kiro的钩子模型就是这一点的实际应用。

以"审查机制"赋能团队，而非"盲目信任"：

在生产路径中保留人工审批节点（尤其是关键模块、权限、数据访问等），确保安全和合规。让AI做实现，但让团队做最终决策。

6、Crevo的设计立场

Crevo的目标是将"自然语言的便利性"与"工程规格的控制力"相结合。我们的设计理念有三个支柱：

1. 以语言为入口，以规格为核心： 用户可以用自然语言开始设计和开发流程。但Crevo会将这些对话转化为结构化、可验证的系统描述（PRD风格的智能草稿 + API契约 + 验收标准），将"随意的提示词"变为可审查的工程事实。
2. 规格作为可执行的一等公民： 规格不只是文档，它们是触发自动生成、测试和部署的可执行对象。每次变更都必须有一个可验证的单元，规格驱动生成才能成为可持续的工程实践。
3. 渐进式采纳路径： 我们不要求团队一夜之间放弃现有工作流。Crevo支持"氛围 → 自动规格 → 迭代"的渐进过程，允许团队按照自己的节奏采纳SDD风格的实践，逐步建立信任。

说得更直白一点：Crevo的设计宗旨是将"氛围的速度"与"SDD的可靠性"打包在一起。

7、结束语

氛围编程是一场革命性的体验，但它不是工程终点。如果我们希望将AI引入大规模生产系统，就必须将规格、验证和同步嵌入到生成过程中。

SDD为AI编程提供了工程语义、验证循环和团队契约。它是从"工具"迈向"平台"和"流程"的关键一步。像Kiro这样的产品正在通过将规格作为系统核心来解决"氛围编程"造成的工程问题。

我对开发者和团队的建议是：享受氛围编程的速度，但不要放弃规格。将规格变成由工具自动维护的 "活资产"，而不是沉重的纸质文档。

只有这样，AI才能真正从"助手"进化为"工程伙伴"。

原文链接: Why the Future of AI Coding Belongs to Spec-Driven Development (Not Vibe Coding)

汇智网翻译整理，转载请标明出处