Problem Framing 和 Spec-Driven Development 不是兩個獨立步驟，而是一個閉環的兩端。Framing 決定你在解什麼問題，Spec 決定你怎麼知道解對了。缺少前者，Spec 可能在解錯的問題上寫得非常完整；缺少後者，Framing 只是一場分析討論，沒有可執行的結果。完整的閉環長這樣：
需求/痛點
│
▼
[Intent Extraction] ← Interview Me：確認「你真正想要的是什麼」
│
▼
[Problem Framing] ← 5 Whys、HMW、JTBD → 問題陳述句
│
▼
[Specify] ← 寫 spec（六大核心 + 驗收標準 + 邊界）
│
▼
[Plan] ← 技術計畫：依賴圖、風險、建置順序
│
▼
[Tasks] ← 垂直切片、每個任務有明確驗收標準
│
▼
[Implement] ← 逐一執行，Doubt-Driven 審核每個非顯然決策
│
▼
[Verify] ← 對照 spec 的驗收標準逐條確認
│
├── 通過 → 完成，更新 spec 紀錄決策
│
└── 不通過 → 根據失敗類型決定回哪一層
├── 實作問題 → 回 Implement
├── 任務拆法有問題 → 回 Tasks
├── Spec 驗收標準設錯 → 回 Specify
└── 根本在解錯問題 → 回 Problem Framing
每個環節的輸入與輸出
| 環節 | 輸入 | 輸出 | 人工審核點 |
|---|---|---|---|
| Intent Extraction | 原始需求陳述（往往模糊） | 確認過的意圖聲明（outcome / user / success / constraint / out of scope） | 用戶明確說「是」 |
| Problem Framing | 意圖聲明 | 問題陳述句（who / context / goal / obstacle / measurable cost） | 問題陳述被利害關係人認可 |
| Specify | 問題陳述句 | Spec 文件（六大核心、驗收標準、假設清單） | Spec review 通過 |
| Plan | Spec | 技術計畫（依賴圖、元件、風險） | 計畫被確認為正確方向 |
| Tasks | 技術計畫 | 任務清單（每個任務含驗收標準 + 驗證指令 + 預期改動範圍） | 任務清單被確認為完整 |
| Implement | 任務清單 | 程式碼變更 | Doubt-Driven 審核每個非顯然決策 |
| Verify | 程式碼 + Spec 驗收標準 | 通過 / 失敗 + 失敗類型分析 | 人工確認驗收標準逐條成立 |
常見短路點
短路 1：跳過 Intent Extraction，直接開始 framing
結果：花時間把一個本來可以對話釐清的問題 framing 得很徹底，但方向從一開始就偏了。Interview Me 的工作是在進入 framing 之前，先確認「我們真的在討論同一件事」。
短路 2：Framing 結論不明確就進入 Specify
徵兆：Spec 的 Objective 欄位空洞（「讓體驗更好」「提升效能」），沒有可測試條件。這種 Spec 寫完跟沒寫一樣，因為它無法當作 Verify 的基準。
短路 3：Specify 跳過假設清單
後果：假設在 Implement 才被發現，這時修改 Spec 要同時重新 review 計畫與任務。一份在 Specify 階段公開的假設清單，讓這類事故在最便宜的時候被攔截。
短路 4：Plan 和 Tasks 合併成一個步驟
問題：Plan 的工作是確定「做什麼、用什麼方式、順序如何」，Tasks 的工作是確定「每個步驟的驗收標準和驗證方式」。合併時，Tasks 的驗收標準往往被省略，結果是 Implement 沒有明確的「完成定義」。
短路 5：Verify 只驗「有沒有跑起來」，不驗「有沒有滿足 spec 的驗收標準」
兩者是不同的問題。程式能跑不代表它在做對的事。Verify 應逐條對照 Spec 的 success criteria，不是跑個 smoke test 就算過。
何時需要重新 framing
回到 Problem Framing 層是正常的，不是失敗的訊號。以下情況應該回頭：
- Verify 失敗，且失敗模式不是「程式碼有 bug」，而是「這個功能根本解不了用戶的痛點」
- 在 Specify 時，發現任何驗收標準都無法寫成「可測試」的格式（通常代表問題定義不夠清楚）
- 在 Implement 時，每個任務的解法都讓你覺得「這樣做好像不對，但我說不清楚哪裡不對」（往往是 framing 沒做好）
- 用戶看到 demo 時反應是「這不是我要的」而非「這裡有個 bug」
回到 framing 的代價，比走到 deploy 才發現方向錯了低得多。
閉環的本質是迭代速度
這個流程的設計目的不是「慢慢來確保正確」，而是「讓方向錯誤被儘快、儘便宜地發現」。每個環節的人工審核閘門，都是一個可以用低成本問「我們還在對的方向嗎」的機會。在 Specify 發現方向錯了，成本是重寫一份文件；在 Implement 發現，是重寫程式碼；在 Production 發現，是事故和信任損失。
延伸
- Problem Framing 工具詳解 → Problem Framing：定義正確問題
- Spec-Driven 工作流程詳解 → Spec-Driven Development：規格先行
- 看一個完整案例 → 實戰：從一個模糊需求走完全流程
- 回到全景 → Problem Framing ＋ Spec-Driven Development 專欄首頁