指令用途

/grilling 是一個通用的密集追問工具，可以針對計畫、決策或想法進行嚴格的審查。它不會給你建議，而是透過提出挑戰性的問題，幫你發現想法中的漏洞、模糊和矛盾。

這就像有一個嚴格的評審在幫你檢查你的想法，確保你考慮了所有重要的面向。

運作流程

1. 提出目標：你描述你的計畫、決策或想法。
2. 第一輪追問：AI 針對核心概念、假設、約束進行追問。
3. 深化理解：你回答問題，AI 根據回答進行更深入的追問。
4. 識別風險：AI 幫你找出潛在的風險和盲點。
5. 完善想法：經過多輪追問後，你的想法會更加完善和可靠。

實戰對話範例

範例一：新產品想法

• You:

  /grilling

• AI:

  讓我們一起嚴格審查這個新產品想法。

  第一個問題：你說要建立一個「新的社交平台」，這是指什麼？跟現有的社交平台（Facebook、Twitter、Instagram）有什麼不同？

  • You:

  我們專注於專業社交，讓開發者可以分享他們的工作。

  AI: 「專業社交」是什麼意思？是 LinkedIn 那種嗎？

  • You:

  不完全是。我們更強調程式碼分享，而不是工作機會。

  AI: 讓我追問：你說「程式碼分享」，這是指什麼？是分享程式碼片段還是分享專案？

  • You:

  主要是分享專案，使用者可以展示他們的作品。

  AI: 讓我追問：現有的平台已經可以展示專案了（例如 GitHub），為什麼需要一個新的平台？

  • You:

  GitHub 更像程式碼庫，我們更像是作品集。

  AI: 讓我追問：作品集和程式碼庫的區別是什麼？使用者為什麼需要作品集平台？

  • You:

  作品集更強調展示，而不是程式碼管理。

  AI: 讓我反問：現有的平台（例如 Dribbble、Behance）已經可以展示作品了，為什麼需要一個新的平台？

  • You:

  這些平台主要設計和藝術，我們專注於開發者。

  AI: 讓我追問：你說「專注於開發者」，這是指什麼？只允許開發者加入嗎？還是內容限制為開發相關？

  • You:

  內容限制為開發相關，例如專案、技術文章、程式碼片段。

  AI: 讓我追問：你如何驗證使用者是開發者？

  • You:

  使用者註冊時需要提供 GitHub 或 GitLab 帳號連結。

  AI: 讓我追問：如果使用者沒有 GitHub 或 GitLab 帳號，可以加入嗎？

  • You:

  可以，但會被標記為「非開發者」。

  AI: 讓我追問：「非開發者」帳號有什麼限制嗎？

  • You:

  可以瀏覽內容，但不能發布內容。

  AI: 讓我追問：為什麼不允許「非開發者」發布內容？

  • You:

  因為我們想保持內容的開發相關性。

  AI: 讓我反問：如果「非開發者」發布了開發相關的內容（例如學習筆記），你會接受嗎？

  • You:

  會。

  AI: 那麼為什麼不允許「非開發者」發布內容？這不是矛盾嗎？

範例二：技術決策

• You:

  /grilling

• AI:

  讓我們一起嚴格審查這個技術決策。

  第一個問題：你說要使用 MongoDB，為什麼？你考慮過其他選項嗎？

  • You:

  我們考慮過 PostgreSQL 和 MySQL，但 MongoDB 更靈活。

  AI: 讓我追問：「更靈活」是什麼意思？你的數據模型會經常變更嗎？

  • You:

  是的，我們的數據模型還在演進中。

  AI: 讓我追問：如果數據模型穩定了，你會考慮換回 SQL 嗎？

  • You:

  不會。

  AI: 讓我追問：為什麼？如果 SQL 更適合穩定的數據模型，為什麼不換回去？

  • You:

  因為換回去的遷移成本太高。

  AI: 讓我追問：你有評估過遷移成本嗎？具體是多少？需要多久？

  • You:

  沒有，但我猜大概需要 2-3 週。

  AI: 讓我追問：你的猜測有依據嗎？你之前做過類似的遷移嗎？

  • You:

  沒有。

  AI: 讓我追問：那麼你為什麼認為需要 2-3 週？這個數字是從哪裡來的？

  • You:

  我只是估算。

  AI: 讓我追問：你考慮過 SQL 的優點嗎？例如 ACID、事務、外鍵？

  • You:

  考慮過，但我們不需要這些功能。

  AI: 讓我追問：為什麼不需要這些功能？你的應用場景是什麼？

  • You:

  我們的應用是簡單的 CRUD，不需要複雜的事務。

  AI: 讓我追問：簡單的 CRUD 仍然可能需要事務。例如：使用者購買商品時，需要同時扣除庫存和建立訂單記錄。這不是事務嗎？

  • You:

  是的，但這個風險可以接受。

  AI: 讓我追問：為什麼這個風險可以接受？如果庫存扣除成功但訂單記錄建立失敗，會發生什麼？

  • You:

  庫存會被多扣。

  AI: 讓我追問：你會如何處理這種情況？

  • You:

  我們會定期檢查並修正庫存。

  AI: 讓我追問：「定期檢查」是多長時間？每天、每週、還是每月？

  • You:

  每週。

  AI: 讓我追問：如果庫存多扣了，使用者會收到退款嗎？

  • You:

  會。

  AI: 讓我追問：退款流程是什麼？自動還是手動？

  • You:

  自動。

  AI: 讓我追問：自動退款可能會有風險（例如誤退款），你如何避免？

  • You:

  我們會記錄所有退款並進行審計。

常見追問類型

概念追問

• 你說的是什麼意思？請給出具體定義。
• 這個術語在你的專案中是什麼意思？

假設追問

• 你有證據支持這個假設嗎？
• 這個假設來自哪里？是數據還是直覺？

風險追問

• 如果這個假設錯了，會發生什麼？
• 你考慮過這個方案的缺點嗎？

約束追問

• 你有什麼技術約束嗎？
• 你有什麼時間或資源約束嗎？

何時不應該使用

• 緊急修復：直接執行，不要花時間追問
• 明確的改進：已經有明確的改進方向，不需要追問
• 簡單的任務：例如修正 typo、小bug fix

與其他技能的區別