规范驱动开发：让AI编程代理从"氛围编程"回归工程

当你听到"智能体编程"（agentic coding）时，脑海里浮现的可能是"氛围编程"（vibe coding）——写一句"给我做个按钮"的提示词，然后祈祷模型给出满意的结果。这门由 DeepLearning.ai 与 JetBrains 联合出品的课程，讲师由 JetBrains 开发者布道师 Paul Everett 担任，Andrew Ng 参与引导，系统地介绍了一种更严肃的替代方案：规范驱动开发（Spec-Driven Development，简称 SDD）。

核心理念很简单：与其手写代码，不如把代理不知道的上下文写清楚。你给代理一个 Markdown 文件或一段详细提示，描述"要构建什么"，由它负责"如何构建"的实现细节。

为什么规范优于氛围编程

氛围编程见效快，但产出的是一次性代码，技术债不断累积。你与代理的对话历史甚至不会被保存下来，做个按钮尚可，一旦扩展到大型持续演进的项目就会失控。

课程把 SDD 定义为对"无监督 AI 生成混乱状态"的专业回应——它是一次范式转变，将解释"是什么"和"为什么"的规范，与解释"怎么做"的实现解耦。规范成为人与代理之间、也是人与人之间的一份契约。

Andrew Ng 在课程中强调了一个务实的判断标准：如果一个短提示就能完成需求，那当然好，他本人也是"懒惰提示"的支持者。但只要项目具备一定复杂度，优秀的开发者几乎总会写详细规范。原因在于开发者拥有独特的上下文和对如何构建的主张，这远优于让缺乏这些信息的 LLM 随机选择。他给出一个很有说服力的时间账：如果代理要跑 20 到 30 分钟写代码（相当于传统开发数小时的工作量），那么花 3 到 4 分钟写清楚指令通常更划算。

规范带来的三大收益

SDD 的价值可以浓缩为三点，课程反复强调：

用小改动控制大变更。规范里一句话——比如"用 SQLite 配 Prisma ORM"——可能对应数百行代码。把它改成 MongoDB，同样能触发下游的放大式修改。写规范因此比写代码高效得多。

消除上下文衰减。代理是无状态的，随着多轮会话进行，上下文窗口被填满，代理越来越容易出错。规范在会话之间乃至不同代理之间持续存在，把代理锚定在实现功能所需的核心上下文上。

提升意图保真度。规范逼迫你在代理动手前先定义问题、成功标准、约束条件和用户流程，让产出代码更贴合你的目标。这正是"氛围编程出一堆垃圾"与"工程化出可用产品"之间的分水岭。

课程还用了一个恰当的类比：编译器把可读源码转换成机器码，而 SDD 引导代理把规范转换成源码——只不过规范是人类语言，更易理解。

宪法与功能开发循环

SDD 的工作流分两个层次。首先是项目级的"宪法"（Constitution），定义不可变的标准，包含三大支柱：

• 使命（Mission）：解释"为什么"，即项目愿景、目标受众、范围。
• 技术栈（Tech Stack）：团队对开发部署技术与约束的共识。
• 路线图（Roadmap）：一份活文档，把工作拆成一系列阶段。

宪法与很多开发者常用的顶层 agents.md 文件目的相近，但它与代理无关（agent-agnostic）且更结构化。绿地项目（全新项目）通过与代理对话来撰写宪法；棕地项目（既有代码库）则让代理基于现有代码逆向生成宪法。

其次是可重复的功能开发循环：规划 → 实现 → 验证。每个功能在独立分支上隔离进行，功能之间进入"重新规划"阶段——修订宪法、更新路线图，甚至改进流程本身。这种在功能间保持干净分界的做法，能显著降低上下文切换的头痛。

课程用建筑师的比喻定位开发者的新角色：你给建造者详细图纸，然后放手让他们施工。你负责设计、监督、审查与验收，避免告诉建造者具体怎么干活，专注于提供他们不知道的上下文。一句话概括——代理是肌肉，规范是大脑。

「绿地项目」与「棕地项目」是软件工程中描述项目起点的常见术语。绿地（Greenfield）指从零开始、没有任何历史遗留约束的全新项目，团队可以自由选择架构与技术栈；棕地（Brownfield）则指在已有代码库或系统上继续开发，需要兼容既有决策、技术债与团队惯例。这一区分在 SDD 语境下尤为重要：绿地项目可以通过与代理的对话来「从头定义」宪法，而棕地项目必须先让代理读懂现有代码的隐性规则，再反向推导出宪法——这个逆向生成过程本身就是对代理理解力的一次考验，也是把隐性知识显性化的关键步骤。

Agent Clinic 实战：从宪法到 MVP

课程用一个名为 Agent Clinic 的示例项目贯穿始终——一个供 AI 代理"看病"的诊所（对幻觉、上下文腐烂、记忆问题等"病症"进行治疗），是对经典学习项目 Pet Clinic 的诙谐戏仿。技术栈为 Next.js 后端加 React 前端，环境使用 WebStorm IDE 搭配 Claude Code 代理。

实战流程颇具启发性。撰写宪法不是独自完成，而是与代理对话，代理会提出你没考虑过的架构问题、已有现成方案的外部包、以及速度与数据保真度之类的权衡。开发者被反复提醒：要人在环路（human-in-the-loop）中审查小改动，不要直接手动编辑文件，而应让代理修改，以保持规范、代码、README 等所有制品同步，避免"漂移"（drift）。

第一个功能 "Hello Hono" 走完了完整的规范-计划-实现-验证循环。课程特别指出一个细节：审查时应聚焦于"功能是否符合规范"这类高层关注点，而非纠结用了哪个 CSS 类或变量名。当发现代码里的问题往往源自计划里的疏漏时，正确做法是让代理同时修正规范和实现，而不只是打补丁。

随着项目推进，课程演示了几个进阶技巧：让代理生成多个子代理（sub-agents）做深度审查，既给代理更多思考空间，又能保护主代理的上下文窗口不被污染；面对产品经理临时提出的"40% 用户在移动端、需要响应式设计"这类变更，用判断力决定是在重新规划阶段直接实现（小改动），还是排进路线图作为独立阶段（大改动）。最终，团队在两个功能完成后大胆地一次性实现剩余路线图，把 MVP 当作对宪法和规范质量的极限测试。

用技能与标准把工作流工程化

课程后半段转向自动化与可移植性。反复输入相同的功能规范提示词很繁琐，可以借助代理的"技能创建器"把它封装成一个 Agent Skill（一个开放标准，为代理提供新能力与专属上下文）。技能可以是项目级或全局级，验证步骤中的更新 README、linting、格式化、测试运行等质量检查都能打包成"验证技能"。

一个值得关注的行业趋势是：过去扩展代理的通用方式是 MCP（Model Context Protocol），例如广受欢迎的 Context 7 就是把最新的包文档注入代理上下文，让代理了解 React 9.2 而非停留在 9.0。但课程指出，越来越多场景中，调用 CLI 工具的技能能以更少的设置和更少的上下文消耗完成同样的目的，Context 7 本身现在也建议采用"技能调用 CLI"的方式。这一从 MCP 服务器转向"技能 + CLI"的趋势正在加速。

开源生态也提供了现成方案：GitHub 的 SpecKit 和 Fission AI 的 Open Spec 都在尝试形式化 SDD 工作流，后者的"提议-探索-应用-归档"流程与课程的规划、实现、重新规划一一对应。

在可移植性上，课程强调让工作流独立于任何单一代理或 IDE。通过 MCP（外部工具）、agents.md（规则）、Agent Skills（可复用工作流）和 ACP（代理-客户端协议）这些标准，可以在 Claude Code、OpenAI Codex、OpenCode 等代理之间自由切换而保留工作流。ACP 的架构借鉴了 LSP，其注册表能自动完成代理的查找、安装与在客户端（如 JetBrains IDE）内的集成。

MCP（Model Context Protocol）是 Anthropic 于 2024 年末提出并开源的一套标准协议，旨在让 AI 代理以统一方式连接外部工具、数据源和服务。其设计类似 USB 接口：一旦某个工具实现了 MCP 服务器端，任何支持 MCP 客户端的代理都能直接调用，无需为每个代理单独适配。Context 7 是其中知名度较高的实现之一，通过 MCP 把第三方库的最新文档实时注入代理的上下文，解决了 LLM 训练数据存在截止日期、无法感知最新 API 变化的问题。然而 MCP 服务器需要独立运行进程、消耗额外上下文配额，并增加配置复杂度；而「技能调用 CLI 工具」的方式直接复用本地已安装的命令行程序，在许多轻量场景下开销更小、更易维护，这也是文中提到行业出现迁移趋势的根本原因。

ACP（Agent Communication Protocol）是另一个值得关注的新兴标准，其设计思路借鉴了编辑器领域广泛采用的 LSP（Language Server Protocol）。LSP 把「语言分析能力」与「编辑器」解耦，使得同一个语言服务器可被 VS Code、Vim、JetBrains 等任意编辑器复用；ACP 则把「代理能力」与「客户端 IDE」解耦，通过注册表机制实现代理的自动发现与集成，从而让开发者在切换代理时不必重新配置整套工作流。

写在最后

规范驱动开发把工作重心从"怎么做"转移到"是什么"和"为什么"。由于模型和代理进化极快，你不该把工作流绑死在某一个工具上——标准化正是抵御这种锁定的关键。

用课程结尾的话说：你今天写下的规范，会成为项目明天的记忆。在代理能几分钟写出数小时代码量的时代，让人类继续做那个手握蓝图的架构师，或许才是"把工程带回来"的真正含义。