近两年“AI 帮我写代码”的口号让开发社区经历了一场体验革命：原来用自然语言就能生成一个可运行的模块；原来写一个 prompt 就能得到 UI 、API 、甚至测试样例。于是“vibe coding”应运而生：把开发变成一次与模型的即时对话，让创意和实现之间的距离极度压缩。
但当我们把目光从“单人原型”拉回到“工程项目”、团队协作与长期可维护性时，vibe coding 的多项根本缺陷暴露无遗。与此同时，一类更系统、更工程化的范式——Specification-Driven Development （ SDD ）——以更强的可控性、可验证性与可扩展性，正成为将 AI 编程推向工程级应用的必由之路。AWS 的 Kiro 是这方面最典型的实践之一，它明确把“规范”作为从原型到生产的桥梁。
下面我从问题、对比、证据与实践建议四个层面展开，说明为什么工程级 AI 编程需要 SDD ，并阐述 Crevo 的实践视角。
一、Vibe Coding 的魅力与核心缺陷（简述）
魅力（为什么会流行）
- 极低的门槛：自然语言即可产生可运行结果，快速得到反馈，适合快速验证想法（ POC ）。
- 高速原型：在产品早期，用“vibe”能极快搭出可演示的原型，节省人力。
核心缺陷（为什么不适合工程化）
- 语义漂移与不确定性：模型在理解模糊需求时会做大量假设，输出与团队意图常常不一致，难以保证边界条件与错误处理都被覆盖。
- 不可解释 / 可审计性差：vibe 输出往往是“黑盒”式的代码片段，缺少来源说明、设计决策与验收标准，团队难以审查与复盘。
- 知识固化风险：当代码和设计未同步成可机器理解的规范时，知识留存在人脑或散落在 PR 中，容易随着人员变动流失。
- 技术债与维护成本：短期内速度很快，但长期却可能产生大量隐性技术债，尤其在依赖模型自动生成的大型系统中尤甚。
- 协作冲突：多人成员各自与模型交互生成的代码，若无统一规则，会造成风格、接口、测试覆盖的碎片化。
这些问题不是小的实现细节，而是对工程可持续性的核心威胁。现实世界的生产系统不能靠一次次“prompt 运气好”去维持稳定。
二、什么是 Spec-Driven Development （ SDD ）——核心价值
SDD 的基本逻辑简单但深刻：将“规范（ spec ）”变成团队协作与自动化的中心事实源（ single source of truth ）。在 SDD 流程中，自然语言或产品需求不是直接驱动代码，而是先转为结构化、可验证、可执行的规范（包括需求、验收标准、接口契约、测试场景、设计要点等），随后由自动化 agent / 人类在这个规范之上产出代码、测试与部署。
SDD 的关键收益：
- 一致性与可验证性：实现可以与规范自动比对，测试直接以规范中的验收条件为准，从而显著降低误差。
- 可审计与可追踪：每个实现点都有规范参照，变更有记录，便于回溯与合规检查。
- 可复用与模块化：良好结构化的规范可以在多个项目间复用，提高工程效率。
- 团队协作友好：规范作为沟通契约，设计、产品、工程、QA 等角色能够共享同一事实源，减少沟通成本。
这些不是抽象理想，而是工程实践中对“可维护性、可扩展性、合规”的直接要求。dev.to 上对 SDD 的初步评估也指出：SDD 在短期会带来上游规范成本，但从长期看是能让 AI-assisted development 从“原型工具”变为“生产工具”的关键。
三、亚马逊为什么把 SDD 作为解决之道
AWS （及其生态中的工具，例如 Kiro ）把 SDD 用作应对 vibe-driven 混乱的实战答案。Kiro 的做法值得我们关注，因为它把理念转成了工程化产品特性：
- 从 prompt 到 spec：把自然语言 prompt 转化为 requirements.md、design.md、tasks 等结构化文档，作为生成的基线。
- agent 与 hooks：通过 agent 自动执行 task 、运行测试、更新 spec ，保持实现与规范的同步。
- 审查与防护：支持用户在自动化操作前批准重要更改，避免模型盲目改动生产代码。
- 可整合现有代码库：Kiro 能读取项目上下文，从已有代码中推断约束，提高生成质量。
多家媒体和动手评测均指出：Kiro 之所以被快速接受，是因为它解决了 vibe coding 到工程化之间的断层——把“快速生成”与“工程质量”连接起来。Hands-on 的报道也明确提到：没有规范，AI 生成就很难扩展到生产环境； Kiro 通过规范驱动来解决这一点。
简言之：Kiro 并不是反对生成，而是给生成插上规矩。
四、直面常见反驳：SDD 的“前期成本”是否不可接受？
反驳 1：SDD 需要先写规范，会拖慢开发速度。
- 回应：这是一个“短期投入、长期回报”的选择。正确的 SDD 并不是写大量死文档，而是借助工具把“规范生成”自动化，把前期的显性劳动转为一次性建模、并由机器维持同步。许多组织宁愿在早期多点投入，也不愿在生产后付出更高昂的维护成本。GitHub 与 AWS 推出的工具链也在朝“把规范写作自动化”方向发展，降低了这个成本门槛。
反驳 2：模型误解规范怎么办？
- 回应：这正是 SDD 要解决的点：不是把“理解”全部寄望给模型，而是把理解产出成可校验的规范单元（明确的验收标准、示例、边界测试），然后用自动化验证继续约束生成结果。由此形成闭环：意图 → 规范 → 生成 → 验证 → 修正。这比仅靠 prompt-trial 更可控。
五、实践建议：如何把 SDD 引入现有工作流
下面是对实际团队可直接采纳的步骤，目标是把“vibe coding 的速度”与“SDD 的工程质量”结合起来。
1) 保留 Vibe 的入口，但把输出“立即结构化”
- 允许开发者用自由自然语言或简短 prompt 快速生成原型；但工具（或平台）必须自动把这些对话产出转换为结构化规范草稿（带验收条件与示例）。如此，原型不会流于一次性产出，而能马上进入规范化闭环。Kiro 的做法就是这个范例。
2) 强制“规范可验证单元”
- 每条功能必须伴随至少一条可执行的验收测试或明确的边界用例。测试既是规范的一部分，也是模型生成结果的自动检验器。
3) 采用轻量级 Spec 模板与迭代流程
- 不要把规范做成厚重的文档；采用模块化模板（需求、接口契约、示例请求/响应、关键用例），并把它们纳入版本控制与变更审查流程。
4) 建立同步机制：实现→规范 的双向同步
- 实现变更应触发回写或标记规范差异的流程（例如通过 CI 校验或 agent hooks ），确保规范不是“写完就丢”的文档。Kiro 的 hook 模型与自动化 agent 是这一思路的实践。
5) 赋予团队“审查机制”而非“全自动信任”
- 在生产路径中保留人工审批节点（特别是关键模块、权限、数据访问等），以保证安全与合规。AI 做实现，团队审查做决策。
六、Crevo 的设计立场
Crevo 的目标是把“自然语言的便捷”与“工程规范的可控”结合起来。我们的设计哲学包含三点：
-
语言即入口，规范即中枢
- 用户可以用自然语言启动设计与开发流程，但 Crevo 会把这些对话转成结构化、可验证的系统描述（ PRD-style 智能草稿 + 接口契约 + 验收条件），把“随意的 prompt”变成可审查的工程事实。
-
规范是可执行的第一公民
- 规范不只是文档；它是触发自动化生成、测试与部署的可执行对象。每次变更都要有可校验单元，规范驱动的生成才能变成可持续的工程实践。
-
渐进式采纳路径
- 我们不要求团队一夜之间放弃现有工作方式。Crevo 支持“快速试探（ vibe ）→ 自动规范化 → 迭代上链”的渐进式流程，让团队在熟悉与信任中逐步采用 SDD-style 的工程实践。
用更直白的话来说：Crevo 想做的是把“vibe 的速度”包装成“SDD 的可靠性”。
七、结论：为什么现在要重视 SDD
- Vibe coding 是革命性的体验，但不是工程级最终态；若要把 AI 带入大规模生产系统，必须在生成过程里嵌入规范、验证与同步。
- SDD 为 AI 编程提供了工程语义、验证闭环和团队契约，是从“工具”跨越到“平台 / 流程”必不可少的步骤。Kiro 等产品正通过把规范作为核心来解决 vibe 带来的工程问题。
- 对开发者与团队的建议是：既享受 Vibe 的速度，也别放弃规范——把规范做成一个被工具自动维护的“活资源”，而不是沉重的纸上说明。这样，AI 才能真正从“助理”进化为“工程伙伴”。
试用 Crevo
告别 Vibe 混乱，拥抱 SDD ，体验 AI 编程的正确方式。
立即注册 Crevo ，使用优惠码（ 30 天有效）3EUSTLMI，开启您的首个“规范驱动”项目，立享5 折优惠。
参考/延伸阅读
- Daniel Sogl,Spec Driven Development (SDD) — A initial review. dev.to.
- Kiro project / docs / blog — “The AI IDE for prototype to production”.
- Hands-on articles and reviews: Devclass, The New Stack 等对 Kiro 的评测报道，讨论 SDD 在工程化上的价值与挑战。
- GitHub / Microsoft / AWS 关于 Spec-Driven 工具链与开源 kit 的文章，说明业界正在推出支持 SDD 的工具集。