吴恩达新课：规范驱动开发重塑AI编程工作流

在AI编程助手日益强大的今天，如何驾驭这些能在20-30分钟内完成传统开发者数小时工作量的智能体，成为开发者必须掌握的新技能。吴恩达（Andrew Ng）联合JetBrains推出的《规范驱动开发（Spec-Driven Development，简称SDD）》课程，给出了一套系统化的答案。本文基于该课程内容，梳理SDD的核心理念与实战工作流。

什么是规范驱动开发（SDD）

规范驱动开发是当前使用智能体（agentic）编程助手构建严肃应用的最佳工作流之一。这里所说的智能体编程助手，是指具备自主规划、工具调用和多步推理能力的AI编程工具，区别于早期仅提供代码补全的Copilot类产品。代表性产品包括Claude Code、Cursor Agent、GitHub Copilot Agent等。它们能够理解高层需求后自主拆解任务、读写文件、运行测试、调试错误，形成完整的开发闭环。这类工具的兴起源于大语言模型（LLM）在代码生成能力上的突破，以及ReAct（Reasoning + Acting）等智能体框架的成熟，使AI从被动响应转变为主动执行。

SDD的核心思路很简单：与其手写代码，不如给编程智能体一个Markdown文件或一段详尽的提示词，明确说明要构建什么，然后由智能体去实现这份规范（spec）。之所以选择Markdown作为规范载体并非偶然——Markdown是一种轻量级标记语言，具备人类可读性强、版本控制友好、几乎所有开发工具原生支持等特点。更关键的是，当前主流LLM在训练数据中大量接触了Markdown格式文档，因此对Markdown结构的解析和遵循能力远优于其他格式。将规范写成.md文件，既方便开发者在代码评审中追踪变更，也能被智能体高效解析为可执行的上下文指令。

课程讲师、JetBrains开发者布道师Paul Everitt指出，这种方式让开发者的重心从"写代码"转移到"写下智能体尚不知道的上下文"。换句话说，你负责定义问题、成功标准和约束条件，智能体负责补全细节、生成完整方案并落地实现。

规范提升意图保真度

吴恩达强调，写规范本身是一项需要深度思考的"硬活"。你必须决定要做什么产品、有哪些功能、采用什么技术架构。如果跳过这一步，这些关键决策就会被交给编程智能体"随风而定"——这在追求速度、愿意"掷骰子"时或许可行，但往往会导致代码可维护性下降，甚至产出相当古怪的产品。

SDD的三大核心优势

课程明确列出了规范驱动开发能立竿见影带来的三个好处。

用小改动控制大规模代码变更

规范的杠杆效应极为惊人。一句话，比如"使用SQLite搭配Prisma ORM"，可能会影响数百行代码；将其改成"MongoDB"，同样会产生相同规模的下游放大效应。

为了理解这种杠杆效应的力度，值得解释一下这两种技术选型的差异。SQLite是一种嵌入式关系型数据库，无需独立服务器进程，数据以单文件存储，特别适合原型开发和中小规模应用。Prisma则是Node.js/TypeScript生态中最流行的ORM（对象关系映射）工具之一，它通过声明式的Schema定义自动生成类型安全的数据库客户端代码。当规范中将数据库从SQLite改为MongoDB（一种文档型NoSQL数据库），不仅Schema定义方式完全不同，数据建模范式、查询语法、关联处理逻辑都会发生根本性变化，由此产生的下游代码变更可达数百行。这意味着编写和修改规范远比手写代码高效——你用一句话就能撬动整个技术栈的调整。

消除会话间的上下文衰减

智能体本质上是无状态（stateless）的，每次会话都是"失忆"的重新开始。这一特性根植于大语言模型的运行机制：每次API调用本质上是独立的推理过程，模型不会自动"记住"前一次会话的内容。虽然现代LLM的上下文窗口已扩展到128K甚至百万级token，但长上下文下的注意力分配会出现"中间遗忘"（Lost in the Middle）现象，即模型对上下文中间部分的信息检索能力显著下降。此外，跨会话的信息完全丢失。

规范文件的作用，就是在第一时间为智能体加载最高质量的上下文，保留那些不可妥协的核心约束（non-negotiables），从而避免多次会话之间的上下文衰减。它将关键上下文前置加载，确保每次会话都从最高质量的信息起点开始。

提升意图保真度

通过规范，你可以清晰定义问题、成功标准、约束条件等，而智能体则能在此基础上进一步细化，形成更完整的执行计划。这确保了最终产出与你的真实意图高度一致，而非模型在缺失上下文情况下的随机猜测。

缺乏规范导致代码难以维护

吴恩达分享了一个反面案例：他曾见过一些团队在开发复杂软件产品时缺乏清晰规范，结果由不同开发者指挥的多个编程智能体虽然都在快速产出，却以相互矛盾的方式构建代码，最终引发了大量下游的麻烦。

如何写出一份好规范

吴恩达介绍了他常用的写规范方法：先与Claude Code、Gemini或ChatGPT Codex等智能体展开对话，运用自己对不同权衡取舍的判断，做出关键的架构决策；然后让智能体总结核心设计；最后再把这些决策落笔写进Markdown文件。

他特别指出，虽然自己也是"懒惰提示"（lazy prompting）的拥护者——如果一句短提示就能搞定需求，那当然最好——但他所认识的优秀开发者，几乎总是会为任何具有一定复杂度的项目编写详细规范。原因在于：这些开发者拥有独特的上下文和明确的观点，知道该构建什么、如何构建，这份判断远胜于让缺失上下文的大模型去随机选择。

一个简单的成本账：如果编程智能体要花20到30分钟自主写代码（相当于传统开发数小时的工作量），那么你花三四分钟坐下来写清楚指令，通常是非常划算的投资。

SDD的完整工作流

规范驱动开发的工作流分为两个层级。

项目层：制定"宪法"

首先在项目层级制定一部"宪法"（constitution），用来定义那些不可变更的标准。这是整个项目的地基，约束着后续所有开发行为。宪法通常包含技术栈选型、代码风格规范、目录结构约定、安全策略、性能要求等全局性约束。它的作用类似于软件工程中的架构决策记录（Architecture Decision Records, ADR），但以智能体可直接消费的格式呈现。

特性层：迭代开发循环

在宪法之上，开发者通过一个个"特性开发循环"（feature development loop）来推进项目。每个特性被隔离在独立的分支上，遵循**计划（plan）→ 实现（implement）→ 验证（verify）**三个步骤，完成后回归干净的初始状态。这种隔离设计减少了特性之间的相互干扰和上下文切换带来的麻烦。

有意思的是，这套工作流同时适用于两类项目：

Greenfield（全新项目）：从零开始，通过与智能体对话来制定项目宪法。
Brownfield（存量代码库）：基于已有代码库自动生成项目宪法。

Greenfield和Brownfield是软件工程中借用自城市规划的经典术语。Greenfield（绿地）项目指在没有历史包袱的情况下从零构建，开发者拥有完全的技术选型自由度，但也面临架构决策密集的挑战。Brownfield（棕地）项目则指在已有代码库基础上进行开发，需要兼顾遗留系统的技术债务、既有架构约束和团队惯例。在实际企业开发中，Brownfield场景远多于Greenfield。SDD工作流覆盖这两种场景具有重要的实用意义——对于Brownfield项目，智能体可以通过分析现有代码结构、依赖关系和编码规范来自动生成项目宪法，这在传统开发中往往是最耗时的逆向工程工作。

基于存量代码库生成项目宪法

两种场景下，后续都通过特性开发循环进行迭代，并以小批量的方式管理版本。此外，课程还会教你如何编写自己的智能体技能（agent skills），来自动化整个规范驱动的工作流。所谓智能体技能，是指预定义的、可复用的指令集或工作流模板，用于指导AI编程助手执行特定类型的任务。在JetBrains的AI助手生态中，开发者可以将常用的开发模式（如"创建REST API端点"、"编写单元测试"、"执行数据库迁移"等）封装为标准化的技能。这些技能本质上是结构化的提示工程（Prompt Engineering）产物，包含了任务描述、输入输出格式、质量标准和验证步骤。通过编写自定义技能，团队可以将最佳实践编码化，使不同成员在使用智能体时获得一致的输出质量，同时降低重复编写复杂提示词的成本。

写在最后

随着AI编程助手能力的跃升，开发者的核心竞争力正在从"编码能力"转向"表达意图与设计架构的能力"。规范驱动开发的价值，恰恰在于它把开发者的独特判断和领域知识，以结构化的方式固化下来，成为指挥智能体的"权威文档"。

这门由吴恩达与JetBrains联合打造的课程，参与者包括JetBrains的Konstantin Czajkur、Zina Smirnova以及DeepLearning.ai的Isabel Zarro。对于希望建立标准化AI编程工作流、避免踩坑的开发者来说，SDD提供了一套值得认真学习的方法论。正如吴恩达所说：让我们开始写规范吧。