工具-讓agent反過來拷問你

🎯 什麼情境該想到我

當你「交代完需求，agent 埋頭做完，你一看發現它完全誤解」的時候——或者更常見的：你自己其實也還沒想清楚。

「沒有人確切知道自己要什麼。」——《Pragmatic Programmer》

核心是把提問方向反轉：不是你交代 agent，是 agent 先拷問你。

動工前明講要進拷問模式：「在開始寫之前，針對這個設計持續問我問題，直到每個分支都有答案為止。不要開始寫程式。」
要求它窮盡設計樹的分支，而不是問三題就收工。判準是「還有沒有沒決定的分支」，不是「問夠多題了」。
一輪問完「現在能問的」，每題附建議答案。Matt Pocock 目前的 grilling skill 先把設計畫成一棵樹，每一輪只問前提都已經定案的那些題（frontier）：每題編號、各附一個建議答案，而且措辭設計成回「yes」就等於採用建議；答案依賴本輪其他未定題的，留到下一輪。你答完，樹往外長，再算下一輪。查得到的事實由 agent 自己查（派 sub-agent 去看檔案、環境），只有決策丟給你。等到沒有未定的分支、而且你確認雙方理解一致，才算結束。（1.2.0 以前是一次只問一題；改成整輪問後，同樣 13 題約 3 輪問完。查證 2026-10-15）
不知道就說不知道——這正是最有價值的訊號，代表那裡是真的風險點，該記下來當開放問題，而不是讓 agent 幫你假設掉。
同時把行話固定下來。拷問過程中出現的專案術語，順手寫進 GLOSSARY.md（Matt Pocock 的 skill 在 1.3.0 前叫 CONTEXT.md），之後每個 session 都受用 → 工具-通用語言。
拷問完才產出規格，然後才動工。

小改動不要用。改個文案、修個明顯的 bug，拷問的成本遠大於誤解的成本。
它會很煩，那是特性不是缺陷。覺得被問到不耐煩時，通常正是你原本會出事的地方（我的判斷）。
要明確叫它「先不要寫」，否則多數 agent 問兩題就自己開工了（經驗推論）。
這不能取代你自己想。它逼你面對沒想過的分支，但答案還是你要給；對建議答案回「yes」沒問題——那是你看過之後做的決定；但如果每題都回「你決定就好」、連建議都沒看，就等於跳過了決策，拷問只是換一種方式讓 agent 自己猜（我的判斷）。
跟需求前置條件不同：工具-建構的先決條件講的是「專案該先確立哪些事」（人的流程），這張講的是「怎麼跟 agent 把它挖出來」（互動手法）。兩張搭配用。