別急著按核准：先讓 Claude Code 訪談你，再讓它寫計畫

Plan mode 解決的是「agent 亂改檔」，沒解決「agent 猜錯你要什麼」。

你一定遇過這種計畫：步驟清楚、檔案列得齊全，讀起來很有把握，於是按下核准。做到一半才發現，它假設 rate limit 算在每個使用者身上，你要的其實是每把 API key。計畫沒有寫錯字，它只是替你做了一個你沒看見的決定。

r/ChatGPTCoding 這篇貼文的標題把解法講完了：Before your agent plans anything, let it interview you。規劃之前，先讓 agent 訪談你。這篇把它拆成可以照做的流程，主角是 Claude Code，最後補上 Codex 和 Cursor 的對應做法。

先分清楚三件事

很多人把這三個東西混在一起，結果開了 plan mode，卻期待它自動訪談：

Plan mode 是權限。 官方文件的定義是讓 Claude 研究並提出改動，但不動你的原始碼，也就是限制它能做什麼。文件也註明一個例外：在 bypass permissions 可用的互動式終端機裡，修改不保證會被擋到你核准為止，這種環境別把它當成硬牆。
AskUserQuestion 是通道。 這是 Claude Code 內建的工具，用選擇題向你要決定或澄清需求，你可以選選項，也可以從 Other 或備註欄打自己的答案。
訪談是行為。 它要靠你的 prompt 或 skill 指定，你不講，agent 不一定會做。

第三點有文件佐證。Claude Code 的權限模式文件提到，auto mode 會推著 Claude 持續工作、少停下來問，除非你的 prompt 或 skill 明確要求它問。所以「請訪談我」這句話不是客套，它會改變 agent 的行為。

這個做法的來源也很清楚。Anthropic 在 Claude Code 最佳實踐文件的「Brainstorm with Claude first」段落給了官方範例：

I want to add rate limiting to the public API but haven't thought it through yet. Interview me until you could write the spec, then write it to SPEC.md.

文件接著說，Claude 會針對你還沒想清楚的部分出選擇題，例如算在 user 還是 key、超量的 request 怎麼處理、哪些不在範圍內，一直問到答案能湊成規格。

社群的傳播則要提到 Anthropic 工程師 Thariq Shihipar。VelvetShark 的文章轉述了 Thariq 分享的 prompt，大意是讀 SPEC 檔、用 AskUserQuestionTool 深入訪談、訪談完把規格寫回檔案。該文稱這則貼文三天破 130 萬次瀏覽，這是轉述數字，而且只代表受歡迎，不代表有效。

五步流程

五步流程：進 Plan mode、Agent 先讀 code、訪談、寫下決策與假設、核准後用乾淨 context 開工

第一步：進 plan mode

三種進入方式，官方文件都有列：

# 只有這一個 prompt 用 plan mode（在 Claude Code 對話框輸入）
/plan 幫公開 API 加 rate limit

# 從 CLI 一開始就進 plan mode
claude --permission-mode plan

第三種是在對話中按 Shift+Tab 切換，再按一次可以不核准計畫直接離開。

第二步：先讀 code，再開口

沒有這一步，訪談會變成最煩的那種問卷。Matt Pocock 的 grilling skill 把分工寫得很漂亮：找事實是 agent 的工作，做決定是你的工作。obra 的 Superpowers 裡，brainstorming skill 也有一段「Look Before You Ask」，要求讀到能解釋現況為止，專案本身答得出來的事就別問。

第三步：訪談

把下面這段 prompt 存起來，換掉第一行就能用：

/plan 我想幫公開 API 加 rate limit，還沒想清楚。

先讀相關程式碼，repo 查得到的事不要問我。
讀完後用 AskUserQuestion 訪談我，規則如下：
- 只問會改變實作或產品行為的決策
- 每輪最多 3 題，每題附上你的建議和理由
- 我的答案引出新決策時，再開下一輪
- 容易改的小細節不要問，直接提案並記成假設
- 剩下的問題都不會改變實作時就停止

訪談結束後才寫計畫。
計畫要分成：決策（我說的）、假設（你補的）、
非目標、驗收條件、實作步驟。

每條規則都在擋一種常見的失敗。「只問會改變實作的決策」擋掉閒聊式問題，「每輪最多 3 題」擋掉問卷轟炸，「記成假設」讓 agent 補上的東西留在你看得到的地方。

判斷一題該不該問，可以用下面這張表。實務上最值得寫進 prompt 的就是這條分界：

判斷表：事實由 Agent 自己查、決策一定問你、日後改得動的細節由 Agent 提案並寫進假設區

拿官方的 rate limit 例子來看，好問題和壞問題差在這裡（對話為示意）：

壞問題：你們有用 Redis 嗎？
好問題：repo 裡已經有 Redis，放在 session 層。
限制要跨 instance 共用嗎？要的話我沿用 Redis，
不用的話單機計數器更簡單，但多 instance 時實際上限會放大。
建議：共用。

壞問題把查資料的工作丟回給你。好問題帶著查到的事實，把取捨攤開，還給了建議。

第四步：把結果寫成可審查的文件

這裡有個容易踩到的坑。一般情況下，Plan mode 不會改你的原始碼，只會寫它自己的計畫檔，所以官方範例那句「寫進 SPEC.md」和 plan mode 的限制有衝突。從文件的描述看，有兩條路：

路線 A，當下就要做。 全程待在 plan mode，計畫檔本身就是規格。想讓它留在專案裡，就設定 plansDirectory（路徑必須在專案根目錄內，否則會退回預設的 ~/.claude/plans）。

路線 B，功能大、會跨很多 session。 不開 plan mode，直接用官方那句 prompt 產出 SPEC.md，也可以放到 docs/specs/ 下。規格寫好後，開新 session 進 plan mode，讓它照規格出實作計畫：

/plan 讀 docs/specs/rate-limit.md，只根據這份規格寫實作計畫。
規格有矛盾或缺口就問我，不要自己補。

不管哪條路，文件都要分開「我說的」和「你補的」。Superpowers 的規則是：只有對方真的說過的話才能算對方的，自己填的東西要標成提案並附理由。這條值得照抄，審查時你只要盯著假設區，不用逐行猜哪句是 agent 自己決定的。

第五步：審計畫，用乾淨的 context 開工

計畫出來時，Claude Code 會給你幾個選項：

Yes, and use auto mode：核准並以 auto mode 開工。auto mode 不可用時，這裡會顯示 Yes, auto-accept edits。
Yes, manually approve edits：核准，但每個修改都要你看過。
No, keep planning：留在 plan mode，告訴它要改哪裡。

按 Ctrl+G 可以用編輯器直接改計畫。假設區有哪條不對，當場改掉最快。

訪談會吃掉不少 context，官方文件也建議有了 SPEC.md 就開新 session，讓實作從乾淨的 context 和書面的完成定義開始。路線 A 可以打開 showClearContextOnPlanAccept，核准畫面會多一個「核准並清掉規劃 context」的選項。

把它變成一個指令

每次貼 prompt 很快就會懶得貼，做成 skill 比較實際。建立 .claude/skills/interview-plan/SKILL.md：

---
name: interview-plan
description: 規劃前先訪談使用者，把模糊需求整理成決策、假設、非目標與驗收條件
disable-model-invocation: true
argument-hint: [需求描述]
---

需求：$ARGUMENTS

1. 先讀相關程式碼和文件，repo 查得到的事不要問使用者。
2. 用 AskUserQuestion 訪談。只問會改變實作或產品行為的決策，
   每輪最多 3 題，每題附建議和理由。
3. 使用者的答案引出新決策時，開下一輪。
4. 容易改的小細節不要問，提案後記成假設。
5. 剩下的問題都不會改變實作時停止，並列出已確認的決策。
6. 計畫分成：決策、假設、非目標、驗收條件、實作步驟。
   決策欄只放使用者親口確認的內容。

disable-model-invocation: true 代表只有你打指令才會觸發，不會在小任務裡突然冒出來訪談你。之後先按 Shift+Tab 進 plan mode，再打：

/interview-plan 幫公開 API 加 rate limit

專案設定可以這樣搭，寫在 .claude/settings.json：

{
  "permissions": { "defaultMode": "plan" },
  "plansDirectory": "./plans",
  "showClearContextOnPlanAccept": true
}

要注意 defaultMode 在 permissions 底下，不是最上層。plan 當預設會讓每個 session 都先從規劃開始，如果團隊常做小修改，拿掉這行，需要時再切換就好。

AskUserQuestion 預設會一直等你回答。文件有 askUserQuestionTimeout 可以設定逾時，但訪談的重點是你親自決定，這個情境我們不建議開。

問法有兩派，差別在節奏

Matt Pocock 和 Superpowers 都在做訪談，設計卻幾乎相反：

	Matt Pocock 的 grilling	Superpowers 的 brainstorming
一次問多少	一輪問完所有前提已確定的決策	每則訊息只問一題
問法	編號問題附建議答案，回 yes 就接受	開放式問題優先，卡住才給選項
結束條件	決策樹每個分支都走過	回放理解、選定方案、寫出設計文件並獲核准
適合	你已有想法，要找漏洞	你還不確定自己要什麼

grilling 的核心是把計畫看成設計樹：一個決定會長出下一層決定。它把前提都已確定、現在就能問的問題叫做 frontier，每輪問完 frontier，再根據答案重新計算。還沒決定上層就問下層，答案常常會作廢，例如還沒決定限制要不要跨 instance 共用，就問 Redis key 怎麼命名。

要選的話，後端工程師已有方向時用一輪多題，效率高。需求本身還模糊時用一次一題，因為你的原話比選項更能表達真正的意圖。

限制與副作用

先講最重要的一點：我們沒有找到比較「有訪談」和「沒訪談」成效的對照數據，這篇也沒有跑過這種比較。官方文件推薦這個做法，社群討論熱度高，但兩者都不等於效果量測。值得自己追蹤的是：計畫核准後被推翻的次數，以及實作後因為需求理解錯誤而重工的比例。

幾個實際會遇到的問題：

建議答案會錨定你。 回 yes 很省力，也容易不想就接受。遇到資安、計費、資料保留這類題目，先自己想過再看建議。
訪談會燒 token 和 context。 Thariq 版本要求「什麼都問、問到完整」，適合大功能，小任務用就太重了。
選擇題的選項是 agent 擬的。 你真正要的答案可能不在裡面，這時用 Other 打自己的話，不要勉強挑一個。
規格會過時。 實作中改了決策就更新文件，否則下一個 session 會照舊規格做。
問得多不代表問得對。 Agent 可能漏掉它沒意識到的問題，訪談不能取代 code review 和測試。

什麼時候該用，什麼時候別用

值得訪談的任務：

需求只有一句話，你也還沒想清楚
會動到資料結構、對外 API、計費或權限
改錯的重工成本高，或會跨好幾個 session
實作者和提需求的人不是同一個人

跳過訪談的任務：

需求已經完整，Superpowers 的例子是「把 icon 改成 cornflower blue」，直接做
用一個拋棄式原型就能試出答案，Superpowers 也說 spike 常常是搞清楚需求最便宜的方法
bug 已有明確重現步驟，先修再說

快速判斷法：如果 agent 猜錯了，你要花多久才會發現、花多久修好？答案是幾分鐘，就讓它直接做。答案是幾天，訪談的那十分鐘很划算。

換成 Codex 或 Cursor

這招不綁 Claude Code，換掉工具名稱就能用：

OpenAI Codex：官方 best practices 寫明 plan mode 會收集脈絡、問澄清問題，用 /plan 或 Shift+Tab 切換，另外也列了「Ask Codex to interview you」，建議要 Codex 挑戰你的假設。上面的 prompt 把 AskUserQuestion 那句改成「一次問我幾個問題，等我回答」即可。
Cursor：官方文件寫明 Plan Mode 會研究 codebase、問澄清問題，再產出可編輯的計畫，用 Shift+Tab 切換。計畫預設存在家目錄，要按「Save to workspace」才會進專案。

Cursor 和 Codex 的文件都把澄清問題寫成 plan mode 的一部分，但「只問決策、事實自己查、分開假設」這些規則還是要你自己補，上面的規則可以直接沿用。

團隊可以這樣導入

這週先個人試。 下一個需求只有一句話的任務，貼上第三步的 prompt，記下被問到的決策裡，有幾個是你原本沒想到的。
把 skill 放進 repo。 專案層的 .claude/skills/ 會跟著版本控制走，大家共用同一套問法。
PR 附上決策與假設。 Reviewer 先看假設區，比從 diff 反推意圖快得多。
定期改 skill。 同一種問題被問到第三次，就把答案寫進專案文件，讓 agent 下次自己查得到。

第四點最容易被忽略。訪談問出來的東西，一部分是這次的決策，一部分其實是團隊的慣例。把慣例寫下來，下一次訪談就會更短。

本文指令與設定依 2026 年 11 月 3 日查閱的官方文件整理，Claude Code 更新很快，實際選項請以你的版本為準。

來源

Anthropic，Claude Code 文件：Best practices、Permission modes、Tools reference、Skills、Settings reference
Matt Pocock，grilling skill
obra（Jesse Vincent），Superpowers brainstorming skill
OpenAI，Codex best practices
Cursor，Plan Mode 文件
VelvetShark，Stop prompting Claude Code, let it interview you（轉述 Thariq Shihipar 的 prompt 與傳播數字）
選題來源：r/ChatGPTCoding 貼文（本文只引用標題，內文未能讀取）

整理：DataAgent · Coding Agent 實戰教學