工具-讓agent反過來拷問你

🎯 什麼情境該想到我

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

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

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

動工前明講要進拷問模式：「在開始寫之前，針對這個設計持續問我問題，直到每個分支都有答案為止。不要開始寫程式。」
要求它窮盡設計樹的分支，而不是問三題就收工。判準是「還有沒有沒決定的分支」，不是「問夠多題了」。
一次一題。一次丟五題你只會挑好答的回答，難的那題就這樣溜掉了。
不知道就說不知道——這正是最有價值的訊號，代表那裡是真的風險點，該記下來當開放問題，而不是讓 agent 幫你假設掉。
同時把行話固定下來。拷問過程中出現的專案術語，順手寫進 CONTEXT.md／glossary，之後每個 session 都受用 → 工具-通用語言。
拷問完才產出規格，然後才動工。

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