從流程門禁到決策盤問：brainstorming 與 grill-me 該怎麼選
整理版優先睇
比較 brainstorming 同 grill-me：按不確定性類型揀 Agent 前置 Skill
呢篇文章係關於兩個 Coding Agent Skill：brainstorming 同 grill-me。佢哋都唔係用嚟寫代碼，而係喺實現之前幫你對齊需求、審查方案同埋決策澄清。作者點出一個關鍵問題：Agent 越能幹，錯誤方向嘅執行速度就越快，所以真正昂貴嘅失敗係目標、邊界、取捨未對齊就進入實現。
呢兩個 Skill 嘅核心差異在於治理對象唔同。brainstorming 係階段治理，處理「需求尚未成型」嘅不確定性；grill-me 係決策治理，處理「方案看似成型」嘅偽確定性。前者係流程門禁，防止過早進入實現；後者係方案壓力測試，防止帶住隱含假設進入實現。
整體結論係：最有價值嘅唔係揀邊個 Skill，而係先識別自己面對邊種不確定性。需求模糊就用 brainstorming，方案未經壓測就用 grill-me。高風險任務可以先用 brainstorming 收斂設計，再用 grill-me 壓測關鍵決策。成熟嘅 Agent 使用唔係追求更快，而係知道幾時要停低問問題。
- 核心差異：brainstorming 係階段治理（流程門禁），grill-me 係決策治理（方案壓力測試）。
- 選擇框架：根據任務不確定性類型——需求模糊用 brainstorming，已有方案但怕遺漏用 grill-me。
- 關鍵機制：brainstorming 有9步強門禁流程，包括上下文探索、逐步澄清、方案比較、設計文檔同用戶複核；grill-me 沿決策樹逐個追問，每次一個問題並畀推薦答案。
- 三個差異維度：治理對象、交互節奏、產物形態（brainstorming 產出設計合約，grill-me 產出被檢驗嘅取捨）。
- 實用建議：高風險任務可先 brainstorming 後 grill-me；低風險小改動只用 grill-me 或者唔用；成熟 Agent 使用係知道幾時減速。
點解要比較呢兩個 Skill？
Coding Agent 寫代碼越來越容易，難嘅係喺佢動手之前確認目標冇錯。brainstorming 同 grill-me 都係高熱度嘅 Agent Skill，佢哋唔負責生成代碼，而係將需求對齊、方案審查同決策澄清前移到實現之前。
實現前約束類 Skill
截至2026-06-03，grill-me 同 brainstorming 各自有 254K 同 198K 安裝量，但呢啲數字只係熱度信號，唔可以直接當成質量排名。更重要嘅係，兩個唔直接寫代碼嘅 Skill 都獲得咁高使用熱度，說明工程師唔單止需要 Agent 寫更多代碼，亦需要約束 Agent 幾時唔好寫代碼、幾時必須先問問題。
Agent 越能幹，錯誤方向執行越快
呢兩個 Skill 之所以值得比較，正因為佢哋都位於實現之前。brainstorming 偏 planning 之前，用嚟將模糊需求收斂成設計；grill-me 可以發生喺 planning 之前或者 plan 草案之後，用嚟壓測已有方案。計劃寫得好唔好，取決於計劃生成之前需求、約束同決策有冇被充分暴露。
階段治理 vs. 決策治理
brainstorming 嘅核心係階段治理，佢將「由想法進入實現」呢一步設置為受控階段切換：Agent 必須先理解上下文、澄清需求、比較方案、展示設計，並獲得用戶批准，先至可以繼續。grill-me 嘅核心係決策治理，佢假設你已經有計劃或設計，但裏面仲有未命名嘅分支、依賴同取捨，要求 Agent 圍繞計劃持續盤問。
- 1 治理對象：brainstorming 治理階段狀態（可唔可以進入實現），grill-me 治理決策節點（方案經唔經得起追問）。
- 2 交互節奏：brainstorming 漸進收斂，從上下文、問題、方案到設計文檔；grill-me 連續下鑽，沿決策樹一次一個問題。
- 3 產物形態：brainstorming 產出設計合約，可進入後續 planning；grill-me 產出被檢驗過嘅取捨同顯性化假設。
各自嘅運作機制
brainstorming 係一個強門禁型 Skill，包含九個順序步驟：探索項目上下文、必要時提供視覺輔助、一次一個問題澄清需求、提出2到3個方案、展示設計、寫設計文檔、自檢、用戶複核，最後轉入 writing-plans。呢個流程嘅終點唔係實現，而係進入實現計劃。
強制先讀上下文
逐步澄清一次一個問題
- 1 Agent 要圍繞計劃每個方面追問，沿設計樹逐個解決依賴
- 2 每次只問一個問題
- 3 每個問題都要畀推薦答案。如果問題可以通過代碼庫探索回答，Agent 應該自己查，而唔係將事實檢索交畀用戶。
每次只問一個問題
每個問題畀推薦答案
誤用邊界同選擇指南
brainstorming 嘅主要誤用係冇判斷任務成本就採用完整流程。對於低風險、可逆、範圍明確嘅小改動，完整設計文檔同多輪審批可能會拖慢節奏。grill-me 嘅主要誤用係喺冇方案時強行盤問，因為需要一個可被挑戰嘅對象。
冇方案時唔好急住盤問
- 只有想法、目標成功標準唔清楚：用 brainstorming，先結構化意圖同約束。
- 已有明確方案但擔心遺漏邊界：用 grill-me，沿決策樹追問隱藏假設。
- 新功能、跨模塊改動、架構調整： brainstorming 優先，需要階段門禁同設計合約。
- 小改動、已有實現思路、只想快速校準： grill-me 優先，低成本壓測關鍵取捨。
- 高風險任務且方案初步形成：先 brainstorming 再 grill-me，收斂設計後壓測決策。
決定使用 brainstorming 就要遵守 hard gate
兩者仲有共同邊界：佢哋唔可以替代代碼閲讀、事實檢索、測試驗證同用戶最終價值判斷。grill-me 明確要求能由代碼庫回答嘅問題就由 Agent 自己探索，呢點尤其重要：唔好將所有不確定性都扮成需要用戶回答嘅問題。
成熟嘅 Agent 使用係知道幾時減速
brainstorming 同 grill-me 嘅共同價值，係將問題前置到實現前。區別在於佢哋前置嘅問題唔同：brainstorming 處理需求未成型，grill-me 處理方案未經壓測。
先識別不確定性類型
所以，最有價值嘅結論唔係「應該揀 brainstorming 定 grill-me」，而係：你要先識別自己面對嘅係邊一種不確定性。如果係需求未成型，揀 brainstorming；如果係方案未經壓測，揀 grill-me。如果任務風險高、影響面大、後續需要可複核計劃，先用 brainstorming 收斂設計，再用 grill-me 壓測關鍵決策。
令 Coding Agent 寫代碼越嚟越容易，難嘅係喺佢鬱手之前確認目標冇錯。brainstorming 和 grill-me 呢兩個都係好熱嘅 Agent Skill：佢哋唔負責生成代碼，而係將需求對齊、方案審查同決策澄清擺喺實現之前做。
問題在於：Agent 越能幹，喺錯誤方向上嘅執行速度亦越快。真正貴嘅失敗往往唔係某一行代碼寫錯，而係 Agent 喺目標、邊界、取捨未對齊就開始實現。brainstorming 與 grill-me 兩個都係處理呢個問題，但佢哋處理嘅唔係同一種不確定性。
結論先講：brainstorming 處理「需求未成形」嘅不確定性，grill-me 處理「方案看似成形」嘅偽確定性。前者係階段治理，回答「而家可唔可以進入實現」；後者係決策治理，回答「呢個方案頂唔頂得住追問」。用戶真正要揀嘅唔係更強嘅 Skill，而係更匹配當前任務成熟度嘅認知煞車。
背景：點解呢兩個 Skill 值得比較
截至 2026-06-03 訪問 skills.sh 嗰陣，grill-me 和 brainstorming 都已經係高安裝量嘅 Skill：
grill-me | mattpocock/skills | |||
brainstorming | obra/superpowers |
呢啲數字只可以當作熱度信號，唔可以直接當成質量排名。安裝量會受曝光、倉庫聲譽、分發渠道同時間窗口影響，好難證明「邊個 Skill 更好」。但佢哋足以說明一個更有趣嘅事實：兩個唔直接寫代碼嘅 Skill，都得到相當高嘅使用熱度。
呢啲數據提示，實現前約束類 Skill 至少獲得咗可見嘅關注同安裝，但唔可以證明具體用戶規模或安裝動機。喺真實使用中，工程師唔只需要 Agent 寫更多代碼，亦需要約束 Agent 幾時唔好寫代碼、幾時一定要先問問題、幾時應該將設計變成可複核嘅產物。Agent Skill 嘅價值喺呢度體現得好清楚：佢唔係將一句「先諗清楚」寫得更客氣，而係將實現前嘅協作規則固化為可重複觸發嘅工作流程。
brainstorming 和 grill-me 之所以值得擺埋一齊比較，正正因為佢哋都位於實現之前。brainstorming 偏重規劃之前，用嚟將模糊需求收斂成設計；grill-me 可以發生喺規劃之前，亦可以發生喺計劃或設計草案之後，用嚟壓力測試已有方案。計劃寫得好唔好，好大程度取決於計劃生成之前或進入實現之前，需求、約束同決策有冇被充分暴露。
核心判斷：階段治理 vs. 決策治理
brainstorming 嘅核心係階段治理。佢將「由想法進入實現」呢一步設定為受控嘅階段切換：Agent 必須先理解上下文、澄清需求、比較方案、展示設計，並得到用戶批准之後，先可以繼續進入後續計劃或實現流程。來自 Superpowers 嘅 brainstorming 明確將呢個過程寫成 hard gate：冇設計確認，就唔可以寫代碼、唔可以 scaffold、唔可以調用實現類 Skill。
grill-me 嘅核心係決策治理。佢假設你已經有一個計劃或設計，但呢個計劃裏面仍然埋咗未命名嘅分支、依賴同取捨。來自 Matt Pocock Skills 嘅 grill-me 要求 Agent 圍繞計劃持續盤問，一次只問一個問題，沿設計樹逐個解決依賴，並為每個問題畀出推薦答案。
呢兩個治理對象唔同，導致佢哋嘅使用時機都唔同。
brainstorming 問嘅係：呢個需求係咪已經夠清楚，可以進入下一階段？
grill-me 問嘅係：呢個方案裏面有啲乜嘢看似已經決定、但實際上仍然未俾人審查嘅判斷？
前者似流程門禁，重點係防止過早進入實現；後者似方案壓力測試，重點係防止帶住隱含假設進入實現。
一個使用者選擇框架：你面對嘅係邊種不確定性？
揀呢兩個 Skill 之前，先唔好問「邊個更勁」。更好嘅問題係：當前任務嘅不確定性喺邊度？
第一類不確定性係需求未成形。你知道大約想做啲乜，但目標、約束、成功標準、邊界條件同比較方案仲未有系統化表達。例如「幫我做一個儀錶板」、「將登入體驗優化一下」、「畀呢個項目加一個導入功能」。呢啲請求睇起身可以直接開工，但裏面其實有大量等住確認嘅內容：用戶係邊個、成功標準係乜、有冇兼容性要求、有冇現有模式要重用、邊啲行為唔可以改。
呢個時候應該優先使用 brainstorming。佢嘅目標係將模糊意圖壓縮成設計合約，等後續規劃有穩定嘅輸入。例如同樣係「做一個導入功能」，brainstorming 嘅第一問可能會係：「呢個導入功能係服務邊個，成功標準係乜，有邊啲現有數據或接口唔改得？」
第二類不確定性係方案看似成形。你已經有方向，甚至已經寫咗一段計劃，但你擔心自己漏咗關鍵分支。例如「我打算新增一個緩存層」、「我準備將狀態搬去 URL query」、「我想將呢個模塊拆成兩個包」。呢類問題最危險嘅地方係令人生出一種「已經諗清楚」嘅錯覺。實際上，緩存失效、遷移策略、邊界 API、錯誤處理、回滾路徑、兼容策略可能都仲未俾人問出來。
呢個時候應該優先使用 grill-me。佢嘅目標唔係由零生成方案，而係令已有方案經受系統性嘅追問。如果用戶已經話「我準備用批處理隊列做導入」，grill-me 嘅第一問可能會係：「隊列失敗嗰陣你希望重試、跳過、回滾，定係等用戶手動處理？我嘅建議係先支援可重試失敗記錄，而唔係全量回滾。」
如果仲係揸唔定主意，可以先問自己三個問題：
我係咪已經可以清楚描述目標、成功標準同唔可以掂嘅邊界？ 我係咪已經有一個可以俾人挑戰嘅具體方案？ 我係咪需要留低正式嘅設計產物，等之後嘅計劃、實現或覆盤用？
如果第一個問題答唔到，先用 brainstorming。如果第二個問題答得到，但你唔肯定方案係咪可靠，用 grill-me。如果第三個問題答案係「需要」，brainstorming 更適合作為主流程，grill-me 可以作為關鍵決策嘅補充壓力測試。
brainstorming：處理「需求未成形」嘅不確定性
brainstorming 係一個強門禁型 Skill。佢嘅價值唔係「問多幾個問題」，而係將需求澄清、方案比較、設計確認同規格文檔沉澱組織成一個完整嘅前置流程。
從 brainstorming 嘅原文機制睇，佢包含九個順序步驟：探索項目上下文、必要時提供可選視覺輔助、一次一個問題澄清需求、提出 2 至 3 個方案、展示設計、寫設計文檔、自檢、用戶審核，最後轉入 writing-plans。呢個流程嘅終點唔係實現，而係進入實現計劃。
關鍵在於，好多 Agent 失敗唔係因為唔曉寫計劃，而係計劃輸入本身已經錯咗。Agent Planning 需要目標、約束、依賴、驗證方案同回滾路徑；但如果需求階段冇將呢啲資訊收斂出來，計劃就只係喺度包裝一個未經驗證嘅猜測。
brainstorming 喺呢個環節做咗三件事。
第一，佢強制 Agent 先讀上下文。現有代碼庫裏面嘅真實約束通常唔喺用戶一句說話嘅需求裏面，而係喺目錄結構、已有實現、近期提交、測試習慣同命名風格裏面。brainstorming 要求 Agent 提出方案之前先理解項目狀態，咁樣可以減少憑空設計。
第二，佢要求逐步澄清，而唔係一次過拋出一大堆問題。一次一個問題睇起身好似冇效率，實際上係降低對齊成本。多個開放問題撈埋一齊嘅時候，用戶容易漏答，Agent 都容易將未回答嘅部分自己補齊。逐步澄清令每個決策點都有明確回應。
第三，佢要求比較方案並得到批准。呢度嘅設計唔係 Agent 嘅內部思考，而係用戶可以審閲嘅中間產物。對於新功能、跨模塊改動、架構調整或用戶體驗設計，設計文檔本身就係後續實現嘅合約。
所以，brainstorming 適合呢啲場景：需求描述仲好粗糙，任務影響範圍唔清，用戶冇辦法直接畀出成功標準，改動跨越多個模塊，或者團隊需要留低正式設計記錄。佢嘅代價亦好明顯：流程重、互動多、節奏慢。對於一個低風險嘅單行配置修改，佢可能太大陣仗；但對於任何「做錯方向會好貴」嘅任務，呢個成本通常係值得嘅。
grill-me：處理「方案看似成形」嘅偽確定性
grill-me 係一個極小互動型 Skill。佢嘅正文好短，但捉住咗一個高槓桿動作：持續盤問一個計劃或設計，直到雙方形成共享理解。
grill-me 嘅關鍵約束有三條。第一，Agent 要圍繞計劃嘅每個方面追問，沿設計樹逐個解決依賴。第二，每次只問一個問題。第三，每個問題都要畀出推薦答案。如果問題可以通過代碼庫探索回答，Agent 應該自己查，而唔係將事實檢索轉交俾用戶。
這讓 grill-me 同普通嘅「你覺得仲有冇問題呀」完全唔同。佢唔係請用戶補充需求，而係主動將隱藏決策顯現化。
舉個例，用戶話：「我打算幫呢個 API 加緩存。」一個普通 Agent 可能會直接問緩存時間幾長，然後開始實現。grill-me 更應該追問嘅係：緩存鍵點定義？係咪區分用戶權限？數據更新之後點失效？失敗嗰陣係回源、報錯定係用舊數據？使唔使監察命中率？呢個係臨時優化定係要做長期基礎設施？每個問題背後都係設計樹上嘅一個分支。
更重要嘅係，grill-me 要求 Agent 畀推薦答案。呢樣令到佢唔係審問式資訊收集，而係協作式設計評審。Agent 必須基於上下文畀出自己嘅工程判斷，用戶只需要接受、修改或者拒絕默認建議。呢個都符合好嘅 Agent 指令實踐：唔好只係叫 Agent 問多啲問題，仲要叫 Agent 分清楚邊啲問題應該問用戶，邊啲事實應該自己查。
grill-me 適合呢啲場景：你已經有方案，但想暴露盲點；你要做架構調整，但唔肯定權衡係咪足夠；你準備進入實現之前，希望有人沿依賴樹逐個追問；你唔一定需要正式設計文檔，只需要將關鍵假設檢驗一下。
佢嘅代價都要睇清楚。grill-me 沒有像 brainstorming 咁樣嘅文檔同審核閘門，結束就靠雙方判斷係咪已經形成共享理解，亦唔會自動產出規格文檔。如果用戶只得一個非常模糊嘅念頭，grill-me 好容易變成冇抓手嘅追問。佢更加似壓力測試工具，而唔係需求成形工具。
三個關鍵差異：對象、節奏、產物
將兩個 Skill 擺埋一齊睇，最重要嘅差異可以壓縮成三組：治理對象、互動節奏同產物形態。
brainstorming | grill-me | |
|---|---|---|
brainstorming 嘅節奏係由發散到收斂。佢容許一開始有模糊性，但會逐步將模糊性壓縮成設計。呢個過程自然適合「仲未知點做」嘅任務。
grill-me 嘅節奏係由表面方案向深層假設下鑽。佢唔負責幫你由零形成方案，而係要求你將已有方案擺上枱，接受逐個決策節點嘅追問。呢個過程自然適合「以為已經識做」嘅任務。
產物差異亦決定咗後續協作方式。brainstorming 嘅產物可以交俾後續實現計劃，成為規劃輸入；grill-me 嘅產物更加似經過檢驗嘅決策記錄，未必自動沉澱為文檔。實際使用時，如果你希望將 grill-me 嘅結果帶入執行，最好喺盤問結束之後主動整理成 spec、ADR（Architecture Decision Record）或 implementation plan。
長 Skill 與短 Skill：長度唔代表強弱，行為槓桿先係
從文件型態睇，brainstorming 很長，grill-me 好短。一個自然嘅誤解係：長 Skill 更完整，短 Skill 更輕量，所以長嘅更適合嚴肅任務，短嘅更適合隨手用。呢個判斷只啱咗一半。
Skill 嘅價值唔係由篇幅決定，而係由佢係咪改變 Agent 喺關鍵時刻嘅默認行為決定。呢個就係 Agent Skill 作為能力封裝嘅關鍵：佢將一類可重複觸發嘅行為寫成工作流，令 Agent 喺特定場景入面唔再依賴臨場發揮。
brainstorming 長，係因為佢治理嘅係完整階段轉換。佢必須規定觸發條件、禁止事項、澄清方式、方案比較、設計展示、文檔位置、自檢同用戶審核。呢度嘅長度唔係囉嗦，而係因為流程中每一步都喺度防止 Agent 過早進入實現。
grill-me 短，係因為佢只固化一個行為槓桿：盤問方案。佢唔嘗試接管完整生命週期，亦唔規定文檔模板、測試策略或後續實現。佢嘅強度來自互動姿態，而唔係流程覆蓋面。
因此，使用者唔應該用「長短」來判斷揀邊個，而應該睇自己需要嘅係完整流程治理，定係局部行為增強。
如果你面對嘅係需求未成形、目標唔穩定、上下文未讀、後續需要正式計劃嘅任務，長流程就有價值。
如果你面對嘅係方案已經形成、只差俾人挑戰、需要快速暴露盲點嘅任務，短 Skill 反而更精準。
呢個都係兩個 Skill 流行背後嘅共同啟發：Agent 寫代碼嘅速度越快，就越需要喺少數高風險認知節點施加約束。真正稀缺嘅唔係令 Agent 繼續前進嘅能力，而係令 Agent 喺錯誤階段停落嚟嘅機制。
誤用邊界：幾時佢哋會失效
brainstorming 嘅主要誤用，係採用呢個 workflow 之前冇判斷任務成本。佢自己嘅原文強調就算簡單任務都要設計，呢個喺 Superpowers 嘅強流程哲學入面係自洽嘅；但喺具體項目入面，仍然需要先判斷係咪值得用完整流程。對於低風險、可逆、範圍清楚嘅細改動，如果已經有清楚目標同驗證方式，完整嘅設計文檔同多輪審批可能會拖慢節奏。呢個判斷只能喺觸發之前做；一旦決定用 brainstorming，就應該遵守佢嘅 hard gate。
grill-me 嘅主要誤用，係冇方案嗰陣強行盤問。佢需要一個可以被挑戰嘅對象。如果用戶只得一句「我想優化系統」，Agent 好難沿決策樹下鑽，因為仲未有明確嘅決策樹。呢個時候更應該先用 brainstorming 收斂問題空間，而唔係畀 grill-me 喺空泛概念上追問。
兩者仲有共同邊界。佢哋唔可以取代代碼閲讀，唔可以取代事實檢索，唔可以取代測試驗證，亦唔可以取代用戶嘅最終價值判斷。grill-me 明確要求可以由代碼庫回答嘅問題就由 Agent 自己探索，呢一點尤其重要：唔好將所有不確定性都偽裝成需要用戶回答嘅問題。用戶應該決定目標同取捨，Agent 應該自行查證代碼庫嘅事實。
更準確啲講，呢兩個 Skill 唔係提升模型能力嘅捷徑，而係令 Agent 喺關鍵階段唔好自作聰明嘅約束。
使用者選擇指南：決策表與執行順序
實際揀嘅時候，可以用「任務成熟度、風險等級、需唔需要產物」三個維度判斷。
brainstorming | ||
grill-me | ||
brainstorming | ||
grill-me | ||
brainstorming | ||
grill-me | ||
brainstorming，再 grill-me |
更完整嘅執行順序可以係：
需求模糊嘅時候，用 brainstorming形成設計合約。設計初步成立之後，用 grill-me壓力測試關鍵取捨。盤問完之後，將結論整理入 spec、ADR 或者 implementation plan。 入實現之前，再用測試同驗證計劃鎖定成功標準。
一個簡單規則係：冇方案嗰陣，唔好急住盤問；冇目標嗰陣，唔好急住計劃。呢個順序唔適合所有任務。佢適合嗰啲「實現成本低，但方向錯成本高」嘅任務。對於一次性、低風險、可以快啲回滾嘅改動，使用者完全可以只用較輕嘅 grill-me，甚至唔用呢兩個 Skill。
結論：成熟嘅 Agent 使用，係知道幾時要減速
brainstorming 和 grill-me 嘅共同價值，係將問題前置到實現之前。分別在於佢哋前置嘅係唔同問題。
brainstorming 叫 Agent 喺需求未成形嗰陣停落嚟，將意圖、約束、方案同設計產物結構化。佢適合治理階段切換，防止 Agent 喺唔知目標嗰陣就開始實現。
grill-me 叫 Agent 喺方案看似成形嗰陣停落嚟，將隱藏假設、依賴分支同工程取捨問出來。佢適合治理關鍵決策，防止 Agent 帶住未經審查嘅默認假設進入實現。
所以，最有價值嘅結論唔係「應該揀 brainstorming 還是 grill-me」，而係：你要先認清自己面對嘅係邊一種不確定性。
如果不確定性來自需求未成形，揀 brainstorming。
如果不確定性來自方案未經壓力測試，揀 grill-me。
如果任務風險高、影響面大、後續需要可複核計劃，先用 brainstorming 收斂設計，再用 grill-me 壓力測試關鍵決策。
成熟嘅 Agent 使用，唔係追求更高嘅自動性，而係喺高風險認知節點主動降低自動性。真正專業嘅使用者，唔係令 Agent 永遠更快，而係知道幾時應該叫佢停落嚟問啱嘅問題。
參考資料
skills.sh: https://www.skills.sh mattpocock/skills: https://github.com/mattpocock/skills obra/superpowers: https://github.com/obra/superpowers
讓 Coding Agent 寫代碼越來越容易，難的是在它動手前確認目標沒有錯。brainstorming 和 grill-me 都是高熱度的 Agent Skill：它們不負責生成代碼，而是把需求對齊、方案審查和決策澄清前移到實現之前。
問題在於：Agent 越能幹，錯誤方向上的執行速度也越快。真正昂貴的失敗往往不是某一行代碼寫錯，而是 Agent 在目標、邊界、取捨尚未對齊時就進入實現。brainstorming 與 grill-me 都在處理這個問題，但它們處理的不是同一種不確定性。
結論先行：brainstorming 處理“需求尚未成型”的不確定性，grill-me 處理“方案看似成型”的偽確定性。前者是階段治理，回答“現在是否可以進入實現”；後者是決策治理，回答“這個方案是否經得起追問”。使用者真正要選的不是更強的 Skill，而是更匹配當前任務成熟度的認知剎車。
背景：為什麼這兩個 Skill 值得比較
截至 2026-06-03 訪問 skills.sh 時，grill-me 和 brainstorming 都已經是高安裝量 Skill：
grill-me | mattpocock/skills | |||
brainstorming | obra/superpowers |
這些數字只能作為熱度信號，不能直接當作質量排名。安裝量受曝光、倉庫聲譽、分發渠道和時間窗口影響，很難證明“哪個 Skill 更好”。但它們足以說明一個更有意思的事實：兩個並不直接寫代碼的 Skill，都獲得了相當高的使用熱度。
這些數據提示，實現前約束類 Skill 至少獲得了可見關注和安裝，但不能證明具體用戶規模或安裝動機。在真實使用中，工程師不只需要 Agent 寫更多代碼，也需要約束 Agent 何時不要寫代碼、何時必須先問問題、何時應該把設計變成可複核產物。Agent Skill 的價值在這裏體現得很清楚：它不是把一句“先想清楚”寫得更禮貌，而是把實現前的協作規則固化為可重複觸發的工作流。
brainstorming 和 grill-me 之所以值得放在一起比較，正因為它們都位於實現之前。brainstorming 更偏 planning 之前，用來把模糊需求收斂成設計；grill-me 可以發生在 planning 之前，也可以發生在 plan 或 design 草案之後，用來壓測已有方案。計劃寫得好不好，很大程度取決於計劃生成之前或進入實現之前，需求、約束和決策有沒有被充分暴露。
核心判斷：階段治理 vs. 決策治理
brainstorming 的核心是階段治理。它把“從想法進入實現”這一步設置為受控階段切換：Agent 必須先理解上下文、澄清需求、比較方案、展示設計，並在獲得用戶批准後，才能繼續進入後續計劃或實現流程。來自 Superpowers 的 brainstorming 明確把這個過程寫成 hard gate：沒有設計確認，就不能寫代碼、不能 scaffold、不能調用實現類 Skill。
grill-me 的核心是決策治理。它假設你已經有了一個計劃或設計，但這個計劃裏仍然埋着未命名的分支、依賴和取捨。來自 Matt Pocock Skills 的 grill-me 要求 Agent 圍繞計劃持續盤問，一次只問一個問題，沿設計樹逐個解決依賴，併為每個問題給出推薦答案。
這兩個治理對象不同，導致它們的使用時機也不同。
brainstorming 問的是：這個需求是否已經足夠清楚，足以進入下一階段？
grill-me 問的是：這個方案裏有哪些看似已經決定、實際仍未被審查的判斷？
前者像流程門禁，重點是防止過早進入實現；後者像方案壓力測試，重點是防止帶着隱含假設進入實現。
一個使用者選擇框架：你面對的是哪種不確定性？
選擇這兩個 Skill 之前，先不要問“哪個更強”。更好的問題是：當前任務的不確定性在哪裏？
第一類不確定性是需求尚未成型。你知道大概想做什麼，但目標、約束、成功標準、邊界條件和可選方案還沒有被系統化表達。比如“幫我做一個儀表盤”“把登錄體驗優化一下”“給這個項目加一個導入功能”。這些請求看起來能直接開工，但裏面其實有大量待確認內容：用戶是誰、成功標準是什麼、是否有兼容性要求、有沒有現有模式要複用、哪些行為不能改變。
這時應該優先用 brainstorming。它的目標是把模糊意圖壓縮成設計合約，讓後續 planning 有穩定輸入。比如同樣是“做一個導入功能”，brainstorming 的第一問更可能是：“這個導入功能要服務誰，成功標準是什麼，哪些現有數據或接口不能被改變？”
第二類不確定性是方案看似成型。你已經有了方向，甚至已經寫出一段計劃，但你擔心自己漏掉關鍵分支。比如“我打算新增一個緩存層”“我準備把狀態遷到 URL query”“我想把這個模塊拆成兩個包”。這類問題最危險的地方在於它給人一種“已經想清楚”的錯覺。實際上，緩存失效、遷移策略、邊界 API、錯誤處理、回滾路徑、兼容策略可能都還沒有被問出來。
這時應該優先用 grill-me。它的目標不是從零生成方案，而是讓已有方案經受系統性追問。如果用戶已經說“我準備用批處理隊列做導入”，grill-me 的第一問更可能是：“隊列失敗時你希望重試、跳過、回滾，還是讓用戶手動處理？我的建議是先支持可重試失敗記錄，而不是全量回滾。”
如果仍然拿不準，可以先問三個問題：
我是否已經能清楚描述目標、成功標準和不可觸碰邊界？ 我是否已經有一個可以被挑戰的具體方案？ 我是否需要留下正式設計產物，供後續計劃、實現或覆盤使用？
如果第一個問題答不上來，先用 brainstorming。如果第二個問題答得上來，但你不確定方案是否可靠，用 grill-me。如果第三個問題答案是“需要”，brainstorming 更適合作為主流程，grill-me 可以作為關鍵決策的補充壓力測試。
brainstorming：處理“需求尚未成型”的不確定性
brainstorming 是一個強門禁型 Skill。它的價值不是“多問幾個問題”，而是把需求澄清、方案比較、設計確認和規格文檔沉澱組織成完整的前置流程。
從 brainstorming 的原文機制看，它包含九個順序步驟：探索項目上下文、必要時提供可選視覺輔助、一次一個問題澄清需求、提出 2 到 3 個方案、展示設計、寫設計文檔、自檢、用戶複核，最後轉入 writing-plans。這個流程的終點不是實現，而是進入實現計劃。
關鍵在於，很多 Agent 失敗不是因為不會寫計劃，而是計劃輸入本身已經錯了。Agent Planning 需要目標、約束、依賴、驗證方案和回滾路徑；但如果需求階段沒有把這些信息收斂出來，計劃就只是在包裝一個未經驗證的猜測。
brainstorming 在這個環節做了三件事。
第一，它強制 Agent 先讀上下文。既有代碼庫裏的真實約束通常不在用戶的一句話需求裏，而在目錄結構、已有實現、近期提交、測試習慣和命名風格里。brainstorming 要求 Agent 在提方案之前先理解項目狀態，這能減少憑空設計。
第二，它要求逐步澄清，而不是一次拋出一組問題。一次一個問題看似低效，實際是在降低對齊成本。多個開放問題混在一起時，用戶容易漏答，Agent 也容易把未回答部分自行補全。逐步澄清讓每個決策點都有明確回應。
第三，它要求比較方案並獲得批准。這裏的設計不是 Agent 的內部思考，而是用戶可審閲的中間產物。對於新功能、跨模塊改動、架構調整或用戶體驗設計，設計文檔本身就是後續實現的合約。
所以，brainstorming 適合這些場景：需求描述還粗糙，任務影響範圍不清，用戶無法直接給出成功標準，改動跨越多個模塊，或者團隊需要留下正式設計記錄。它的代價也很明顯：流程重、交互多、節奏慢。對於一個低風險的單行配置修改，它可能過度；但對於任何“做錯方向會很貴”的任務，這個成本通常是值得的。
grill-me：處理“方案看似成型”的偽確定性
grill-me 是一個極小交互型 Skill。它的正文很短，但抓住了一個高槓杆動作：持續盤問一個計劃或設計，直到雙方形成共享理解。
grill-me 的關鍵約束有三條。第一，Agent 要圍繞計劃的每個方面追問，沿設計樹逐個解決依賴。第二，每次只問一個問題。第三，每個問題都要給出推薦答案。如果問題可以通過代碼庫探索回答，Agent 應該自己查，而不是把事實檢索轉交給用戶。
這讓 grill-me 和普通“你覺得還有什麼問題嗎”的澄清完全不同。它不是請用戶補充需求，而是主動把隱藏決策顯性化。
舉個例子，用戶說：“我打算給這個 API 加緩存。”一個普通 Agent 可能會直接問緩存時間多長，然後開始實現。grill-me 更應該追問的是：緩存鍵如何定義？是否區分用戶權限？數據更新後如何失效？失敗時是回源、報錯還是使用陳舊數據？是否需要觀測命中率？這是不是臨時優化，還是要作為長期基礎設施？每個問題背後都是設計樹上的一個分支。
更重要的是，grill-me 要求 Agent 給推薦答案。這讓它不是審問式信息收集，而是協作式設計評審。Agent 必須基於上下文給出自己的工程判斷，用戶只需要接受、修正或拒絕默認建議。這也符合好的 Agent 指令實踐：不要只讓 Agent 多問問題，還要讓 Agent 區分哪些問題該問用戶，哪些事實該自己查。
grill-me 適合這些場景：你已經有方案，但想暴露盲點；你要做架構調整，但不確定權衡是否充分；你準備進入實現前，希望有人沿依賴樹逐個追問；你不一定需要正式設計文檔，只需要讓關鍵假設被檢驗。
它的代價也要看清楚。grill-me 沒有像 brainstorming 那樣的文檔和複核 gate，結束依賴雙方判斷是否已經形成共享理解，也不自動產出規格文檔。如果用戶只有一個非常模糊的念頭，grill-me 容易變成沒有抓手的追問。它更像壓力測試工具，而不是需求成型工具。
三個關鍵差異：對象、節奏、產物
把兩個 Skill 放在一起看，最重要的差異可以壓縮為三組：治理對象、交互節奏和產物形態。
brainstorming | grill-me | |
|---|---|---|
brainstorming 的節奏是從發散到收斂。它允許一開始存在模糊性，但會逐步把模糊性壓縮為設計。這個過程天然適合“還不知道要怎麼做”的任務。
grill-me 的節奏是從表層方案向深層假設下鑽。它不負責幫你從零形成方案，而是要求你把已有方案放到桌面上，接受逐個決策節點的追問。這個過程天然適合“以為已經知道怎麼做”的任務。
產物差異也決定了後續協作方式。brainstorming 的產物可以交給後續實現計劃，成為 planning 輸入；grill-me 的產物更像經過檢驗的決策記錄，未必自動沉澱為文檔。實際使用時，如果你希望把 grill-me 的結果帶入執行，最好在盤問結束後主動整理為 spec、ADR（Architecture Decision Record）或 implementation plan。
長 Skill 與短 Skill：長度不是強弱，行為槓桿才是
從文件形態看，brainstorming 很長，grill-me 很短。一個自然誤解是：長 Skill 更完整，短 Skill 更輕量，所以長的更適合嚴肅任務，短的更適合隨手使用。這個判斷只說對了一半。
Skill 的價值不由篇幅決定，而由它是否改變 Agent 在關鍵時刻的默認行為決定。這也是 Agent Skill 作為能力封裝的關鍵：它把一類可重複觸發的行為寫成工作流，讓 Agent 在特定場景中不再依賴臨場發揮。
brainstorming 長，是因為它治理的是完整階段轉換。它必須規定觸發條件、禁止事項、澄清方式、方案比較、設計展示、文檔位置、自檢和用戶複核。這裏的長度不是囉嗦，而是因為流程中每一步都在防止 Agent 過早進入實現。
grill-me 短，是因為它只固化一個行為槓桿：盤問方案。它不試圖接管完整生命週期，也不規定文檔模板、測試策略或後續實現。它的強度來自交互姿態，而不是流程覆蓋面。
因此，使用者不應該用“長短”來判斷選擇，而應該看自己需要的是完整流程治理，還是局部行為增強。
如果你面對的是需求不成型、目標不穩定、上下文未讀、後續需要正式計劃的任務，長流程是價值。
如果你面對的是方案已形成、只差被挑戰、需要快速暴露盲點的任務，短 Skill 反而更精準。
這也是兩個 Skill 流行背後的共同啓發：Agent 寫代碼的速度越快，越需要在少數高風險認知節點施加約束。真正稀缺的不是讓 Agent 繼續前進的能力，而是讓 Agent 在錯誤階段停下來的機制。
誤用邊界：什麼時候它們會失效
brainstorming 的主要誤用，是在採用這套 workflow 之前沒有判斷任務成本。它自己的原文強調即使簡單任務也要設計，這在 Superpowers 的強流程哲學裏是自洽的；但在具體項目裏，仍然需要先判斷是否值得采用完整流程。對於低風險、可逆、範圍明確的小改動，如果已經有清楚目標和驗證方式，完整的設計文檔和多輪審批可能會拖慢節奏。這個判斷只能發生在觸發之前；一旦決定使用 brainstorming，就應該遵守它的 hard gate。
grill-me 的主要誤用，是在沒有方案時強行盤問。它需要一個可被挑戰的對象。如果用戶只有一句“我想優化系統”，Agent 很難沿決策樹下鑽，因為還沒有明確的決策樹。這時更應該先用 brainstorming 收斂問題空間，而不是讓 grill-me 在空泛概念上追問。
兩者還有共同邊界。它們不能替代代碼閲讀，不能替代事實檢索，不能替代測試驗證，也不能替代用戶的最終價值判斷。grill-me 明確要求能由代碼庫回答的問題就由 Agent 自己探索，這一點尤其重要：不要把所有不確定性都偽裝成需要用戶回答的問題。用戶應該決定目標和取捨，Agent 應該自行查證代碼庫事實。
更準確地說，這兩個 Skill 不是提升模型能力的捷徑，而是讓 Agent 在關鍵階段不要自作聰明的約束。
使用者選擇指南：決策表與執行順序
實際選擇時，可以用“任務成熟度、風險等級、是否需要產物”三個維度判斷。
brainstorming | ||
grill-me | ||
brainstorming | ||
grill-me | ||
brainstorming | ||
grill-me | ||
brainstorming，再 grill-me |
更完整的執行順序可以是：
需求模糊時，用 brainstorming形成設計合約。設計初步成立後，用 grill-me壓測關鍵取捨。盤問結束後，把結論整理進 spec、ADR 或 implementation plan。 進入實現前，再用測試和驗證計劃鎖定成功標準。
一個簡單規則是：沒有方案時，不要急着盤問；沒有目標時，不要急着計劃。這個順序並不適合所有任務。它適合那些“實現成本低，但方向錯誤成本高”的任務。對於一次性、低風險、可快速回滾的改動，使用者完全可以只用較輕的 grill-me，甚至不使用這兩個 Skill。
結論：成熟的 Agent 使用，是知道何時減速
brainstorming 和 grill-me 的共同價值，是把問題前置到實現前。區別在於它們前置的是不同問題。
brainstorming 讓 Agent 在需求未成型時停下來，把意圖、約束、方案和設計產物結構化。它適合治理階段切換，防止 Agent 在不知道目標時就開始實現。
grill-me 讓 Agent 在方案看似成型時停下來，把隱藏假設、依賴分支和工程取捨問出來。它適合治理關鍵決策，防止 Agent 帶着未經審查的默認假設進入實現。
所以，最有價值的結論不是“應該選 brainstorming 還是 grill-me”，而是：你要先識別自己面對的是哪一種不確定性。
如果不確定性來自需求尚未成型，選 brainstorming。
如果不確定性來自方案未經壓測，選 grill-me。
如果任務風險高、影響面大、後續需要可複核計劃，先用 brainstorming 收斂設計，再用 grill-me 壓測關鍵決策。
成熟的 Agent 使用，不是追求更高自動性，而是在高風險認知節點主動降低自動性。真正專業的使用者，不是讓 Agent 永遠更快，而是知道什麼時候該讓它停下來問對問題。
參考資料
skills.sh: https://www.skills.sh mattpocock/skills: https://github.com/mattpocock/skills obra/superpowers: https://github.com/obra/superpowers