规范驱动开发不再手写代码，而是写清楚「你想要的」

与 JetBrains 合作打造　·　主讲：Paul Everitt（JetBrains 开发者布道师）

核心做法：给编码智能体一个 Markdown 文件或一段长提示，把要构建的东西说明白，它就来实现这份规范。

你的工作重心，从「手写代码」转向「写下智能体本身并不掌握的上下文」。

三个立刻能看到的好处

用小改动控制大变更

规范里一句话的调整，可能牵动成百上千行代码。

比如把 Prisma 换成 MongoDB——只改一处，下游被放大执行。写规范因此极其高效，效率远高于直接写代码。

消除会话之间的上下文衰减

规范把「不可妥协的要求」保留下来。智能体是无状态的，所以启动那一刻给它装载最高质量的上下文，非常关键。

提升意图保真度

由你定义问题、成功标准、约束条件等等，智能体再据此展开，形成更完整的计划。

怎么写一份规范

和智能体对话

用 Claude Code、Gemini 或 ChatGPT Codex 这类工具，一起把关键架构选择谈清楚。

带着你的判断做取舍

用什么方式做权衡，取决于你自己的知识与偏好，而不是交给随机。

让智能体归纳成 Markdown

把聊定的关键决策总结成一份 Markdown 文件，这就是你的规范。

代价：写规范是脑力活

这一步没人能替你做

写规范需要思考，而且很辛苦。你必须决定：要做的是什么产品、它有哪些功能、采用什么技术架构。如果跳过规范，这些重要决定就等于交给了编码智能体去随风飘。

想跑得飞快、干脆掷骰子，也许可以接受；但代价是代码更不容易维护，有时还会做出相当奇怪的产品。

一个真实的反面场景

曾有一些团队在做复杂软件产品，却始终没有清晰的规范。结果，不同开发者指挥各自的编码智能体，各自快速推进，方向却互相矛盾，下游问题层出不穷。

完整工作流

项目级「宪法」

先定义不可变的标准，再进入迭代。

特性开发循环

计划

Plan

实现

Implement

验证

Verify

每个特性isolated在自己的分支上，做完就留下一个干净的起点，减少来回切换带来的麻烦与头痛。

绿场与棕场，同一套流程

绿场项目

从零开始，和智能体对话，从无到有制定项目宪法。

棕场项目

已有代码库，就基于现有代码生成项目宪法。

两种情况殊途同归：接下来都进入特性开发循环，以小步方式管理版本演进。

什么时候用「懒提示」

短提示就够了

如果一段简短提示就能达到目的，那很好，懒提示值得提倡。

复杂项目

但真正优秀的开发者，几乎都会为有一定复杂度的项目写下详细规范——因为他们拥有独特上下文，对做什么、怎么做有明确主张。

如果编码智能体要跑上二十分钟到半小时，可能相当于传统开发者数小时的工作量，那你不如先坐下来花三四分钟，把指令写清楚。

—— 课程观点

行动建议

项目一开始就写下「宪法」，明确不可变的标准。
每个特性走一遍计划、实现、验证，并单独开分支。
把架构决策交给对话，把决策结论沉淀成 Markdown 规范。
需要长期运行的任务，先花几分钟把指令写清楚再交给智能体。
尝试编写自己的智能体技能，把规范驱动的工作流自动化。

本课程由 JetBrains 团队与 DBL 的多位贡献者共同完成。下一步：动手写下你的第一份规范。

规范驱动开发 · 课程笔记