前言¶
方案寫到一半、決策有了雛形，接下來最常見的做法是發到羣裏求意見。意見會來，但通常是整體評價：「看起來還行」「方向對的」。真正要挑出來的漏洞，往往在你沒寫出來的那幾條分支裏，而熟人評審很少逐條追問。
另一種做法是自己反覆想。問題是想的時候容易順着原來的假設走，同一個漏洞會繞開兩次。
「發起方案拷問」針對的就是這個環節：你已經有方案或決策雛形，它負責發起一輪逐分支、並且給出推薦答案的壓力拷問，把評審從「整體評價」變成「逐條過」。
這是什麼¶
一句話定位：一個在方案成型期介入的評審型 Skill，對已有方案逐分支提問，並給出傾向性結論。
- 出品方：崑崙增長（@kunlungrowth）
- 座標：
@kunlungrowth/kg-grill-me - 版本：1.0.0
- 來源：enterprise
- 分類：business-ops
- 標籤：
requires_api_key=false，即不需要額外配置 API Key - 頁面數據：評分 100000，下載 951 次，安裝 0
它解決的問題是：方案有雛形之後，缺一個結構化、不客氣的逐分支質疑過程。它不負責從零生成方案，也不負責執行方案。
核心功能¶
官方簡介給出的能力只有兩條，都圍繞「拷問」這個動作：
- 逐分支：把方案拆開成分支分別審視，而不是隻給一個總評。這意味着分支是否覆蓋完整、每條分支的假設是否成立，都會被單獨過一遍。
- 給推薦答案：不止於提問，還會給出傾向性結論。這一定位比單純頭腦風暴更接近評審：你要的是「這一條我建議怎麼處理」，而不是「你覺得這條怎麼樣」。
適用前提寫在簡介裏：你需要已經「有方案或決策雛形」。輸入物是一個初步方案或一個待定決策，不是一句需求描述。
安裝與啓用¶
官方頁面未提供安裝命令、目錄路徑或配置字段。已有資料裏也沒有 Cursor、Codex CLI、Claude Code 三種環境各自的差異說明。這部分不寫推測內容，需要時以官方頁面當前說明爲準。
可以確定的是配置側：標籤爲 requires_api_key=false，因此不涉及 API Key 的申請與填入。
典型用法¶
官方資料未提供可復現的調用示例，下面是一條基於簡介構造的輸入示意，不是官方原文。
把方案寫成包含分支、假設和備選的文本交給它，例如：
方案：下季度獲客預算從內容投放轉向渠道分銷。
分支一：內容投放削減 50%，預計自然流量下降 30%。
分支二：新增 3 個區域渠道，每個渠道首季度投入 20 萬。
分支三：保留 10% 預算做新渠道實驗。
請逐分支拷問，並給出每個分支的推薦處理方式。
期望得到的輸出是逐條質疑加上每條的推薦答案，而不是一段整體評價。實際措辭以你使用的客戶端爲準。
適用場景與注意¶
適合誰：
- 方案已經寫到有分支和假設的程度，需要一次不客氣的複覈
- 決策涉及多條互斥路徑，自己反覆想容易繞回原結論
- 團隊評審節奏慢，需要一個能立刻啓動的結構化提問過程
限制：
- 輸入必須是成型的方案或決策雛形。如果只有一句需求或一個模糊方向，它沒有足夠信息拆分支
- 「推薦答案」是模型基於你提供的方案文本給出的傾向性結論，不替代事實覈查。分支裏涉及的數據、成本、外部依賴仍需自行驗證
- 拷問質量取決於方案文本的完整度。分支寫得含糊，拷問也只能在含糊的層面展開
結尾¶
這個 Skill 的價值在於把方案評審從整體感覺拉回到逐分支判斷：每條分支單獨過，每條給出推薦答案。它不幫你寫方案，也不替你決策，只是在你已有雛形時補上一輪結構化的壓力測試。
官方地址：https://api.skillhub.cn/kunlungrowth/kg-grill-me
頁面地址：https://www.skillhub.cn/skills/kunlungrowth/kg-grill-me
