OpenAI onepage/ AI coding workflow
Gary Chen · YouTube
700 萬人下載的 /grill-me：先對齊，再叫 AI 寫程式
這支影片拆解 Matt Pocock 最受歡迎的 skill：它不急著產生 code，而是讓 agent 沿著設計決策樹追問。目標不是問得越多越好，而是在動工前消除「你以為它懂了」的錯位。
Published: 2026-07-24Video ID: aR97E7aKEggSource: Gary Chen
01 / 反轉提問者
不是寫更長的 prompt
需求文字再完整，也常漏掉取捨、例外與既有約束。/grill-me 讓 agent 依照它需要的資訊提問，而非靠人預先猜題。
02 / 逐枝收斂
走完決策樹
每個問題都應縮小一個分岔：誰使用、何時發生、資料從哪來、失敗怎麼辦、什麼算完成；尚未決定就不假裝有答案。
03 / 再進入執行
對齊不是交付物
訪談完成後，可再轉成 PRD、可驗收的 issue 或實作任務。重點是把對話中做出的決定留下，避免 agent 在 coding 時重新猜測。
Key signals
這個小 skill 真正處理的是 agent 的哪種失敗？
Failure mode
誤解需求
模型很快開始做事，不代表它和你有同一個問題定義。
Mechanism
連續提問
依賴關係由問題順序顯露：先目標，後範圍與取捨，再談實作。
Output
共同設計
好的結果是雙方都能判斷何時可以停止問、開始做。
Boundary
仍要驗證
對齊不能取代測試、code review、權限控制或產品責任。
How it works
從一句模糊需求，到可交給 agent 的任務
1
先說目標，不急著指定解法
例如「改善訂單列表」還不夠。先釐清使用者要完成的工作、今天的痛點、成功時能觀察到什麼改變，避免把第一個想到的 UI 當成需求本身。
2
讓 agent 挖出分支與依賴
排序還是篩選？資料量與權限如何影響選項？空狀態、錯誤與 migration 誰負責？每一題都在把未說出口的決定變成可討論的選項。
3
把決定壓成可驗收的邊界
當範圍、非目標、資料契約與驗收條件清楚後，才轉成 PRD 或切成垂直 slices。此時 agent 寫 code 是在執行共同定義的任務，不是在即興猜產品。
Use it well
什麼時候值得「被烤問」，什麼時候不用？
適合：決策多、代價高的變更新功能、跨模組改造、資料模型調整、產品規格仍模糊時，問題本身就是降低返工的投資。
適合：人腦有隱性脈絡領域術語、團隊慣例與過去取捨沒寫在 ticket 裡；訪談能把它們攤開來檢查。
不必：可逆、證據明確的小修已有明確 bug、重現步驟、測試與最小修復路徑時，過度訪談只會延遲 feedback loop。
警惕：不要把它變成無限追問為每個分支設定停止條件。能由 codebase、文件或實驗回答的問題，應先查證，而不是全部丟回給人。
Practical prompt
可直接採用的最小工作方式
先帶一個真實任務，而不是叫它「幫我想想」提供目標、已知限制與現有證據；讓問題聚焦在未知決策，而非重新發明已經確認的背景。
每輪回答都回填決定與未決項把已確認、待查證、明確排除三類分開。這比保留一長串聊天紀錄更容易轉交、review 與驗收。
先做小型可驗證切片把共同設計切成可 demo、可測試的垂直任務；最早的 feedback 可以反過來檢驗原本的決定是否合理。
把 /grill-me 視為開始前的協定它不是萬用 prompt，也不保證品質；它的價值是讓重要假設在寫 code 前浮出水面。
Video route
觀看時可抓住的閱讀主線
長 prompt 的盲點人很難完整列出所有決策，模型又會在資訊不足時自信地選一條路。
讓 agent 做訪談者以問題走過設計樹，逐項處理目標、使用情境、例外、邊界與驗收方式。
把共同理解接到工程流程設計對齊後，才能更穩定地生成規格、拆 issue、做實作與以新 context review。
流程不等於保證對齊改善的是理解失真；品質仍須靠可重現的測試、獨立驗證與人類的責任判斷。
References