這篇文章一開始其實不是現在這個樣子。
我原本只想寫一篇關於 AI 協作的文章。我剛完成一個蠻複雜的網站專案，過程中用了 AI 釐清需求、規劃功能、執行修改，也不斷 review 它做出來的結果。我覺得這個經驗值得整理，但還不確定真正想談的是工程流程、怎麼 review AI，還是怎麼把模糊需求慢慢做清楚。
如果我當時直接請 AI 幫我產生一份文章 spec，它應該也能列出讀者、主題、案例和文章結構。那份 spec 可能看起來很完整，我也可以逐段給 feedback，再讓它開始寫。
但這次我沒有這樣做。我叫 AI 先 Grill 我。
它一次只問一個問題，也會同時提供幾個方向和推薦答案。我回答「可以」、「不太對」，或補上一段自己的想法之後，它才根據我的答案繼續問下一題。
最後，文章從一個很廣的「我如何和 AI 協作」，慢慢變成一個比較清楚的觀點：我們不只可以學習怎麼問 AI，也可以讓 AI 有機會反過來問我們。
我後來才發現，這個過程本身就是我真正想寫的內容。
Spec 不只是一份文件，也可以是形成判斷的過程
現在很常見的做法，是先給 AI 一段需求，請它產生 spec，再由人 review。這當然比一句「幫我做完」更可靠，也很適合需求已經清楚、只需要整理成執行文件的情況。
但有些時候，我並不是已經知道答案，只是還沒有把它完整說出來。我是在比較不同選項、修正 AI 的推薦、回答下一個問題的過程裡，才逐漸知道自己真正想要什麼。
如果 AI 太早產生完整 spec，我很容易進入 review mode：這段可以、那段要改、還缺一個例子。我的 feedback 會被限制在它已經建立好的框架裡。多輪 Grill 則多給了我幾次重新定義問題的機會。
對我來說，兩種方式都合理。差別只在於：我現在需要的是一份可執行的文件，還是我其實仍需要更多機會形成自己的判斷？
推薦答案讓我更容易知道自己不同意什麼
Grill Me 對我特別有幫助的地方，是它不只丟給我一個很大的開放式問題。
「你想寫一篇什麼樣的文章？」還是很難回答。但如果 AI 提出幾個方向，說明它們會把文章帶去哪裡，再告訴我它推薦哪一個，我通常很快就會產生反應：這個太像工具教學、那個太專案 specific、這個方向接近了，但我真正重視的不是更好的 spec，而是人怎麼把自己的判斷放進去。
所以推薦答案的價值不一定是它答對了。很多時候，它只是提供一個足夠具體的東西，讓我可以接受、修正或反駁。
這也表示我不希望 AI 每次只給一個看似最專業的答案。那很容易讓人直接沿用它的 framing。比較好的方式是給少量但有差異的選項、說明推薦理由，也保留一個可能：我可以回答「都不是」。
AI 在這裡不是替我決定，而是幫助原本隱性的決策浮現。
有些事情，做到一半才知道還需要決定什麼
這個方法不只適合寫文章。
例如，一開始的需求可能只是：希望內容頁可以播放一段很長的錄音。聽起來很明確，AI 也可以立刻規劃上傳欄位、播放器和各種平台支援。
但我們一題一題往下問之後，才發現真正的選擇包括：音檔要放在哪裡？是直接音訊檔，還是 podcast 平台？既有的內文是不是已經能處理其他 embed？新的功能要解決所有音訊來源，還是只先支援目前缺少的長音檔？播放器需不需要自己的標題和說明？
回答完之後，功能反而縮小了。新的 feature 只需要解決長音檔播放；其他複雜來源繼續用既有的內文處理，不需要為了想像中的彈性一次做完所有可能性。
而且規劃不一定只發生在 build 之前。做出第一個可以 review 的段落後，實際畫面和資料會暴露新的問題。我可以再停下來確認下一步，而不是要求 AI 一開始就寫出一份涵蓋所有情況的完整 spec。
這也是我現在比較喜歡的節奏：想清楚一段，做一段，看見新的 evidence，再決定下一段。
不是每一件事都需要完整 Grill
如果工作很明確、修改很容易回復、驗收方式也清楚，直接做通常比較合理。我不會為了使用一個 skill，讓每件小事都多出一套訪談流程。
但即使需求已經蠻清楚了，讓 AI 快速問一輪還是可能有幫助。這時不是從零 discovery，而是請一個第三者做簡短的 blind-spot check：是否漏掉某個使用情境？哪個假設還沒有證據？有沒有一個現在看似簡單、做下去卻很難回頭的選擇？
真正需要記住的其實只有一件事：遇到一件模糊、重要，或你想好好一步一步釐清的事情時，主動跟 AI 說「Grill 我」。
如果使用 Claude、Codex 或其他支援 skills 的工具，也可以直接請 AI 幫你安裝 grill-me／grilling。但安裝本身不是重點。即使沒有 skill，也可以直接這樣說：
先不要開始做。一次問我一個問題，每題提供幾個選項和你的推薦，直到我們對需求、取捨與完成條件有共同理解。
把 AI 用量花在方向，而不只是產出
我現在也不是有無限 AI 用量的重度使用者。很多時候，我只有一般的月費訂閱，所以仍然會在意 model、effort 和 context 的成本。
多輪對話不代表每次都要重新處理全部內容。支援 cache 的系統可以重用不少既有 context；我也會根據這件事需要多少推理、查找資料和工具操作，選擇適合的 model 與 effort。不過實際用量仍會因工具而異，我不會把 Grill 寫成一定比較省 token 的方法。
我更在意的是：方向對了之後，後面的 token 才真的有用。
如果一開始的 framing 就偏了，即使 AI 很快產出完整 spec、程式或文章，我仍然要花時間 review、修正，甚至整份重做。相較之下，把一部分用量花在多問幾個重要問題，常常能減少後面大量無效的產出。
所以我想最大化的不是每個 token 產生多少文字，而是其中有多少內容真的承載了我的判斷。
我真正想要的，也不是讓 AI 替我把更多重要的事情做完，而是借助 AI，讓我把事情完成得很重要。