规格驱动开发实战：吴恩达×JetBrains AI编程新范式

从写代码到写规格：AI编程的新范式

随着智能编程助手（Agentic Coding Assistant）能力的快速提升，开发者与AI协作的方式正在发生根本性转变。吴恩达（Andrew Ng）领衔的 DeepLearning.ai 与 JetBrains 合作推出的这门新课程，聚焦于构建复杂应用的最佳工作流——规格驱动开发（Spec-Driven Development）。

什么是 Agentic Coding Assistant？ 智能编程助手与早期代码补全工具（如 GitHub Copilot 初代）的本质区别在于"Agency"——即自主规划、调用工具、执行多步骤任务的能力。早期工具仅能在光标处补全单行或函数级代码，而 Agentic Coding Assistant（如 Cursor Agent、Claude Code、Devin）能够读取整个代码库、运行终端命令、调用外部 API、在多个文件间协调修改，并根据测试反馈自我纠正。这种能力的跃升源于大语言模型上下文窗口的扩大（从 4K 到 200K+ tokens）、工具调用（Function Calling）能力的成熟，以及 ReAct（Reasoning + Acting）等推理框架的落地。

值得补充的是，ReAct 框架的核心思想是让模型在"推理（Reasoning）"和"行动（Acting）"之间交替迭代：模型先用自然语言思考下一步该做什么（Chain-of-Thought），再执行一个具体的工具调用动作（如读取文件、运行命令），然后根据反馈继续推理。这种"思考-行动-观察"的循环使 Agent 能够处理需要多步骤、跨工具协作的复杂任务，而不仅仅是单次生成文本。正是这种"能干活"而非"只建议"的特性，使得规格驱动开发成为可能——开发者无需亲手实现每一行，只需描述清楚"要什么"。

课程的核心理念直截了当：与其手写代码，不如把精力放在"写下 Agent 尚不具备的上下文"上。你给编程助手一个 Markdown 文件或一段详尽的提示词，说明究竟要构建什么，Agent 便会据此实现。授课讲师由 JetBrains 开发者布道师 Paul Everett 担任，课程对新手尤为友好，并配有完整示例代码。

规格驱动开发的三大核心收益

课程开篇点明了规格驱动开发能立竿见影带来的三个好处，也是理解整套方法论的关键所在。

值得注意的是，规格驱动开发并非凭空而来，它深刻呼应了软件工程中"设计先于实现"的悠久传统。从 1968 年 NATO 软件工程会议确立需求规格的重要性，到极限编程（XP）中的用户故事（User Story），再到行为驱动开发（BDD）中的 Gherkin 规格语言——软件工程界始终在探索如何用人类可读的语言精确表达意图。其中，BDD 的 Gherkin 语法尤为值得关注：它用"Given（给定条件）/ When（当操作发生）/ Then（则期望结果）"的结构来描述软件行为，使得规格本身就能驱动自动化测试，这与今天 AI 编程中"规格驱动代码生成"的理念高度同构。

在 AI 编程语境下，这一传统焕发了新的生命力：过去规格文件的主要读者是人类开发者，如今它的首要"执行者"变成了 AI Agent。这一角色转换带来了深刻的质变——传统规格文件往往因为"写了没人严格执行"而流于形式，而 AI Agent 会字面意义上地"遵守"规格中的每一个技术选型声明，规格的精确度与完整度直接决定了代码输出的质量。传统的"写完规格就扔进抽屉"的困境得以根本性改变——规格首次成为可以被机器直接消费的可执行文档。

用微小的规格变更掌控大规模代码改动

第一个收益是杠杆效应。规格文件中的一句话，往往能牵动数百行代码。课程举了一个典型例子："use SQLite with Prisma ORM"这样一句话，就可能影响数百行代码的生成；把它改成"MongoDB"，同样会产生连锁放大效应。

这一现象背后有着清晰的技术逻辑：数据库选型决策会向上传导至数据模型定义、向下渗透到查询语句写法、向外影响连接池配置和环境变量管理，而 ORM 层（如 Prisma 或 Mongoose）的切换更会同步触发 Schema 语法、迁移脚本和类型定义的全面重写。

以 Prisma 和 Mongoose 的切换为例，这不仅是 API 层面的替换——Prisma 使用声明式的 .prisma Schema 文件和强类型的 TypeScript 客户端，而 Mongoose 则基于 JavaScript 的 Schema 对象和回调/Promise 风格的查询接口；前者面向关系型数据库的表结构思维，后者面向文档数据库的嵌套结构思维。这意味着数据层的每一个 CRUD 操作、每一个关联查询、每一个事务处理都需要重写，而这些变更还会进一步向上影响业务逻辑层对数据结构的假设。在传统开发中，这类架构级变更往往是令人头疼的重构工程；而在规格驱动模式下，它只需修改规格中的一个技术选型声明，Agent 便会自动处理所有下游影响。这意味着编写规格远比手写代码高效。你在规格层面做出的一个决策，会被 Agent 忠实地放大到整个代码库。这种"以小博大"的特性，正是规格驱动开发效率优势的根本来源。

消除会话间的上下文衰减

第二个收益关乎 Agent 的本质局限。课程强调，Agent 是无状态（stateless）的——每次启动都是一张白纸。因此，在 Agent 启动的那一刻就为其加载最高质量的上下文，至关重要。

为什么 Agent 是无状态的？ 大语言模型本身不存储任何会话间的持久记忆——每次推理调用都是独立的，模型"知道"的一切都来自当前输入的上下文窗口（Context Window）。对于 Agentic 系统而言，这意味着每次新会话启动时，Agent 对项目历史、架构决策、团队约定一无所知，除非这些信息被显式地注入到提示词中。

这一局限催生了一个活跃的研究与工程方向：长期记忆（Long-term Memory） 机制。目前主流的解决方案包括三类：一是外化存储（External Storage），将对话历史、决策记录存入向量数据库，通过语义检索按需注入；二是结构化记忆文件，即本文所讨论的规格文件和宪法文档，作为持久化的显式上下文；三是记忆蒸馏（Memory Distillation），定期将长会话压缩为摘要并存储，下次启动时优先加载。部分工具（如 Cursor 的 .cursorrules、Claude 的 CLAUDE.md）已经将第二种方案制度化，允许开发者在项目根目录放置持久化的上下文文件，每次 Agent 启动时自动加载。

从认知科学的角度看，规格文件所解决的问题与人类团队协作中的知识管理问题高度相似。管理学家迈克尔·波兰尼（Michael Polanyi）提出的"隐性知识（Tacit Knowledge）"概念——那些难以言传、存在于专家直觉中的经验——正是规格文件试图系统性外化的对象。资深开发者对"为什么选择这个架构"的判断、对"哪些边界绝对不能跨越"的直觉，如果不被写入规格，就会在每次新开会话时从 Agent 的认知中彻底消失。规格文件充当"记忆锚点"的角色，保存那些不可妥协的核心约束（non-negotiables），从而避免多次会话之间出现上下文衰减。没有规格，你每次都得重新向 Agent 解释项目背景，既低效又容易出错。

提升意图保真度

第三个收益是意图保真度（Intent Fidelity）。规格由你来定义，代表你真实的构建意图；Agent 则在此基础上进行扩展，生成更完整的实施计划。

吴恩达分享了他常用的写规格方法：先与 Claude Code、Gemini 或 ChatGPT Codex 这类 Agent 展开对话，运用自己对各种权衡取舍的判断做出关键架构决策，再让 Agent 把这些核心决策整理成一份 Markdown 规格文件。

"意图保真度"这一概念在提示词工程（Prompt Engineering）领域有着深刻的技术根源。研究表明，语言模型对模糊或欠约束的指令会倾向于"补全"——用训练数据中的统计模式填充空白，这些模式未必符合具体项目的需求。这种现象在模型对齐（Alignment）研究中被称为规格博弈（Specification Gaming）：模型会找到满足字面指令但违背真实意图的捷径，尤其当指令存在歧义时。

高意图保真度的规格通过减少 Agent 的"自由发挥空间"来降低这种风险：当规格明确指定了技术选型、边界条件和验收标准，模型的输出分布就会向开发者真实意图收窄，而非向"平均程序员会怎么做"的统计中心收敛。这也是为什么规格越详细，往往代码质量越稳定——并非因为约束越多越好，而是因为每一个明确的约束都在压缩 Agent 的不确定性空间，减少了模型"自作主张"地填充细节的机会。

为什么不能把决策全交给Agent

课程坦诚指出，写规格是需要深度思考的苦活——你必须决定要构建什么、有哪些功能、采用怎样的技术架构。如果没有规格，你就等于把这些重要决策交给编程 Agent 随机发挥。

吴恩达对此有清醒的判断：如果你只想快速试错、"掷骰子"，这或许可行；但这必然导致可维护性更差的代码，有时甚至产出相当怪异的产品。

他举了一个真实案例：某些团队在开发复杂软件产品时缺乏清晰的规格，结果不同开发者指挥下的多个编程 Agent 虽然都在快速推进，却以相互矛盾的方式修改代码，最终引发大量下游问题。这正是缺乏统一规格的典型代价。

这一现象在软件工程领域有一个经典的理论支撑：康威定律（Conway's Law） 指出，系统设计往往反映了创造它的组织的沟通结构。这一定律最初由 Melvin Conway 于 1967 年提出，微软、Spotify 等科技公司后来将其反向运用——通过先设计目标架构，再调整团队结构来匹配它（即"逆康威演进"）。在多 Agent 并发开发的场景下，如果没有规格文件充当"组织记忆"，各 Agent 的决策就会退化为各自为政的局部最优，最终在代码库层面形成架构熵增（Architectural Entropy）——系统复杂度以超线性速度增长，可维护性急剧下降。规格文件实质上扮演了"虚拟架构师"的角色，在没有人类实时仲裁的情况下，为并发的 Agent 活动提供全局一致的决策依据。

说个细节，吴恩达并非全盘否定简单提示。他明确表示自己也支持"懒惰提示（Lazy Prompting）"——当一句短提示就能搞定时，那再好不过。但对于任何有一定复杂度的项目，他所认识的优秀开发者几乎都会编写详细规格，因为他们拥有独特的上下文和明确的构建主张，这必然优于让缺失这些上下文的大模型随机选择。

一个精辟的成本对比：如果你的编程 Agent 要花 20 到 30 分钟写代码（相当于传统开发者数小时的工作量），那么你花三四分钟坐下来写清楚指令，往往是更划算的投入。

Constitution + 功能开发循环：完整工作流拆解

规格驱动开发的具体流程分为两个层次。

首先是在项目层面制定一部**"宪法"（Constitution）**，用来定义项目中不可变的标准和约束。

为什么叫"宪法"？多 Agent 协作的治理挑战 将项目约束文件称为"宪法"有其深刻的工程隐喻。在多 Agent 或多开发者并行工作的场景下，最大的工程风险之一是"局部最优但全局矛盾"——每个 Agent 在自己的任务范围内做出了合理的技术决策，但这些决策相互冲突，导致代码库的整体一致性崩塌。项目宪法通过明确规定技术栈选择（如"使用 PostgreSQL 而非 SQLite"）、代码风格约定、模块边界、安全约束等"不可违背的原则"，为所有 Agent 提供统一的决策框架。

这一概念与 Anthropic 为 Claude 系列模型设计的"Constitutional AI（宪法AI）"训练方法论存在有趣的呼应：Constitutional AI 通过让模型内化一套明确的原则来约束其输出行为，而项目宪法则通过在上下文中注入约束规则来引导 Agent 的代码生成行为。两者都体现了同一种思路：与其在事后纠错，不如在决策前设置护栏。这本质上是在将架构治理（Architectural Governance）的职责从人类架构师的大脑中提取出来，转化为机器可读的约束规则，使得并发的 Agent 活动能够保持全局一致性。

这份宪法是整个项目的最高准则，确保所有 Agent 的行为保持一致。在实践层面，一份完善的项目宪法通常涵盖以下几个维度：技术约束（使用哪些框架、语言版本、禁止引入哪些依赖）、架构原则（模块如何划分、接口如何定义、数据流向如何规范）、质量标准（测试覆盖率要求、性能基准、安全规范）以及团队约定（命名规范、注释风格、提交信息格式）。这四个维度共同构成了一个完整的"决策空间边界"，使得任何 Agent 在任何时间点启动，都能在同一套约束体系内做出一致的技术选择。

接着是反复迭代的功能开发循环（Feature Development Loops）。每个功能都被隔离在独立分支上，经历"计划（Plan）—实现（Implement）—验证（Verify）"三个步骤。这种隔离机制让每个功能开发都有干净的起点，减少功能间的相互干扰与上下文切换带来的损耗。

值得注意的是，这一"Plan-Implement-Verify"三步循环与测试驱动开发（TDD）的"Red-Green-Refactor"循环有着结构上的深刻相似性：两者都将验证（测试/验证）视为开发流程的内置环节而非事后补丁，都强调小步迭代而非大批量交付。区别在于，TDD 中验证标准（测试用例）由人类提前编写，而规格驱动开发中的验证标准可以从规格文件中自动派生——这是 AI 时代对 TDD 精神的一种延伸与进化。

这套工作流同时支持两类项目：

• Greenfield（全新项目）：从零开始，通过与 Agent 对话制定项目宪法。
• Brownfield（存量代码库）：基于现有代码库生成项目宪法。

Greenfield 与 Brownfield 的差异化挑战 这两个术语来自房地产和城市规划领域，在软件工程中用于描述项目起点的性质。绿地（Greenfield）项目指从零开始的新项目，开发者可以自由选择技术栈和架构，风险在于过度设计（over-specification）——规格写得过于详尽反而可能限制 Agent 找到更优解的空间；棕地（Brownfield）项目则指在既有代码库上继续开发，需要尊重已有的技术债务、依赖关系和历史决策。

在 AI 编程语境下，棕地项目的规格制定面临额外挑战：需要先对现有代码库进行"逆向工程"——让 Agent 扫描代码库、识别既有模式和约束，再生成描述现状的宪法文件。这一过程类似于软件考古学（Software Archaeology），需要从代码本身"挖掘"出当年的设计意图。这也是为什么课程明确区分了两种入口路径，并为棕地场景专门设计了从现有代码库反向生成宪法的工作流。

值得补充的是，棕地项目的"逆向宪法"生成过程本身就是一个颇具价值的知识管理行为：它强迫团队将长期积累在代码注释、口口相传和个人记忆中的架构知识显式化，往往能暴露出那些"大家都知道但从没写下来"的隐形约束，为后续的人机协作奠定更坚实的认知基础。无论哪种情况，后续都通过功能开发循环进行迭代，以小步方式管理版本演进。

课程内容与行业展望

除了核心的规格驱动方法论，课程还会带你编写自己的 Agent Skills（智能体技能），在完整项目中实践，并最终构建一个概念验证（PoC）来自动化整个规格驱动工作流。

从行业角度看，这门课程折射出 AI 编程正从"生成代码片段"向"工程化协作"演进的大趋势。当 Agent 能够连续工作数十分钟、产出相当于数小时人力的代码时，开发者的核心价值正从"写代码"转移到"定义意图、管理约束、把控架构"。

这一转变在职业角色层面有着深远影响：未来的优秀开发者将更接近于"系统架构师 + 质量仲裁者"的复合角色，需要具备清晰表达需求的能力（规格写作）、判断输出质量的能力（代码审查）以及设计验证机制的能力（测试策略），而具体的编码执行将越来越多地由 Agent 承担。从更宏观的视角看，这一转变与历史上每一次编程抽象层级的跃升（从机器码到汇编、从汇编到高级语言、从命令式编程到声明式编程）遵循着同样的规律：每一次抽象层级的提升都将开发者从底层细节中解放出来，转而专注于更高层次的意图表达。规格驱动开发可能正是这一历史进程的最新章节——将自然语言确立为新的编程抽象层，而 AI Agent 则成为将这一层翻译为可执行代码的"编译器"。

规格驱动开发正是对这一转变的系统化回应。对于希望认真使用 AI 构建生产级应用的开发者而言，这套方法论提供了一条清晰可循的路径：先想清楚要构建什么，再让 Agent 去实现。参与该课程制作的还有来自 JetBrains 的 Konstantin Czajker、Zina Smirnova 以及 DeepLearning.ai 的 Isabel Zarro 等多位贡献者。

核心要点