好的，没问题。作为一位在软件工程领域摸爬滚打多年的老手，我来帮你把这篇文章的“AI味儿”去掉，换上点人话。 写代码这件事，AI确实给我们带来了巨大的便利，但便利的另一面，也带来了一堆新麻烦：项目做着做着就跑偏了，AI有时候会“自由发挥”生成一些意料之外的代码，快速修补留下的技术债越堆越高，最要命的是，跟AI对话一长，它的输出质量就开始“开倒车”。这时候，很多人会问：我们不是已经写了需求文档吗？ 文档是静态的，但开发过程是动态的。文档写完了，往往会慢慢被遗忘。而规范驱动开发的核心思想，就是让规范成为开发周期里始终在线、持续更新的“活”指引。 **什么是规范驱动开发？** 一句话讲明白：在动手写代码之前，先把规范写清楚；在实现的过程中，你得一直回头看看这份规范。 这不仅仅是“先写文档”那么简单。它的核心是把规范当作驱动整个开发流程的原动力。 **三个层次，一个核心** 规范驱动开发通常可以分成三个层次，但无论哪个层次，核心目标只有一个：规范是活的，不是死的。 [图片：规范驱动开发的三个层次] | 层次 | 名称 | 通俗理解 | | :--- | :--- | :--- | | Level 1 | spec-first | 先写规范再动手 | | Level 2 | spec-anchored | 做完了也保留规范，方便日后维护 | | Level 3 | spec-as-source | 只改规范，不改代码 | 坦率地说，大多数团队都停留在 Level 1，而且往往是“一次性规范”——写完就扔到一边不管了。 [图片：spec-once：规范启动项目后被遗忘] 这不是真正的规范驱动开发。真正的价值在于形成一个持续的反馈循环： [图片：规范驱动开发作为持续反馈循环] 需求 → 规范 → 实现 → 反馈 → 更新规范 → 迭代实现 → …… 循环往复，这才是关键。 **实践要点** **模块化拆分** 把大项目拆解成一个个可以独立操作的小模块，每个模块都有明确的阶段划分： * 每个模块都能独立测试、独立部署、独立迭代。 * 每个阶段都是可验证的，这样问题就能早发现、早解决。 一个推荐的工作流是： 1. **尽职调查**：先读文档，翻翻其他相关材料，把情况摸清楚。 2. **架构规划**：设计好系统架构，想清楚资源依赖关系。 3. **分步构建**：从最小的、可测试的模块开始，一步步搭建。 **规范文档的内容** 一份靠谱的规范文档，至少得包含以下几样东西： 1. **需求定义**：用大白话讲清楚我们要解决什么问题。 2. **架构考量**：系统架构怎么搭，技术选型为什么这么选，关键决策要讲明白。 3. **实现计划**：分阶段、一步步怎么干。 4. **测试策略**：每个阶段用什么方法来验证。 **核心经验** **1. 前期规划投入，换来高效实现** | 做法 | 结果 | | :--- | :--- | | 写几句快速提示就让AI开干 | 大量时间花在纠偏上，甚至可能推倒重来 | | 规划阶段舍得花时间 | 后续交互基本就是小调整，很少需要大改 | 一个额外的收获是：把项目中学到的东西沉淀到文档里，它就成了未来的翻跟斗。 **2. 小步构建，逐步验证** 前期的规划，让模块化变得自然而然。每个阶段都能独立验证，问题一冒头就能发现并处理掉。一个很实用的做法是“堆叠式 Pull Request”——创建更小、更容易审查的 PR，让它们之间有明确的依赖关系。 **3. 保持灵活性，预留备选方案** 新技术或工具在早期阶段可能并不完善，所以一定要有备选方案。当预期方案不工作了，要知道怎么切换到备选路线。理解底层原理，别完全依赖那些高层抽象。 **4. 安全设计要趁早** 安全不是事后打的补丁，它应该是架构的一部分。后期再添加安全机制，成本往往高得多，可能需要重构已有代码，甚至某些设计决策是没法回头的。 **落地实践：以 GSD 为例** 理论说完了，来看怎么落地。我们用 GSD (Get Shit Done) 这个工具作为例子，看看规范驱动开发是怎么变成现实的。 **工作流：一个完整的规范驱动闭环** 讨论 → 规划 → 执行 → 验证 → 发布 每个阶段都有明确的输入和输出： | 阶段 | 输入 | 输出 | | :--- | :--- | :--- | | 讨论 | 阶段目标 | CONTEXT.md（决策锁定） | | 规划 | CONTEXT.md | PLAN.md（原子化任务） | | 执行 | PLAN.md | 代码 & SUMMARY.md | | 验证 | 代码 | UAT.md（验收报告） | **关键设计** 1. **规范文件体系**：GSD 会自动维护一套规范文件，确保上下文始终保持新鲜。比如： `项目愿景，始终加载` `STATE.md` 这类文件就能跨会话记住状态。 2. **原子化任务**：每个计划都是一条独立可执行的小任务。比如： `` `创建登录接口` `src/app/api/auth/login/route.ts` `使用jose处理JWT。验证凭据。返回httpOnly cookie。` `curl -X POST localhost:3000/api/auth/login 返回 200` `有效凭据返回cookie，无效凭据返回401` `` 这种 XML 格式的任务指令非常精确，能有效避免 AI 随意发挥。 3. **新上下文执行**：每个任务都使用全新的上下文窗口来执行，彻底避免了历史污染的困扰。20万 token 的上下文，全部用来干正事，没有半点历史垃圾，输出质量始终稳定。 4. **Wa ve 并行执行**：根据任务依赖关系，将它们分组执行： Wa ve 1（并行）：Plan 01, Plan 02 ↓ Wa ve 2（并行）：Plan 03, Plan 04（依赖 Wa ve 1） ↓ Wa ve 3：Plan 05（依赖 Wa ve 2） **快速开始** `npx get-shit-done-cc@latest` 安装后，在 Claude Code 对话框里输入这些指令，就能完整体验整个流程： `/gsd-new-project` → 提问、研究、确定需求、生成路线图 `/gsd-discuss-phase 1` → 收集实现决策 `/gsd-plan-phase 1` → 研究、规划、验证 `/gsd-execute-phase 1` → 并行执行计划 `/gsd-verify-work 1` → 用户验收测试 `/gsd-ship 1` → 创建 PR **规范驱动开发的落地保障** | 问题 | GSD 的解法 | | :--- | :--- | | 规范写完就忘 | STATE.md 跨会话记忆，始终加载 | | 上下文腐烂 | 每个任务用新上下文，零历史污染 | | AI 随意发挥 | XML 格式的原子化任务，指令精确 | | 难以并行 | Wa ve 分组，独立任务并行执行 | | 无法验证 | 验证步骤内建在计划里 | **核心要点速查表** | 建议 | 说明 | | :--- | :--- | | ✅ 规范先行 | 在写代码之前先写规范；实现过程中不断回顾规范 | | ✅ 小步构建 | 将项目分解为可独立测试的小模块 | | ✅ 安全早做 | 不要把安全留到最后，作为架构的一部分设计 | | ✅ 反馈循环 | 需求→规范→实现→反馈→更新规范，持续迭代 | **写在最后** AI 编程工具一日千里，但工具本身永远替代不了扎实的工程实践。规范驱动开发不是额外增加负担，而是把 AI 编程从“碰运气”变成“可控流程”的关键方法论。不管技术背景如何，只要掌握了正确的方法，每个人都能构建出高质量的软件。