让Claude Code少靠猜测：规格驱动开发实战流程

让AI编程智能体“做一个75天健身挑战的记录应用”，几秒钟后你多半就能拿到一个能运行的应用。但这句请求里埋着几十项决定，比如漏掉一天会怎样、数据存在哪里，而你对这些决定没有任何发言权。智能体会悄悄做出决定，你要等代码写好之后才知道。规格驱动开发（SDD）把这个顺序倒了过来：先把决定写进简短的文件并加以批准，然后才让智能体动手构建。写代码的仍然是AI，改变的是由谁决定、何时决定。下面介绍这一循环在Claude Code中如何运转，以及什么情况下不值得专门写规格。

一句提示词替你做了哪些决定

在一次测试中，Claude Code在Claude Desktop应用里以Auto mode运行，这是一种执行工具调用时不停下来等待批准的权限设置；它在一个空文件夹里只收到了上面那句提示词。它一个问题也没问。它先加载了frontend-design技能，也就是一组打包好的任务指令，实际上等于自行认定用户需要图形界面。随后，它只生成了一个index.html文件，并把这个含糊的请求理解为知名的75 Hard健身挑战，把每天两次锻炼、遵守饮食计划、喝1加仑水、读10页书和拍一张进度照片直接写死在代码里。

直到最后，Claude才在“Things to know”下列出它的假设，比如严格模式和仅在浏览器中存储数据。到那时，这些规则已经成了代码。在实际使用中，这类假设往往要很久以后才会暴露出来，比如到了第13天，连续记录在毫无预警的情况下被重置。

氛围编程出问题的五个地方

氛围编程（vibe coding）是指用日常语言描述想要什么，其余部分交给AI去猜，再通过聊天修正结果。这种方式很快，但开发者只能被动应对AI已经做出的选择，由此会带来五个问题：

这五个问题有一个共同的根源：关键需求和设计决策从未被写下来。把提示词写得更长也无济于事，因为凡是没写进去的部分，模型照样会自行补上。不过，对于风险低、用完即弃的工作，比如快速的概念验证、搭建样板代码、制作原型或简单的个人网站，氛围编程依然适用，在这些场景下写正式规格只会徒增负担。

规格就像一张签了字的施工单

规格（spec）是specification的缩写，是开发者与AI之间就要做什么、为什么做而达成的书面约定。它就像承包商在盖房子之前拿到的签字施工单：单子上没写的内容都会在现场临时决定，施工方换成AI，道理也一样。一份有用的规格会写明用户、核心目标、应用的限制，以及软件不做什么。至于怎么做，比如文件名和数据结构，则交给AI决定。AI会根据批准后的规格起草一份带编号的计划，开发者在写任何代码之前先审阅这份计划。在这个阶段改正一条错误规则，只需回复一次；等代码写好后再改，就意味着代价高昂的重构。

这并不是瀑布式开发。瀑布式开发要提前花几个月规划整个项目，而SDD运行的是以单个功能为单位的短循环。智能体每次的表现都不会完全相同，但一份严谨的规格能缩小它的选择范围，让它少猜很多，即使错误永远不会降到零。

规格文件如何组织

所有内容都放在顶层的specs文件夹中。三个基础文件只需写一次；之后每个功能在features下各有一个带编号的文件夹，里面放着属于它自己的三个文件。

验证条件必须可以观察，比如在空表单上点击Start，确认没有保存任何内容。之后的工作就变成一个循环：挑选路线图上的下一项，编写它的规格，批准，让AI构建，验证，然后标记为完成。同样的循环在Cursor或Codex中也适用。

▲ 基础文件与按功能划分的规格文件夹

通过访谈打好基础

绿地（greenfield）项目是指从一个既没有代码、也没有提交记录的空文件夹起步的项目。Claude在空文件夹中创建Git仓库后，第一条提示词就立下了明确规则：先不要写代码，而是围绕愿景、技术栈和路线图，一次一个问题地访谈开发者；路线图最多六个功能，每个功能都要能在一次工作时段内通过浏览器完成测试。让Claude使用它的AskUserQuestion工具后，访谈就变成了带推荐答案的选择题。

Claude把路线图六个位置中的三个留给了必备功能：今日打卡、显示“75天中的第N天”的天数计数器，以及漏掉一天后的重新开始处理。其余位置分给了进度网格、完成界面以及备份的导出和导入；由于所有数据都只保存在浏览器里，备份尤为重要。用氛围编程做出的应用允许用户勾选过去任意一天，而这份规格只允许编辑昨天。技术栈最终定为纯HTML、CSS和JavaScript，不用框架，也没有构建步骤，这些都在应用代码出现之前就已敲定。这个例子为了节省时间直接采用了推荐答案；真实项目则应认真考虑每一个问题。

每个功能都走两条提示词的循环

此后，每个功能都会依次经过同一对提示词。规划提示词生成规格文件，经审阅后提交；实现提示词在全新的对话中依据这些文件进行构建，只有在测试和人工检查都通过之后，才会合并该功能。

规划：先访谈，再写三个文件

规划提示词让Claude Code从roadmap.md中挑出下一个尚未构建的功能，按命名规则创建分支（例如feature/1-todays-check-in），并在不写代码的前提下访谈开发者。对于第一个功能“今日打卡”，这一步敲定了若干细节：勾选的项目原地变暗；过了午夜切换到新的一天；Playwright测试在Chromium和WebKit上运行，并使用Pixel 7和iPhone 15的移动设备配置。

产出包括：写有R1至R12各项需求及排除事项的requirements.md；包含16个自动化测试场景和8步人工检查流程的validation.md；以及载明构建顺序和一条风险提示的plan.md。风险提示指出，第一个功能还要承担项目搭建工作，因此如果一次会话拖得太久，应在第4步、也就是得到一个可用的清单时暂停。基础文件中的疏漏会波及这三个文件，所以要先审阅基础文件。

构建：清空对话，再依据规格实现

提交规格后，开发者运行/clear清空了对话。项目状态保存在由Git管理的Markdown文件中，而不是聊天记录里，因此无论是新会话还是其他队友，都能接着做下去。实现提示词要求Claude Code逐步执行plan.md，只构建requirements.md中规定的内容，运行validation.md中的全部测试，并报告仍需人工检查的项目。

38项Playwright测试全部通过，但Claude Code仍把路线图上的该项留作未完成，等待人工检查。直到在本地服务器上勾选完六项任务、页头显示“Day complete”之后，Claude才提交、合并并把该功能标记为已完成。第二个功能沿用了这两条提示词，通过了118项测试。Playwright会增加搭建工作，但与单纯手动点击检查相比，它是强大得多的安全网。即便如此，仅靠自动化测试仍然不够，在验收之前应由人检查界面。

▲ 自动化测试后的人工检查

把重复使用的提示词做成技能

为了避免每做一个功能都粘贴一长段提示词，规划提示词被做成了一个Claude Code技能。技能是一组有名称、保存在磁盘上、可作为命令运行的指令。这个技能保存在.claude/skills/feature-spec/SKILL.md，它会找到路线图上的下一项、创建分支、进行访谈，并在不改动应用代码的情况下写出三个规格文件。重启桌面应用后，输入/feature-spec即可开始下一个功能。技能是让智能体了解项目的四种方式之一，另外三种是：最先加载的CLAUDE.md或AGENTS.md中的常设规则、拥有独立上下文窗口的审查智能体，以及引入外部上下文和工具的MCP服务器。

为现有代码库补上规格

现实中的大部分工作发生在棕地（brownfield）项目中，也就是没有规格的现有代码库，这时基础文件要从代码中提炼。这里的例子是一个75天健身记录的渐进式Web应用，即一种可安装的Web应用，配有FastAPI后端和自动化测试。

1. 让Claude Code在不改动代码的前提下检查代码仓库和测试，并根据发现写出三个基础文件。
2. 核对文档与代码不一致的地方。README描述了四个连续记录指标，而后端早已把它们合并为一个；README还列出了实际并不存在的部署文件和配置文件。真正可信的依据是代码，而不是文档。
3. 提交基础文件和技能，然后运行/feature-spec。针对新的暂停日功能，Claude Code创建了feature/07-pause-days分支，询问一次75天的挑战应允许多少个暂停日，并推荐了五天。
4. 批准规格，让Claude Code构建一项功能，允许用户提前安排最多五天休息日而不中断连续记录。测试通过后，在手机上手动检查结果。

从Plan Mode到BMAD：如何选择框架

各种SDD框架用各自的命令、规则和智能体角色来封装同一个循环。截至2026年10月13日，按从轻到重排列如下：

这五个框架尚未经过正面对比的基准测试，因此这份列表反映的是轻重，而不是优劣。一种实用的做法是分两层：新项目和大型功能用BMAD这类较重的框架，较小的工作用Plan Mode。切勿在同一个代码仓库中运行两个规格框架，因为相互冲突的文档会破坏唯一可信的信息来源。Plan Mode是例外，它不写入任何文件，可以与一个框架并用。

要点总结

如果不把决定写下来，AI智能体就会替你选择技术栈、规则，甚至样式。因此要自己做出这些决定，并让每个重要功能都经过规划、编写规格和实现这几个阶段。上手步骤如下：

1. 创建specs文件夹，让AI访谈你，写出三个基础文件；如果已有代码，就从代码中提炼。
2. 用一条禁止写代码的规划提示词开始下一个功能，然后审阅并提交它的规格文件。
3. 清空对话，依据规格构建，只有在测试通过且你亲自检查过结果之后才合并。
4. 同一条提示词粘贴过两次，就把它做成技能。
5. 如果改动能写进一张简短的工单、涉及的文件少于三个、不涉及设计决策，或者只是凭肉眼调整的外观细节，就不必写规格。