Spec-Driven Development with Coding Agents

Vibe Coding的尽头是什么？

过去两年，AI 编码代理的能力飞速提升。Claude Code等coding agents已经能够自主完成相当规模的编程任务。但大多数开发者（including me）仍然在用“聊天”的方式使用这些工具——描述一个目标，拿到一段代码。

前几天看了吴恩达和 JetBrains的Paul Everitt联合推出的《Spec-Driven Development with Coding Agents》，算是对这一问题的回应。课程的核心口号是： “Building AI agents that ship to production, not just impress in demos.”

这个不到一个半小时的课课程提供了一个更轻量级、更易于入门的方法论框架。本文以课程内容为主线，辅以工程实践中的补充观察，希望能梳理Spec-Driven Development(SDD) 的核心理念、工作流和落地技巧。

一、为什么需要 SDD

简单概括Vibe Coding的根本问题：模糊Prompt → AI猜 → 反复改 → 技术债、返工率高

Andrew Ng.分享了一个真实观察：他见过一些团队在开发复杂软件产品时没有清晰的规范，结果不同的编码代理在不同的开发者指导下，以互相矛盾的方式快速构建，导致大量下游问题。这不是agent能力的问题，而是上下文缺失的问题。

SDD的核心主张：规范成为可执行的工件，直接驱动实现，而不再只是指导实现。SDD的价值可被归纳为三个核心收益：

第一，小改动撬动大代码。 一句“使用SQLite配合Prisma ORM”，可能影响数百行代码；改成MongoDB，同样的下游放大效应依然成立。写规范的效率远高于写代码。

第二，消除跨会话的上下文衰减。 Agent是无状态的，每次启动都需要加载最高质量的上下文。规范正是这种高质量的、持久化的上下文载体。

第三，提升意图保真度。 开发者定义问题、成功标准和约束，agent在此基础上展开更完整的计划，而不是凭自己的“偏好”猜测。

如果你能用一个简短提示完成目标那也很好，Andrew Ng. 也是“懒惰提示”的倡导者。但对于有一定复杂度的项目，优秀的开发者会写详细的规范，因为他们拥有LLM所缺失的独特上下文和关于“如何构建”的明确主张。 “如果编码代理要花 20 到 30 分钟写代码——这相当于传统开发者数小时的工作——你最好花三到四分钟写下清晰的指令。”

二、课程主要模块

2.1 SDD核心理念与对比

课程首先建立SDD的基本框架：以结构化、可执行的规范为唯一事实来源，流程为Specify → Plan → Tasks → Implement → Validate。与Vibe Coding的对比贯穿始终：Vibe Coding 是“模糊Prompt → AI 猜 → 反复改 → 技术债”，SDD 是“先写清晰Spec → AI按Spec生成 → 按Spec验收 → 质量稳定、可审计、可协作”。

2.2 如何写高质量、可被AI执行的Spec

一份合格的Spec需要包含以下要素：

• 功能目标与用户场景：明确“为什么做”和“给谁用”

• 输入/输出格式、数据约束：字段类型、长度、枚举值等

• 错误处理策略：异常码、返回逻辑、边界case

• 验收标准（Given-When-Then可测场景） ：这是判断“做完了没有”的客观依据

• 非功能要求：性能、安全、依赖限制

Spec 不是形式主义模板，而是让AI精准理解意图的沟通工具。

2.3 SpecOps 四阶段工作流

SDD可落地为四个可重复的阶段：

Understand（理解） ：Agent首先分析现有代码库、依赖和架构，而非直接写代码。Agent要先“读懂”现状，才能写出有意义的规范。

Spec（编写规范） ：生成并维护requirements.md、design.md、tasks.md，通过Git追踪，实现跨会话持久化。这对应了“消除上下文衰减”的机制。

Implement（实现） ：Agent按Spec分任务编码，自动校验格式与约束。任务被拆解为小而可审查的单元。

Complete（验收） ：按Spec做对抗性评估和依赖审查，确保符合验收标准。课程特别强调了依赖引入关卡——审查新包的安全性、兼容性。

三、Constitution 与功能开发循环

这样的工作流可以用一条主线概括：创建项目章程 → 功能开发循环 → MVP 交付。

3.1 项目章程（Constitution）

SDD 首先要在项目层面建立一份章程（Constitution） ，定义不可变的标准。这份章程包含使命、技术栈和路线图，作为一个持久化文档，代理会在每次启动时重新阅读。

3.2 功能开发循环：Plan → Implement → Validate

章程建立后，进入功能开发循环。每个功能被隔离在独立分支上，经过 计划、实现、验证 三个步骤，在功能之间留下干净的切换空间，减少上下文切换的困扰。

每个功能循环会产出三份核心文档：plan.md（技术方案）、requirements.md（功能需求）、validation.md（验证标准）。这三份文档共同构成了“规范”的具体载体。

3.3 项目重新规划（Project Replanning）

规范不是一成不变的，项目推进过程中需要根据实际反馈调整方向。这种 “规范-实现-反馈-再规范”的循环，是SDD区别于“一次性大设计”的关键。

3.4 遗留代码支持与Agent可替换性

遗留代码支持：将SDD工作流应用于现有遗留代码库。

Agent 可替换性：将工作流打包为可复用的Agent Skill，使其在跨agent、跨 IDE 的范围内可移植，而不是绑定在某个工具上。

四、实践建议

从项目章程开始，哪怕只是一个简短的文档。 章程不需要一开始就很完整，但需要明确使命、技术栈和路线图这三件事。章程是后续所有规范的基础，也是团队的共识。

投资规范的粒度。 任务拆解的粒度决定了可测试性和范围。如果一个任务无法写出明确的验收标准，它就不应该被交给agent执行。

接受重新规划是常态。 规范不是一次性产物。在功能实现偏离预期时，回到规范层面调整，而不是在代码层面打补丁。

保持 Agent 可替换性。 将工作流打包为 Agent Skill，避免绑定在单一工具上。

警惕流程膨胀。 SDD 增加了前期工作量。对于快速原型和探索性项目，传统的 Vibe Coding 可能仍然更合适。SDD 适用于那些需要可靠性和可维护性的严肃开发任务。

结语

“写规范需要思考，这是艰苦的工作。” 你必须决定要构建什么产品、它有什么功能、技术架构是什么。而没有规范，你就把这些重要的决定交给了coding agent的“一时兴起”，会带来更难以维护的代码。

Spec-Driven Development 代表了 AI 辅助开发的一次重要进化：从“让 AI 写代码”到“让 AI 在明确的规范边界内生成经过验证的实现”。在编码代理能力日益强大的时代，开发者的核心价值正在从编写实现细节转向定义和验证意图。