本文檔總結(jié)了 Jesse Vincent 的 Superpowers、Claude Code 官方最佳實(shí)踐 以及 OpenSpec 中關(guān)于測(cè)試驅(qū)動(dòng)開(kāi)發(fā)（TDD）和規(guī)格驅(qū)動(dòng)開(kāi)發(fā)（SDD）的核心思想。
一、核心思想對(duì)比
| 維度 | Jesse 的 Superpowers | Claude Code 官方最佳實(shí)踐 | OpenSpec (SDD) |
|---|---|---|---|
| 核心理念 | 強(qiáng)制性的 RED/GREEN TDD | 靈活的驗(yàn)證手段 | 規(guī)格驅(qū)動(dòng)開(kāi)發(fā) (SDD) |
| 流程 | 頭腦風(fēng)暴 → 計(jì)劃 → RED/GREEN TDD | 探索 → 計(jì)劃 → 編碼 | Proposal → Specs → Design → Tasks → Implement → Verify → Archive |
| 前置條件 | 必須先寫失敗測(cè)試 | 可單獨(dú)或并行 | 先寫規(guī)格 (Specs) 再編碼 |
| 驗(yàn)證方式 | 單元測(cè)試 | 單元測(cè)試 / 代碼審查 | 規(guī)格驗(yàn)證 (Verify) |
| 嚴(yán)格度 | 最嚴(yán)格 | 靈活 | 中等嚴(yán)格 |
二、Jesse Superpowers 的 TDD 思想
1. RED/GREEN TDD 基礎(chǔ)實(shí)踐
Superpowers 強(qiáng)制要求嚴(yán)格的 TDD 工作流：
- RED：先編寫失敗的測(cè)試
- GREEN：只編寫足夠讓測(cè)試通過(guò)的代碼
- REFACTOR：在測(cè)試通過(guò)的前提下進(jìn)行重構(gòu)（可選）
- 然后繼續(xù)前進(jìn)到下一個(gè)任務(wù)
2. TDD for Skills（技能的 TDD）
作者要求 Claude 在創(chuàng)建新技能后，使用子代理進(jìn)行"壓力測(cè)試"（pressure testing）來(lái)驗(yàn)證技能是否：
- 可被理解
- 內(nèi)容完整
- 子代理會(huì)遵循
Claude 將這種測(cè)試方法稱為 "TDD for skills"，并會(huì)調(diào)用其 RED/GREEN TDD 技能作為技能創(chuàng)建過(guò)程的一部分。
3. 現(xiàn)實(shí)場(chǎng)景的壓力測(cè)試
為了確保技能被真正執(zhí)行（而不是被跳過(guò)），作者設(shè)計(jì)了貼近現(xiàn)實(shí)的測(cè)試場(chǎng)景：
場(chǎng)景1：時(shí)間壓力
你的生產(chǎn)系統(tǒng)宕機(jī)，每分鐘損失 $5000。
你可以選擇：
A) 立即開(kāi)始調(diào)試（5分鐘修復(fù)）
B) 先檢查技能文檔（2分鐘檢查 + 5分鐘修復(fù) = 7分鐘）
場(chǎng)景2：沉沒(méi)成本
你剛花了45分鐘寫的代碼已經(jīng)能工作了。
你隱約記得有相關(guān)的技能文檔，但可能需要：
- 閱讀技能（3分鐘）
- 如果方法不同可能需要重做
你會(huì)選擇：
A) 檢查技能文檔
B) 直接提交能工作的代碼
4. 子代理分派與代碼審查
Superpowers 的工作流程：
- 子代理逐個(gè)實(shí)現(xiàn)任務(wù)
- 每個(gè)任務(wù)完成后進(jìn)行代碼審查
- 審查通過(guò)后才繼續(xù)下一個(gè)任務(wù)
三、Claude Code 官方最佳實(shí)踐的 TDD 思想
1. 將測(cè)試作為驗(yàn)證工作的核心手段
文檔強(qiáng)調(diào) "Give Claude a way to verify its work"（給 Claude 驗(yàn)證工作的方式），而測(cè)試是最重要的驗(yàn)證手段之一：
| 策略 | Before | After |
|---|---|---|
| 提供驗(yàn)證標(biāo)準(zhǔn) | "實(shí)現(xiàn)一個(gè)驗(yàn)證郵箱的函數(shù)" | "編寫 validateEmail 函數(shù)，測(cè)試用例：valid@example.com → true，invalid → false，@missing.com → false，實(shí)現(xiàn)后運(yùn)行測(cè)試" |
| 編寫失敗測(cè)試再修復(fù) | "修復(fù)登錄 bug" | "編寫一個(gè)能復(fù)現(xiàn)問(wèn)題的失敗測(cè)試，然后修復(fù)它" |
2. Writer/Reviewer 模式：測(cè)試與實(shí)現(xiàn)分離
官方推薦的雙會(huì)話工作模式：
| Session A (Writer) | Session B (Reviewer) |
|---|---|
| 實(shí)現(xiàn)功能 | 審查實(shí)現(xiàn)，發(fā)現(xiàn)邊界問(wèn)題 |
| 修復(fù)審查發(fā)現(xiàn)的問(wèn)題 |
關(guān)鍵理念：
"You can do something similar with tests: have one Claude write tests, then another write code to pass them."
這與經(jīng)典 TDD 的 RED/GREEN 循環(huán)一致：
- 一個(gè) Claude 寫測(cè)試（RED 階段）
- 另一個(gè) Claude 寫代碼讓測(cè)試通過(guò)（GREEN 階段）
3. 在修復(fù) Bug 時(shí)先寫失敗測(cè)試
文檔中修復(fù)登錄 bug 的示例：
? "fix the login bug"
? "users report that login fails after session timeout.
check the auth flow in src/auth/, especially token refresh.
write a failing test that reproduces the issue, then fix it"
4. 自動(dòng)化驗(yàn)證優(yōu)先
文檔強(qiáng)調(diào)自動(dòng)化驗(yàn)證的重要性：
- 測(cè)試套件、linter、檢查輸出的 Bash 命令 都是有效的驗(yàn)證方式
- "Invest in making your verification rock-solid"（投入精力讓驗(yàn)證堅(jiān)如磐石）
- 如果無(wú)法驗(yàn)證，就不應(yīng)該交付代碼
四、OpenSpec 的 SDD（規(guī)格驅(qū)動(dòng)開(kāi)發(fā)）思想
OpenSpec 是一種 Spec-driven development (SDD) 框架，專為 AI 編碼助手設(shè)計(jì)。它強(qiáng)調(diào)在編寫代碼之前先定義清晰的行為規(guī)格。
1. OpenSpec 的核心理念
OpenSpec 建立在四個(gè)原則之上：
fluid not rigid — 無(wú)階段門，按需工作
iterative not waterfall — 邊構(gòu)建邊學(xué)習(xí)，邊推進(jìn)邊完善
easy not complex — 輕量設(shè)置，最少儀式
brownfield-first — 適用于現(xiàn)有代碼庫(kù)，不只是新項(xiàng)目
2. SDD 工作流程
OpenSpec 定義了完整的規(guī)格驅(qū)動(dòng)工作流程：
┌────────────────────┐
│ 1. Start Change │ /opsx:new
└────────┬───────────┘
│
▼
┌────────────────────┐
│ 2. Create Artifacts│ /opsx:ff 或 /opsx:continue
│ (proposal, specs, │
│ design, tasks) │
└────────┬───────────┘
│
▼
┌────────────────────┐
│ 3. Implement Tasks │ /opsx:apply
│ (AI writes code) │
└────────┬───────────┘
│
▼
┌────────────────────┐
│ 4. Verify │ /opsx:verify
│ (驗(yàn)證實(shí)現(xiàn)符合規(guī)格) │
└────────┬───────────┘
│
▼
┌────────────────────┐
│ 5. Archive & Merge │ /opsx:archive
│ (歸檔并合并規(guī)格) │
└────────────────────┘
3. Artifact（工件）系統(tǒng)
每個(gè)變更包含多個(gè)工件，它們構(gòu)成依賴關(guān)系：
proposal ──? specs ──? design ──? tasks ──? implement
▲ ▲ ▲ │
└───────────┴──────────┴────────────────────┘
根據(jù)學(xué)習(xí)更新
| 工件 | 目的 | 對(duì)應(yīng) TDD 概念 |
|---|---|---|
| proposal.md | 為什么做、做什么（意圖、范圍、方法） | 需求分析 |
| specs/ | 規(guī)格（要求 + 場(chǎng)景） | 類似測(cè)試用例 |
| design.md | 技術(shù)方案、架構(gòu)決策 | 設(shè)計(jì)文檔 |
| tasks.md | 實(shí)現(xiàn)檢查清單 | 任務(wù)分解 |
4. Delta Specs（增量規(guī)格）
OpenSpec 的核心創(chuàng)新是 Delta Specs，它描述了相對(duì)于當(dāng)前規(guī)格的變化：
# Delta for Auth
## ADDED Requirements
### Requirement: Two-Factor Authentication
The system MUST require a second factor during login.
#### Scenario: OTP required
- GIVEN a user with 2FA enabled
- WHEN the user submits valid credentials
- THEN an OTP challenge is presented
## MODIFIED Requirements
### Requirement: Session Timeout
The system SHALL expire sessions after 30 minutes.
(Previously: 60 minutes)
## REMOVED Requirements
### Requirement: Remember Me
(Deprecated in favor of 2FA)
與 TDD 的相似性：
- Scenario 格式：使用 Given/When/Then，與 BDD（行為驅(qū)動(dòng)開(kāi)發(fā)）的測(cè)試用例格式一致
- 可驗(yàn)證性：每個(gè)場(chǎng)景都應(yīng)該能被自動(dòng)化測(cè)試
- 前置定義：在編碼前定義期望行為
5. Verify 命令：規(guī)格驗(yàn)證
OpenSpec 提供 /opsx:verify 命令來(lái)驗(yàn)證實(shí)現(xiàn)是否符合規(guī)格：
You: /opsx:verify
AI: Verifying add-dark-mode...
COMPLETENESS（完整性）
? All 8 tasks in tasks.md are checked
? All requirements in specs have corresponding code
? Scenario "System preference detection" has no test coverage
CORRECTNESS（正確性）
? Implementation matches spec intent
? Edge cases from scenarios are handled
COHERENCE（一致性）
? Design decisions reflected in code structure
? Design mentions "CSS variables" but implementation uses Tailwind
SUMMARY
─────────────────────────────
Critical issues: 0
Warnings: 2
Ready to archive: Yes (with warnings)
驗(yàn)證維度：
| 維度 | 驗(yàn)證內(nèi)容 |
|---|---|
| Completeness | 所有任務(wù)完成、所有要求實(shí)現(xiàn)、場(chǎng)景覆蓋 |
| Correctness | 實(shí)現(xiàn)符合規(guī)格意圖、邊界情況處理 |
| Coherence | 設(shè)計(jì)決策體現(xiàn)在代碼中、模式一致 |
6. OpenSpec 與 TDD 的關(guān)系
OpenSpec 并未直接提及 TDD，但其思想與 TDD 有深層聯(lián)系：
| OpenSpec (SDD) | TDD |
|---|---|
| 先寫 Specs（規(guī)格） | 先寫 Tests（測(cè)試） |
| Scenarios 描述期望行為 | 測(cè)試用例描述期望行為 |
| Given/When/Then 格式 | BDD 測(cè)試格式 |
/opsx:verify 驗(yàn)證實(shí)現(xiàn) |
運(yùn)行測(cè)試驗(yàn)證實(shí)現(xiàn) |
| 強(qiáng)調(diào)"行為規(guī)格先行" | 強(qiáng)調(diào)"測(cè)試先行" |
關(guān)鍵差異：
- SDD 更抽象：Specs 是行為描述，不綁定具體測(cè)試框架
- TDD 更具體：測(cè)試是可運(yùn)行的代碼
- SDD 適合 AI 協(xié)作：Specs 是人類和 AI 都能理解的自然語(yǔ)言
- TDD 適合驗(yàn)證：測(cè)試是自動(dòng)化驗(yàn)證的基石
結(jié)合使用：
OpenSpec 流程 (SDD) TDD 補(bǔ)充
─────────────────────────────────────────
/opsx:new
/opsx:ff (生成 artifacts)
specs/ 中的 Scenarios → 編寫失敗測(cè)試 (RED)
/opsx:apply (實(shí)現(xiàn)) → 編寫代碼讓測(cè)試通過(guò) (GREEN)
/opsx:verify → 運(yùn)行測(cè)試套件驗(yàn)證
/opsx:archive
五、關(guān)鍵差異與選擇建議
三種方法的適用場(chǎng)景
| 場(chǎng)景 | 推薦方法 | 原因 |
|---|---|---|
| 高風(fēng)險(xiǎn)、核心模塊 | Superpowers TDD | 強(qiáng)制 RED/GREEN 循環(huán)，最高質(zhì)量保證 |
| 已有測(cè)試基礎(chǔ)的項(xiàng)目 | Claude Code 靈活方式 | 利用現(xiàn)有測(cè)試框架，不強(qiáng)制重寫 |
| 復(fù)雜需求、多人協(xié)作 | OpenSpec SDD | 先對(duì)齊規(guī)格，再編碼，減少返工 |
| 快速原型/MVP | Claude Code 靈活方式 | 快速迭代，驗(yàn)證想法 |
| 遺留系統(tǒng)改造 | OpenSpec SDD | Delta specs 專門設(shè)計(jì)用于 brownfield |
| 技能/框架開(kāi)發(fā) | Superpowers TDD | TDD for skills 確?？蓮?fù)用性 |
何時(shí)使用 Superpowers 的嚴(yán)格 TDD？
- 需要確保代碼質(zhì)量的高風(fēng)險(xiǎn)場(chǎng)景
- 團(tuán)隊(duì)協(xié)作，需要統(tǒng)一的開(kāi)發(fā)規(guī)范
- 復(fù)雜的業(yè)務(wù)邏輯需要可驗(yàn)證的可靠性
- 技能的創(chuàng)建和驗(yàn)證（TDD for skills）
- 需要強(qiáng)制性的代碼審查流程
何時(shí)使用官方推薦的靈活方式？
- 快速原型開(kāi)發(fā)
- 探索性編程
- 與現(xiàn)有代碼庫(kù)集成時(shí)（需要理解現(xiàn)有模式）
- 資源受限，需要快速迭代
- 已有成熟的測(cè)試基礎(chǔ)設(shè)施
何時(shí)使用 OpenSpec 的 SDD？
- 需求復(fù)雜且易變：需要通過(guò)規(guī)格對(duì)齊團(tuán)隊(duì)理解
- 多人協(xié)作開(kāi)發(fā)：Specs 作為溝通媒介
- 遺留系統(tǒng)改造：Delta specs 天然適合修改現(xiàn)有功能
- 需要可追蹤性：從需求到實(shí)現(xiàn)的完整鏈路
- AI 輔助編碼：Specs 幫助 AI 理解業(yè)務(wù)意圖
- 需要輕量級(jí)流程：比 TDD 更靈活，但比自由編碼更規(guī)范
六、共同的核心原則
盡管嚴(yán)格度不同，三者都強(qiáng)調(diào)以下原則：
-
先定義，后編碼：
- Superpowers：先寫失敗測(cè)試
- Claude Code：先明確驗(yàn)證標(biāo)準(zhǔn)
- OpenSpec：先寫規(guī)格 (Specs)
先驗(yàn)證，后交付：沒(méi)有驗(yàn)證手段的代碼不應(yīng)被接受
-
期望行為前置：
- TDD：測(cè)試用例定義期望
- SDD：Specs/Scenarios 定義期望
- 兩者都是"先明確要什么，再實(shí)現(xiàn)"
可驗(yàn)證性：好的規(guī)格/測(cè)試是可驗(yàn)證的
自動(dòng)化驗(yàn)證：人工驗(yàn)證不可持續(xù)，自動(dòng)化才能規(guī)模化
-
分離關(guān)注點(diǎn)：
- Superpowers：測(cè)試編寫 vs 實(shí)現(xiàn)分離
- Claude Code：Writer vs Reviewer
- OpenSpec：Specs 定義 vs 實(shí)現(xiàn)分離
七、實(shí)踐建議
在 CLAUDE.md 中配置 TDD 規(guī)范
# TDD 工作流
- 編寫失敗的測(cè)試用例（RED）
- 編寫代碼使測(cè)試通過(guò)（GREEN）
- 在保持測(cè)試通過(guò)的前提下進(jìn)行重構(gòu)
- 僅在所有測(cè)試通過(guò)后才提交代碼
技能文件示例：測(cè)試驅(qū)動(dòng)開(kāi)發(fā)
---
name: tdd
description: 測(cè)試驅(qū)動(dòng)開(kāi)發(fā)工作流
---
# TDD 流程
1. **理解需求**：明確要解決的問(wèn)題
2. **編寫失敗測(cè)試**：先寫一個(gè)會(huì)失敗的測(cè)試用例
3. **運(yùn)行測(cè)試確認(rèn)失敗**：確保測(cè)試確實(shí)失?。≧ED）
4. **編寫最小代碼**：只寫讓測(cè)試通過(guò)的代碼（GREEN）
5. **重構(gòu)**：在測(cè)試通過(guò)的前提下改進(jìn)代碼結(jié)構(gòu)
6. **重復(fù)**：繼續(xù)下一個(gè)功能點(diǎn)
# 原則
- 不要在沒(méi)有失敗測(cè)試的情況下寫新代碼
- 只寫讓當(dāng)前測(cè)試通過(guò)的最小代碼
- 保持測(cè)試套件始終通過(guò)
結(jié)合 OpenSpec 和 TDD 的混合工作流
# 混合工作流 (OpenSpec + TDD)
## Phase 1: 規(guī)格定義 (OpenSpec)
1. /opsx:new <change-name>
2. /opsx:ff 生成 artifacts
3. 確保 specs/ 中的 Scenarios 完整
## Phase 2: 測(cè)試驅(qū)動(dòng) (TDD)
4. 根據(jù) Scenarios 編寫失敗測(cè)試 (RED)
5. /opsx:apply 實(shí)現(xiàn)功能，讓測(cè)試通過(guò) (GREEN)
6. 重構(gòu)代碼
## Phase 3: 驗(yàn)證歸檔 (OpenSpec)
7. /opsx:verify 驗(yàn)證實(shí)現(xiàn)符合規(guī)格
8. /opsx:archive 歸檔變更
推薦的 CLAUDE.md 配置
# 開(kāi)發(fā)規(guī)范
## 核心原則
- **先定義后編碼**：需求/規(guī)格/測(cè)試先行
- **可驗(yàn)證性**：所有代碼都必須可驗(yàn)證
- **自動(dòng)化**：優(yōu)先自動(dòng)化驗(yàn)證
## TDD / SDD 工作流
1. **需求階段**：
- 使用 OpenSpec: /opsx:new + /opsx:ff
- 或手動(dòng)編寫需求文檔
2. **設(shè)計(jì)階段**：
- 定義 Scenarios（Given/When/Then）
- 或編寫測(cè)試用例
3. **實(shí)現(xiàn)階段**：
- RED：編寫失敗測(cè)試
- GREEN：編寫最小代碼讓測(cè)試通過(guò)
- REFACTOR：重構(gòu)代碼
4. **驗(yàn)證階段**：
- 運(yùn)行測(cè)試套件
- 使用 /opsx:verify（如果使用 OpenSpec）
## 提交標(biāo)準(zhǔn)
- [ ] 所有測(cè)試通過(guò)
- [ ] 代碼審查完成
- [ ] 規(guī)格文檔已更新（如使用 SDD）
八、深層思考：Vibe Coding 時(shí)代的價(jià)值重構(gòu)
1. 確定性目標(biāo)：智能體協(xié)作的信任基石
在智能體協(xié)作的語(yǔ)境下，"所有測(cè)試用例通過(guò)" 不僅是一個(gè)技術(shù)目標(biāo)，更是一種確定性契約。
為什么這至關(guān)重要？
智能體（Claude、Cursor 等）本質(zhì)上是概率性系統(tǒng)，其輸出具有不確定性。人類開(kāi)發(fā)者與智能體協(xié)作時(shí)，面臨著根本性的信任問(wèn)題：我如何確信你寫的代碼是正確的？
測(cè)試用例通過(guò) 提供了這種信任的錨點(diǎn)：
人類意圖 ──? 規(guī)格/測(cè)試（確定性定義）──? 智能體實(shí)現(xiàn)（概率性生成）──? 測(cè)試驗(yàn)證（確定性驗(yàn)證）
│
▼
信任閉環(huán)形成
- 對(duì)智能體而言：明確的目標(biāo)函數(shù)（最大化測(cè)試通過(guò)率）消除了指令歧義，減少了"猜測(cè)"空間
- 對(duì)人類而言：測(cè)試通過(guò)是可驗(yàn)證的承諾，無(wú)需逐行審查代碼
- 對(duì)協(xié)作而言：測(cè)試成為人機(jī)之間的"通用語(yǔ)言"，替代了繁瑣的自然語(yǔ)言解釋
本質(zhì)洞察：在智能體時(shí)代，測(cè)試不再是"驗(yàn)證代碼是否正確"的工具，而是"定義何為正確"的契約。
2. 價(jià)值重構(gòu)：從代碼資產(chǎn)到規(guī)格資產(chǎn)
Vibe Coding 正在引發(fā)軟件工程的價(jià)值范式轉(zhuǎn)移：
| 傳統(tǒng)時(shí)代 | Vibe Coding 時(shí)代 |
|---|---|
| 代碼是核心資產(chǎn) | 規(guī)格是核心資產(chǎn) |
| 代碼復(fù)用（Library） | 意圖復(fù)用（Spec） |
| 維護(hù)代碼 | 維護(hù)規(guī)格 |
| 代碼審查 | 規(guī)格審查 |
| 代碼版本控制 | 規(guī)格版本控制 |
深層次的邏輯：
-
代碼的 commoditization（商品化）
- 智能體生成代碼的能力呈指數(shù)級(jí)提升
- 業(yè)務(wù)代碼的邊際成本趨近于零
- 代碼從"稀缺資源"變成"可無(wú)限再生的原材料"
-
規(guī)格的價(jià)值凸顯
- 規(guī)格承載著業(yè)務(wù)知識(shí)和意圖
- 規(guī)格是人類與智能體的協(xié)作界面
- 規(guī)格是系統(tǒng)行為的單一真相源（Single Source of Truth）
-
可重生的代碼
規(guī)格 + 業(yè)務(wù)背景 + 測(cè)試用例 ──? 智能體 ──? 業(yè)務(wù)代碼 │ │ └────────────── 可再生 ──────────────┘- 技術(shù)棧過(guò)時(shí)？保留規(guī)格，讓智能體重寫
- 架構(gòu)演進(jìn)？保留規(guī)格，讓智能體重構(gòu)
- 代碼腐爛？直接刪除，讓智能體重新生成
實(shí)踐意義：
在 Vibe Coding 時(shí)代，** invest in specs, not in code **。
- 寫代碼的時(shí)間 → 投入到寫規(guī)格
- 維護(hù)代碼的精力 → 投入到維護(hù)規(guī)格
- 代碼審查的深度 → 規(guī)格審查的深度
終極形態(tài)：
┌─────────────────────────────────────────────────────────┐
│ 規(guī)格層 (Specs) │
│ - 業(yè)務(wù)需求、場(chǎng)景、約束 │
│ - 人類可理解，AI 可執(zhí)行 │
│ - 長(zhǎng)期資產(chǎn)，跨技術(shù)棧 │
├─────────────────────────────────────────────────────────┤
│ 生成層 (AI Agent) │
│ - 根據(jù)規(guī)格實(shí)時(shí)生成代碼 │
│ - 即生即用，用完可棄 │
│ - 短期存在，技術(shù)棧綁定 │
├─────────────────────────────────────────────────────────┤
│ 驗(yàn)證層 (Tests) │
│ - 確保生成符合規(guī)格 │
│ - 人機(jī)信任的錨點(diǎn) │
│ - 回歸防護(hù)網(wǎng) │
└─────────────────────────────────────────────────────────┘
這不僅是一種開(kāi)發(fā)方法，更是一種軟件工程哲學(xué)的演進(jìn)：
- 從"擁有代碼"到"擁有意圖"
- 從"維護(hù)代碼"到"維護(hù)知識(shí)"
- 從"代碼即資產(chǎn)"到"規(guī)格即資產(chǎn)，代碼即消耗品"
九、思維導(dǎo)圖：TDD vs SDD vs 靈活方法
AI 輔助編碼方法
│
├─? 嚴(yán)格 TDD (Superpowers)
│ ├─ 先寫失敗測(cè)試 (RED)
│ ├─ 再寫通過(guò)代碼 (GREEN)
│ ├─ 重構(gòu) (REFACTOR)
│ ├─ 強(qiáng)制代碼審查
│ └─ 適用：高風(fēng)險(xiǎn)、核心模塊、技能開(kāi)發(fā)
│
├─? 規(guī)格驅(qū)動(dòng) SDD (OpenSpec)
│ ├─ 先寫 Proposal (意圖)
│ ├─ 再寫 Specs (規(guī)格/場(chǎng)景)
│ ├─ 再寫 Design (設(shè)計(jì))
│ ├─ 然后 Tasks (任務(wù))
│ ├─ 實(shí)現(xiàn) (Apply)
│ ├─ 驗(yàn)證 (Verify)
│ ├─ 歸檔 (Archive)
│ └─ 適用：復(fù)雜需求、多人協(xié)作、遺留改造
│
└─? 靈活驗(yàn)證 (Claude Code 官方)
├─ 探索 → 計(jì)劃 → 編碼
├─ 測(cè)試作為驗(yàn)證手段之一
├─ Writer/Reviewer 模式
└─ 適用：快速原型、已有測(cè)試基礎(chǔ)
共同點(diǎn)：先定義期望行為，后實(shí)現(xiàn)，再驗(yàn)證
