universal-dev-standards 5.8.0 → 5.11.0

package/bundled/locales/zh-TW/skills/brainstorm-assistant/guide.md

@@ -4,9 +4,9 @@ description: |
   使用時機：需要完整了解腦力激盪流程、技法細節、評估矩陣。
   關鍵字：brainstorm, guide, HMW, SCAMPER, Six Thinking Hats, 腦力激盪, 指南, 發想, 創意。
 source: ../../../../skills/brainstorm-assistant/guide.md
-source_version: 1.0.0
-translation_version: 1.0.0
-last_synced: 2026-02-12
+source_version: 2.1.0
+translation_version: 2.1.0
+last_synced: 2026-05-14
 status: current
 ---
 
@@ -14,80 +14,159 @@ status: current
 
 > **語言**: [English](../../../../skills/brainstorm-assistant/guide.md) | 繁體中文
 
-**版本**: 1.0.0
-**最後更新**: 2026-02-12
+**版本**: 2.1.0
+**最後更新**: 2026-05-09
 **適用範圍**: 所有軟體專案
-**範疇**: universal
-**類型**: Utility Skill（無核心規範）
+**Scope**: universal
+**類型**: 工具型 Skill（無對應核心標準）
 
 ---
 
 ## 目的
 
-多數規格框架假設開發者已有明確的想法。但實務上，許多功能始於模糊的概念——「改善入門流程」、「讓它更快」、「加入社群功能」。在沒有結構化發想的情況下直接撰寫規格會導致：
+多數規格框架預設開發者已有清晰的想法。實務上，許多功能起步時只是模糊概念——「改善導引流程」、「讓系統更快」、「加入社群功能」。在缺乏結構化發想的情況下直接跳到撰寫規格，會導致：
 
-- 視野狹隘，錯過更好的替代方案
-- 規格解決的是表面症狀而非根本原因
-- 浪費精力在不符合真正需求的功能上
+- 視野狹窄，錯過更好的替代方案
+- 規格在解決症狀而非根本原因
+- 在無法回應真實需求的功能上浪費精力
 
-本技能填補 UDS 工作流程中的發想缺口：
+本 Skill 填補 UDS 工作流程中的發想缺口：
 
 ```
 /brainstorm → /requirement → /sdd → 實作
      ▲              ▲          ▲
-   (新增)         既有        既有
+   (本工具)        既有        既有
 ```
 
 ---
 
-## 快速參考
+## 認知科學依據 | Research Foundations
 
-### 工作流程總覽
+v2.0 流程基於三項研究發現，這些發現挑戰了 Osborn 經典腦力激盪規則中的假設：
+
+The v2.0 workflow is grounded in three research findings that challenge
+assumptions in Osborn's classic brainstorming rules.
+
+### 1. 先獨立思考，再合併（Nominal Group Technique）
+
+成員先各自獨立產生想法、再合併的群體，在質與量上都穩定優於互動式群體。其機制是**生產阻塞（production blocking）**：在聆聽他人（或閱讀 AI 輸出）時，你自己的思考流會被中斷。
+
+**在本 Skill 的應用：** Phase 0 PRE-FLIGHT 在 AI 生成任何內容前收集使用者的三個想法，防止 AI 先說話導致的錨定效應。
+
+### 2. 創意想法出現在發散階段的後半段（Nijstad et al.）
+
+研究一致顯示，腦力激盪中前 3–5 個想法幾乎總是最熟悉、最顯而易見的。真正具創意的想法在「顯而易見答案區」耗盡後才會浮現——通常在第 7、8 個想法之後。
+
+**在本 Skill 的應用：** Phase 2 的 10 個想法最低門檻和語義批次化，強制使用者在開始評估前突破「顯而易見答案區」。
+
+### 3. 辯論比「禁止批評」規則產生更多更好的想法（Nemeth, 1995）
+
+Charlan Nemeth 的研究直接挑戰 Osborn 「延後一切判斷」的核心規則。被指示要辯論與批評的群體，比遵循傳統「禁止批評」規則的群體產生了更多、品質也更好的想法。機制在於：批評強制了對假設的明確辯護，讓潛藏的弱點在投入承諾前浮現。
+
+**在本 Skill 的應用：** Phase 3 的反駁輪在最終選擇前對排名最高的想法引入結構化辯論。
+
+---
+
+## 快速參考 | Quick Reference
+
+### 流程概觀
 
 ```
-┌────────────┐    ┌────────────┐    ┌────────────┐    ┌────────────┐
-│   FRAME    │───▶│  DIVERGE   │───▶│  CONVERGE  │───▶│   OUTPUT   │
-│   定義問題  │    │   發散思考  │    │   收斂評估  │    │   輸出提案  │
-└────────────┘    └────────────┘    └────────────┘    └────────────┘
+┌─────────────┐  ┌────────────┐  ┌─────────────────┐  ┌─────────────┐  ┌────────────┐
+│  PRE-FLIGHT │─▶│   FRAME    │─▶│    DIVERGE      │─▶│  CONVERGE   │─▶│   OUTPUT   │
+│  (Phase 0)  │  │  定義問題   │  │ Batch 1 (1-5)   │  │  評分 +     │  │  腦力激盪   │
+│ 使用者先寫   │  │            │  │ Batch 2 (6-10+) │  │  反駁輪     │  │  報告      │
+│ 3 個想法    │  │            │  │ 門檻：≥10 個想法│  │             │  │            │
+└─────────────┘  └────────────┘  └─────────────────┘  └─────────────┘  └────────────┘
 ```
 
 ### 階段摘要
 
-| 階段 | 目標 | 主要技法 | 時間 |
+| 階段 | 目標 | 關鍵機制 | 時間 |
 |------|------|----------|------|
-| **FRAME** | 清楚定義問題 | 5 Whys、HMW、利害關係人對應 | 10-15 分鐘 |
-| **DIVERGE** | 產生大量想法 | HMW、SCAMPER、六頂思考帽 | 15-20 分鐘 |
-| **CONVERGE** | 評估與排序 | 評估矩陣、點數投票 | 10-15 分鐘 |
-| **OUTPUT** | 可執行的報告 | 腦力激盪報告模板 | 5-10 分鐘 |
+| **PRE-FLIGHT** | 防止 AI 錨定 | 使用者先寫 3 個想法 | 3–5 分鐘 |
+| **FRAME** | 清晰定義問題 | 5 Whys、HMW | 10–15 分鐘 |
+| **DIVERGE** | 產生 ≥10 個多樣想法 | 批次化 + 語義門檻 | 15–25 分鐘 |
+| **CONVERGE** | 選出禁得起考驗的想法 | 評分 + 反駁輪 | 15–20 分鐘 |
+| **OUTPUT** | 可行動的報告 | 腦力激盪報告範本 | 5–10 分鐘 |
+
+---
+
+## Phase 0: PRE-FLIGHT | 防止 AI 錨定
+
+> 目標：在任何 AI 內容生成之前，建立使用者的獨立思考框架。
+>
+> Goal: Establish independent thinking before any AI content is generated.
+
+### 為何重要
+
+v2.0 中槓桿效應最高的改動。研究顯示，一旦看到任何 AI 生成的框架，後續想法就會在該語義空間內聚集。Pre-flight 為這種偏見創造了「智識免疫系統」。
+
+### 提示使用者提供
+
+```
+在我們開始腦力激盪前，請花 2–3 分鐘寫下：
+
+1. 問題（一句話）：你想解決的核心問題是什麼？
+2. 你最初的想法（3 個，品質不拘）：
+   - 想法 A：
+   - 想法 B：
+   - 想法 C：
+3. 我「不想要」什麼（要避免的解決方案類型，或 N/A）：
+
+準備好就送出。AI 會先讀完這些再生成任何內容。
+```
+
+### 收到 Pre-flight 輸入後的 AI 行為
+
+1. 確認使用者的想法但不予評價
+2. 進入 FRAME
+3. 在 DIVERGE Batch 1 中，明確探索使用者沒提到的方向
+4. 如果使用者宣告了不要的解決方案類型，整個工作階段都要排除該類型
+
+### 跳過 Pre-flight
+
+使用 `--skip-preflight` 跳過。會顯示一行警告：
+
+```
+⚠ 跳過 Pre-flight 可能導致 AI 錨定
+```
+
+工作階段立即進入 FRAME。下列情境跳過 Pre-flight 是合適的：
+- 使用者已在他處寫了詳細筆記
+- 這是對熟悉問題的重複工作階段
+- 時間極度受限（盡可能改用 `--quick`）
 
 ---
 
-## 階段 1：FRAME | 定義問題
+## Phase 1: FRAME | 定義問題
 
 > 目標：在產生解決方案之前，確保我們正在解決正確的問題。
+>
+> Goal: Ensure we're solving the right problem before generating solutions.
 
-### 步驟 1.1：5 Whys — 根因分析
+### Step 1.1: 5 Whys — 根本原因分析
 
-反覆追問「為什麼？」以深入表面問題之下。
+不斷問「為什麼？」，挖到表層問題之下。
 
-**模板：**
+**範本：**
 
 ```
-問題：[初始問題陳述]
+問題：[初步問題敘述]
 
-為什麼 1：為什麼會有這個問題？
-→ 因為 [原因 1]
+Why 1：為什麼這個問題存在？
+→ 因為 [理由 1]
 
-為什麼 2：為什麼會 [原因 1]？
-→ 因為 [原因 2]
+Why 2：為什麼 [理由 1] 會發生？
+→ 因為 [理由 2]
 
-為什麼 3：為什麼會 [原因 2]？
-→ 因為 [原因 3]
+Why 3：為什麼 [理由 2] 會發生？
+→ 因為 [理由 3]
 
-為什麼 4：為什麼會 [原因 3]？
-→ 因為 [原因 4]
+Why 4：為什麼 [理由 3] 會發生？
+→ 因為 [理由 4]
 
-為什麼 5：為什麼會 [原因 4]？
+Why 5：為什麼 [理由 4] 會發生？
 → 因為 [根本原因]
 
 根本原因：[根本原因]
@@ -96,391 +175,704 @@ status: current
 **範例：**
 
 ```
-問題：使用者在結帳流程中放棄
+問題：使用者中途放棄結帳流程
 
-為什麼 1：為什麼使用者放棄結帳？
-→ 因為流程太耗時
+Why 1：為什麼使用者會放棄結帳？
+→ 因為流程花太久
 
-為什麼 2：為什麼太耗時？
+Why 2：為什麼會花太久？
 → 因為有 5 個獨立頁面
 
-為什麼 3：為什麼有 5 個頁面？
-→ 因為每個驗證步驟都有獨立頁面
+Why 3：為什麼會有 5 個頁面？
+→ 因為每個驗證步驟都有自己的頁面
 
-為什麼 4：為什麼每個驗證都需要獨立頁面？
-→ 因為原始設計假設網路連線速度慢
+Why 4：為什麼每個驗證需要單獨頁面？
+→ 因為原本的設計假設使用者連線速度慢
 
-為什麼 5：為什麼那個假設仍然成立？
-→ 已經不成立了——大多數使用者現在都用寬頻
+Why 5：為什麼這個假設仍然成立？
+→ 不再成立——現在多數使用者都用寬頻
 
-根本原因：為撥號時代設計的過時多頁面架構
+根本原因：為撥接時代設計的過時多頁架構
 ```
 
-### 步驟 1.2：HMW — 問題重構
+### Step 1.2: HMW — 問題再框架
 
-將根本原因轉化為以機會為導向的問題。
+將根本原因轉換為以機會為焦點的問題。
 
-**格式：** 「我們如何能 [動詞] [期望結果] 給 [利害關係人]？」
+**格式：** 「我們可以怎麼 [動詞] [期望結果] 給 [利害關係人]？」
 
 **規則：**
-- 足夠廣泛以容許創意解法
-- 足夠具體以可付諸行動
-- 問題中絕不包含解決方案
+- 範圍夠廣，允許有創意的解法
+- 範圍夠具體，可以行動
+- 問題本身絕不包含解法
 
 **HMW 問題範例：**
 
 ```
-根本原因：過時的多頁面結帳架構
+根本原因：過時的多頁結帳架構
 
-HMW 1：我們如何能在不失去驗證的前提下減少結帳步驟？
-HMW 2：我們如何能讓結帳感覺是即時的？
-HMW 3：我們如何能在不中斷使用者流程的情況下驗證資料？
+HMW 1：我們可以怎麼減少結帳步驟而不損失驗證？
+HMW 2：我們可以怎麼讓結帳「感覺」是瞬間完成的？
+HMW 3：我們可以怎麼在不打斷使用者流程的情況下驗證資料？
 ```
 
-### 步驟 1.3：利害關係人對應
+### Step 1.3: 利害關係人對應
 
-識別誰受影響及其需求。
+辨識誰被影響、他們的需求是什麼。
 
 | 利害關係人 | 需求 | 痛點 |
-|-----------|------|------|
+|------------|------|------|
 | 終端使用者 | 快速、簡單的結帳 | 步驟太多 |
-| 企業 | 高轉換率 | 購物車放棄率高 |
-| 開發人員 | 可維護的程式碼 | 複雜的頁面轉場 |
+| 業務方 | 高轉換率 | 購物車放棄 |
+| 開發者 | 易維護的程式碼 | 複雜的頁面轉場 |
 
-### 步驟 1.4：程式碼庫脈絡（如適用）
+### Step 1.4: 程式碼脈絡（如果適用）
 
-在為現有專案進行腦力激盪時，蒐集脈絡：
+針對既有專案做腦力激盪時，先蒐集脈絡：
 
-- **讀取** `README.md`、`package.json` 了解專案概況
-- **搜尋** 相關功能、現有實作
-- **瀏覽** 相關檔案結構
+- **Read** `README.md`、`package.json` 了解專案概況
+- **Grep** 相關功能、既有實作
+- **Glob** 相關檔案結構
 
-這讓發想能立足於現實，避免提出與現有架構衝突的想法。
+這讓發想立足現實，避免提出與既有架構相衝突的想法。
 
 ---
 
-## 階段 2：DIVERGE | 發散思考
+## Phase 2: DIVERGE | 發散思考（v2.0 升級版）
 
-> 目標：盡可能產生多個想法。此階段重量不重質。
+> 目標：在評估之前，跨越兩個語義批次產生至少 10 個想法。
+>
+> Goal: Generate at least 10 ideas across two semantic batches before evaluating any.
 
-**發散思考規則：**
-1. 延遲評判——沒有壞點子
-2. 追求數量——目標 10 個以上
-3. 借力使力——「是的，而且...」
-4. 鼓勵狂野的想法——它們常常引出實際的突破
+### 10 個想法門檻
 
-### 技法 A：HMW 腦力激盪（預設）
+**研究依據：** Nijstad 等人指出，最有創意的想法出現在發散階段的後半段。停在 3–5 個想法幾乎一定是停在「顯而易見答案區」。
 
-針對每個 HMW 問題，產生 3-5 個解決方案。
+在產生 10 個想法之前，「進入 CONVERGE」選項是隱藏的。不足 10 個時，狀態列顯示 `Continue diverging (N/10)`（繼續發散 N/10）。
 
-**模板：**
+### Batch 1 — 直覺批（想法 1–5） | Intuition Batch
 
-```
-HMW：我們如何能 [問題]？
+產生快速、未經過濾的想法。此階段不評估。
 
-想法：
-1. [想法] — [簡要說明]
-2. [想法] — [簡要說明]
-3. [想法] — [簡要說明]
-4. [想法] — [簡要說明]
-5. [想法] — [簡要說明]
-```
+規則：
+- 速度優先於深度
+- 沒有錯的想法
+- 將此批次標記為「直覺批——快速、未過濾」
+- 第 5 個想法後顯示 `✓ Intuition batch complete`
 
-### 技法 B：SCAMPER
+### Batch 2 — 延伸批（想法 6–10） | Extension Batch
 
-對現有功能或流程套用 7 個創意提示。最適合改善已有的東西。
+產生跨越 Batch 1 語義邊界的想法。
 
-| 字母 | 提示 | 要問的問題 | 範例 |
-|------|------|-----------|------|
-| **S** | 替代 (Substitute) | 可以替換什麼元件？ | 用 passkey 取代密碼驗證 |
-| **C** | 結合 (Combine) | 可以合併什麼？ | 將登入+註冊合為一個流程 |
-| **A** | 調適 (Adapt) | 可以借用什麼？ | 將電商一鍵購買用於 SaaS |
-| **M** | 修改 (Modify) | 可以放大、縮小或改變什麼？ | 將表單欄位精簡至僅需 email |
-| **P** | 另作他用 (Put to other use) | 能用於其他目的嗎？ | 用入門流程作為功能教學 |
-| **E** | 刪除 (Eliminate) | 可以完全移除什麼？ | 刪除 email 驗證步驟 |
-| **R** | 反轉 (Reverse) | 如果反過來做呢？ | 讓使用者先用再註冊 |
+開始前顯示：
+```
+延伸批：想法必須跨越 Batch 1 的語義邊界。
+如果你的下一個想法與 Batch 1 某個想法在同主題分類內，
+先試試不同的角度。
+```
 
-**模板：**
+語義重疊偵測（非阻擋性）：
+- 如果新提的想法與任何 Batch 1 想法共享主題類型，標示：
+  `⚠ 語義重疊——試試不同方向`
+- 使用者仍可送出該想法；旗標僅為建議性
 
-```
-改善的功能：[功能名稱]
+### 超過 10 個之後
 
-S - 替代：[想法]
-C - 結合：[想法]
-A - 調適：[想法]
-M - 修改：[想法]
-P - 另作他用：[想法]
-E - 刪除：[想法]
-R - 反轉：[想法]
-```
+使用者可繼續超過 10 個想法，無上限。10 個之後，「進入 CONVERGE」選項與「繼續發散」並列出現。
 
-### 技法 C：六頂思考帽
+### 技法 | Techniques
+
+| 技法 | 使用時機 |
+|------|----------|
+| **HMW Questions** | 預設起點 |
+| **SCAMPER** | 改善現有功能 |
+| **Six Thinking Hats** | 需要多角度思考 |
 
-從 6 個不同角度檢視問題。最適合需要全面分析的時候。
+#### 技法 A：HMW 腦力激盪（預設）
 
-| 帽子 | 顏色 | 焦點 | 問題 |
-|------|------|------|------|
-| 1 | 白色 | 事實與資料 | 我們知道什麼？有什麼資料？ |
-| 2 | 紅色 | 情感與直覺 | 直覺怎麼說？使用者感受如何？ |
-| 3 | 黑色 | 風險與謹慎 | 什麼可能出錯？有什麼風險？ |
-| 4 | 黃色 | 好處與樂觀 | 最好的情況是什麼？這帶來什麼價值？ |
-| 5 | 綠色 | 創意 | 有什麼新想法？如果我們...？ |
-| 6 | 藍色 | 流程與總結 | 全貌是什麼？下一步是什麼？ |
+針對每個 HMW 問題，產生 3–5 個解法想法。
 
-**模板：**
+**範本：**
 
 ```
-主題：[主題]
+HMW：我們可以怎麼 [問題]？
 
-白帽（事實）：
-- [事實/數據]
+想法：
+1. [想法] — [簡短說明]
+2. [想法] — [簡短說明]
+3. [想法] — [簡短說明]
+4. [想法] — [簡短說明]
+5. [想法] — [簡短說明]
+```
 
-紅帽（感受）：
-- [直覺/情感]
+#### 技法 B：SCAMPER
 
-黑帽（風險）：
-- [風險/顧慮]
+對既有功能或流程套用 7 個創意提示。最適合用於改善既有事物。
 
-黃帽（好處）：
-- [機會/效益]
+| 字母 | 提示 | 應問的問題 | 範例 |
+|------|------|-----------|------|
+| **S** | Substitute（取代） | 哪個組件可以替換？ | 用 passkeys 取代密碼認證 |
+| **C** | Combine（合併） | 哪些可以合在一起？ | 把登入 + 註冊合併為單一流程 |
+| **A** | Adapt（改編） | 可以從別處借鑒什麼？ | 借電商「一鍵購買」應用於 SaaS |
+| **M** | Modify（修改） | 可以放大、縮小或改變什麼？ | 將表單欄位縮減為僅 email |
+| **P** | Put to other use（其他用途） | 能否服務不同目的？ | 把導引流程當作功能教學 |
+| **E** | Eliminate（消除） | 什麼可以完全移除？ | 消除 email 驗證步驟 |
+| **R** | Reverse（反轉） | 反過來做會如何？ | 讓使用者先用、之後再註冊 |
 
-綠帽（創意）：
-- [創意想法]
+**範本：**
 
-藍帽（總結）：
-- [綜合與下一步]
 ```
+要改進的功能：[功能名稱]
+
+S - 取代：       [想法]
+C - 合併：       [想法]
+A - 改編：       [想法]
+M - 修改：       [想法]
+P - 其他用途：   [想法]
+E - 消除：       [想法]
+R - 反轉：       [想法]
+```
+
+#### 技法 C：Six Thinking Hats（六頂思考帽）
+
+從 6 個獨立角度檢視問題。適合需要全面分析時。
+
+| 帽 | 顏色 | 焦點 | 問題 |
+|----|------|------|------|
+| 1 | 白 | 事實與資料 | 我們知道什麼？有什麼數據？ |
+| 2 | 紅 | 情緒與直覺 | 直覺怎麼說？使用者感覺如何？ |
+| 3 | 黑 | 風險與謹慎 | 可能哪裡出錯？風險是什麼？ |
+| 4 | 黃 | 利益與樂觀 | 最好的情況是什麼？這加了什麼價值？ |
+| 5 | 綠 | 創意 | 浮現了什麼新想法？如果…會怎樣？ |
+| 6 | 藍 | 流程與總結 | 全局是什麼？下一步是什麼？ |
 
 ---
 
-## 階段 3：CONVERGE | 收斂評估
+## Phase 3: CONVERGE | 反駁收斂（v2.0 升級版）
 
-> 目標：客觀評估想法，選出最值得推進的方案。
+> 目標：選出同時通過正向評分和結構化辯論的想法。
+>
+> Goal: Select ideas that survive both positive scoring AND structured debate.
 
-### 評估矩陣
+### Step 3a：評估矩陣 | Evaluation Matrix
 
-以 1-5 分對每個想法進行 4 項標準評分：
+依 4 個準則（1–5 分）為每個想法評分：
 
-| 標準 | 權重 | 評分指南 |
+| 準則 | 權重 | 評分指引 |
 |------|------|----------|
-| **可行性** | 30% | 5=極簡單、4=直接、3=中等、2=困難、1=幾乎不可能 |
-| **影響力** | 30% | 5=革命性、4=顯著、3=中等、2=輕微、1=可忽略 |
-| **成本** | 20% | 5=數小時、4=數天、3=數週、2=數月、1=數季（反向：越低成本越高分） |
-| **一致性** | 20% | 5=核心使命、4=戰略性、3=相關、2=邊緣、1=偏離使命 |
+| **可行性** | 30% | 5=易如反掌、4=直接、3=中等、2=困難、1=幾乎不可能 |
+| **影響力** | 30% | 5=轉變性、4=顯著、3=中等、2=次要、1=可忽略 |
+| **投入** | 20% | 5=幾小時、4=幾天、3=幾週、2=幾個月、1=幾季（反向：投入越低分數越高） |
+| **對齊度** | 20% | 5=核心使命、4=策略性、3=相關、2=邊緣、1=偏離使命 |
 
 **加權分數公式：**
 
 ```
-分數 = (可行性 × 0.3) + (影響力 × 0.3) + (成本 × 0.2) + (一致性 × 0.2)
+Score = (可行性 × 0.3) + (影響力 × 0.3) + (投入 × 0.2) + (對齊度 × 0.2)
 ```
 
 **範例：**
 
-| # | 想法 | 可行性 | 影響力 | 成本 | 一致性 | **分數** |
+| # | 想法 | 可行性 | 影響力 | 投入 | 對齊度 | **分數** |
 |---|------|--------|--------|------|--------|----------|
 | 1 | 單頁結帳 | 4 | 5 | 3 | 5 | **4.3** |
 | 2 | 一鍵購買 | 3 | 4 | 2 | 4 | **3.3** |
 | 3 | 漸進式表單 | 5 | 4 | 4 | 4 | **4.3** |
 | 4 | 訪客結帳 | 5 | 3 | 5 | 3 | **4.0** |
 
-### 快速排序：點數投票
+### Step 3b：反駁輪 | Rebuttal Round
+
+**研究依據（Nemeth, 1995）：** 被允許辯論的群體比遵循「禁止批評」規則的群體產生更多、更好的想法。機制在於批評強制對假設作出明確辯護，這在投入承諾之前讓潛藏弱點浮現。
+
+**對前 3 名的每一個想法**，AI 提出 **2 個具體的反論點。**
+
+每個反論點的格式：
+```
+「這個想法會在 [特定脈絡] 失敗，因為 [特定理由]。」
+```
+
+**不可接受**（太空泛）：
+- 「這可能很難實作。」
+- 「可能會有 edge case。」
+
+**可接受**（特定失敗條件）：
+- 「這個想法會對企業客戶失敗，因為他們的 IT 政策禁止把 OAuth token 存在瀏覽器 localStorage。」
+- 「這個想法會在尖峰流量時失敗，因為同步 API 呼叫會阻塞 render thread，造成 500ms+ 的視覺卡頓。」
 
-當評估矩陣感覺太重時，使用點數投票：
+### 使用者回應選項
+
+工作階段繼續前，使用者**必須**對每個反論點選擇下列三項之一：
+
+| 選項 | 動作 |
+|------|------|
+| (a) 接受批評 | 提供修改版本的想法以解決該失敗情況 |
+| (b) 不同意 | 提供具體理由為何該反論點不適用 |
+| (c) 批評有效 | 從排名中移除該想法 |
+
+### 反駁輪在報告中的結果
+
+通過反駁輪的每個想法會在最終報告中獲得徽章：
+
+```
+✓ 通過反駁 — [使用者回應的一句話摘要]
+```
 
-1. 列出所有想法
-2. 每人 3 票（點）
-3. 投給你最看好的想法（可以把多票投在同一個想法上）
-4. 最高票數者勝出
+**跳過：** `--no-rebuttal` 跳過反駁輪。報告對應段落標為「反駁輪：已跳過」。
 
 ---
 
-## 階段 4：OUTPUT | 輸出提案
+## Phase 4: OUTPUT | 輸出提案
 
 > 目標：產生可直接輸入 `/requirement` 或 `/sdd` 的結構化報告。
+>
+> Goal: Produce a structured report that feeds directly into `/requirement` or `/sdd`.
 
-### 腦力激盪報告模板
+### 腦力激盪報告範本
 
 ```markdown
 # 腦力激盪報告：[主題]
 
-**日期**: YYYY-MM-DD
-**參與者**: [人類, AI 助手]
-**使用技法**: [HMW, SCAMPER 等]
+**日期**：YYYY-MM-DD
+**參與者**：[人類, AI 助手]
+**使用技法**：[HMW, SCAMPER, etc.]
+**Pre-flight**：[已完成 / 已跳過]
+**反駁輪**：[已完成 / 已跳過]
 
-## 問題陳述
+## 問題敘述
 
-[FRAME 階段精煉的問題陳述，包含 5 Whys 的根本原因]
+[FRAME 階段精煉後的問題敘述，包含 5 Whys 的根本原因]
 
 ## HMW 問題
 
-1. 我們如何能...？
-2. 我們如何能...？
-3. 我們如何能...？
+1. 我們可以怎麼 …？
+2. 我們可以怎麼 …？
+3. 我們可以怎麼 …？
 
 ## 產生的想法
 
-| # | 想法 | 來源技法 | 可行性 | 影響力 | 成本 | 一致性 | 分數 |
-|---|------|----------|--------|--------|------|--------|------|
-| 1 | ...  | SCAMPER-R | 4     | 5      | 3    | 5      | 4.3  |
-| 2 | ...  | HMW       | 3     | 4      | 2    | 4      | 3.3  |
+| # | 想法 | 批次 | 來源技法 | 可行性 | 影響力 | 投入 | 對齊度 | 分數 |
+|---|------|------|----------|--------|--------|------|--------|------|
+| 1 | ...  | B1   | SCAMPER-R | 4     | 5      | 3    | 5      | 4.3  |
+| 2 | ...  | B2   | HMW       | 3     | 4      | 2    | 4      | 3.3  |
+| 3 | ...  | B2   | Six Hats-Green | 5 | 4    | 4    | 4      | 4.3  |
 
-## 前 3 名推薦
+## Top 3 推薦
 
-### 1. [想法名稱]（分數：X.X）
-- **原因**: [推薦理由]
-- **主要效益**: [首要價值]
-- **主要風險**: [首要顧慮]
-- **預估範圍**: [小 / 中 / 大]
+### 1. [想法名稱]（分數：X.X）✓ 通過反駁
+- **為何**：[理由]
+- **關鍵效益**：[主要價值]
+- **反駁回應**：[使用者如何回應挑戰的一句話摘要]
+- **估計範圍**：[小 / 中 / 大]
 
-### 2. [想法名稱]（分數：X.X）
-- **原因**: [推薦理由]
-- **主要效益**: [首要價值]
-- **主要風險**: [首要顧慮]
-- **預估範圍**: [小 / 中 / 大]
+### 2. [想法名稱]（分數：X.X）✓ 通過反駁
+- **為何**：[理由]
+- **關鍵效益**：[主要價值]
+- **反駁回應**：[一句話摘要]
+- **估計範圍**：[小 / 中 / 大]
 
-### 3. [想法名稱]（分數：X.X）
-- **原因**: [推薦理由]
-- **主要效益**: [首要價值]
-- **主要風險**: [首要顧慮]
-- **預估範圍**: [小 / 中 / 大]
+### 3. [想法名稱]（分數：X.X）✓ 通過反駁
+- **為何**：[理由]
+- **關鍵效益**：[主要價值]
+- **反駁回應**：[一句話摘要]
+- **估計範圍**：[小 / 中 / 大]
 
-## 淘汰的想法（附原因）
+## 已捨棄的想法（含理由）
 
-| 想法 | 淘汰原因 |
+| 想法 | 捨棄理由 |
 |------|----------|
+| ...  | 反駁輪中移除（反論點被接受） |
 | ...  | 可行性低（分數：1/5） |
 
-## 後續步驟
+## 下一步
 
 - [ ] 以推薦 #1 進入 `/requirement`
-- [ ] 若需求已明確，直接進入 `/sdd`
+- [ ] 如需求已明確，進入 `/sdd`
 - [ ] 對 [子主題] 進行後續腦力激盪
 ```
 
 ---
 
-## 與 UDS 工作流程整合
+## 旗標參考 | Flags Reference
 
-腦力激盪報告可直接對應到下游工具：
+| 旗標 | 影響階段 | 行為 |
+|------|----------|------|
+| `--skip-preflight` | Phase 0 | 跳過 Pre-flight；顯示一行錨定警告 |
+| `--no-rebuttal` | Phase 3 | 跳過反駁輪；報告對應段落標為「反駁輪：已跳過」 |
+| `--quick` | 全部 | 3 個想法快速模式；Phase 0、10 個想法門檻、反駁輪皆豁免 |
+| `--technique scamper` | Phase 2 | 強制 SCAMPER 為主要發散技法 |
 
-### 對應至 `/requirement`
+### Quick 模式（`--quick`）
 
-| 腦力激盪報告章節 | `/requirement` 欄位 |
-|-----------------|---------------------|
-| 問題陳述 | User Story 脈絡 |
-| 首選推薦 | 功能描述 |
-| HMW 問題 | 驗收標準的種子 |
-| 利害關係人對應 | 利害關係人章節 |
-| 淘汰的想法 | 不在範圍內 |
+5 分鐘內交付結果。輸出最多 20 行。
 
-### 對應至 `/sdd`
+```
+1 個 HMW 問題 → 3 個想法 → 1 個推薦 → 下一步
+```
+
+所有認知科學閘門（Pre-flight、10 個想法最低門檻、反駁輪）在 quick 模式下都豁免。Quick 模式適合：
+- 寫程式中段的決定
+- 重新界定已被理解的問題範圍
+- 完整工作階段前的初步定位
+
+永遠提供升級選項：「要進行完整的腦力激盪工作階段嗎？」
+
+---
+
+## 與 UDS 工作流的整合
+
+腦力激盪報告直接對應到下游工具：
+
+### 對應到 `/requirement`
+
+| 腦力激盪報告區段 | `/requirement` 欄位 |
+|------------------|---------------------|
+| 問題敘述 | User Story 脈絡 |
+| Top 推薦 | 功能描述 |
+| HMW 問題 | Acceptance Criteria 種子 |
+| 利害關係人地圖 | 利害關係人段落 |
+| 已捨棄的想法 | 超出範圍 |
+
+### 對應到 `/sdd`
 
-| 腦力激盪報告章節 | `/sdd` 欄位 |
-|-----------------|-------------|
-| 問題陳述 | 摘要 / 動機 |
-| 首選推薦 | 提議的解決方案 |
-| 評估矩陣 | 權衡 / 考慮過的替代方案 |
-| 風險（黑帽） | 風險章節 |
-| 預估範圍 | 範圍章節 |
+| 腦力激盪報告區段 | `/sdd` 欄位 |
+|------------------|-------------|
+| 問題敘述 | Summary / Motivation |
+| Top 推薦 | 提案的解法 |
+| 評估矩陣 | 取捨 / 替代方案考量 |
+| 反駁回應 | 風險段落 |
+| 估計範圍 | Scope 段落 |
 
 ---
 
-## 設定偵測
+## 配置偵測
 
-當在專案目錄中調用時，腦力激盪助手會：
+在專案目錄中啟動時，腦力激盪助手會：
 
-1. **檢查現有規格** — 避免對已有規格的問題重複腦力激盪
-2. **讀取專案 README** — 了解專案目的與限制
-3. **掃描近期 issues/PR** — 識別當前痛點（如有 git 倉庫）
-4. **檢查技術棧** — 使可行性評估立足於實際技術
+1. **檢查既有規格** — 避免對已有規格的問題重複腦力激盪
+2. **讀取專案 README** — 理解專案目的與限制
+3. **掃描近期 issues/PRs** — 辨識當前痛點（如為 git 儲存庫）
+4. **檢查技術堆疊** — 讓可行性評估立足於實際技術
 
 ---
 
-## 範例演練
+## 範例走查（v2.0）
 
-### 情境：「我們需要改善使用者留存率」
+### 情境：「我們需要提升使用者留存率」
+
+**PRE-FLIGHT（使用者送出）：**
+```
+問題：30 天留存率為 15%，低於業界平均 40%
+我的想法：
+  A：在 7 天未活躍後寄送召回 email
+  B：加入成就 / 遊戲化系統
+  C：登入時顯示「最新動態」摘要
+不想要：需要後端 ML 模型的解法（出貨太慢）
+```
 
 **FRAME：**
 ```
 5 Whys：
-問題：使用者留存率低（30 天留存率 15%）
+問題：留存率 15%
+Why 1：使用者註冊後不久就停用 → 沒探索到關鍵功能
+Why 2：為何沒探索功能？→ 導引只展示基本設定
+Why 3：為何只有基本設定？→ 一次性精靈設計的假設
+Why 4：為何用一次性精靈？→ 團隊假設使用者會自己探索
+Why 5：為何這假設失敗？→ 20+ 功能，無漸進式揭露
 
-為什麼 1：使用者在初始註冊後停止使用
-→ 因為他們沒有發現關鍵功能
+根本原因：缺乏漸進式導引——使用者看到的不是全部就是什麼都沒有
 
-為什麼 2：為什麼沒有發現功能？
-→ 因為入門流程只展示基本設定
+HMW 問題：
+1. 我們可以怎麼引導使用者在對的時機發現功能？
+2. 我們可以怎麼讓功能探索感覺自然而非強迫？
+3. 我們可以怎麼透過慶祝里程碑建立使用習慣？
+```
 
-為什麼 3：為什麼入門只展示基本設定？
-→ 因為它被設計為一次性精靈
+**DIVERGE — Batch 1（直覺）：**
+```
+AI 註記：探索使用者 A/B/C 想法之外的方向
+
+1. 由使用者行為觸發的情境提示  [HMW-1]
+2. 漸進式檢查清單取代一次性精靈  [SCAMPER-S]
+3. 首任務導引（跳過設定，直接做真實工作）  [SCAMPER-C]
+4. 為新使用者配對同儕導師  [SCAMPER-R]
+5. 連續習慣追蹤器（每日登入獎勵）  [HMW-3]
+✓ Intuition batch complete
+```
 
-為什麼 4：為什麼是一次性精靈？
-→ 因為團隊假設使用者會自行探索
+**DIVERGE — Batch 2（延伸——跨越語義邊界）：**
+```
+延伸批：想法必須跨越 Batch 1 的語義邊界
 
-為什麼 5：為什麼那個假設不成立？
-→ 因為應用有 20+ 功能但沒有漸進式揭露
+6. API 驅動導引：偵測使用者資料並自動填入範例  [HMW-1]
+7. 反向導引：先展示高手工作流程，按要求簡化  [SCAMPER-R]
+8. 社會認證：顯示「同儕每週使用功能 X 3 次」  [HMW-2]
+9. 功能解鎖閘：透過使用獲得進階功能權限  [HMW-3]
+10. 同期分組節奏：按註冊週分組，同時寄送相同訣竅  [HMW-1]
+```
 
-根本原因：沒有漸進式入門——使用者看到全部或什麼都看不到
+**CONVERGE — 評分：**
+```
+| # | 想法                          | 可行性 | 影響力 | 投入 | 對齊度 | 分數 |
+|---|-------------------------------|--------|--------|------|--------|------|
+| 2 | 漸進式檢查清單                | 5      | 5      | 4    | 5      | 4.8  |
+| 6 | API 驅動導引                  | 4      | 5      | 3    | 5      | 4.3  |
+| 1 | 情境提示                      | 4      | 4      | 3    | 5      | 4.0  |
+```
+
+**CONVERGE — 反駁輪：**
+```
+想法 #2：漸進式檢查清單
+
+反論點 1：「這個想法會對重新安裝 app 的回頭使用者失敗，因為若清單狀態
+綁定裝置就會遺失，導致老手要重做新手任務，覺得被當小孩看。」
+
+使用者回應（b — 不同意）：「清單狀態存在 server 端綁定 user ID，所以
+回頭使用者會從上次停下的地方繼續。」
+
+反論點 2：「這個想法會對高手使用者失敗，他們覺得檢查清單很幼稚，若沒
+退出選項就會立刻關掉。」
+
+使用者回應（a — 接受）：修改 → 在每個清單項目上加一鍵『我已知道』
+忽略按鈕，並在設定中提供『隱藏清單』選項。
+
+→ ✓ 通過反駁
+```
+
+**OUTPUT：** 最高推薦為「漸進式檢查清單（修改版）」→ 進入 `/requirement`。
+
+---
+
+## 模式選擇指引 | Mode Selection Guide
+
+SKILL.md 的模式選擇表使用客觀觸發條件，消除「我應該用哪個模式？」的決策負擔。本節說明各規則的設計理由。
+
+### 為何用客觀觸發條件而非主觀診斷
+
+v2.0 腦力激盪反駁輪本身就揭露了這個問題：如果使用者必須先診斷「我的問題是策略型還是執行型？」，這個元決策會在工作階段開始前就消耗認知資源。客觀觸發條件（字數、是否帶旗標、是否有規格）消除了這個問題。
+
+### 觸發條件校準
+
+`< 20 字` 這個門檻是起步啟發法，不是永久規則。在 5–10 次工作階段後，回顧短輸入是否一致地導致探索不足，或是它們本來就確實簡單。依觀察而非直覺調整門檻。
+
+---
+
+## 自我評估框架 | Self-Evaluation Framework
+
+每次腦力激盪結束後使用這三個指標，建立長期品質紀錄。不要以單次工作階段評估 v2.0 vs v1.0，至少收集 3 次可比較的工作階段後再下結論。
+
+### 三個指標
+
+#### 1. 採用率 | Adoption Rate
+**問題：** 在這次工作階段產生的所有想法中，你會實際使用或進一步研究多少？
+
+**評分：**
+- 5 = 3+ 個想法直接可行動
+- 4 = 2 個想法可行動、1+ 個值得探索
+- 3 = 1 個想法可行動
+- 2 = 沒想法直接可行動，但浮現了有用的框架
+- 1 = 工作階段沒產出任何有用的東西
+
+**為何重要：** 採用率是最接近「腦力激盪是否解決了正確的問題？」的代理指標。它校正那些感覺有產出但想法從未被回顧的工作階段。
+
+#### 2. 語義多樣性 | Diversity
+**問題：** 延伸批（6–10）的想法在主題與方法上是否顯著不同於直覺批（1–5）的想法？
+
+**評分：**
+- 5 = 延伸批探索了完全不同的問題維度
+- 4 = 延伸批有 3+ 個想法明顯跨越了語義邊界
+- 3 = 有一些延伸，但多數想法是 Batch 1 主題的變化
+- 2 = 延伸批實質上是 Batch 1 的延續
+- 1 = 兩批之間沒有顯著的語義差異
+
+**為何重要：** 多樣性衡量 10 個想法門檻是否真的把使用者推過「顯而易見答案區」。如果多樣性分數持續偏低，Batch 2 的語義邊界指示可能需要強化。
+
+#### 3. 認知負擔 | Cognitive Load
+**問題：** 這次工作階段在心智上有多耗費？（分數越高 = 負擔越低）
+
+**評分：**
+- 5 = 工作階段感覺毫不費力且有產出
+- 4 = 有些摩擦但整體有產出
+- 3 = 中等付出，幾個挫折時刻
+- 2 = 工作階段全程感覺像在工作
+- 1 = 精疲力盡；不會再用此格式
+
+**為何重要：** 在認知負擔上持續評為 1–2 分的腦力激盪方法，無論品質如何提升，最終都會被放棄、改用非正式思考。目標：認知負擔 ≥ 3，同時採用率與多樣性也在改進。
+
+### 工作階段記錄範本
 
-HMW 問題：
-1. 我們如何能在適當時機引導使用者發現功能？
-2. 我們如何能讓功能發現感覺自然而非強迫？
-3. 我們如何能慶祝使用者里程碑以建立參與習慣？
 ```
+日期：YYYY-MM-DD
+主題：[一句話]
+模式：[Full / Quick / No-Rebuttal / Skip-Preflight]
+時長：[分鐘]
+
+採用率：     /5 — [原因]
+語義多樣性： /5 — [原因]
+認知負擔：   /5 — [原因]
+
+值得記錄的觀察：
+[一句話描述什麼有用、什麼感覺不對]
+```
+
+### 趨勢判讀 | Interpreting Trends
+
+收集 3+ 次工作階段後，留意這些模式：
+
+| 模式 | 詮釋 | 行動 |
+|------|------|------|
+| 採用率持續 ≤ 2 | 問題框架在 FRAME 階段失敗，而非技法問題 | 發散前花更多時間在 5 Whys |
+| 多樣性持續 ≤ 2 | 10 個想法門檻沒產生語義廣度 | 在 Batch 2 前強制明確的主題切換 |
+| 認知負擔持續 ≤ 2 | 流程開銷對問題複雜度而言太高 | 較低風險的問題改用 `--no-rebuttal` 或 `--quick` |
+| 三個指標都 ≥ 4 | v2.0 對這類問題運作良好 | 維持現狀 |
+| 採用率上升但認知負擔下降 | 習慣化——新流程開始變自然 | 繼續；偶爾用 `--quick` 換氣 |
+
+---
+
+## A/B 實驗協議 | A/B Experiment Protocol
+
+使用此協議驗證 v2.0 是否真的對你的特定問題類型優於 v1.0，而非單純依賴研究假設。
+
+### 協議設計
+
+**時長：** 3 對工作階段（最少）
+**方法：** 同類問題，交替方法
+
+**工作階段配對：**
+```
+Session A1：類型 X 的問題 → v1.0（AI 先生成、無 Pre-flight）
+Session B1：類型 X 的問題 → v2.0（Pre-flight + 完整流程）
+[間隔一週]
+Session A2：類型 Y 的問題 → v2.0
+Session B2：類型 Y 的問題 → v1.0
+[間隔一週]
+Session A3：類型 X 的問題 → v2.0
+Session B3：類型 X 的問題 → v1.0
+```
+
+交替能降低順序效應（從 session A 學到的東西影響 session B）。
+
+**關鍵：每次工作階段完成後立即評估。** 不要等——對認知負擔的記憶衰退最快。
+
+### 要測量什麼
+
+每次工作階段記錄：
+
+| 測量 | v1.0 工作階段 | v2.0 工作階段 |
+|------|---------------|---------------|
+| 採用率（1–5） | | |
+| 多樣性（1–5） | | |
+| 認知負擔（1–5） | | |
+| 完成時間（分鐘） | | |
+| 產生的想法數 | | |
+| Batch 2 讓你驚訝的想法 | N/A | |
+
+### 解讀結果
+
+- **v2.0 勝出** 若採用率與多樣性都較高，且認知負擔差距 ≤ 1 分
+- **v1.0 勝出** 若 v2.0 的認知負擔高 ≥ 2 分*且*採用率差距 < 1 分
+- **依情境而定** 若結果隨問題類型而異 → 實作完整情境路由（見模式選擇章節）
+
+### 待驗證的關鍵假設
+
+v2.0 背後的三個研究假設在「AI 輔助單人」情境下有不同程度的外部效度風險（見下方「研究效度說明」）。A/B 協議應該明確檢驗：
+
+1. **Pre-flight 假設：** 在你寫了 3 個想法後，AI 的第一批是否真的探索了不同領域？要明確追蹤。
+2. **10 個想法門檻假設：** 想法 7–10 是否一致地比想法 1–3 更多樣或更有用？每次回顧工作階段記錄。
+3. **反駁假設：** 反駁輪之後，你是否真的修改或捨棄了任何想法？如果從未發生，反駁輪對你的問題類型可能沒在加值。
+
+---
+
+## 研究效度說明 | Research Validity Caveats
+
+v2.0 基於三項研究發現。每項在應用於 AI 輔助單人腦力激盪時，有不同程度的外部效度風險。在將研究視為確定事實之前，請理解其局限性。
+
+### 假設 1：AI 輸出會錨定思考（NGT 依據）
+
+**原始發現：** Nominal Group Technique 顯示個別腦力激盪後合併的結果優於互動式群體。機制：群體中的生產阻塞與從眾壓力。
+
+**對 v2.0 的應用：** Pre-flight 假設 AI 輸出對你思考的錨定效應，與群體中主導性的人類聲音相同。
+
+**外部效度風險：中**
+
+錨定機制可能不同。人類社會錨定涉及從眾壓力與即時打斷。AI 輸出是靜態文字，你可以選擇忽略。問題是「先讀 AI 輸出再寫你自己的想法」是否會有意義地縮窄你的語義探索。
+
+**如何驗證：** 在你的 A/B 實驗中，v2.0 工作階段後記錄 AI 第一批是否真的與你的 Pre-flight 想法不同。若是，Pre-flight 有效。若 AI 經常產生與你相似的想法，Pre-flight 的價值可能在於迫使你明確說出起點——一個不同但仍有效的好處。
+
+### 假設 2：最佳想法出現在後半段（Nijstad 依據）
+
+**原始發現：** Nijstad 等人指出腦力激盪中早期想法最因循。創意想法在顯而易見區耗盡後浮現。
+
+**對 v2.0 的應用：** 10 個想法最低門檻與語義批次化假設這個時間模式在 AI 輔助情境中也成立。
+
+**外部效度風險：低**
+
+這個發現是關於認知模式（先耗盡顯而易見的關聯），不是關於群體動態。它更可能轉移到 AI 輔助單人情境，因為底層機制（語義網路遍歷）不論是人類或 AI 在產生想法都適用。
+
+**如何驗證：** 每次工作階段後，比較想法 1–5 與想法 7–10。後期想法是否一致地更不顯而易見？若是，門檻值回票價。
+
+### 假設 3：辯論產生更好的想法（Nemeth 依據）
+
+**原始發現：** Nemeth (1995) 顯示被指示辯論的群體比遵循「禁止批評」規則的群體產生更多、更好的想法。
+
+**對 v2.0 的應用：** 反駁輪假設與 AI 反論點的結構化辯論能改善想法品質。
+
+**外部效度風險：高**
+
+這是最沒把握的轉移。Nemeth 的發現是關於*持不同觀點與利益的人之間的真實異議*。AI 按需扮演「魔鬼代言人」可能產生形式上正確但缺乏真實異議的反論點——也就是 Nemeth 效應的真正驅動力。反論點可能感覺對立但並未真正帶來啟示。
+
+**如何驗證：** 每次反駁輪後誠實評估：反論點是否揭露了你「真的沒考慮過」的事？若答案一致是「沒有，我已想過這個」，反駁輪可能在提供虛假的信心而非真正的挑戰。對熟悉領域考慮改用 `--no-rebuttal`。
+
+---
+
+## 漸進採用協議 | Gradual Adoption Protocol
+
+如果完整 v2.0 流程感覺負擔過重，按順序逐步採用三個改動，而非一次全部導入。每個階段使用兩週再加入下一個。
+
+### Phase 1：僅 Pre-flight（第 1–2 週）
+
+執行 `/brainstorm --no-rebuttal [主題]`，啟用 Pre-flight 但跳過反駁。焦點：先寫 3 個想法是否改變了 AI 的產出？
 
-**DIVERGE（HMW + SCAMPER）：**
+### Phase 2：加入 10 個想法門檻（第 3–4 週）
 
-| # | 想法 | 技法 |
-|---|------|------|
-| 1 | 基於使用者行為觸發的情境提示 | HMW-1 |
-| 2 | 每週「你知道嗎？」email 介紹一項功能 | HMW-1 |
-| 3 | 成就系統與解鎖徽章 | HMW-3 |
-| 4 | 用漸進式清單取代精靈 | SCAMPER-S |
-| 5 | 將入門與第一個實際任務結合 | SCAMPER-C |
-| 6 | 借鑑 Duolingo 的連續天數系統 | SCAMPER-A |
-| 7 | 將入門精簡為 1 個問題：「你的目標是什麼？」 | SCAMPER-M |
-| 8 | 取消註冊牆，讓使用者先試用 | SCAMPER-E |
-| 9 | 反轉：讓進階使用者指導新使用者 | SCAMPER-R |
+繼續使用 Pre-flight，現在執行 10 個想法最低門檻。焦點：想法 7–10 是否比想法 1–5 更好？
 
-**CONVERGE：**
+### Phase 3：加入反駁輪（第 5–6 週）
 
-| # | 想法 | 可行性 | 影響力 | 成本 | 一致性 | 分數 |
-|---|------|--------|--------|------|--------|------|
-| 7 | 目標導向入門 | 5 | 5 | 4 | 5 | **4.8** |
-| 1 | 情境提示 | 4 | 4 | 3 | 5 | **4.0** |
-| 5 | 透過實際任務入門 | 3 | 5 | 2 | 5 | **3.8** |
+執行完整 v2.0 流程。焦點：反論點是否揭露了你未考慮過的問題？
 
-**OUTPUT：** 首選推薦是「目標導向入門」→ 進入 `/requirement`。
+6 週後，回顧工作階段記錄與 A/B 實驗資料，校準哪個組合對你的問題類型最佳。
 
 ---
 
-## 最佳實踐
+## 最佳實踐 | Best Practices
 
-### 應該做的
+### Do's
 
-- 從 FRAME 開始——抵抗直接跳到解決方案的衝動
-- 在評估任何想法之前，先產生至少 10 個
-- 利用程式碼庫脈絡為可行性評分提供依據
-- 保存腦力激盪報告以供日後參考
-- 為每個階段設定時間限制以維持動力
+- 開始前完成 Pre-flight——只需 3 分鐘，能大幅提升想法多樣性
+- 走完到 10+ 個想法——最佳想法出現在後段
+- 認真對待反駁輪——空泛的辯護是警訊
+- 每次工作階段後記錄三個評估指標
+- 時間受限用 `--quick`，重要決策用完整模式
+- 每 3 次工作階段後回顧記錄趨勢
 
-### 不應該做的
+### Don'ts
 
-- 不要在 DIVERGE 階段進行評估
-- 不要只使用一種技法——結合使用
-- 不要跳過 5 Whys——表面問題會導致表面解決方案
-- 不要在利害關係人可參與時獨自腦力激盪
-- 不要強迫所有想法通過同一種技法
+- 在寫 Pre-flight 想法前別讀 AI 輸出
+- 在 DIVERGE 階段別評估
+- 別停在 5 個想法——撐過「顯而易見答案區」
+- 別接受空泛的 AI 反論點（「這可能很難」）——堅持要具體的失敗條件
+- 別跳過 5 Whys——表層問題會導致表層解法
+- 別從單次工作階段得結論——等 3+ 資料點
 
 ---
 
-## 相關規範
+## 相關標準
 
-| 規範 | 關係 |
+| 標準 | 關係 |
 |------|------|
-| [需求工程](../../../../core/requirement-engineering.md) | 腦力激盪輸出供需求撰寫使用 |
-| [規格驅動開發](../../../../core/spec-driven-development.md) | 腦力激盪輸出供 SDD 提案使用 |
-| [專案現況評估](../project-discovery/SKILL.md) | Discovery 為腦力激盪提供脈絡 |
+| [Requirement Engineering](../../core/requirement-engineering.md) | 腦力激盪輸出餵入需求撰寫 |
+| [Spec-Driven Development](../../core/spec-driven-development.md) | 腦力激盪輸出餵入 SDD 提案 |
+| [Project Discovery](../project-discovery/SKILL.md) | Discovery 為腦力激盪提供脈絡 |
 
 ---
 
@@ -488,7 +880,9 @@ HMW 問題：
 
 | 版本 | 日期 | 變更 |
 |------|------|------|
-| 1.0.0 | 2026-02-12 | 初始發布 |
+| 2.1.0 | 2026-05-09 | XSPEC-196 Phase 2：模式選擇客觀路由表；自我評估框架（3 指標 + 工作階段記錄範本 + 趨勢判讀）；A/B 實驗協議；研究效度說明（3 假設搭配外部效度風險評等）；漸進採用協議（3 階段、6 週計畫） |
+| 2.0.0 | 2026-05-09 | XSPEC-196：Phase 0 Pre-flight（反錨定）、反駁輪（Nemeth 協議）、10 個想法最低門檻 + 語義批次化；新增研究依據章節 |
+| 1.0.0 | 2026-02-12 | 初始版本 |
 
 ---
 
@@ -496,4 +890,4 @@ HMW 問題：
 
 本文件以 [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) 授權釋出。
 
-**來源**: [universal-dev-standards](https://github.com/AsiaOstrich/universal-dev-standards)
+**來源**：[universal-dev-standards](https://github.com/AsiaOstrich/universal-dev-standards)