吴恩达新课：规范驱动开发重塑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从被动响应转变为主动执行。要理解这一跃迁的深度，值得回溯智能体编程助手的技术演进脉络。GitHub Copilot于2021年发布时，基于OpenAI的Codex模型，主要提供行级或函数级的代码补全，其工作模式本质上是单轮推理——给定上下文前缀，预测最可能的代码续写。而2024-2025年涌现的智能体编程助手则融合了函数调用（Function Calling）、工具使用（Tool Use）和多轮规划能力，能够在一次任务中自主执行数十甚至上百步操作。这一跃迁的关键推动力包括：GPT-4、Claude 3.5/4等模型在代码推理能力上的质变；上下文窗口从4K扩展到128K乃至百万级token；以及模型对结构化输出和工具调用协议的原生支持。

ReAct框架由Princeton大学和Google于2022年联合提出，其核心思想是让LLM交替进行推理（Reasoning）和行动（Acting）：模型先生成一段思维链分析当前状态，再决定调用哪个外部工具，获取工具返回的结果后继续推理，如此循环直至任务完成。这一范式突破了传统链式思维（Chain-of-Thought）仅在文本层面推理的局限，赋予了模型与外部环境交互的能力。在编程场景中，这意味着智能体可以读取文件→分析代码结构→编写修改方案→执行代码→观察运行结果→修复错误，形成完整的自主开发闭环。

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

从工程实践的角度看，Markdown的优势还有更深层的考量。Markdown文件天然兼容Git的diff和merge机制，团队成员对规范的每次修改都会留下清晰的变更记录，这对于追溯架构决策的演化过程至关重要。此外，Markdown的层级标题结构（#、##、###）恰好为LLM提供了天然的语义分段，使模型能够高效定位与当前任务相关的规范片段，而不必逐字处理整个文档。相比之下，Word文档的二进制格式无法被版本控制系统有效追踪，YAML/JSON虽然机器可读但人类编辑体验较差且容易因格式错误导致解析失败。

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

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

SDD的三大核心优势

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

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

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

为了理解这种杠杆效应的力度，值得解释一下这两种技术选型的差异。SQLite是一种嵌入式关系型数据库，无需独立服务器进程，数据以单文件存储，特别适合原型开发和中小规模应用。Prisma则是Node.js/TypeScript生态中最流行的ORM（对象关系映射）工具之一。ORM是连接面向对象编程语言与关系型数据库的桥梁，它将数据库表映射为编程语言中的类和对象，使开发者可以用编程语言原生语法而非SQL来操作数据库。Prisma的独特之处在于采用声明式的Schema语言定义数据模型，然后自动生成完全类型安全的数据库客户端代码，在编译阶段即可捕获查询错误。

当规范中将数据库从SQLite改为MongoDB（一种文档型NoSQL数据库），涉及的不仅是连接配置的变化——关系型数据库强调范式化设计和外键约束，而MongoDB采用文档嵌套模型，鼓励数据反范式化以优化读取性能，两者的数据建模哲学截然不同。Schema定义方式、数据建模范式、查询语法、关联处理逻辑都会发生根本性变化，由此产生的下游代码变更可达数百行。这意味着编写和修改规范远比手写代码高效——你用一句话就能撬动整个技术栈的调整。

消除会话间的上下文衰减

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

这一现象由斯坦福大学等机构在2023年的研究中系统揭示。研究表明，即使LLM拥有超长上下文窗口，其对信息的检索准确率呈现明显的U型曲线——位于输入开头和末尾的信息被正确利用的概率远高于中间部分。这意味着简单地将大量信息堆砌进上下文并不能保证智能体有效利用这些信息。此外，跨会话的信息完全丢失，进一步加剧了上下文断裂的问题。

智能体的无状态特性催生了一个新兴的技术方向——上下文工程（Context Engineering）。这一概念由Shopify CEO Tobi Lütke等人在2025年推广，其核心理念是：AI应用的质量不再仅取决于模型能力，更取决于如何为模型构建和管理上下文。上下文工程涵盖了信息选择（决定哪些信息应进入上下文）、信息排序（利用注意力分布特征优化信息位置）、信息压缩（在有限窗口内最大化信息密度）和信息持久化（跨会话保存关键上下文）等子问题。SDD中的规范文件，本质上就是上下文工程的一种核心实践范式。

规范文件的作用，就是在第一时间为智能体加载最高质量的上下文，保留那些不可妥协的核心约束（non-negotiables），从而避免多次会话之间的上下文衰减。SDD中将规范作为上下文的前置加载策略，本质上是在利用Lost in the Middle这一认知：将最关键的约束和决策放在上下文的显著位置（通常是开头），确保模型优先注意到并遵循这些信息。每次会话都从最高质量的信息起点开始，而非依赖模型对历史对话的模糊记忆。

提升意图保真度

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

吴恩达分享了一个反面案例：他曾见过一些团队在开发复杂软件产品时缺乏清晰规范，结果由不同开发者指挥的多个编程智能体虽然都在快速产出，却以相互矛盾的方式构建代码，最终引发了大量下游的麻烦。这种情况在多人协作的团队中尤为突出——当每个开发者使用各自的隐式假设指导智能体时，产出的代码在命名规范、错误处理模式、状态管理策略等方面可能完全不一致，导致集成时的冲突成本远超各自独立开发时节省的时间。

这一问题的根源在于，AI智能体放大了传统开发中"隐式约定"的脆弱性。在传统团队中，资深开发者通过代码评审、结对编程和口头约定来传递编码惯例，新人通过阅读存量代码逐渐内化团队风格。但当智能体介入后，每次会话都是一个缺乏团队记忆的"新人"，它只能依赖被显式写入的规范，无法通过耳濡目染习得隐性知识。项目宪法在这种场景下扮演了"单一事实来源"（Single Source of Truth）的角色，确保所有智能体在相同的约束框架下工作，从根本上解决多智能体协作的一致性问题。

如何写出一份好规范

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

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

一个简单的成本账：如果编程智能体要花20到30分钟自主写代码（相当于传统开发数小时的工作量），那么你花三四分钟坐下来写清楚指令，通常是非常划算的投资。从投入产出比来看，这三四分钟的规范编写时间不仅能显著降低智能体的返工概率，还能减少后续人工代码审查和修正的时间成本，整体开发效率的提升往往是数量级的。

SDD的完整工作流

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

项目层：制定"宪法"

首先在项目层级制定一部"宪法"（constitution），用来定义那些不可变更的标准。这是整个项目的地基，约束着后续所有开发行为。宪法通常包含技术栈选型、代码风格规范、目录结构约定、安全策略、性能要求等全局性约束。

它的作用类似于软件工程中的架构决策记录（Architecture Decision Records, ADR），但以智能体可直接消费的格式呈现。ADR是Michael Nygard在2011年提出的实践，每条记录以简短文档形式捕获一个重要的架构决策，包含上下文、决策内容、后果和状态。ADR已被众多工程团队采纳为知识管理工具，但它主要面向人类读者。SDD中的项目宪法可以视为ADR的智能体友好版本——它不仅记录了"为什么这样决策"，还以智能体可直接执行的格式规定了"如何遵循这些决策"。这种从文档化到可执行化的转变，是AI原生开发流程的重要特征。

特性层：迭代开发循环

在宪法之上，开发者通过一个个"特性开发循环"（feature development loop）来推进项目。每个特性被隔离在独立的分支上，遵循**计划（plan）→ 实现（implement）→ 验证（verify）**三个步骤，完成后回归干净的初始状态。

这种隔离设计与Git Flow、GitHub Flow等成熟的版本管理实践一脉相承，但在AI编程场景下其意义被进一步放大。由于智能体可能在短时间内产生大量代码变更，如果多个特性在同一分支上并行开发，不仅会造成合并冲突的指数级增长，还会污染智能体的上下文——它可能将未完成特性A的半成品代码误认为是项目的稳定状态，从而在开发特性B时做出错误假设。小批量版本管理还有助于在智能体产出偏离预期时快速回滚，将损失控制在单个特性的范围内。

其中验证步骤值得特别关注。这一环节与经典软件工程中的红-绿-重构（Red-Green-Refactor）测试驱动开发（TDD）循环形成有趣的呼应。TDD要求先编写失败的测试（红），再编写最少的代码使测试通过（绿），最后重构代码结构。SDD的验证步骤同样强调在实现完成后立即验证，但其验证范围更广——不仅包括自动化测试，还包括规范符合度检查，即智能体产出的代码是否忠实遵循了规范中定义的约束。这种规范符合度验证在传统开发中几乎不存在，因为人类开发者编写的代码天然反映了自己的设计意图，但智能体可能在执行过程中偏离规范的隐含要求。

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

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

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

两种场景下，后续都通过特性开发循环进行迭代，并以小批量的方式管理版本。此外，课程还会教你如何编写自己的智能体技能（agent skills），来自动化整个规范驱动的工作流。

所谓智能体技能，是指预定义的、可复用的指令集或工作流模板，用于指导AI编程助手执行特定类型的任务。在JetBrains的AI助手生态中，开发者可以将常用的开发模式（如"创建REST API端点"、"编写单元测试"、"执行数据库迁移"等）封装为标准化的技能。这些技能本质上是结构化的提示工程（Prompt Engineering）产物，包含了任务描述、输入输出格式、质量标准和验证步骤。

提示工程本身已经历了从手工艺到工程化的演进。早期的提示工程依赖个人经验和试错，而智能体技能的出现标志着提示工程进入了软件工程化阶段——技能被版本控制、测试验证、团队共享，如同传统开发中的代码库和CI/CD流水线。这种趋势还催生了"提示即代码"（Prompt as Code）的理念：将提示词纳入代码仓库管理，与应用代码一起经历评审、测试和部署流程，从而确保AI辅助开发的可重复性和可审计性。通过编写自定义技能，团队可以将最佳实践编码化，使不同成员在使用智能体时获得一致的输出质量，同时降低重复编写复杂提示词的成本。

写在最后

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

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