interview-me

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 式答案而你照單全收沒追問
• 三輪以上信心沒有明顯上升：你在問錯問題，退一步重新框
• 複述漏掉「不做什麼」

驗證

• 第一輪就寫了明文假設與信心數字
• 信心低於約 70% 時附了一句缺什麼
• 一次一題，每題附猜測
• 使用者給出話術式答案時至少追問過一次「不用交代的話你要什麼」
• 寫了具體複述（結果 / 使用者 / 為什麼現在 / 成功標準 / 約束 / 不做什麼）
• 拿到明確的「可以」（不是「你看著辦」、不是「聽起來不錯」、不是沉默）
• 下游交接（OpenSpec / brainstorming）用的是確認過的意圖，不是原始模糊需求