定義錯問題，然後把它解得很漂亮，是工程裡最浪費的一種浪費。這個專欄把兩件事放在一起討論：Problem Framing（把模糊需求淬煉成一個值得解的問題）與 Spec-Driven Development（在寫任何程式之前先把規格寫清楚）。兩者的核心都是「先想清楚、再動手」，合在一起形成一個閉環：問題 → 規格 → 實作 → 驗證 → 重新問問題。
這不是純理論。Thoughtworks 在 2025 年把 Spec-Driven Development 列為 AI 輔助工程的關鍵新實踐；Microsoft 稱之為「AI-native engineering 的規格先行方法」；5 Whys 源自 Toyota 生產系統，半個世紀來業界廣泛採用。本專欄全程標示哪些是方法論主張（合理但難量化），哪些是有跡可循的業界實踐或可佐證事實。
專欄第二輪延伸了「如何用 Claude 落地這套方法論」：涵蓋 Claude Code 的 skills、subagents、hooks、MCP、CLAUDE.md 這些機制，以及在三個開發情境（大功能、架構設計、維護）中對應哪些 skill 組合。
學習路徑
方法論核心
- Problem Framing：定義正確問題 — 為何先 framing、核心工具（5 Whys、HMW、JTBD）、常見反模式
- Spec-Driven Development：規格先行 — 四階段閘門工作流程、spec 寫什麼、與直接動手的對比
- Framing → Spec → 實作 → 驗證：閉環全景 — 全流程每個環節的輸入輸出、常見短路點
- 實戰：從一個模糊需求走完全流程 — 一個具體小案例，從「體驗更好」到可執行 spec
- 延伸：TDD、Planning、ADR、Doubt-Driven 的關係 — 這套流程怎麼和其他工具銜接
用 Claude 落地
- 用 Claude 做開發輔助：機制層全景 — Skills、Plugins、MCP、Subagents、Hooks、CLAUDE.md、Scheduled Tasks 的分工與層次
- 用 Claude 輔助開發：三個情境的 skill 組合 — 大功能開發 / Architecture 設計 / Maintenance 維護的 skill 鏈與 Claude 機制介入點
形式化方法工具
- kiro-frame：Problem Frames 形式化工具 — Zave–Jackson S∧W⊨R 模型、五個基本 frame、W Register 擋住 AI 幻想假設、卡進 cc-sdd pipeline 的方式與誠實評價
延伸：Problem Frames 作為更大流程的一環
Problem Frames 在「Event Storming → Problem Frames → Event Sourcing → 前端 → Pattern Language」這條領域設計流程裡擔任框定+假設顯性化的輔助角色——把 Event Storming 挖出的 Hotspots 轉成可形式化的 W Register，再把 Aggregates 的不變量寫進 S∧W⊨R 驗證。見 Event Storming + Event Sourcing + Pattern Language：AI 輔助領域設計流程。
🔍 待解問題 / 持續追蹤
- Problem Frames 的形式化成本不低（Zave–Jackson 論文 + Jackson 書本身就是進入門檻）；「何時形式化的收益超過啟發式工具」有無更清晰的判準，而不只是「複雜系統用、簡單系統不用」這個粗粒度建議？
- W（Domain Assumptions Register）把假設狀態分成 verified / assumed-risk / to-confirm，但「to-confirm」掛著的假設若在 spec-design 之後才被確認是錯的，回修成本有多大？W Register 的最晚確認時間點是哪裡？
- Problem Framing 的價值幾乎沒有爭議，但「framing 時間應佔總開發時間多少比例」業界並無統一標準；有團隊 30 分鐘就夠，有的需要幾天發現期。門檻在哪？
- 5 Whys 的批評者指出：不同人、不同時間問同一個問題，可能得到截然不同的根因鏈——它找到的是「一條」根因路徑而非「唯一」根因。這個限制如何在實務中處理？
- Spec-Driven 在 AI 輔助工程場景（把 spec 當 AI agent 的 prompt）尤其有吸引力，但 spec 的粒度應細到什麼程度？太粗 AI 無法執行，太細等於用另一種語言重寫程式。
- 「先寫 spec 再寫程式」的過程中，如果寫到一半才發現原本的 framing 有問題，回頭成本怎麼最小化？spec 的哪些部分是「冪等的」，哪些是「牽一髮動全身的」？
- Spec 的 success criteria 是否就等同於 TDD 的 red test？兩者粒度往往不同，如何串接而不重複？
- CLAUDE.md 的品質難以「客觀量測」——「開一個新 session 讓 Claude 描述專案」是一個啟發式測試，但仍是主觀判斷。有無更系統化的 CLAUDE.md 品質評估方法？
- Hooks（PostToolUse 自動跑測試）的回饋迴圈在大型 monorepo 中可能太慢（full test suite 需幾分鐘），如何設計適當的 subset 讓 hooks 速度可接受？
🕒 更新紀錄
- 2026-06-30（第三輪）— 新增「kiro-frame：Problem Frames 形式化工具」。分析 kiro-frame Claude Code skill：Zave–Jackson S∧W⊨R 參考模型（IEEE TSE 1997、Jackson 2001 有出版基礎）、Problem Context 三類域（causal/biddable/lexical）、五個基本 frame 與 concern 清單、W（Domain Assumptions Register）擋住 AI 幻想假設、卡進 cc-sdd pipeline 的非侵入方式、Frame Review Gate 的 entailment 與 well-formedness 檢查；誠實區分方法論主張（skill 效益未量化）與可佐證事實（方法有學術出版）。學習路徑新增「形式化方法工具」段；待解問題補入形式化成本判準與 W Register 最晚確認時間點兩則。
- 2026-06-30（第二輪）— 第二輪延伸。新增「用 Claude 做開發輔助：機制層全景」和「三個情境的 skill 組合」兩篇原子筆記，涵蓋 Skills / Plugins / MCP / Subagents / Hooks / CLAUDE.md / Scheduled Tasks 六個機制，以及大功能開發、Architecture 設計、Maintenance 三個情境的 skill 鏈。一手素材：本機已安裝 skills（spec-driven、planning、incremental-implementation、api-and-interface-design、documentation-and-adrs、debugging-and-error-recovery、observability-and-instrumentation、deprecation-and-migration 等 36 個）；外部來源：Thoughtworks、Microsoft Developer Blog、alexop.dev、duet.so Claude Code Skills Guide；可佐證時間點（MCP Nov 2024、Subagents Jul 2025、Hooks Sep 2025、Plugins Oct 2025、Agent Teams Feb 2026）來自多個獨立媒體交叉確認。
- 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 篇原子筆記。