指令用途
/grill-me 是一個強力的工具，用於透過密集訪談來磨利計畫或設計。它不會給你建議，而是透過提出挑戰性的問題，幫你發現想法中的漏洞、模糊和矛盾。
這就像有一個嚴格的設計評審在幫你檢查你的想法，確保你考慮了所有重要的面向。
運作流程
- 提出計畫：你描述你的計畫或設計。
- 第一輪追問：AI 針對核心概念、假設和約束進行追問。
- 深化理解：你回答問題，AI 根據回答進行更深入的追問。
- 識別風險：AI 幫你找出潛在的風險和盲點。
- 完善計畫：經過多輪追問後，你的計畫會更加完善和可靠。
實戰對話範例
範例一：新增社交功能
- You:
/grill-me - AI:
讓我們一起磨利這個社交功能的設計。
第一個問題：你說要新增「社交功能」，這是指什麼？是點讚、留言、還是分享？或者全部？
- You:
點讚和留言。
AI: 好的。讓我繼續問。
第二個問題：為什麼需要點讚和留言？這會解決什麼問題？
- You:
讓使用者更有參與感。
AI: 這是一個目標。但讓我追問：參與感是如何定義的？是時間停留更長？還是更頻繁地回來？或者是發表更多內容？
- You:
更頻繁地回來。
AI: 好的，所以你的假設是：點讚和留言會讓使用者更頻繁地回來。這個假設有證據嗎？或者這只是直覺？
- You:
這是直覺，但我看過其他平台也有類似功能。
AI: 讓我追問：你觀察過使用者目前的行為嗎？他們現在會為什麼回來？什麼讓他們不回來？
- You:
他們回來是看新內容。但不回來是因為沒有互動。
AI: 所以你的假設是：互動會讓他們回來。但讓我反問：如果內容本身不夠吸引人，即使有互動功能，他們會回來嗎？
- You:
不會。
AI: 那麼，為什麼不先改善內容品質？互動功能可能不是核心問題。
範例二：重構 API
- You:
/grill-me - AI:
讓我們一起磨利這個 API 重構的計畫。
第一個問題：為什麼要重構 API？目前的問題是什麼？
- You:
目前的 API 太舊了，不符合 RESTful 規範。
AI: 讓我追問：不規範會造成什麼問題？是開發者使用困難？還是維護困難？或者是效能問題？
- You:
開發者使用困難，URL 設計不一致。
AI: 好的。讓我追問：你收到過開發者的抱怨嗎？有多少開發者？他們的痛點是什麼？
- You:
團隊內有 5 個開發者，他們說 URL 很難記。
AI: 讓我追問：如果 URL 很難記，會影響什麼？是開發速度？還是 API 調用錯誤？
- You:
會影響開發速度，因為需要查文件。
AI: 讓我反問：這個問題是因為 URL 設計，還是因為文件不夠好？或者兩者都是？
- You:
可能兩者都是。
AI: 那麼，為什麼不先改善文件？重構 API 的成本很高，而且可能引入 bug。
- You:
因為文件再好，URL 還是不一致。
AI: 好的。讓我追問：你考慮過漸進式重構嗎？不是一次性重構所有 API，而是逐漸改進？
常見追問類型
概念追問
- 你說的是什麼意思？請給出具體定義。
- 這個術語在你的專案中是什麼意思？
假設追問
- 你有證據支持這個假設嗎？
- 這個假設來自哪里？是數據還是直覺？
風險追問
- 如果這個假設錯了，會發生什麼？
- 你考慮過這個方案的缺點嗎？
約束追問
- 你有什麼技術約束嗎？
- 你有什麼時間或資源約束嗎？
何時不應該使用
- 緊急修復：直接執行，不要花時間追問
- 明確的改進：已經有明確的改進方向，不需要追問
- 簡單的任務：例如修正 typo、小bug fix
與 /grill-with-docs 的區別
| 特性 | /grill-me | /grill-with-docs |
|---|---|---|
| 目的 | 磨利計畫或設計 | 磨利計畫或設計 |
| 文件生成 | 無 | 自動生成 ADR 和詞彙表 |
| 術語記錄 | 口頭確認 | 自動記錄到詞彙表 |
| 決策記錄 | 無 | 自動記錄到 ADR |
| 適用場景 | 小型計畫、快速探索 | 中大型計畫、需要正式文件 |