/grill-me：別讓 AI 說'看起來不錯'，讓它說'這裏有問題

/grill-me 係 OpenCode 嘅一個斜槓命令，亦都係 superpowers 系列技能之一。佢嘅核心行為好簡單：令 AI 用逐題追問嘅方式，對用戶嘅計劃或設計進行地毯式拷問，唔行完決策樹嘅每一塊葉就唔肯停。

常規嘅 AI 交互入面，你畀出一個方案，AI 好大機會會話「睇落唔錯，我幫你實現」。但 /grill-me 唔同——佢強制 AI 企喺對立面，用連續不斷嘅追問嚟檢驗每一個假設、每一個細節、每一個邊界條件。你可以當佢係一個永遠唔會攰嘅設計審查員。

同 brainstorming 比較：brainstorming 係 AI 幫你發散——由一個模糊意圖撞出可能嘅設計方向。grill-me 係 AI 逼你收斂——假設你已經有咗一個方案，佢要通過層層挑戰幫你殺死入面嘅爛決策，淨係留低經得起考驗嘅部分。

grill-me 同 superpowers 嘅最核心分別

好多人第一次接觸 grill-me 會將佢同 brainstorming 撈亂。佢哋都係 superpowers 技能家族嘅成員，但目標同機制完全唔同。

由目的嚟睇，brainstorming 解決嘅係「我仲未諗好」嘅問題——用戶有一個模糊嘅想法，AI 通過開放式提問逐步幫用戶將設計具體化。grill-me 解決嘅係「我諗好咗，但唔肯定係咪啱」——用戶已經有一個方案或 spec，AI 透過逐級追問挑戰佢嘅每一個設計決策。

由提問方式嚟睇，brainstorming 係探索式：一個問題可能有多個方向，用戶可以發散思考。grill-me 係追問式：每個問題都沿住上一問嘅結論繼續深入，逐層挖到唔可以再分嘅原子決策。一問一答，問完一個先入下一個。

由輸出物嚟睇，brainstorming 產出嘅係一份初次設計文檔——佢保證咗方向嘅正確性，但唔保證細節嘅齊全。grill-me 產出嘅係一份被打磨過嘅最終 spec——入面嘅每一個設計決策都已經經歷過挑戰同驗證，一係被證明成立，一係被推翻替換。

打個比喻：brainstorming 係建築師幫你畫出第一版藍圖，grill-me 係結構工程師拎住藍圖逐條柱問「呢條承唔承到力？如果地震點算？地基有幾深？」

使用時機都唔同。brainstorming 應該喺一切創造性工作之前調用——你喺開口講「幫我做一個嘢」嘅時候就應該觸發佢。grill-me 喺你已經有咗一個方案、一份 spec、一份設計文檔嘅時候調用——你需要 AI 嚟「揾錯處」，唔係需要 AI 嚟「翻譯你嘅想法」。

最核心嘅分別一句講曬：brainstorming 幫你「想出方案」，grill-me 幫你「殺死爛方案」。

grill-me 實際使用例子

以下所有內容嚟自一次真實嘅 grill-me 對話：用 /grill-me 拷問一個叫 dev-loop 嘅 Java+Maven 自動化開發 skill 嘅 spec。原始輸入係一份大約 200 行嘅設計文檔，最終產出係一份 530 行、包含 65+ 條完整設計決策嘅精確 spec。呢度揀咗 2 個關鍵拷問點做例子。

例子一：TDD 依賴——一個被推翻嘅重用決策

原始 spec 計劃喺 implementing 階段引用外部已經有嘅 test-driven-development skill。呢個睇落好合理——重用現有模塊，唔重複造輪子。

grill-me 將呢個問題擺上枱之後，用戶嘅回答經歷咗一次反轉：

AI：TDD 流程係直接寫喺 SKILL.md 入面，定係引用已經存在嘅 test-driven-development skill？

用戶：引用。

呢個回答喺當時睇嚟係「啱」嘅——減少重複，保持簡潔。grill-me 記錄咗呢個決策，然後繼續追問其他方面。但 20 幾個問題之後，用戶重新審視咗成個 skill 嘅結構，主動推翻咗自己嘅決定：

用戶：我計劃唔依賴其他 skill，統一放到呢個 skill 入面去維護。可唔可以參考 test-driven-development skill 寫入新嘅 skill 入面？

AI：可以。需要做嘅適配——例子由 TypeScript/Jest 改成 Java/JUnit 5 風格，門禁命令由 npm test 改成 mvn test。保留核心約束內容，壓縮篇幅。

呢個反轉說明咗 grill-me 嘅一個關鍵價值：佢唔係一次性做出「正確決定」嘅工具，而係通過持續暴露決策後果，令用戶自己發現更好嘅選擇。

引用外部 skill 意味着兩個檔案嘅維護週期唔同步，TDD skill 嘅 TypeScript/Jest 例子對 Java 項目完全冇意義，而且每次加載 dev-loop 都要額外加載一個外部檔案。內聯之後，TDD 流程直接適配 Java/JUnit 5，維護只需要改一個檔案，skill 完全自包含。呢個決策如果冇被 grill-me 先揪出嚟再記錄，用戶可能根本唔會返轉頭審視佢。

例子二：修復策略由 1 行變成 8 輪子循環

原始 spec 對修復策略嘅描述就一句話：「失敗就修復重試，最多 5 次。」呢句話有好多解釋空間：點樣修？每次修嘅分別喺邊？咩情況下放棄？

以下係實際對話逐步深入嘅過程。

第一輪追問——grill-me 要求細化每一輪嘅策略差異：

AI：修復策略升級路徑——第 1 次直接修復，第 2 次擴展上下文，第 3 次重讀需求，第 4 次簡化實現，第 5 次放棄。每級之間幾時切換？連續失敗幾次先升級？

用戶同意頭三次，但對於「簡化實現」，反應好激烈：

用戶：唔允許簡化實現，只允許更換實現方案。

呢一句直接否決咗 spec 原方案中嘅「兜底策略」。簡化實現意味住 cut 功能——用一個退化嘅版本嚟通過門禁，但交付畀研發嘅產物唔完整。喺用戶眼中，呢個係唔可以接受嘅。

但 grill-me 冇因為呢個修正就停低。如果只允許換方案，換方案本身都需要規則：

AI：對於第 4 次更換實現方案，需要執行幾次更換方案失敗後先算失敗？變更方案前係咪需要再次讀 spec？

用戶：執行 5 次更換方案失敗後先算失敗，變更方案前都需要再次讀 spec。

由呢個時候開始，修復策略嘅結構完全變咗。唔再係「5 次重試」，而係「前 3 次逐步升級 + 後 5 次換方案子循環 = 最多 8 次重試」。每一次換方案前強制重讀需求文檔，防止方案偏離原始意圖。而且 5 種方案全部失敗後先標記 blocked——畀咗 AI 充分嘅容錯空間，同時亦避免咗「換一次方案失敗就放棄」嘅草率。

最終修復策略由 spec 入面嘅 1 行模糊描述變咗做精確嘅 8 輪子循環規則表，包含升級路徑、切換條件、回退機制同 blocked 狀態嘅觸發條件。如果冇 grill-me 嘅逐級追問，AI 喺實現階段可能會第 2 次失敗就簡化實現，冇咗核心功能——而呢個係用戶絕對唔可以接受嘅。

點解 grill-me 對大模型特別好用

前面嘅例子說明咗一個現象：經過 grill-me 拷問之後嘅 spec，細節密度同決策完備性遠超原始版本。呢個唔係偶然——grill-me 嘅設計充分匹配咗大模型嘅能力特徵同弱點。

解決大模型嘅「過度順從」問題

大模型有一個根深蒂固嘅傾向：同意用戶。你畀出一個方案，佢好大機會會先肯定再補充。「睇落唔錯」、「呢個方案係可行嘅」——呢個係大模型嘅默認社交模式。

但設計審查需要嘅係質疑，唔係肯定。你需要有人話你知「呢度唔啱」、「呢個假設唔成立」、「呢種邊界你有冇考慮過」。

grill-me 用 skill 指令強行扭轉咗呢個模式。佢嘅 prompt 寫住：「Interview me relentlessly about every aspect of this plan... Resolving dependencies between decisions one-by-one. Ask the questions one at a time.」——你一定要追問，你唔可以 skip，你唔可以因為「呢個睇落冇問題」就放過。

呢種指令級別嘅強制約束，將「討好型 AI」改造成「挑戰型 AI」。而呢個正正係大模型喺創意同設計工作中最稀缺嘅品質。

適合大模型嘅「一次一事」認知模式

大模型喺處理「一次回答好多問題」嘅 prompt 時，容易出現焦點漂移——後面問題嘅答案俾前面問題嘅上下文幹擾，或者某啲子問題被遺漏。

grill-me 嘅一問一答模式完美避開咗呢個缺陷。每個問題獨立一問，AI 只需要關注當前呢一個決策點。上一問嘅結論作為下一問嘅上下文輸入——呢個係大模型最擅長嘅工作窗口：單輪問題，明確上下文，聚焦決策。

同時，人類俾人追問時，每一步都喺逐步暴露自己嘅隱藏假設。AI 唔需要一次性「估到」所有疏漏，而係通過用戶嘅每一個回答，自然噉揾到下一個需要挑戰嘅方向。

利用大模型嘅系統性遍歷能力

人類做設計審查最大嘅敵係疲勞。一份 200 行嘅 spec，人工審查大概去到 50 行就開始跳讀，去到 100 行就開始假設「下面應該冇問題啦」。加上每個人都有認知盲區——你永遠唔知自己唔知啲咩——遺漏幾乎係必然嘅。

AI 唔會攰。75 輪拷問，AI 每一輪嘅狀態同第一輪一樣專注。佢可以逐層逐分支遍歷成個決策樹，將一個模糊決策拆做子決策，再將子決策拆做更細嘅子決策，直到每一個分支都去到唔可以再分嘅原子級別。

喺今次 dev-loop 嘅實戰入面，75 輪拷問覆蓋咗檔案路徑、平台適配、命名規範、任務粒度、修復策略、門禁命令、狀態持久化、併發安全、異常恢復、Python 編排等 10 幾個維度嘅 65+ 個設計決策。人工審查做到呢個顆粒度嘅概率幾乎係零。

將隱性知識顯性化

好多設計決策喺用戶腦入面係「理所當然」嘅——你甚至冇意識到佢係一個決策。

「引用外部 skill」——你係因為外部 skill 更好，定係純粹嘅「暫時唔重複造輪子」嘅習慣？「失敗重試 5 次」——點解係 5 次而唔係 8 次？5 次入面每一輪做啲咩？

呢啲問題喺常規工作流程中唔會俾人問到，因為冇人有精力去質疑每一個「明顯係啱嘅」決定。但 grill-me 會——佢唔會預先假設任何嘢係「明顯嘅」，每一條設計決策都必須經受挑戰。

經過呢種追問之後，原本喺用戶腦入面嘅隱性假設被逐一顯性化：一係被證明係正確嘅（經過咗挑戰），一係被發現係站唔住腳嘅（被推翻替換）。最終產出嘅 spec，唔係「睇落合理」，而係「經得起逐條挑戰」。

呢個就係 grill-me 對 AI 編程工作流程嘅真正價值：佢唔直接幫你寫 code，佢幫你確保你即將寫嘅 code 係啱嘅。

/grill-me 是 OpenCode 的一個斜槓命令，也是 superpowers 系列技能之一。它的核心行為極其簡單：讓 AI 以逐題追問的方式，對用戶的計劃或設計進行地毯式拷問，不走完決策樹的每一片葉子不罷休。

常規的 AI 交互中，你給出一個方案，AI 大概率會說"看起來不錯，我幫你實現"。但 /grill-me 不同——它強制 AI 站在對立面，用連續不斷的追問來檢驗每一個假設、每一個細節、每一個邊界條件。你可以把它理解為一個永不疲倦的設計審查員。

與 brainstorming 的對比：brainstorming 是 AI 幫你發散——從一個模糊意圖碰撞出可能的設計方向。grill-me 是 AI 逼你收斂——假設你已經有了一個方案，它要通過層層挑戰幫你殺死裏面的爛決策，只留下經得起檢驗的部分。

grill-me 和 superpowers 的最核心區別

很多人第一次接觸 grill-me 會把它和 brainstorming 混淆。它們同屬 superpowers 技能家族，但目標和機制完全不同。

從目的看，brainstorming 解決的是"我還沒想好"的問題——用戶有一個模糊的想法，AI 通過開放式提問逐步幫用戶把設計具象化。grill-me 解決的是"我想好了，但不確定它是不是對的"——用戶已經有了一個方案或 spec，AI 通過逐級追問挑戰它的每一個設計決策。

從提問方式看，brainstorming 是探索式：一個問題可能有多個方向，用戶可以發散思考。grill-me 是追問式：每個問題都沿着上一問的結論繼續深入，逐層挖到不可再分的原子決策。一問一答，問完一個才進入下一個。

從輸出物看，brainstorming 產出的是一份初次設計文檔——它保證了方向的正確性，但不保證細節的完備性。grill-me 產出的是一份被打磨過的最終 spec——其中的每一個設計決策都已經歷過挑戰和驗證，要麼被證明成立，要麼被推翻替換。

打個比方：brainstorming 是建築師幫你畫出第一版藍圖，grill-me 是結構工程師拿着藍圖逐根柱子問"這根承重夠不夠？如果地震了怎麼辦？地基多深？"

使用時機也不同。brainstorming 應該在一切創造性工作之前調用——你在開口說"幫我做一個東西"的時候就應該觸發它。grill-me 在你已經有了一個方案、一份 spec、一份設計文檔時調用——你需要 AI 來"找茬"，而不是需要 AI 來"翻譯你的想法"。

最核心的區別一句話：brainstorming 幫你"想出方案"，grill-me 幫你"殺死爛方案"。

grill-me 實際使用示例

以下所有內容來自一次真實的 grill-me 會話：用 /grill-me 拷問一個名為 dev-loop 的 Java+Maven 自動化開發 skill 的 spec。原始輸入是一份約 200 行的設計文檔，最終產出是一份 530 行、包含 65+ 條完整設計決策的精確 spec。這裏挑選 2 個關鍵拷問點作為示例。

示例一：TDD 依賴——一個被推翻的複用決策

原始 spec 計劃在 implementing 階段引用外部已有的 test-driven-development skill。這看起來很合理——複用已有模塊，不重複造輪子。

grill-me 把這個問題擺到桌面上之後，用戶的回答經歷了一次反轉：

AI：TDD 流程是直接寫在 SKILL.md 裏，還是引用已存在的 test-driven-development skill？

用戶：引用。

這個回答在當時看來是"對"的——減少重複，保持簡潔。grill-me 記錄了這個決策，然後繼續追問其他方面。但 20 多個問題之後，用戶重新審視了整個 skill 的結構，主動推翻了自己的決定：

用戶：我計劃不依賴其他 skill，統一放到此 skill 裏面去維護。可以參考 test-driven-development skill 寫入新的 skill 裏面嗎？

AI：可以。需要做的適配——示例從 TypeScript/Jest 改成 Java/JUnit 5 風格，門禁命令從 npm test 改成 mvn test。保留核心約束內容，壓縮篇幅。

這個反轉說明了 grill-me 的一個關鍵價值：它不是一次性做出"正確決定"的工具，而是通過持續暴露決策後果，讓用戶自己發現更好的選擇。

引用外部 skill 意味着兩個文件的維護週期不同步，TDD skill 的 TypeScript/Jest 示例對 Java 項目毫無意義，且每次加載 dev-loop 都要額外加載一個外部文件。內聯後，TDD 流程直接適配 Java/JUnit 5，維護只需改一個文件，skill 完全自包含。這個決策如果沒有被 grill-me 先揪出來再記錄，用戶可能根本不會回頭審視它。

示例二：修復策略從 1 行變成 8 輪子循環

原始 spec 對修復策略的描述就一句話："失敗則修復重試，最多 5 次。" 這句話有很大的解釋空間：怎麼修？每次修的差別在哪？什麼情況下放棄？

以下是實際的對話逐步深入的過程。

第一輪追問——grill-me 要求細化每一輪的策略差異：

AI：修復策略升級路徑——第 1 次直接修復，第 2 次擴展上下文，第 3 次重讀需求，第 4 次簡化實現，第 5 次放棄。每級之間什麼時候切換？連續失敗幾次才升級？

用戶同意前三次，但對於"簡化實現"，反應很激烈：

用戶：不允許簡化實現，只允許更換實現方案。

這一句直接否決了 spec 原方案中的"兜底策略"。簡化實現意味着砍功能——用一個退化的版本來通過門禁，但交付給研發的產物不完整。在用戶眼裏，這是不可接受的。

但 grill-me 沒有因為這個修正就停下。如果只允許換方案，換方案本身也需要規則：

AI：對於第 4 次更換實現方案，需要執行幾次更換方案失敗後才算失敗？變更方案前是否需要再次讀 spec？

用戶：執行 5 次更換方案失敗後才算失敗，變更方案前也需要再次讀 spec。

從這時起，修復策略的結構完全變了。不再是"5 次重試"，而是"前 3 次逐步升級 + 後 5 次換方案子循環 = 最多 8 次重試"。每一次換方案前強制重讀需求文檔，防止方案偏離原始意圖。而且 5 種方案全部失敗後才標記 blocked——給了 AI 充分的容錯空間，同時也避免了"換一次方案失敗就放棄"的草率。

最終修復策略從 spec 裏的 1 行模糊描述變成了精確的 8 輪子循環規則表，包含升級路徑、切換條件、回退機制和 blocked 狀態的觸發條件。如果沒有 grill-me 的逐級追問，AI 在實現階段可能會第 2 次失敗就簡化實現，丟掉核心功能——而這是用戶絕對不能接受的。

為什麼 grill-me 對大模型特別好用

前面的示例說明了一個現象：經過 grill-me 拷問後的 spec，細節密度和決策完備性遠超原始版本。這不是偶然——grill-me 的設計充分匹配了大模型的能力特徵和弱點。

解決大模型的"過度順從"問題

大模型有一個根深蒂固的傾向：同意用戶。你給出一個方案，它大概率會先肯定再補充。"看起來不錯"、"這個方案是可行的"——這是大模型的默認社交模式。

但設計審查需要的是質疑，不是肯定。你需要有人告訴你"這裏不對"、"這個假設不成立"、"這種邊界你考慮過嗎"。

grill-me 用 skill 指令強行扭轉了這個模式。它的 prompt 寫的是："Interview me relentlessly about every aspect of this plan... Resolving dependencies between decisions one-by-one. Ask the questions one at a time." ——你必須追問，你不許跳過，你不許因為'這個看起來沒問題'就放過去。

這種指令級別的強制約束，把"討好型 AI"改造成了"挑戰型 AI"。而這恰恰是大模型在創意和設計工作中最稀缺的品質。

適合大模型的"一次一事"認知模式

大模型在處理"一次回答很多問題"的 prompt 時，容易出現焦點漂移——後面問題的答案被前面問題的上下文干擾，或者某些子問題被遺漏。

grill-me 的一問一答模式完美避開了這個缺陷。每個問題獨立一問，AI 只需要關注當前這一個決策點。上一問的結論作為下一問的上下文輸入——這是大模型最擅長的工作窗口：單輪問題，明確上下文，聚焦決策。

同時，人類被追問時，每一步都在逐步暴露自己的隱藏假設。AI 不需要一次性"猜到"所有疏漏，而是通過用戶的每一個回答，自然地找到下一個需要挑戰的方向。

利用大模型的系統性遍歷能力

人類做設計審查最大的敵人是疲勞。一份 200 行的 spec，人工審查大概到 50 行就開始跳讀，到 100 行就開始假設"下面應該沒問題了"。加上每個人都有認知盲區——你永遠不知道自己不知道什麼——遺漏幾乎是必然的。

AI 不會疲勞。75 輪拷問，AI 每一輪的狀態和第一輪一樣專注。它可以逐層逐分支遍歷整個決策樹，把一個模糊決策拆成子決策，再把子決策拆成更細的子決策，直到每一個分支都抵達不可再分的原子級別。

在這次 dev-loop 的實戰中，75 輪拷問覆蓋了文件路徑、平台適配、命名規範、任務粒度、修復策略、門禁命令、狀態持久化、併發安全、異常恢復、Python 編排等 10 多個維度的 65+ 個設計決策。人工審查做到這個顆粒度的概率幾乎為零。

把隱性知識顯性化

很多設計決策在用戶腦子裏是"理所當然"的——你甚至沒有意識到它是一個決策。

"引用外部 skill"——你是因為外部 skill 更好，還是純粹的"先不重複造輪子"的習慣？"失敗重試 5 次"——為什麼是 5 次而不是 8 次？5 次裏每一輪都做什麼？

這些問題在常規工作流中不會被問到，因為沒有人有精力去質疑每一個"顯然是對的"的決定。但 grill-me 會——它不預設任何事情是"顯然的"，每一條設計決策都必須經受挑戰。

經過這種追問之後，原本在用戶腦中的隱性假設被逐一顯性化：要麼被證明是正確的（經過了挑戰），要麼被發現是站不住腳的（被推翻替換）。最終產出的 spec，不是"看起來合理"，而是"經得起逐條挑戰"。

這就是 grill-me 對 AI 編程工作流的真正價值：它不直接幫你寫代碼，它幫你確保你即將寫的代碼是對的。