编程智能体可以快速开发功能，但速度并不能告诉它产品应该是什么样子。规格驱动开发（SDD）要求开发者在智能体修改代码之前，先将意图、约束和验收标准写成规格文档。智能体负责实现；开发者保留对架构的控制权，并决定成果是否可以交付。
为什么再写一条提示词可能解决不了问题
非正式的提示词驱动开发，通常被称为氛围编程（vibe coding），或许足以应付一个简单、用完即弃的任务。但当项目需要在多个文件中保持设计决策一致时，这种方式就不那么可靠了。先要求做一个按钮，再抱怨它太大，或许能改好这个按钮，却无法为应用的其余部分确立一条持久的规则。
反复纠错还会让对话历史占满智能体的上下文窗口，也就是它一次能够利用的有限信息空间。随着对话历史增长，项目最初的意图会越来越难找回。编程智能体能够检查文件、运行命令，并在整个工作区内修改内容，因此一条不明确的指令可能影响远不止一条回复。
▲ 即兴提示词与结构化规格
规格文档为这些决策提供了更稳定的载体。它说明功能必须做什么、为什么要做，同时将适当的实现选择留给智能体。对一条技术约束做简短修改，就可能引发数百行代码的改动；这种杠杆效应使得在实施前审查约束尤为重要。
建立项目章程
从受版本控制的 /specs 目录中的三个 Markdown 文件开始。它们共同构成项目章程：一套共享的基准，开发者可以随着需求变化有意识地修订。
▲ 项目章程的三份文档
mission.md定义产品的目标、面向人群和预期行为。tech-stack.md记录获准使用的技术和架构约束。roadmap.md将工作划分为有先后顺序的阶段。每个小阶段包含一到三个可独立交付的功能，比一项笼统的大请求更容易检查。
一个示例项目是为过度劳累的 AI 智能体设计的讽刺性诊所应用。最初的技术选择包括 TypeScript、用于服务器的 Hono，以及用于数据存储的 SQLite。这些选择应写进项目文档，而不只是留在与智能体的对话里。开发者将生成的文件作为 Git 差异进行审查，并在开始功能开发前提交。
智能体可以通过就范围和技术选择提出结构化问题，协助起草项目章程。但重要决策仍需由开发者敲定。目标不是规定每个变量名，而是明确项目使命、边界、依赖和标准。
让每个功能经过三个阶段
将路线图中的每个阶段视为一个受控循环，而不是一场持续不断的对话。把需求、任务计划和检查项分别放在不同文件中，并在进入下一阶段前审查当前阶段。
- 制定规格。 创建功能分支，编写
requirements.md、plan.md和validation.md。需求文件定义功能及其边界；计划文件安排工作顺序；验证文件说明如何判断结果。让智能体在写文件前先澄清尚未确定的选择。 - 实施。 审查并提交功能规格，然后指示智能体执行计划。对于直接的项目搭建工作，可以批量执行。数据库迁移等敏感改动则值得拆成更小的任务组，并加以仔细检查。
- 验证。 运行计划中的检查，审查代码差异，并亲自测试行为。智能体报告测试通过，不能替代人工审查。如果最终采纳的实现与规格不一致，就更新规格，然后提交并合并该功能。
在最初的服务器阶段，计划涵盖依赖、开发脚本、首页和验证。智能体运行了 TypeScript 检查，并测试了本地端点；开发者也检查了页面渲染效果。审查期间，开发者使用编辑器的重构工具，将页面各部分移入独立的组件文件。这项人工改进使实现与书面计划出现了偏差，因此在合并分支前，功能文档也得到了更新。
最后这一步很重要。如果代码变了，规格却没有变，下一轮智能体会话就可能遵循过时的项目描述。在 Claude Code 中，开始新的功能阶段前使用 /clear 清除对话历史，可以帮助智能体从已提交的项目文件出发，而不是依赖过时的聊天上下文。
在阶段之间重新规划，并对大型改动复查
项目章程是基准，并不禁止变更。在功能分支之间，暂停下来审视项目现在需要什么。在诊所应用的例子中，一次重新规划加入了 Vitest 测试。另一则模拟的利益相关方更新指出，该应用 40% 的用户通过移动浏览器访问，因此需要加入移动优先的样式要求并调整视口设置。将这些决策记录在技术标准中，有助于让后续功能与之保持一致。
审查力度也应与改动规模相匹配。对于一个规模较大的功能，三个并行工作的智能体审查者分别检查了 TypeScript、数据库架构和 HTML 无障碍性。它们发现的问题包括缺少启用 SQLite 外键约束的设置，以及不必要的运行时依赖。智能体修复了这些问题，但它的审查并不能取代开发者的判断。
后续一次构建将路线图的几个阶段合并为一份包含十项任务的最小可行产品计划。运行中的应用支持预期的预约流程，但反向对照需求检查时发现了一个缺口：无效的预约输入返回 HTTP 200，而规格要求返回 HTTP 400。界面能正常工作，并不意味着每项验收标准都已满足。将实现与规格重新对照，揭示了第一轮检查遗漏的问题。
在现有代码中采用同样的方法
不必创建新代码仓库。对于没有规格文档的现有项目，可以让智能体检查代码、软件包配置、README 和任务清单。在提交生成的使命、技术栈和路线图文件前，应对照应用的实际行为审查这些文件。之后，下一个维护任务就可以遵循同样的制定规格—实施—验证循环。
可复用的 Agent Skills 可以将重复性工作打包，例如准备功能分支和起草规格文件。由于技能可能运行命令，安装前应检查其代码。将项目决策保存在 Markdown 和 Git 中，也让工作流程更容易在 Claude Code、OpenAI Codex 等智能体之间迁移；聊天历史不必成为唯一的项目记录。
从小处着手，保留人工审查
写好三份项目章程文件，选择路线图中一个范围狭窄的阶段，并在要求智能体编码前定义需求、计划和验证标准。检查最终的代码差异与运行行为，让文档与已采纳的改动重新保持一致，并在下一阶段开始前重新规划。SDD 的实际价值不在于让智能体永不出错，而在于为开发者提供书面依据，以指导其工作并发现遗漏。