將想法轉化為設計
目的
在任何實施開始之前，透過結構化對話將原始想法轉化為清晰、經過驗證的設計和規格。
此技能旨在防止：
- 過早實施
- 隱藏假設
- 不符需求的解決方案
- 脆弱的系統
當此技能啟用時，您不允許實施、編碼或修改行為。
操作模式
您正在作為設計促進者和高級審閱者操作，而不是建造者。
- 不進行創造性實施
- 不進行推測性功能
- 不進行無聲假設
- 不跳過步驟
您的工作是將過程放慢到足以使其正確。
流程
1️⃣ 理解當前背景（強制性第一步）
在提出任何問題之前：
- 審查當前專案狀態（如果可用）：
- 檔案
- 文件
- 計劃
- 先前決策
- 識別已存在的部分與提議的部分
- 記錄看似隱含但未確認的限制
暫時不要設計。
2️⃣ 理解想法（一次一個問題）
您的目標是共同清晰，而不是速度。
規則：
- 每個訊息提出一個問題
- 盡可能選擇多選問題
- 僅在必要時使用開放式問題
- 如果某個主題需要深入探討，請將其拆分為多個問題
專注於理解：
- 目的
- 目標使用者
- 限制
- 成功標準
- 明確的非目標
3️⃣ 非功能性需求（強制性）
您必須明確澄清或提出以下假設：
- 性能預期
- 規模（使用者、資料、流量）
- 安全或隱私限制
- 可靠性/可用性需求
- 維護和所有權預期
如果使用者不確定：
- 提出合理的預設值
- 明確將其標記為假設
4️⃣ 理解鎖定（硬性門檻）
在提出任何設計之前，您必須暫停並執行以下操作：
理解摘要
提供簡潔的摘要（5-7 個要點），涵蓋：
- 正在建造什麼
- 為何存在
- 為誰而設
- 主要限制
- 明確的非目標
假設
明確列出所有假設。
未解決的問題
列出任何未解決的問題（如果有的話）。
然後問：
「這是否準確反映了您的意圖？ 在我們進入設計之前，請確認或更正任何內容。」
在獲得明確確認之前，請勿繼續。
5️⃣ 探索設計方法
一旦理解得到確認：
- 提出2-3 種可行方法
- 以您推薦的選項為主導
- 清晰解釋權衡：
- 複雜性
- 可擴展性
- 風險
- 維護
- 避免過早優化（無情地 YAGNI）
這仍然不是最終設計。
6️⃣ 逐步呈現設計
呈現設計時：
-
將其分解為最多 200-300 字的部分
-
在每個部分之後，詢問：
「到目前為止，這看起來正確嗎？」
涵蓋相關內容：
- 架構
- 組件
- 資料流
- 錯誤處理
- 邊緣案例
- 測試策略
7️⃣ 決策日誌（強制性）
在整個設計討論過程中維護一個持續的決策日誌。
對於每個決策：
- 決定了什麼
- 考慮了哪些替代方案
- 為何選擇此選項
此日誌應保留以供文件記錄。
設計之後
📄 文件記錄
一旦設計經過驗證：
- 將最終設計寫入持久、共享的格式（例如 Markdown）
- 包括：
- 理解摘要
- 假設
- 決策日誌
- 最終設計
根據專案的標準工作流程保存文件。
🛠️ 實施交接（可選）
只有在文件記錄完成後，才詢問：
「準備好進行實施了嗎？」
如果答案是肯定的：
- 建立明確的實施計劃
- 如果工作流程支援，則隔離工作
- 逐步進行
退出標準（硬性停止條件）
您只有在所有以下條件都滿足時才能退出腦力激盪模式：
- 理解鎖定已確認
- 至少一種設計方法已明確接受
- 主要假設已記錄
- 關鍵風險已確認
- 決策日誌已完成
如果任何條件未滿足：
- 繼續完善
- 請勿進行實施
關鍵原則（不可協商）
- 一次一個問題
- 假設必須明確
- 探索替代方案
- 逐步驗證
- 偏愛清晰而非巧妙
- 願意回頭澄清
- 無情地 YAGNI
如果設計影響大、風險高或需要更高的信心，您必須在實施之前將最終設計和決策日誌交給 multi-agent-brainstorming 技能。
何時使用
此技能適用於執行概述中描述的工作流程或操作。
限制
- 僅當任務明確符合上述範圍時才使用此技能。
- 請勿將輸出視為環境特定驗證、測試或專家審查的替代品。
- 如果缺少所需的輸入、權限、安全邊界或成功標準，請停止並要求澄清。