开发者常遇到此类场景：在项目开发中尝试添加功能时，借助 AI 编程工具生成代码，随后因需求变更导致代码混乱。例如要求增加用户登录、密码加密及失败提示，几轮修改后可能导致注册接口异常，最终耗费大量时间修复。
这种「越改越乱」的现象，几乎每个使用 AI 编写代码的人都曾体会。
许多人第一反应是模型不够聪明，但问题核心在于输入给 AI 的信息本身就是碎片化的。近期国外开发者圈热议的Spec-Driven Development（规约驱动开发），核心在于先将需求明确化，再让 AI 执行。
本文将详解该流程，并结合 Claude Code 进行实战演示。
为什么你跟 AI 越聊越乱？
当前多数开发者使用 AI 写代码采用聊天式交互，即想到哪说到哪，这种方式被称为Vibe Coding。对于小型脚本或 Demo，这种方式效率极高。
然而，一旦项目具备一定规模或需长期维护，Vibe Coding 的弊端便显现出来。如同口头向外包提需求，缺乏完整蓝图，导致最终产物与预期不符。
AI 每次仅基于当前上下文理解，缺乏项目整体视角，容易在后续步骤中推翻前期设计。问题根源在于缺乏一份双方认可的完整规约。
规约驱动，到底把什么摆到了明面上？
规约驱动开发（Spec-Driven Development）的核心在于将「要做成什么样」明确化，形成文档供双方确认。其流程分为四个阶段：
第一步明确需求与目的，不涉及技术；第二步确定技术架构；第三步拆解具体任务；第四步由 AI 编写代码。与 Vibe Coding 不同，规约驱动将各阶段分开，确保每一步都可审查和修正。
这种分步确认机制能有效防止需求理解偏差和技术方案错误。规约并非一成不变，可在任何阶段修正，是双方不断更新的共识。
spec-kit 一套命令跑下来是什么体验？
GitHub 官方推出的spec-kit工具（100k+ star）可辅助执行该流程。其核心通过几条斜杠命令引导完成规约驱动的各阶段。
首先是确立项目铁律的「宪法」命令：
用于设定代码风格、测试规范等全局规则。
其次是关键的需求规约命令：
此阶段仅描述需求，不涉及技术选型，生成需求规约文档作为双方对齐的第一份文件。
随后是技术方案制定：
基于需求文档确定技术栈和架构，产出一份技术实现方案。
接着是任务拆解：
将技术方案拆分为可执行的具体任务清单。
最后是代码实现：
AI 依据任务清单执行代码编写，因前期已充分对齐，大幅降低出错概率。
在 Claude Code 里，怎么真的用起来？
以下通过构建团队看板工具为例，演示如何在 Claude Code 中落地该流程。
装工具、进项目
首先安装 spec-kit 命令行工具，并初始化项目，指定集成 Claude Code：
初始化后会在当前目录生成项目文件夹及技能配置。需进入项目目录再启动 Claude Code 以加载技能：
启动后输入斜杠即可调用 spec-kit 相关技能。
specify：先说清楚要做什么
输入需求指令，仅描述功能不涉及技术：
AI 将生成详细的需求规约文档，需仔细审查以避免后续返工。
plan：再定技术方案
需求确认后，指定技术栈生成方案：
审查生成的模块设计、接口定义及数据表结构。
tasks：把方案拆成任务
执行任务拆解命令，生成具体执行清单：
至此，需求、方案、任务已全部对齐，虽未写代码，但规划已完成。
implement：放手让它写代码
执行实现命令，AI 按任务清单编写代码：
开发完成后运行项目验证，核心功能如任务分配、拖拽等均正常运作，且全流程无 Bug。
对于大型项目，建议分阶段实施，避免上下文过长导致 AI 顾此失彼。
需求含糊、项目又大，靠什么兜底？
针对需求模糊或大型项目，spec-kit 提供额外命令进行兜底。
首先是澄清命令：
该命令会主动询问需求文档中的模糊点，建议在 specify 之后、plan 之前使用，提前暴露潜在问题。
其次是一致性检查命令：
用于交叉比对需求、方案与任务清单，确保无冲突或遗漏。
这些命令强制将「想清楚」作为写代码前的必要工序。
这不就是又回到瀑布流了吗？
规约驱动虽分阶段，但与传统瀑布流有本质区别。传统瀑布流文档一旦定死难以修改，而规约驱动的文档是活的，可随时修正并重新生成，成本低且灵活。
该模式适用于需长期维护的项目。对于一次性脚本，Vibe Coding 仍更高效。核心在于判断工作是否值得「先想清楚」。
最后
AI 编程工具日益强大，瓶颈已从模型能力转向人类能否清晰表达需求。规约驱动的核心价值在于迫使开发者将需求想明白、说清楚。
AI 时代真正拉开差距的，是谁能把一件事讲清楚。若正受困于 AI 代码混乱，不妨尝试先写规约再动手，体验顺畅的开发流程。