| name | interview-me |
| description | 需求不明時的意圖萃取訪談：一次一題、每題附上自己的猜測、聽出「真正想要 vs 覺得應該要」，直到能預測使用者反應（約 95% 信心）才動工。適用：需求缺少對象 / 動機 / 成功標準 / 約束，或使用者點名「訪談我」「先確認一下」「我們確定嗎」。明確自足的指示、純資訊查詢、機械性操作不適用。 |
| source | adapted from openclawyhwang-hub/tGD tgd-interview-me (Apache-2.0) |
| updated | "2026-07-13T00:00:00.000Z" |
Interview Me（意圖萃取訪談）
核心
人開口要的跟真正想要的是兩回事。說「做個儀表板」是因為大家都這樣講，不是因為儀表板解決他的問題。抓出這個落差最便宜的時機是在任何計畫、規格、程式碼存在之前；開工之後切換成本是真的，使用者會把錯的東西合理化成「還行」。
本 skill 是前置於 brainstorming 與規格撰寫的階段：一次問一題，每題附上自己的猜測，問到你能預測使用者接下來會說什麼為止。
何時使用
- 需求缺少任一項：這是給誰用、為什麼要、成功長什麼樣、綁死的約束是什麼
- 需求是慣例式而非具體的（「做個 X」「弄快一點」），不猜就無法展開
- 你發現自己正在默默腦補沒被講出來的需求
- 兩個合理價值在拉扯（簡單 vs 彈性、成本 vs 速度）而使用者沒說要哪個
- 使用者明確點名：「訪談我」「先確認一下」「我們確定嗎」
不適用：指示明確自足（改名、修 typo）、使用者明說要快不要驗、純資訊查詢、機械性操作、你已有 95% 以上信心（先重讀下方停止條件再認定沒有）。
前提限制
需要活的、能回話的使用者。非互動情境（CI、排程、autonomous loop）禁用；在那些情境遇到需求不明，標記為 blocker 呈報，不要用猜的。
流程（五步）
Step 1：先寫假設，附信心數字
問任何問題之前，先用一句話寫下你目前對需求的最佳解讀，加上誠實的信心數字：
假設：你要的是在 standup 回答「我們狀況如何」的方法，「儀表板」只是慣例式的講法
信心：約 30%。缺：給誰用、「指標」指什麼、成功長什麼樣
數字逼出誠實。信心低於約 70% 時，同一行附一句缺什麼，讓使用者知道訪談要補的是什麼。
Step 2：一次一題，每題附猜測
問：<一個聚焦的問題>
猜：<你對答案的假設，以及推出這個假設的理由>
等使用者反應完才問下一題。一次一題的理由：問題塞成清單使用者只會掃讀；第三題常依賴第一題的答案，一次全問會鎖死錯的框架。附猜測的理由：對錯誤猜測做反應比從零生答案快；把你的假設攤在檯面上，這正是訪談要曝光的東西。
風險是客氣的使用者順著你的猜測附和。對策：明顯表現出願意猜錯，偶爾往預期會被打槍的方向猜。
Step 3：聽出「真正想要 vs 覺得應該要」
最危險的答案是聽起來很得體的那種。警訊：
- 套最佳實踐話術（「要可擴充」「架構要乾淨」）但沒有具體內容
- 遵從慣例（「一般 app 都怎麼做」「標準做法」）
- 「我應該要⋯」「好的工程實踐說⋯」
- 目標是 buzzword（「現代」「穩健」）而不是具體結果
聽到這些就問：
「如果不用向任何人交代，你實際上想要的是什麼？」
這一題常比前五題加起來有用。
Step 4：用使用者自己的話複述
信心夠高時，把你認為的需求寫回去，5 到 8 行，讓使用者能逐行確認或修正：
我現在認為你要的是：
- 結果： <一行>
- 使用者： <一行，誰受益>
- 為什麼現在：<一行，什麼變了>
- 成功標準： <一行，怎麼知道做對了>
- 約束： <一行，綁死的限制>
- 不做什麼： <一行，明確排除的範圍>
可以 / 不對 / 要修？
「不做什麼」那行不可省：一半的認知錯位是對「不建什麼」的沉默歧見。
Step 5：要明確的「可以」
以下都不算確認：
- 「你看著辦」：這是委任不是決定，代表使用者自己也沒有 95% 信心。改用兩個具體選項重新問
- 「聽起來不錯」：模糊。追問「有想修的地方嗎」，沉默不是確認
- 「好啦開始吧」：常是客氣的退場。同樣追問
被修正就吸收修正、重新複述，迴圈到拿到明確的「可以」為止。
95% 停止條件
自問：接下來要問的三題，我能預測使用者的反應嗎？能，代表有共同理解，停止訪談、產出複述。不能，就問下一題。這是可檢核的測試，不是感覺。地板：問了好幾輪還是無法預測，這是關於需求本身的資訊。停下來說：「我問了 X 題還是無法預測你的反應，有根本的東西缺了，要不要退一步？」
產出
確認過的意圖陳述（Step 4 的複述 + Step 5 的明確 yes），對話形式即可，不落檔。下游：具體需求走 OpenSpec 提案（openspec/changes/），方案推敲走 superpowers brainstorming，兩者都以確認過的意圖為輸入，不是以原始的模糊需求為輸入。
紅旗
- 一則訊息塞三題以上：那是問卷不是訪談
- 問題沒附自己的猜測：那是調查不是承諾
- 把「你看著辦」當終局答案收下
- 使用者還沒明確確認複述就開始寫規格、計畫、程式碼
- 問「最佳實踐會怎麼做」而不是「你實際上想要什麼」
- 使用者給了 buzzword 式答案而你照單全收沒追問
- 三輪以上信心沒有明顯上升：你在問錯問題，退一步重新框
- 複述漏掉「不做什麼」
驗證
