Framing 容易停留在啟發式層次——5 Whys 問到第五層，HMW 生成幾個方向，但這些輸出通常是非正式的、依賴語感的陳述。Problem Frames 是 Michael Jackson 提出的形式化分析方法，把「機器要造什麼」與「世界的樣子是什麼」嚴格分開，並用一個可驗證的邏輯斷言連起來。kiro-frame 是一個 Claude Code skill，把這套方法接進 cc-sdd 的 spec-driven pipeline，讓 framing 的結果以可被下游 skill 繼承的結構產出，而不只是一份閱讀用的筆記。
理論基礎：Zave–Jackson 參考模型
Pamela Zave 與 Michael Jackson 在 1997 年的論文〈Four Dark Corners of Requirements Engineering〉提出一個參考模型，核心斷言是：
S ∧ W ⊨ R
三個符號各有嚴格定義：
| 符號 | 名稱 | 性質 | 詞彙範圍 |
|---|---|---|---|
| R | Requirement | Optative（期望世界如何） | 世界詞彙 |
| W | Domain assumptions | Indicative（世界現在如何） | 世界詞彙 |
| S | Specification | Indicative（機器在介面上做什麼） | 僅 shared phenomena |
斷言的意思：在世界假設 W 成立、機器確實做到 S 的條件下，需求 R 必然被滿足。這是一個邏輯蘊含，不是一個願景。
為何詞彙分離重要：S 只能用 shared phenomena（機器與世界共同可見的事件或狀態）描述。用世界詞彙描述 S，或用機器詞彙描述 R，都是常見的規格寫壞的方式——混詞彙讓 entailment 無法成立，bug 也因此無法被形式上定位。
可佐證性：Zave–Jackson 模型發表於 IEEE Transactions on Software Engineering（1997），Problem Frames 完整理論收錄在 Jackson《Problem Frames: Analysing and Structuring Software Development Problems》（Addison-Wesley, 2001）。這是有學術出版基礎的形式方法，不是工具文件裡自創的術語。
Problem Context 的三類域
Problem context（問題脈絡）把系統邊界圖分成三個部分：
Machine：待建造的軟體。它只能透過 shared phenomena 接觸世界，不能直接操作世界域的任何事物。
Problem domains（問題域，可有多個）：
| 類型 | 說明 | 範例 |
|---|---|---|
| Causal（因果域） | 有可預測的物理或邏輯因果規律 | 硬體設備、物理系統 |
| Biddable（可請求域） | 可以接受請求但不能被強制 | 使用者、操作員 |
| Lexical（詞彙域） | 資料或符號的表示與儲存 | 資料庫、日誌、設定檔 |
Shared phenomena（共享現象）：機器與某個域在介面上共同可見的事件或狀態，標記方式：
M!：機器控制（Machine initiates）D!：域控制（Domain initiates）
這個標記讓控制權的歸屬顯性化——一個在 spec 裡寫成機器控制但在現實中由用戶發起的現象，是一個隱藏的 W 假設破口。
五個基本 Frame
Problem Frames 把所有子問題歸入五種原型模式，每種對應不同的域組成與關切重點：
| Frame | 核心關切 | 典型域組合 |
|---|---|---|
| Required Behaviour | 機器直接控制並約束一個因果域的行為 | Machine ↔ Causal domain |
| Commanded Behaviour | 透過 biddable 域的指令來控制另一個因果域 | Machine ↔ Biddable ↔ Causal |
| Information Display | 把一個域的狀態即時顯示給觀察者 | Machine ↔ Causal/Lexical ↔ Biddable |
| Simple Workpieces | 操作一個由人編輯的 lexical 域（文件、設定） | Machine ↔ Biddable ↔ Lexical |
| Transformation | 把一個 lexical 域的內容轉換成另一個 lexical 域 | Machine ↔ Lexical ↔ Lexical |
每個 frame 都帶一份 concern 清單，常見條目：
- Initialization：狀態從什麼初始條件啟動？
- Reliability：機器或域故障時如何處理？
- Identities：物件如何被唯一識別？
- Completeness：所有需要處理的事件是否都被涵蓋？
- Overrun：事件產生速度超過處理速度時怎麼辦？
- Breakage：預期的域性質（W 裡的假設）如果不成立，後果是什麼？
一個複雜功能往往是多個 frame 的組合；拆開之後，每個子問題的 concern 才能被獨立檢查。
最高槓桿的產出：W Register
kiro-frame 最有實用價值的輸出不是 frame 圖，而是 W（Domain Assumptions Register）——一份把「AI 否則會默默假設的事」逐條寫成可被檢查的陳述的清單。
每一條 W 有三種狀態：
| 狀態 | 意義 |
|---|---|
verified | 已有具體方式確認（測試、文件、對話記錄） |
assumed-risk | 知道這個假設存在、接受其風險 |
to-confirm | 尚未確認，需要在進入下游步驟前補上 |
為何它對 AI 輔助開發特別重要：LLM 在沒有 W 的情況下，會用訓練資料裡的「常識」填補假設——這些假設通常不被記錄、無法被審核、也不反映目前專案的實際約束。把 W 寫明並附進 brief.md，讓每個下游 skill（spec-requirements、spec-design、spec-tasks）都讀到同一份假設清單，而不是各自猜。這個效果是結構性的，不依賴 prompt 技巧。
方法論主張（未量化）：「顯性 W 能減少 AI 幻想假設」是合理推論，但「顯性 W 能減少多少幻想」並沒有針對這個 skill 的實驗數據。
卡進 cc-sdd Pipeline 的方式
kiro-frame 在 cc-sdd pipeline 裡插入分析層：
/kiro-discovery
│
▼
/kiro-frame <feature> ← kiro-frame 的位置
│ 產出 frame.md
│ → Problem Frame Summary 附進 brief.md
▼
/kiro-spec-init
│
▼
/kiro-spec-requirements
│
▼
/kiro-spec-design
│
▼
/kiro-spec-tasks
│
▼
/kiro-impl
kiro-frame 的介入對下游 skill 是透明的：它只修改 brief.md（追加 Problem Frame Summary），不改變其他 skill 的介面。下游 skill 不需要知道 framing 是否發生——只要 brief 裡有 W 清單，它們自動繼承這個約束。
安裝方式：複製 skill 目錄到 .claude/skills/kiro-frame/。若需要讓 frame-review-gate 在下游 spec 步驟真正去做 entailment 驗證，需在對應 skill 文件加一行引用。
Frame Review Gate
frame-review-gate 是一個驗證關卡，對每個子問題檢查以下條件：
Entailment check：S ∧ W ⊨ R 是否成立？亦即：「如果世界按照 W 的假設運作、機器確實做到 S，R 真的會被滿足嗎？」
五個 well-formedness 條件：
| 條件 | 問題 |
|---|---|
| Consistency | S 的行為要求之間有無矛盾？W 的假設之間有無矛盾？ |
| Non-triviality | S 是否確實做了一些有意義的事？ |
| Vocabulary separation | R 確實用世界詞彙寫？S 確實只用 shared phenomena？ |
| Grounding | W 的假設有無根據——verified 或 assumed-risk 都可，但不能沒有來源 |
| Assumption accountability | 每個 W 的狀態（verified/assumed-risk/to-confirm）是否都已標記？ |
Breakage check：W 的某個假設如果不成立，整個 S∧W⊨R 推導就崩了。Breakage check 逐一問：「這條 W 如果在 production 被打破，最壞情況是什麼？」
與本專欄既有概念的對應
Problem Framing（本專欄第一篇） 用的工具（5 Whys、HMW、JTBD）是啟發式的，目的是找到值得解的問題陳述。kiro-frame 接在這之後，把啟發式結論轉譯成形式化的結構——R/W/S 是對問題陳述（R）和假設清單（W）的精確化，不是替代。
Spec-Driven Development（本專欄第二篇） 的假設浮現機制（「先列出你在假設的事」）與 W Register 在功能上高度對應。差別在於：SDD 的假設清單是 spec 寫作過程的附帶產物，W Register 是 framing 的一級輸出，且有驗證狀態欄位（verified / assumed-risk / to-confirm）。
Framing → Spec 閉環（本專欄第三篇） 的「Specify 環節前，把假設公開可被指正」這個短路防止機制，正是 kiro-frame 的 W Register 要結構性地做到的事。
cc-sdd pipeline 的 /kiro-spec-requirements 等下游 skill，讀到的 brief.md 會含有 Problem Frame Summary；這讓「顯性世界模型 → spec」的連接是機制層面的，不靠每次 framing 完了後手動整理輸出。
誠實評價
優點
- W 是可被審查的文件：把 AI（和人類）會默默假設的事寫成清單，讓每個假設有明確的確認狀態，這是結構性的品質提升，而不只是 prompt 改善。
- S∧W⊨R 是問題定向的正確性判準：「spec 正確嗎」不是感覺題，Entailment check 給出了一個可以操作的問法。
- Five frames 有助發現忽視的域：系統化地問「這個子問題的域是 causal / biddable / lexical？」，常常讓人在 framing 階段就發現被忽略的 stakeholder 或約束。
- cc-sdd 整合是非侵入的：只改 brief.md，下游 skill 不需修改。
取捨與門檻
- 形式化有學習成本：Zave–Jackson 模型和 frame 分類需要一定的學習投入；Jackson 的書本身就是一本 400 頁的學術著作。不熟悉的人在前幾次使用時，framing 的品質可能不如熟練使用 5 Whys 的直覺方法。
- R/W/S 的詞彙分離難以保持：在實際寫作中，「世界詞彙」和「機器詞彙」的邊界不總是清晰；特別是在 biddable 域裡，用戶行為和系統行為的交界很容易模糊。
- 這個 skill 本身的效益是主張：Problem Frames 作為學術方法有出版記錄可佐證，但「kiro-frame skill 讓開發效果更好」屬於工具作者的主張，沒有獨立的實驗驗證。
- 何時不值得用：bug fix、config 變更、或任何問題到解法的映射已經顯而易見的情況，framing 投入大於收益。kiro-frame 自己的文件也明確標出這三類跳過情境。
延伸
- Problem Framing 工具：5 Whys、HMW、JTBD → Problem Framing：定義正確問題
- Framing 結果的下游消費方式 → Framing → Spec → 實作 → 驗證：閉環全景
- cc-sdd pipeline 的 Claude skill 介入點 → 用 Claude 輔助開發：三個情境的 skill 組合
- 回到全景 → Problem Framing ＋ Spec-Driven Development 專欄首頁