這篇文章一開始，其實不是現在這個樣子。
我原本只是想整理一段和 AI 協作的經驗。前陣子完成了一個蠻複雜的網站專案，從釐清需求、規劃功能到實際修改，都有 AI 參與；我的工作則是不斷 review 結果、指出問題，再決定下一步。這段經驗值得寫下來，但當時還不確定，真正想談的是工程流程、如何 review AI，還是如何把模糊需求一步步做清楚。
如果直接請 AI 產生文章 spec，它大概也能列出讀者、主題、案例和文章結構。接下來只要逐段給 feedback，就可以讓它開始寫。
但這次，我沒有先要一份 spec，而是先叫 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 的用量再多，也不代表值得把它花在錯誤方向上。對我來說，真正的問題不是能產生多少內容，而是較好的模型與更多思考時間，是否用在真正重要的判斷上。
多輪對話不代表每次都要重新處理全部內容。支援 cache 的系統可以重用不少既有 context；也可以根據這件事需要多少推理、查找資料和工具操作，選擇適合的 model 與 effort。不過實際用量仍會因工具而異，因此不能把 Grill 寫成一定比較省 token 的方法。
更重要的是：方向對了之後，後面的 token 才真的有用。
如果一開始的 framing 就偏了，即使 AI 很快產出完整 spec、程式或文章，後面仍然得花時間 review、修正，甚至整份重做。相較之下，把一部分用量花在多問幾個重要問題，常常能減少大量無效的產出。
真正值得最大化的不是每個 token 產生多少文字，而是其中有多少內容真的承載了我的判斷。
我真正想要的，也不是讓 AI 替我把更多重要的事情做完，而是借助 AI，讓我把事情完成得很重要。
如果方向已經形成，下一步可以讀〈從輸入到具體成果，是一種可以訓練的能力〉。
如果 AI 已經開始同時處理不同工作，可以接著讀〈當 AI 開始處理各種工作，該怎麼分配它們？〉。