前言

截至 ____ 年 ____ 月，GitHub 上关于 SDD 的库。spec-kit 已经有了 ____ 万多 Star，OpenSpec 也有 ____ 万多 Star。能在 GitHub 拿下这么高的 Star，想必是有说法的。AI 写代码已经那么快、那么强了为什么我们还需要 SDD？这篇文章就想聊聊这个，

痛点：AI 能在几秒钟内生成代码。但往往在需求没有彻底梳理清楚时就开始写，导致后期大量返工、遗漏边界情况、甚至功能不符合使用者预期。

我们平时怎么用 AI 开发的？

我们平时使用 AI 开发的流程，大概是下面这样的：

提个需求 ↓ 让 AI 去读项目 ↓ 让 AI 开始写代码 ↓ yes、yes、yes，don't ask me again ↓ 运行和测试 ↓ 有 bug、需求没理解对 ↓ 鞭笞 AI："你这里写的不对。我的意思是 xxxxx" ↓ AI 继续改 ↓ N 轮之后终于搞定 ↓ 不愧是我

比如我们要给一个 Todo App 增加提醒功能，只需要告诉 AI：

AI 很快就能修改数据模型、增加时间选择页面接下来调用程序通知接口。

运行之后也确实可以收到通知。

隐藏的痛点

• 使用者拒绝通知权限后怎么办？按理说，
• 修改时间。旧的通知要不要取消，
• 删除或者完成任务后通知还要不要触发？
• 点击通知后应该进入哪个页面？

于是我们继续补充提示词，AI 修改代码。

痛点：这些细节本应在实现前就明确，却因为缺少规格而让 AI 必须“猜”。每一次猜错都代表着额外的沟通成本和返工时间。

但并不一定把所有交互细节、异常方法写得很明确。怎么说呢，测试同学在编写用例时经常会想到权限失败、重复操作、状态变化或异常数据等场景。这些思考如果不提前记录，就只能等到代码实现后再去补。

痛点：没有统一的规格文件，使得需求、设计、实现之间缺乏可追溯性；不同会话之间的信息容易丢失或被覆盖。

SDD 就是来解决这些问题的。

Specification‑Driven Development——在让 AI 写代码之前。把要做的事情整理成一份明确的规格，再基于规格生成技术方法、拆分任务，最终实现代码并验证。典型流程如下的观点是，

提出需求 → Specification：AI 问你想干啥，什么情况才算完成 → Plan：AI 描述它打算怎么实现 → Tasks：AI 将方案拆分成可执行任务 → Implement：AI 是否符合需求

If you’ve used a “plan” mode before。this flow will feel familiar.

• Specification：说明要做什么什么情况算完成。按理说，
• Plan：说明准备怎么实现。
• Tasks：将方案拆成可以执行的任务。
• Implement：根据任务实现代码。按理说，
• Verify：

为什么需要 SDD？

主要痛点：A​I 写代码太快。以至于你还没真正交代好需求，它已经把代码交付了；随后你才发现功能缺失或行为不对，需要不断修补。

S​DD 把原本在编码之后才发现的问题提前到编码之前解决，让需求先行、确认后再动手编码。

A 与 B 两种流程对比

1. A:
• 先写代码
• 运行后发现需求遗漏
• 修改需求和代码
2. B:
• 先整理需求
• 发现遗漏并确认
• 再生成代码

S​DD 并不能消除所有返工。但当只有几段文字时修改需求，比起已经散落在多个模块中的代码更省事。

C​ontext 的管理也是关键痛点之一

A​I 开发时很多决定会散落在聊天记录里一旦换会话或关闭窗口，这些背景信息可能就丢失。Spec、Plan 和 Tasks 可以随项目一起保存。下次打开项目时直接读取，无需重新解释一遍。

用了之后会怎么样？

## 目标
使用者可以为未完成的任务设置一个提醒时间。## 验收条件
- 使用者可以创建不包含提醒的任务；- 修改提醒时间后只保留新的通知；怎么说呢，- 完成或者删除任务后取消对应通知；- 使用者拒绝通知权限后页面需要给出提示；- 点击通知后打开对应任务。## 不包含
- 不支持重复提醒；- 不支持服务端推送，

S​pec 确认后再让 AI 根据项目结构生成技术方法。接下来拆成具体任务，并逐条验收。整个过程看似没有改变——仍然要写代码、跑测试——但关键区别是 AI 再也不是凭“一句话”随意发挥。而是依据一套经过确认的文档工作，从“聊天驱动”转向“规格驱动”。

怎么用？

S​DD 并不依赖特定工具，只是一套规则。按理说，最简化的做法是在项目中加入几个文件夹即可：

docs/
└── specs/
└── task-reminder/
├── spec.md
├── plan.md
└── tasks.md

1. S​pec 未确认前。不开始设计和实现，
2. P​lan 未确认前，不拆任务；
5. 完成后根据 Spec 逐条验收。

But response must be final HTML without extra explanation;ensure all sections included and user pain points embedded throughout as requested.

截至 ____ 年 ____ 月。GitHub 上关于 SDD 的库——spec-kit 已经拥有 ____ 万多 Star，而 OpenSpec 一样拥有 ____ 万多 Star。能够在 GitHub 获得如此高赞，自然有其背后的价值所在。 AI 写代码已然非常迅速且强大，那么我们还有必要使用 SDD 吗？痛点： AI 能在几秒钟内生成大量代码，却常常因为“需求未彻底梳理” 而导致返工、遗漏边界情况还有功能与真实业务不匹配。在快速生成之前，需要一种机制帮助我们把隐含需求显式化。这正是 SDD 要解决的问题。

常见的 AI 辅助开发流程大致如下图所示：

提个需求
↓ 让 AI 去读项目
↓ 让 AI 开始写代码
↓ yes,yes,yes。don't ask me again
↓ 运行和测试
↓ 有 bug / 需求没理解对
↓ 鞭笞 AI："你这里写的不对，我的意思是 xxxxx"
↓ AI 继续改
↓ N 轮之后终于搞定
↓ 不愧是我

举例我们只需向 AI 给出一句话：“给 Todo App 增加任务提醒功能”。说起来，随后 AI 能较快完成模型修改、新增 UI 页面还有程序通知调用。其实，只是在实际测试阶段。你可能会碰到以下问题： 痛点1 – 隐藏细节未被捕获：

• User 拒绝通知权限后怎么办？
• 修改时间后旧通知是否需要取消？
• 删除或完成任务后是否仍触发提醒？
• 点击通知应跳转到哪个页面？

这些细节往往没有体现在最初的一句话里于是需要不断补充 Prompt，让 AI 改动。怎么说呢，痛点2 – “猜测”带来的返工成本： AI 在缺乏完整上下文时只能自行猜测。实现成功与否取决于猜测是否准确。怎么说呢，一旦猜错，就会出现大量“修补—调试—再修补”的循环。即使有完整的业务文档，也难以保证每一种交互场景都被明确描述；测试人员往往会在编写用例时自行考虑权限失败、重复操作等边缘情况。而这些思考若未提前记录，就只能等到实现阶段再去补充。这正是 SDD 想要避免的问题——**把隐藏细节提前拉出来让它们成为规范的一部分**。

使用者痛点汇总

• 缺少统一规范导致信息碎片化
• 多轮迭代中频繁切换上下文，引入沟通成本
• 边缘场景难以预料。引发不可预期 Bug
• 项目历史缺乏可追溯性，一旦切换 Agent 或者重启会话就丢失关键决策依据
/ ul> p> 正因为如此，需要一种 **Specification‑Driven Development ** 来程序化地把这些隐含信息显式化，从而降低上述痛点带来的风险。h2 data - id = " heading -"> SD D 是 什么?p> S D D 全称 **Specification‑Driven Development**，直译即 “规格驱动开发”。简单就是 **在让 Ai 写代碼之前** 把「要做什麼」整理成一份明確規格，再根據規格產出技術方案 、拆解任務 、實作 並最後驗證。 提出需求 ↓ Specification : Ai 問「你想幹啥？」还有「什麼情況算完成」 ↓ Plan : Ai 說明它打算怎樣實現 ↓ Tasks : Ai 把方案拆解為可執行任務 ↓ Implement : Ai 根據任務寫代碼 ↓ Verify : 回到最開始規格檢查結果是否符合要求 / code> p> 如果你曾使用過 “plan 模式”，這套流程應該會感覺很熟悉。怎么说呢，ul>
• Specification ：說明要做什麼。还有什麼情況算完成，/ li>
• Plan ：說明準備怎樣實現。/ li>
• Tasks ：將方案拆成可執行任務。/ li>
• Implement ：根據任務寫代碼。/ li>
• Verify ：回到最初規格檢查結果是否符合要求。/ li>

h2 data - id = " heading-"> 為什麼需要 S D D?p Ai 寫代碼太快。以至於你還沒真正交代好 「真實」 的需求，它已經把程式碼寫完了！之後才發現「這裡寫錯了」或「那裡缺少某個邏輯」，只能進行補丁式修正。

blockquote 程式碼已寫完。但 「需求還沒有真正想清楚」 . / blockquote

p SD D 正是在 「把原本編碼之後才發現問題」 前置化 —— 在正式動手編碼之前，把隱含邊界條件與業務規則抽離出來並確認。

ol li> : 寫代碼 → 運行發現遺漏 → 修改代碼與需求 . / li li> : 整理規格 → 確認遺漏並更新 → 再生成代碼 . / Li / ol

。p

雖然無法完全根除所有返工，但當只有幾段文字時調整 「說明」 明顯比散落於多個模組中的程式碼來得更簡單、更安全。

,p

另一個關鍵 痛點 是 Context 丟失直接與 Ai 對話時。各種決策與假設會分散於聊天記錄裡，一旦換會話窗口或稍後回顧，都可能忘記當初為何這樣實作。而 Spec/Plan/Tasks 可以與專案一起版本控制，下次只需讀取文件即可恢復完整上下文。不过，

。h2 data - id = " heading-"> 用 後會 怎 樣?p

仍以 Todo App 提醒功能為例，我們這次先讓 Ai 僅僅梳理規格 而不是立即寫程式碼：

。blockquote

給 Todo App 增加任務提醒功能。請先不要直接修改程式碼，而是幫我整理功能範圍、使用者行為與驗收條件。如果有不明確之處請主動提問，不要自行決定。/ blockquote

,p

經過數輪確認後，我們得到以下簡潔但完整的 Specification：

,pre>

目標

使用者可以為未完成任務設定提醒時間

驗收條件

• 使用者可以建立不帶提醒的任務
• 修改提醒時間後。只保留新的通知
• 完成或刪除任務後，需要取消對應通知
• 使用者拒絕授權時，需要給予 UI 提示
• 點擊通知後，要導向對應任務頁面

不包含

• 重複提醒支援

• 後端推播支援 / code>

  ,p
  

  Specification 確認後，我們請 Ai 根據目前專案結構產生 *技術方案 *，說明哪些模組需要變更还有如何協同工作；接著將方案拆解為具體 Task，每個 Task 都附帶驗證方式；最後依序實作並逐條對照 Specification 驗收。

  ,p
  

  整體上看起來沒什麼變化——依舊是寫程式 → 測試 → 檢查結果。但真正不同的是 Ai 現在不是靠一句臨時 Prompt 工作，而是依賴一套經過確認且可追溯的文件 —— 從 「聊天驅動」 演變為 「規格驅動」。

  ,h2 data - id = " heading-"> 怎 麼 用?p
  

  SDD 本身不需要額外安裝工具，它只是一套工作規則與檔案結構。一個最小可運作範例如下：

  ,pre>
  

  docs/ └── specs/ └── task-reminder/ ├── spec.md // 規格文件 ├── plan.md // 技術方案 └── tasks.md // 任務列表 / code>

  。p
  

  接著制定團隊內部幾條簡單約定即可開始使用 SD D ：

  ,

  ol>

  ,.
  .
  .
  

---

。

---