interview-me

訪談我

概述

人們要求的和他們真正想要的是兩回事。他們要求「一個儀表板」，因為那是大家會要求的東西，而不是因為儀表板能解決他們的問題。他們說「讓它更快」，卻沒有具體的數字目標。

發現這個差距最便宜的時機，是在任何計畫、規格或程式碼存在之前。一旦你開始建構，轉換成本就會變得真實，使用者會將錯誤的東西合理化為「夠好了」。錯配就此鎖定。

這項技能在付出任何代價之前就縮小差距。其他定義階段的技能假設你大致知道自己想要什麼：idea-refine 從想法產生變體，spec-driven-development 將需求寫下來，doubt-driven-development 在你草擬計畫後進行壓力測試。而 interview-me 是所有這些之前的部分，你一次問一個問題，並附上你的最佳猜測，直到你能在使用者說出口之前預測他們要說什麼。

使用時機

在以下情況使用此技能：

• 需求缺少至少一項：誰是使用者、為什麼他們想要、成功的樣貌、限制條件是什麼
• 請求是常規而非具體的（「幫我建 X」、「讓它更快」），而且你無法在不猜測的情況下拆解常規
• 你忍不住想從尚未浮上檯面的假設開始
• 當兩個合理的價值互相衝突時（簡單 vs. 彈性、成本 vs. 速度），使用者沒有說他們在最佳化哪一個
• 使用者明確要求：「訪談我」、「拷問我」、「開始之前，我們確定嗎？」、「壓力測試我的想法」

何時不該使用：

• 需求明確且自包含（「重新命名這個變數」、「修正這個錯字」）
• 使用者明確要求速度優先於驗證
• 純資訊請求（「X 怎麼運作？」、「這段程式碼做什麼？」）
• 機械性操作（重新命名、格式化、移動檔案）
• 你已經有 ≥95% 的信心；在假設你沒有之前，重新閱讀下面的停止條件

載入限制

此技能需要一個活躍、有回應的使用者。請勿在非互動環境中呼叫，例如 CI 管線、排程執行、/loop 或自主迴圈。如果你處於其中一種情況且需求不明確，請將其標記為使用者的阻礙，而不是自行猜測。

流程

步驟 1：提出假設，附上信心指數

在問任何問題之前，用一句話寫下你目前對使用者想要什麼的最佳解讀，加上誠實的信心指數（0–100%）：

假設：你想要一種在站立會議中回答「我們做得如何？」的方式，而「儀表板」是你想到的常規答案。
信心：~30% — 缺少：給誰用、「指標」在上下文中的意思，以及成功的樣貌

這個數字強迫你誠實。如果你寫了一個很高的數字，但實際上無法預測使用者對你接下來要問的三個問題的反應，那麼這個數字是錯的。從你能夠辯護的信心水準開始。

當信心低於 ~70% 時，在同一行附加一個簡短原因——還有什麼未解決或缺少的。這告訴使用者訪談需要浮現什麼，並防止數字變成模糊的信號。

步驟 2：一次問一個問題，每個問題附上猜測

格式：

Q：<一個聚焦的問題>
猜測：<你對答案的假設，以及產生這個假設的推理>

等待使用者回應後再問下一個問題。

為什麼一次一個，而不是一批：

• 如果你把假設埋在清單裡，使用者無法對你的假設做出反應
• 批次鼓勵略讀和表面答案
• 第三個問題通常取決於第一個問題的答案；一次問完會鎖定錯誤的框架
• 使用者仔細思考的能量是有限的；一次花一個問題

為什麼要附上猜測：

• 使用者對錯誤猜測的反應比從頭產生答案更快
• 它讓你承諾一個你可以明顯錯誤的假設，這讓你保持誠實
• 它浮現出你的假設，而這正是訪談想要揭露的

這裡的風險是禮貌的使用者為了討好而同意你的猜測。透過明顯願意犯錯來減輕風險，並偶爾猜測一個你預期使用者會反駁的方向。

步驟 3：傾聽「想要 vs. 應該想要」

最危險的答案是使用者說出一個深思熟慮的回答聽起來像什麼，而不是他們真正想要的。注意：

• 符合最佳實務模式的答案（「我想要它可擴展」、「乾淨的架構」）但沒有具體細節
• 遵循常規的答案（「大多數應用程式的方式」、「標準方法」）
• 像是「我可能應該…」、「我想我應該…」、「好的工程實務說…」的片語
• 作為目標的流行詞——當「現代」、「可擴展」、「穩健」是答案，而不是具體的結果

當你聽到這些時，要問的問題是：

「如果你不需要向任何人證明這個，你真正想要的是什麼？」

這一個問題通常比前面五個問題更有用。

步驟 4：用使用者自己的話重新陳述意圖

當你的信心很高時，寫下你現在認為使用者想要的。保持簡潔（5–8 行），盡可能使用他們的語言，並結構化以便使用者可以逐行確認或修正：

這是我現在認為你想要的：

- 成果：      <一行>
- 使用者：    <一行 — 誰受益>
- 為什麼現在：<一行 — 什麼改變了>
- 成功：      <一行 — 我們如何知道它有效>
- 限制條件：  <一行 — 主要的限制>
- 不包含：    <一行 — 我們明確不做的事>

是 / 否 / 修正？

包含「不包含」是不可協商的。一半的錯配來自於對不建構什麼的沉默分歧。

步驟 5：確認——明確的「是」，不是「你覺得就好」

門檻是明確的「是」。以下不是「是」：

• 「你覺得最好就好。」→ 使用者在授權，這意味著他們也沒有 95% 的信心。重新提出兩個具體選項作為選擇。
• 「聽起來不錯。」→ 模糊。問：「有什麼要修正的嗎？」沉默不是確認。
• 「好，我們開始吧。」→ 通常是禮貌的結束，不是認可。同樣的後續追問。
• 沉默後接著「好吧，開始吧。」→ 使用者已經放棄訪談，而不是達成共識。停下來問你是否遺漏了什麼。

如果他們修正你，納入修正並重新陳述。循環直到你得到明確的「是」。

95% 信心停止點

當你能對以下問題回答「是」時，你就完成了：

我能預測使用者對我接下來要問的三個問題的反應嗎？

如果可以，你們有共同的理解。停止訪談並產生重新陳述。如果不行，你還沒完成；問下一個問題。

這是一個可檢查的測試，不是一種感覺。它也有一個下限：如果你已經進行了好幾輪仍然無法預測，這是有關需求的資訊，而不是繼續磨下去的理由。停下來告訴使用者：「我問了 X 個問題，但仍然無法預測你的反應。有些根本的東西缺失了。想要退一步嗎？」

輸出

此技能的輸出是一個已確認的意圖陳述：步驟 4 的重新陳述，加上步驟 5 的明確「是」。這就是交付物。規格、計畫和任務清單是下游的；它們消耗此技能產生的意圖。

如果使用者希望意圖持續存在（多階段專案、交接給其他協作者），提議將其儲存到 docs/intent/[topic].md。只有在他們確認後才儲存。

範例

一個簡短的前後對比。

沒有 interview-me：

使用者：幫我建一個我們指標的儀表板
代理人：<開始提議圖表庫和版面配置>

代理人假設了：給誰用、什麼指標、「給我們團隊」的意思、成功的樣貌。這些都沒有被陳述。每個假設都是一個使用者之後可以說「這不是我的意思」的地方。

有 interview-me：

使用者：幫我建一個我們指標的儀表板

代理人：
假設：你想要一種在站立會議中回答「我們做得如何？」的方式，而「儀表板」是你想到的常規答案。
信心：~30% — 缺少：給誰用、什麼「指標」、以及成功的樣貌

Q：     當你說「我們做得如何？」，是誰在問——你一個人、工程團隊在站立會議中、還是往上報（例如你的主管、高階主管、董事會）？
猜測：工程團隊在站立會議中，因為「我們」通常這樣界定範圍，而且站立會議是這個問題被問的地方。如果是給高階主管，指標和框架會差很多。

使用者：其實是給我自己。我老是搞不清楚哪些實驗正在進行，以及它們的早期信號長怎樣。

代理人：
更新解讀：根本不是團隊儀表板。是個人的實驗追蹤器。信心：~60% — 仍然缺少：「早期信號」的意思以及完成的樣貌。

Q：     差距是你不知道有哪些實驗存在，還是你無法在一個地方看到它們的結果？
猜測：第二個。你某處有實驗清單，但它們的結果分散在五個不同的工具，手動對帳是你厭倦的事。

使用者：其實是第一個。我根本沒有一個清單。它們分散在不同的文件中。

代理人：<繼續>

兩個問題之後，代理人發現真正的需求不是「一個儀表板」。而是「一個清單」。不同的產出、不同的範圍、不同的工作。儀表板會是錯的。

與其他技能的互動

• idea-refine：下游。如果確認的意圖是「我想要 X，但我不知道如何界定範圍」，交給 idea-refine 根據現在明確的意圖產生變體。
• spec-driven-development：下游。如果確認的意圖是具體的（「我想要 X 給 Y 使用者，有 Z 成功標準」），交給 spec-driven-development 寫下來。
• planning-and-task-breakdown：此技能下游兩步（在規格之後）。
• doubt-driven-development：時間線的另一端。Interview-me 是決策前的意圖提取；doubt-driven 是決策後的產出審查。兩者都捕捉分歧，但在不同時機。
• source-driven-development：正交。Interview-me 釐清使用者想要什麼；SDD 驗證框架事實。它們不衝突。

常見的合理化

合理化	現實
「需求夠清楚了」	如果你現在無法用一句話寫出使用者想要的成果，需求就不清楚。在決定之前先執行步驟 1。
「問太多問題浪費他們的時間」	4–6 個有針對性的問題浪費的時間很小。建構錯誤的東西浪費的時間巨大，而且使用者是承擔那個成本的人。
「我一邊建構一邊弄清楚」	程式碼存在後的轉換成本是現在的 10 倍。實作期間的發現是重工。
「他們說『你覺得就好』，所以我應該直接決定」	「你覺得就好」是授權，不是決定。重新提出兩個具體選項作為選擇。
「我應該給他們幾個選項來挑」	當使用者知道他們想要什麼並且在取捨之間選擇時，選項才有用。他們還不知道他們想要什麼。列出選項會擴大搜尋範圍；提問則縮小範圍。
「如果我附上我的猜測，我是在引導他們」	引導就是重點。反應比從頭產生更快。風險是諂媚，而不是引導；透過明顯願意犯錯來減輕風險。
「我們談夠了，我懂了」	測試一下：你能預測他們對接下來三個問題的反應嗎？如果不能，你還沒懂。
「使用者說了『是』，我們完成了」	如果這個「是」是在模糊的重新陳述或開放式的「聽起來不錯」之後，這個「是」是空洞的。具體重新陳述並再次確認。

紅旗

• 一條訊息中三個或更多問題：那是批次處理，不是訪談
• 一個沒有附上你假設的問題：那是調查，不是承諾
• 接受「你覺得最好就好」作為最終答案
• 在使用者明確確認你的重新陳述之前，就產出規格、計畫或任務清單
• 問題被框架為「什麼是最佳實務？」而不是「你真正想要什麼？」
• 使用者給出一個顯示專業度的答案（「可擴展」、「乾淨」、「現代」），而你沒有探究這是否真的是他們想要的
• 三輪或更多輪之後你的信心沒有明顯上升：你問錯了問題，退一步重新框架
• 信心指數低於 ~70% 且沒有附上原因：使用者不知道缺少什麼，就無法幫助縮小差距
• 在使用者確認之前就儲存意圖文件（文件本身暗示了一個使用者沒有給出的「是」）
• 在重新陳述中跳過「不包含」這一行（關於非目標的沉默分歧是錯配的一半）

驗證

應用 interview-me 之後：

• [ ] 在第一輪中陳述了一個明確的假設和信心指數
• [ ] 每個低於 ~70% 的信心指數都附有一行原因（還有什麼未解決或缺少的）
• [ ] 問題一次問一個，每個都附上代理人的猜測
• [ ] 當使用者給出顯示專業度或常規的答案時，至少執行了一次「如果你不需要證明，你真正想要什麼？」的探詢
• [ ] 一個具體的重新陳述（成果 / 使用者 / 為什麼現在 / 成功 / 限制條件 / 不包含）被寫回給使用者
• [ ] 使用者用明確的「是」確認了重新陳述（不是「你覺得就好」、不是「聽起來不錯」、不是沉默）
• [ ] 在停止點，代理人能夠預測接下來三個問題的反應
• [ ] 任何交給下游技能（idea-refine、spec-driven-development）的交接都是以確認的意圖為框架，而不是原始不明確的需求