為什麼要進行需求澄清？

在人機協作中，最大的浪費不是程式碼寫得慢，而是寫錯了方向。當開發者提出一個高階、模糊的需求（例如：「重構我們的用戶模組，使其支援雙重驗證」），AI 助手如果立刻開始動手修改程式碼，極易引發災難：

• 假設錯誤：AI 假設你使用的是特定第三方 OTP 服務，但實際上專案約定使用本地密鑰產生。
• 架構衝突：AI 修改了資料庫，但資料庫欄位定義與現有 DBA 的安全規範衝突。

$deep-interview 引進了「蘇格拉底式澄清學」，在動工前強制進行一輪互動式架構訪談，以收斂需求。

互動訪談的核心邏輯

$deep-interview 的核心是主動發問，而非盲目動工。它的運作流程如下：

 ┌──────────────────────┐
 │  User vague request  │
 └──────────┬───────────┘
            │
            ▼
 ┌──────────────────────┐     互動澄清      ┌──────────────────┐
 │   $deep-interview    │◀──────────────────┤  3 點技術分歧問卷  │
 └──────────┬───────────┘                   └──────────────────┘
            │
            ▼
 ┌──────────────────────┐
 │  Agree on decisions  │
 └──────────┬───────────┘
            │
            ▼
 ┌──────────────────────┐
 │      $ralplan        │
 │ Planner→Arch→Critic  │
 └──────────┬───────────┘
            │
            ▼
 ┌──────────────────────┐
 │     $ultragoal       │
 └──────────────────────┘

1. 尋找分歧點 (Decision Triggers)： 分析使用者的需求描述，並比對專案 codebase，找出技術實現上的分歧點（例如：UI 選擇、資料庫設計、接口兼容性）。
2. 生成收斂問題： 將這些分歧點轉化為 2-3 個具備 A/B 選項的選擇題，在終端機中阻塞呈現。
3. 達成決策共識： 根據開發者的回答固定關鍵約束，但不直接把「訪談結束」視為 execution approval。
4. 交給 $ralplan 審查計畫： Planner → Architect → Critic 以 advisory evidence 檢查 scope、風險與驗收條件；確認後才由 $ultragoal 進入持久執行。

訪談學的三大原則

為了確保訪談的高效，OMX 遵循以下發問原則：

• 不問瑣碎問題：不問諸如「按鈕要用什麼顏色」等次要細節，只聚焦於影響代碼編譯與專案架構的 Critical Decisions。
• 提供預設推薦 (Recommended Defaults)：每個問題都必須提供一個推薦選項（例如：「[A] (推薦) 保留舊方法，以保持相容」），幫助開發者快速決策。
• 把訪談結果變成規劃輸入：訪談回答應形成可追蹤的需求約束，再交給 $ralplan 檢查，而不是把問答結束直接等同於「任務已批准可執行」。