吴恩达新课详解：用规范驱动开发驾驭编程智能体

吴恩达（Andrew Ng）与 JetBrains 合作推出了一门面向新手的实战课程，主讲人为 JetBrains 开发者布道师 Paul Everett，主题聚焦于规范驱动开发（Spec-Driven Development）。这套工作流被认为是当下用智能体编程助手构建严肃应用的最佳方式。本文梳理课程的核心思路，帮助你理解为什么写规范比手写代码更高效。

什么是规范驱动开发

规范驱动开发的核心理念很直接：与其一行行手写代码，不如把精力放在编写智能体尚不具备的上下文信息上。你给编程智能体一个 Markdown 文件或一段详细的长提示词，说清楚要构建什么，智能体就据此实现整个规范。

换句话说，开发者的角色从「代码工人」转向「意图设计者」。你负责思考要做什么产品、需要哪些功能、采用什么技术栈与技术架构，而智能体负责把这些决策落地为可运行的代码。课程强调，这些关键决策不应该完全交给编程智能体随机发挥——那样虽然快，却往往产出难以维护的代码，甚至是奇怪的产品。

规范驱动开发的三大收益

课程指出，采用这套工作流你会立刻感受到三个好处。

用小改动控制大变更

第一个收益是可以通过对规范的微小改动来控制大规模的代码变化。比如一句话「使用 SQLite 配合 Prisma ORM」，可能会影响数百行代码；把它改成「改用 MongoDB」，同样一句话就能触发大范围调整。相比手写代码，修改规范的效率高出许多。

消除会话间的上下文衰减

第二个收益是规范能防止跨会话的上下文衰减，保留那些不可妥协的原则。智能体本质上是无状态的（stateless），每次启动时都需要重新加载上下文，因此在它「开机」时喂给它最高质量的上下文至关重要。规范文件正好承担了这个持久化记忆的角色。

大语言模型的「无状态」特性是理解规范价值的关键。每次新会话开始时，模型对之前的对话、决策和代码完全没有记忆，需要完全依赖当前输入的上下文来理解任务。这与人类开发者形成鲜明对比——人类能在脑中积累项目认知、记住踩过的坑、理解技术债的来龙去脉。规范文件本质上是把这种「项目认知」外部化、结构化，让每次新会话的模型都能在同等起点上工作。没有这样的持久化上下文，智能体在不同会话中可能做出相互矛盾的架构决策，例如第一次用了 REST API，第二次却改用 GraphQL，第三次又换回来，导致代码库逐渐失去一致性。

提升意图保真度

第三个收益是提升意图保真度（intent fidelity）。你定义问题、成功标准、约束条件等要素，智能体则在此基础上扩展出更完整的执行计划。吴恩达分享了自己的常用做法：先和 Claude Code、Gemini 或 ChatGPT Codex 这类智能体对话，用自己对不同权衡取舍的理解来做关键架构决策，然后让智能体把这些决策总结进一个 Markdown 文件。

为什么写规范值得花时间

写规范需要真正的思考，这是一项艰苦的工作。你必须决定要构建什么产品、有哪些功能、用什么技术以及技术架构如何设计。课程坦言，如果没有清晰的规范，就等于把这些重要决策交给编程智能体的「一时兴起」。

吴恩达举了一个真实的反面案例：一些团队在开发复杂软件产品时缺乏明确规范，导致不同开发者指挥的不同编程智能体各自快速构建，但缺乏统一上下文，最终引发大量下游麻烦。

他给出一个实用的判断标准：如果你的编程智能体要独自跑 20 到 30 分钟去写代码（这可能相当于几小时的传统开发工作量），那么花 3 到 4 分钟坐下来写清楚的说明，往往是更划算的投入。他同时也是「懒惰提示（lazy prompting）」的支持者——如果一句短提示就能搞定，那当然很好；但对于任何有明显复杂度的项目，优秀的开发者几乎总会写详细规范，因为他们拥有独特的上下文和明确的构建主张，这比让缺乏上下文的大模型随机选择要好得多。

工作流：宪法与特性开发循环

规范驱动开发在项目层面需要建立一部「宪法（constitution）」，用来定义项目不可变的标准，然后通过特性开发循环（feature development loops）不断迭代。

每个循环把单个特性隔离在自己的分支上，包含**计划（plan）、实现（implement）、验证（verify）**三个步骤，在特性之间留下干净的状态，减少上下文切换带来的麻烦。

这套工作流同时支持全新项目（greenfield）和存量项目（brownfield）：

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

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

「宪法（constitution）」这一概念借鉴了软件工程中的架构决策记录（Architecture Decision Records，ADR）思想，但更偏向于给 AI 智能体阅读而非人类。一份好的项目宪法通常包含：技术栈选型及理由、代码风格与目录结构约定、核心业务规则与约束、明确禁止的实现方式（例如「不使用全局状态」「所有 API 调用必须有错误处理」）。「全新项目（greenfield）vs 存量项目（brownfield）」是软件工程中的常用区分：前者从零起步，自由度高但需要做全部决策；后者要在已有代码约束下工作，需要先让智能体理解现有代码的风格和结构，再生成对应的宪法文档，以确保新功能与历史代码保持一致性。

小结

这门课程传递的核心观点是：在智能体编程时代，写好规范是一种高杠杆行为。用小小的规范改动撬动大规模代码变更、跨会话保持上下文一致、提升意图保真度，再配合「宪法 + 特性循环」的结构化流程，开发者就能既享受智能体的高效率，又不牺牲代码的可维护性。对于想认真用编程智能体构建应用的新手来说，这是一条清晰可落地的入门路径。