定義錯問題，然後把它解得很漂亮，是工程裡最浪費的一種浪費。這個專欄把兩件事放在一起討論：Problem Framing（把模糊需求淬煉成一個值得解的問題）與 Spec-Driven Development（在寫任何程式之前先把規格寫清楚）。兩者的核心都是「先想清楚、再動手」，合在一起形成一個閉環：問題 → 規格 → 實作 → 驗證 → 重新問問題。
這不是純理論。Thoughtworks 在 2025 年把 Spec-Driven Development 列為 AI 輔助工程的關鍵新實踐；Microsoft 稱之為「AI-native engineering 的規格先行方法」；5 Whys 源自 Toyota 生產系統，半個世紀來業界廣泛採用。本專欄全程標示哪些是方法論主張（合理但難量化），哪些是有跡可循的業界實踐或可佐證事實。
學習路徑
- Problem Framing：定義正確問題 — 為何先 framing、核心工具（5 Whys、HMW、JTBD）、常見反模式
- Spec-Driven Development：規格先行 — 四階段閘門工作流程、spec 寫什麼、與直接動手的對比
- Framing → Spec → 實作 → 驗證：閉環全景 — 全流程每個環節的輸入輸出、常見短路點
- 實戰：從一個模糊需求走完全流程 — 一個具體小案例，從「體驗更好」到可執行 spec
- 延伸：TDD、Planning、ADR、Doubt-Driven 的關係 — 這套流程怎麼和其他工具銜接
🔍 待解問題 / 持續追蹤
- Problem Framing 的價值幾乎沒有爭議，但「framing 時間應佔總開發時間多少比例」業界並無統一標準；有團隊 30 分鐘就夠，有的需要幾天發現期。門檻在哪？
- 5 Whys 的批評者指出：不同人、不同時間問同一個問題，可能得到截然不同的根因鏈——它找到的是「一條」根因路徑而非「唯一」根因。這個限制如何在實務中處理？
- Spec-Driven 在 AI 輔助工程場景（把 spec 當 AI agent 的 prompt）尤其有吸引力，但 spec 的粒度應細到什麼程度？太粗 AI 無法執行，太細等於用另一種語言重寫程式。
- 「先寫 spec 再寫程式」的過程中，如果寫到一半才發現原本的 framing 有問題，回頭成本怎麼最小化？spec 的哪些部分是「冪等的」，哪些是「牽一髮動全身的」？
- Spec 的 success criteria 是否就等同於 TDD 的 red test？兩者粒度往往不同，如何串接而不重複？
🕒 更新紀錄
- 2026-06-29 — 建立專欄。以 Claude Code 官方 spec-driven-development、planning-and-task-breakdown、interview-me、doubt-driven-development 技法檔為主要一手素材，補入 Thoughtworks（2025）、Microsoft 開發者部落格、Innerview Problem Framing 分析等外部來源；5 Whys 溯源至 Toyota 生產系統；全程標示方法論主張與可佐證事實的分界。1 篇 hub＋5 篇原子筆記。