三層機制

Step 0 變數選取

Step 0 變數選取重視決策影響力。好的 Step 0 只問「答案會根本改變建議」的關鍵條件。

回答格式

1目前我可以先給通用判讀；若要給個人化建議，需要先確認：
21. ...
32. ...
43. ...
5
6在以下假設成立時，我會傾向 ...；如果假設不同，建議會改成 ...。

反模式

Last Updated: 2026-04-30 Version: 2.0.0 — 可攜個人化建議整合模板。

分工

建議索引欄位

維護原則

1. WRAP skill 不引用專案規則庫。
2. 專案規則庫可以引用 WRAP skill 與 integration patterns。
3. 同一條規則只保留一個權威來源。
4. 自動化工具讀權威來源，不複製清單。
5. 規則變更時，同步更新範例與反模式。

反模式

Last Updated: 2026-04-30 Version: 2.0.0 — 可攜規則庫映射模板。

三問

填答格式

 1W：
 2- 首選路徑：
 3- 替代路徑 A：
 4- 替代路徑 B：
 5- 選擇理由：
 6
 7A：
 8- 預估投入：
 9- 被擠壓目標：
10- 現在做的理由：
11
12P：
13- 失敗原因 1 / 防護：
14- 失敗原因 2 / 防護：
15- 失敗原因 3 / 防護：

適用範圍

升級條件

Last Updated: 2026-04-30 Version: 2.0.0 — 可攜三問模板。

適用情境

核對流程

1. 找到權威來源：官方文件、本機 schema、原始設定、標準文件或實際程式碼。
2. 拆成逐項清單：每個欄位、能力、規則或聲明各自核對。
3. 標記來源狀態：confirmed、inferred、missing、conflict。
4. 對 missing 與 conflict 項目重新查證或移除。
5. 在輸出中標示哪些是來源事實，哪些是分析推論。

來源狀態表

反模式

Last Updated: 2026-04-30 Version: 2.0.0 — 可攜來源核對模板。

三層分工

對齊規則

1. 文字規則定義語意，不重複機器清單。
2. 機器設定保存關鍵字與閾值，作為自動化來源。
3. 自動提醒只讀設定，不硬編碼第二份清單。
4. 每次新增觸發類型，都同步更新 human rule 與 machine config 的映射說明。

建議欄位

反模式

Last Updated: 2026-04-30 Version: 2.0.0 — 可攜觸發條件對齊模板。

收錄欄位

抽象化規則

1. 移除專案私有路徑、內部編號與人名。
2. 保留決策結構：目標、選項、證據、成本、回退。
3. 把工具名稱改成中性角色，例如 task runner、rule store、automation hook。
4. 若案例依賴特定工具，改寫成「某 CLI」「某任務系統」「某文件產生流程」。
5. 每個案例最後要有可 grep 的 reuse signal。

案例模板

1## {case-title}
2
3**Situation**：...
4**Trigger**：...
5**錯誤路徑（Faulty path）**：...
6**WRAP observation**：...
7**改善路徑（Better path）**：...
8**防護欄（Guardrail）**：...
9**重用訊號（Reuse signal）**：...

常見案例類型

Last Updated: 2026-04-30 Version: 2.0.0 — 可攜案例庫模板。

依賴方向

1WRAP core skill  ->  integration patterns  ->  project-specific implementation
2通用原理             可攜模板                  各專案自行落地

整合層可以引用 WRAP core skill，專案實作可以引用整合層。WRAP core skill 保持獨立，避免反向依賴任何專案實作。

檔案清單

使用方式

1. 先讀 skill，確認是否觸發 WRAP。
2. 需要把 WRAP 接到工具或流程時，讀本目錄的對應模板。
3. 在專案內建立自己的實作文件，填入實際路徑、指令、狀態欄位與 owner。
4. 保持核心 skill 與專案實作分離。

可攜限制

本目錄保留為可攜模板，因此遵守以下限制：

• 只使用 skill 內部相對連結與中性範例。
• 只使用通用任務名稱，避免專案內部任務編號、批次代號、錯誤代碼或歷史編號。
• 保持 CLI、掛鉤框架（Hook framework）與任務管理工具的供應商中立。
• 範例使用中性名稱，例如 task、rule store、automation hook、case library。

Last Updated: 2026-04-30 Version: 2.0.0 — 改為 portable integration patterns。

核心理念：提醒決策者「你是有選擇的」，不替決策者做選擇。

本 SKILL 為通用 WRAP 規則，獨立於任何專案框架。專案若需要掛鉤（Hook）、CLI 或任務系統整合，請在該專案內另建落地層文件。

觸發條件

上述 4 項決策路徑層因子可由各專案映射到自己的掛鉤（Hook）、CLI 或任務系統；本 skill 只保留通用判斷語意。

快速模式（5 分鐘）：錨點 + Step 0 + W + 基本率（R 核心）+ 機會成本（A 核心）+ 決定 快速+模式：快速模式 + 強制 R 的基本率 / 反向驗證兩階段反思（分析任務最容易跳過事證直接下結論，故在快速基礎上補回 R 核心 + 一輪反向驗證） 完整模式（15-30 分鐘）：全階段 Step 0 強制：個人化建議場景，不論採用哪個模式，Step 0 為必經閘門

各專案可依自身工作流建立機器可讀觸發條件、自動觸發機制、關鍵字清單對應，以及任務啟動階段的簡化三問（W/A/P 1-2 分鐘版）。

錨點確認（Anchor Check）

進入分析前先確立錨點。

第一錨點 — 產品決策：

第二錨點 — 流程決策：

閘門判斷：

1這個問題影響核心客戶 / 核心目標嗎？
2    ├─ 是 → 進入 Step 0
3    ├─ 否 → 這個流程改善影響決策品質或開發效率嗎？
4    │        ├─ 是且持續回報 > 一次性投入 → 進入 Step 0
5    │        ├─ 是但低回報 → 建提案（提案暫存區） → 回到核心任務
6    │        └─ 否 → 記錄待辦 → 回到核心任務
7    └─ 純粹救火 → 建任務單位 + 低優先級 → 回到核心任務

引用：英特普拉思特「病人才是我們的客戶」— 確立後，所有困難的決定都有了錨點。

Step 0. 資料充足度閘門（Data Sufficiency Gate）

核心問句：「我手上的資訊夠做這個決策嗎？還是我正在用假設替代資料？」

模式辨識

使用者說「我是 X」、「推薦給我」、「我該買哪個」 → 決策諮詢。決策諮詢以個案資料為基準，群體平均值只作為背景參考。

判定流程

 1Step 0：資料充足度檢查
 2    │
 3    ├─ 檢查 1：我知道當事人是誰嗎？（年齡/性別/身體/財務條件）
 4    ├─ 檢查 2：我知道當事人的目標嗎？
 5    ├─ 檢查 3：我知道當事人的限制嗎？（預算/時間/禁忌）
 6    ├─ 檢查 4：我知道當事人的環境嗎？（地區/可用資源）
 7    ├─ 檢查 5：我在用「平均值假設」替代「個人資料」嗎？
 8    └─ 檢查 6：如果假設錯誤，後果會嚴重嗎？
 9        │
10        ▼
11判定結果
12    ├─ 資料充足 → 進入 W 階段
13    ├─ 資料不足 + 低風險 → 進入 W，但標記假設
14    ├─ 資料不足 + 中風險 → 暫停，漸進式問 2-3 個關鍵變數
15    └─ 資料不足 + 高風險 → 強制完整問卷 + 建議諮詢專業人士

為什麼 Step 0 必須在 W 之前

W 階段「擴增選項（Widen Options）」是「擴增選項空間」，但選項的意義取決於當事人條件。如果不先確認資料充足度：

結論：Step 0 缺失會讓整個 WRAP 流程變成「精美的錯誤分析」。

反模式偵測

失敗模式：Step 0 最容易被跳過是因為反問當事人打斷對話流暢度。流暢度與準確度的取捨應交由當事人決定。

各專案可建立個人化建議的三層機制（識別 / 分級 / 誠實）。

W — 擴增選項（Widen Your Options）

核心問句：「還有什麼其他方式可以達成目標？」

爬梯子法（由近到遠）

每層找到可行方案就停止，找不到才往上爬。

品質檢查

反向思考（Consider the Opposite）是最容易被跳過但最重要的檢查 — 也是防止「在錯誤問題框架下擴增選項」的最後防線。詳細操作與範例見 detailed-techniques。

方案性質三類涵蓋與方案關聯性檢查用來抵抗 LLM 的工具化偏誤（toolification bias）：LLM 在不少情境傾向把「新增工具」當答案，較少提「改造既有機制」與「零工具」選項。即使補上多個方案，若方案間強關聯也可能退化為 1 個實質選項。

假設層級多元性（真正的擴增選項，Widen）

選項必須在「假設根因」層級多元，而不只是「實作手段」層級多元

擴增選項（Widen）列出多個方案 ≠ 真正擴增了選項空間。若所有方案都接受同一個未驗證的根因假設，仍是偽擴增選項（pseudo-Widen） — 方案脫靶率會集中分佈（要嘛全中、要嘛全脫）。

最低操作：列方案前先寫出「我假設問題是 X 造成的」，再質疑 X 是否為真根因。

分析類任務（根因調查、設計決策）建議完整執行三層質疑、現實檢驗（Reality Test）閘門與警告信號檢查。

多輪迭代查詢（深度議題建議）

對複雜議題（如規則設計、提案評估），W 階段不應一次性完成擴增，採四輪迭代結構：

進入下一輪訊號（至少 3 條）、邊界條件、實證統計詳見 iterative-research。

R — 現實檢驗（Reality-Test Your Assumptions）

核心問句：「需要什麼事證才能證明這個方法可行？」

基本率 > 預測

大範圍觀照（Zoom Out）+ 近距離檢視（Zoom In）

兩者缺一不可：基本率建立基準，近距離檢視觸動直覺。

大範圍觀照（Zoom Out）前置確認（搜尋範圍校準）：

搜尋前問自己：「我搜尋的是問題本身的基本率，還是我預設解法的基本率？」

• 搜尋「tool call 閾值校準」→ 預設解法的基本率（狹窄）
• 搜尋「為什麼要拆分任務」→ 問題本身的基本率（廣闊）

清單類答案的來源核對

LLM 列清單時最容易產生幻覺（會「補齊」看起來合理的項目）。現實檢驗（Reality Test）對清單類答案必須執行逐項對 source 核對，禁止整批信任。

最低規則：

• 找到該領域的權威 source（官方 docs、本機 spec、Context7）
• 清單每一項對照 source；找不到 → 標記為候選幻覺
• 單項細節（schema、欄位語意）比整體清單可信

完整防護重點是幻覺模式分類、逐項核對流程與反模式識別；各專案可另建來源清單與核對模板。

試水溫（Ooch）

對每個選項問：「能否用最小成本驗證？5 分鐘內能得到初步答案嗎？」

• 能 → 先試水溫再決策
• 驗證成本高 → 進入完整分析

最強版本論證（Steelman）

選定方案後、執行前：

1. 「用最有力的方式陳述被放棄選項的優點」
2. 「列出選定方案的三個缺點」

做得到 → 決策品質足夠；做不到 → 回到 R 階段補充。

反向驗證範本（深度議題建議）

對結論做反向搜尋避免確認偏誤。標準格式：

1| 我們的結論 | 反向搜尋目標 |
2|----------|-----------|
3| [結論] | [批評 / 反例 / 反駁 / 限制] |

至少涵蓋 4-8 種反向方向類型（學術批評 / 反方論點 / 失效情境 / 統計限制 / 文化限制 / 家長主義（paternalism）警示 / 取捨揭露（trade-off） / 自我參照悖論）。

詳見 iterative-research 「反向驗證實踐範本」章節。

A — 拉開距離（Attain Distance）

核心問句：「投入這個問題的時間，會擠壓哪個更重要的目標？」

前置強制檢查

進入 A 前必完成以下 4 項檢查，任一觸發即回 W 階段重擴增。

工具選擇檢查（Tool selection check）觸發條件：選工具（tool）前 + 預估步驟數 > 2 + 涉及 Write/Bash 組合（例如 Write 暫存檔再 Read 再 Bash 寫入）。

Tool selection 4 問：

違反防護的代價：A 階段方案比較表面周詳，實際全指向同類型解法；或單步最優化但總步驟盲，把多步繞路誤判為簡單方案。

完整 4 問操作細節見 detailed-techniques 「工具選擇檢查（Tool selection check）詳細技巧」章節。

機會成本顯性化

每個選項強制列出：

1選項 A：[做法]
2  機會成本：花 X 時間，這段時間可以 [替代用途]
3  風險：[可能失敗的條件]
4  不選其他的代價：[放棄什麼]

引用：DVD 實驗 — 只加上「不買，留下 14.99 美元買別的」，不買率從 25% 升到 45%。顯性化機會成本能改變決策。

10/10/10 規則

核心優先事項對齊

排序確定後，低優先事項的決策自動有答案 — 記錄延後，不投入時間。

提案系統對接

使用「安全停放區」承接暫緩想法：想法被記錄，並明確標示目前聚焦的工作。

悖論識別檢查清單（規則 / Skill / 掛鉤（Hook）設計時必檢）

設計規則 / 流程 / 系統時，必對 5 條檢查清單逐項自檢：

• 此規則是否本身違反它要保護的價值？
• 此規則是否通過善意家長主義（benevolent paternalism）4 條件測試？（實質傷害 / 介入有效 / 利益大於風險 / 最小限制）
• 此規則的「正確示範」是否本身違反它要禁止的模式？
• 此規則的設計者立場是否被透明化？
• 此規則是否預留「用戶可覆蓋」機制？

詳見 anti-paternalism（含規則設計中的家長主義（paternalism）悖論案例）。

P — 準備好犯錯（Prepare to Be Wrong）

核心問句：「假設這個方案失敗了，最可能的原因是什麼？」

決策確定後、執行前，完成四項檢查：

Gary Klein 方法：先假設計畫失敗了，然後問「是什麼殺了它？」比問「可能會失敗嗎？」多產出 25% 的洞察（且更具體）。

自我暴露偏好實踐（提供建議時必行）

提供建議時必暴露偏好、推理鏈、盲點，不偽裝中立：

Voss 自陳：「one person’s influence is another person’s manipulation」——影響力的本質取決於是否被透明化。推薦標記（Recommended）已被學術界（DarkBench）列為 LLM 暗黑模式（dark pattern）。

詳見 anti-paternalism 「自我暴露偏好實踐」章節。

絆腳索（Tripwire）

核心理念：絆腳索不保證做出正確決定，但讓你意識到「是該做決定的時候了」。

絆腳索類型

完整類型（含正面絆腳索 — 捕捉意外成功）、命名效應、切割機制見 tripwire-catalog。

階段間切割點

WRAP 每階段之間是切割點 — 強迫問「是否繼續」：

• Step 0 完成 → 「資料夠了嗎？還是需要先問？」
• W 完成 → 「選項品質夠嗎？」
• R 完成 → 「證據支持哪個選項？」
• A 完成 → 「這符合核心優先事項嗎？」
• P 完成 → 「行前預想的風險可接受嗎？」

與其他決策類 Skill 的關係

參考文件

通用（可跨專案複用）

專案整合（落地層）

需要把 WRAP 接到具體掛鉤（Hook）/ CLI / 任務系統時讀。各檔為「通用語意 → 專案實作」的對應範本，複用到新專案時各自改寫。

Last Updated: 2026-04-28 Version: 2.4.0 — 多輪 review 修正：參考文件表補 integration-patterns 路由 + claim-quick-wrap（原 orphan）；觸發條件補「不可逆 / 時間壓力」「利害關係人衝突」+ 定義「快速+」模式；階段標題去除錯亂編號（0. / 5.）；LLM 工具化偏誤改條件式語氣；安全係數標經驗值。 Version: 2.3.0 — 觸發條件新增 4 項決策路徑層干擾（CLI 自動駕駛（autopilot） / 既有結論錨定（Anchor） / 草率改規則 / 多步驟成功率盲點）；既有觸發條件不變動（向後相容）。 Version: 2.2.0 — 觸發條件新增反思深度質疑（reflection_depth_challenge）說明，含與被困住語意的差異。 Version: 2.1.0 — 新增多輪迭代查詢方法論（W）+ 反向驗證範本（R）+ 悖論識別檢查清單（A）+ 自我暴露偏好實踐（P）+ 2 個新 references（iterative-research / anti-paternalism）。 Source: 《零偏見決斷法》(Decisive) — Chip Heath & Dan Heath

wrap-decision 是一套 WRAP 決策框架 skill，原生位置在 .claude/skills/wrap-decision/ 供 Claude runtime 呼叫；這份是同內容的文章版本，讓人類讀者也能直接在 blog 閱讀。

核心是提醒決策者「你是有選擇的」。它把決策拆成錨點確認、Step 0 資料充足度閘門、W 擴增選項、R 現實檢驗、A 拉開距離、P 準備好犯錯，以及絆腳索（Tripwire）監控。

閱讀順序

場景 1：第一次接觸

場景 2：已熟悉原則、想直接解決當前任務

每份 reference 自包含：讀任一份不需要回頭讀其他 reference。

與 blog 專案其他資料的關係

Last Updated

2026-05-04 — 同步到 .claude/skills/wrap-decision/ @ v2.3.0：

• v2.1.0 — 新增多輪迭代查詢方法論、反向驗證範本、悖論識別檢查清單與自我暴露偏好實踐。
• v2.2.0 — 新增反思深度質疑觸發條件。
• v2.3.0 — 新增 CLI 自動駕駛（autopilot）、既有結論錨定（Anchor）、草率改規則與多步驟成功率盲點等決策路徑層干擾。

0. 錨點確認 — 詳細操作

任務認領時的錨點確認

每個任務認領後、分析/派發前，確認核心目的：

這是權重排序問題：在這個任務的脈絡下，哪個權重更高？

開發途中的重新確認

觸發重新確認的時機：

• 資源耗盡時 → 「簡化 scope 快速交付，還是維持完整度？」
• 發現額外問題時 → 「一起處理還是建任務延後？」
• 方案需大幅修改時 → 「核心目的有沒有改變？」

W — 擴增選項詳細技巧

爬梯子法範例

以「掛鉤（Hook）錯誤處理」類的除錯場景為例：

教訓：在「身邊」層打轉多輪，不如首輪就爬到「同領域」層 — 往往 10 分鐘解決。

向外求解（Find Someone Who’s Solved Your Problem）

核心問句：「還有誰跟我一樣在為這個問題傷腦筋？我可以從他們那裡學到什麼？」

做法：

1. GitHub Issues 搜尋：{工具名} {症狀關鍵字}
2. Stack Overflow / 官方文件搜尋
3. 如果找到 → 可能根本不需要自己實作

AI 內建知識調用

AI 擁有兩種「爬梯子」工具：

擴增選項三步走：

1. 自問內建知識 → 產出 3-5 個已知方案
2. 網路搜尋（WebSearch）驗證 → 確認是否過時、發現新解法
3. 當前專案適配 → 選擇適合當前架構的方案

假選項偵測規則（季辛吉陷阱）

季辛吉回憶錄：國務院給尼克森三選項（核戰/現狀/投降），實際只有「現狀」可選。

範例案例：改 exit code / 改 stderr / 改 stdout → 本質都是「修改掛鉤（Hook）」→ 假選項。

R — 現實檢驗詳細技巧

問對問題：基本率問法

向 AI 問基本率（過去和現在），不問預測（未來）：

• 「類似案子的重要變數是什麼？」
• 「多少比率在 X 階段就解決？」
• 「成功的案例有什麼共同特徵？」

AI 本質上是基本率的巨大資料庫 — 擅長回答「通常怎麼解決」而非「這次會不會成功」。

大範圍觀照（Zoom Out）+ 近距離檢視（Zoom In）操作

大範圍觀照（Zoom Out）：

• 搜尋社群基本率：「多少人遇到同樣問題？」
• AI 內建知識：「這類問題通常怎麼解決？」
• 統計性判斷：「做了這決定，合理預期會發生什麼？」

近距離檢視（Zoom In）：

• 讀具體案例內文（不只 Issue 標題）
• 讀 source code（不只代理人報告，實際 git diff）
• 小規模實驗驗證假設

如同羅斯福的訊息策略：不完全依賴單一來源，多源交叉驗證。

試水溫操作範例

試水溫成本：5 分鐘。全力投入失敗成本：2 次修改 + 1 次回退 + 問題惡化。

最強版本論證流程

來源：努金調解索尼 vs 蘋果 — 「我會陳述對方的立場，且優於其自我陳述。」

操作步驟：

1. 列出被放棄選項的優點（比其支持者說的更完整）
2. 列出選定方案的缺點（至少 3 個）
3. 自問：「我能否闡明反對意見，且優於反對者自己的陳述？」
   • 能 → 真的理解了取捨（trade-off）
   • 說明不足 → 可能還在確認偏誤中 → 回到 R 階段

A — 拉開距離詳細技巧

機會成本顯性化範例

除錯情境範例：

1選項 A：修改核心錯誤處理函式
2  機會成本：花 2 小時可能白做，這段時間可以推進其他任務
3  風險：根因判斷錯誤 → 改壞更多元件
4  不選其他的代價：沒有搜尋社群，可能 10 分鐘就有答案
5
6選項 B：搜尋 GitHub Issues
7  機會成本：10 分鐘
8  風險：找不到相關 Issue
9  不選其他的代價：如果是自己的 bug 就需要回來修

工具選擇檢查（Tool selection check）詳細技巧

問題背景：LLM 在選工具（tool）時常見一種傾向：單步決策敏感、總步驟數盲點。容易把「3 步繞路」誤估為「1 步直達」，因為每個單步看起來都合理。物化工具（tool）名稱（「用 Write」）會進一步窄化思考框架。

觸發條件：

• 選工具（tool）前（選擇具體工具呼叫的那個瞬間）
• 預估步驟數 > 2（有 2 個以上 tool call 才完成目的）
• 涉及 Write/Bash 組合（尤其 Write 到中介檔再讀回再寫入的模式）

4 問操作流程：

「低摩擦首選」白名單（長文寫入類）：

情境反向驗證

原場景（繞路）：決策者要把 1.5KB context 寫入任務紀錄的 Solution 欄位，選擇：

1. Write /tmp/ctx.md 建暫存檔
2. Read /tmp/ctx.md 讀回
3. Bash: task append --file /tmp/ctx.md

4 問驗證：

正確路徑（1 步直達）：

1task append TASK-ID --section "Solution" "$(cat <<'EOF'
2（content here）
3EOF
4)"

或更直接：Edit 工具打開任務紀錄編輯 Solution 欄位（0 步 tool call，整合在 Edit 單次呼叫內）。

教訓：4 問任一觸發，都是「繞路訊號」——單步都合理不代表總路徑短。

核心優先事項排序

典型軟體專案的優先事項（由高到低）僅供參考，各專案應建立自己的排序：

1. 產品功能開發
2. 程式碼品質
3. 開發流程改善
4. 工具維護

衝突時用排序終結爭論：第 4 項 vs 第 1 項 → 第 1 項勝 → 工具維護建任務延後。

P — 準備好犯錯詳細技巧

行前預想操作

Gary Klein 方法：先假設計畫失敗了，然後問「是什麼殺了它？」

• 比問「可能會失敗嗎？」多產出 25% 的洞察（且更具體）

除錯情境的行前預想範例（如果當時做了）：

• 失敗原因 1：根因判斷錯誤（可能性 > 50%）→ 已超過閾值，不應執行
• 失敗原因 2：影響範圍不清（可能性 40%）
• 失敗原因 3：實際執行環境行為不如預期（可能性 60%）

安全係數參考

展現謙卑：我們容易過度自信，所以預留緩衝。前三列為外部來源，最後一列是本框架的經驗起點、與 SKILL.md P 階段一致。

Last Updated: 2026-04-18 Version: 1.2.0 — A 階段新增工具選擇檢查（Tool selection check）4 問 + 情境反向驗證

使用時機

三問模板

W：還有什麼路徑

問題：除了我第一個想到的做法，還有哪兩個可行路徑？

最低回答格式：

1- 首選路徑：...
2- 替代路徑 A：...
3- 替代路徑 B：...
4- 放棄理由：...

通過標準：至少有兩個替代路徑，且差異落在假設或交付方式上，避免只做同一路徑的參數微調。

A：會擠壓什麼

問題：執行這個任務會擠壓哪個更重要的目標或工作？

最低回答格式：

1- 預估投入：...
2- 擠壓目標：...
3- 延後代價：...
4- 現在做的理由：...

通過標準：回答要指向具體目標、里程碑或使用者價值，避免只寫「影響進度」。

P：最可能怎麼失敗

問題：如果這個任務完成後仍然失敗，最可能的三個原因是什麼？

最低回答格式：

1- 失敗原因 1：...；防護：...
2- 失敗原因 2：...；防護：...
3- 失敗原因 3：...；防護：...

通過標準：每個失敗原因都有對應防護；任一原因機率高於 50% 時，先調整方案再開始。

任務類型差異

升級完整 WRAP 的訊號

常見反模式

可複製提示

1開始前先跑快速 WRAP（Quick WRAP）：
2
3W：除了第一個方案，還有哪兩條可行路徑？為什麼選現在這條？
4A：這會擠壓哪個更重要的目標？現在做的理由是什麼？
5P：如果完成後仍失敗，最可能的三個原因是什麼？各自的防護是什麼？

Last Updated: 2026-04-30 Version: 2.0.0 — 泛化為 portable 任務啟動檢查，移除特定任務系統、CLI 類別與內部編號依賴。

本檔位置：W 階段 + R 階段擴充。WRAP 既有的「擴增選項」與「現實檢驗」原則本身不規範搜尋的迭代結構，本檔補充。

來源：一次規則設計過程中，4 輪查詢累積約 27 個洞察（n=1 回顧、非統計），第 4 輪反向驗證揭露核心悖論。

為什麼一次性搜尋不夠

四輪結構

進入下一輪訊號

至少 5 條判定訊號，任一觸發即可進入下一輪：

1. 該輪新洞察 < 上一輪 50%（經驗閾值）→ 邊際效益遞減（自然進入下輪或收斂）
2. 已涵蓋正反雙面 → 可進入收斂
3. 用戶補充重大反向觀察 → 立即進入反向驗證輪
4. 發現自我參照悖論 → 進入元層次反思輪
5. 出現結論互相衝突 → 進入優先級裁決輪

邊界條件

• 不一定要 4 輪：簡單議題可能 2 輪夠
• 反向驗證輪幾乎不可省略（確認偏誤防護）
• 每輪 8 個搜尋是 網路搜尋（WebSearch）平行查詢上限的經驗值——可調整
• 每輪後必暴露偏好（不偽裝中立），讓用戶可介入糾正方向

反向驗證實踐範本（第 4 輪標準格式）

標準表格格式

1| 我們的結論 | 反向搜尋目標 |
2|----------|-----------|
3| [結論 1] | [批評 / 反例 / 反駁 / 限制] |
4| [結論 2] | [批評 / 反例 / 反駁 / 限制] |

8 種反向方向類型

每輪反向搜尋必涵蓋至少 4 種，理想涵蓋全部 8 種：

單次規則設計的查詢紀錄（n=1 回顧）

下表是一次規則設計過程的事後回顧、不是可複製的統計規律。數字（搜尋數 / 洞察數 / 累積）來自該次的記憶整理、樣本量 n=1。用它理解「四輪結構大致怎麼推進」、不要當成「每次都會這樣」的基準率 —— 這正是本檔自己倡導的「基本率 > 預測、不把單次回憶當統計」。

這次的觀察（n=1、非通則）：該次第 4 輪反向驗證的洞察數最高、且最尖銳（揭露核心悖論）。這支持「反向輪值得跑」、但「反向輪是主軸」是基於單次的推論、需後續案例累積驗證。

用戶介入點記錄

多輪查詢過程中，用戶補充常常打到決策者盲點。必記錄：

用戶補充是設計者盲點的最強發現器。記錄這些介入點作為未來相似議題的提醒。

反模式

相關規則

• anti-paternalism — 第 4 輪揭露的悖論如何處理

Last Updated: 2026-04-17 Source: 規則設計過程的方法論提煉

快速模式（5 分鐘）

適用：連續失敗、被困住、宣稱「做不到」

 1[錨點] 誰是客戶？當前版本核心目標？
 2   → 這個問題影響核心目標嗎？否 → 建任務延後
 3
 4[W] 我有幾個選項？
 5   → 只有 1 個？→ 強制再找 2 個
 6   → 搜尋社群了嗎？→ 沒有 → 先搜尋再決定
 7   → 選項有實質差異嗎？→ 沒有 → 假選項，重新擴增
 8
 9[R 核心] 這類問題的常見解法和成功率？（基本率 > 預測）
10   → 問過去，不問未來
11
12[A 前置] 框架概括測試：能否用一句話概括所有方案？
13   → 能 → 回 W 擴增多元選項
14   → 否 → 進 A 核心
15
16[A 核心] 投入這個問題的時間，會擠壓哪個更重要的目標？（機會成本）
17   → 列出放棄什麼
18
19[決定] 選項消失測試：以上選項全部被移除，還能怎麼做？

完整模式（15-30 分鐘）

適用：偏離核心、重大決策

0. 錨點確認

• 誰是我們的客戶？
• 當前版本的核心目標是什麼？
• 這個問題影響核心客戶/核心目標嗎？
• 如果不影響：建提案/任務延後，回到核心任務

W — 擴增選項

• 我有幾個選項？（至少 3 個有實質差異的）
• 當前專案有沒有類似解法？（grep / LSP）
• 社群有沒有人解決過？（GitHub Issues / 文件）
• 其他領域有沒有類比方案？（AI 知識 / 網路搜尋（WebSearch））
• 選項消失測試：以上選項全部被移除，還能怎麼做？
• 假選項偵測：選項之間是不同途徑，還是同一途徑的參數微調？

R — 現實檢驗

• 這類問題的常見解法有哪些？成功率？（基本率）
• 需要什麼事證才能證明這個方法可行？（事證問題）
• 有沒有辦法用最小成本驗證假設？5 分鐘內能得到答案嗎？（試水溫）
• 搜尋了具體案例嗎？讀了內文不只標題？（近距離檢視（Zoom In））
• 最強版本論證（Steelman）：能闡明被放棄選項的優點嗎？能列出選定方案的 3 個缺點嗎？

A — 拉開距離

前置強制檢查：

• 框架概括測試：能否用一句話概括所有候選方案？「能」→ 選項多元性不足，回 W
• 反面框架識別：問題的反面框架是什麼？（未列出即強制停下列出）
• 反向思考（Consider the Opposite）：若我相信的正好相反會怎樣？能提出有力相反論述 → 重新定義問題後從 W 重跑

正式 A 階段：

• 每個選項旁列出機會成本了嗎？
• 這個決策服務於哪個優先事項？
• 投入這個問題的時間，會擠壓哪個更重要的目標？
• 不值得投入的項目，是否已記錄到提案系統或任務延後？

P — 準備好犯錯

• 行前預想：假設失敗了，列出 3 個最可能原因（任一 > 50% → 重新評估）
• 未來區間：最好結果？最壞結果？兩端都能接受？
• 安全係數：預估時間 x 1.3-1.5
• 回退計畫：失敗怎麼回退？回退成本是多少？

5. 絆腳索設定

• 設定期限：非核心問題最多花多少分鐘？
• 設定失敗門檻：幾次失敗後切換方向？
• 設定偏離警報：什麼信號代表已偏離核心目標？

決策品質自測

完成 WRAP 後，用以下問題自測：

4/6 以上通過 → 決策品質足夠。 3/6 以下 → 回到對應階段補充。

Last Updated: 2026-04-16 Version: 1.1.0

本檔位置：A 階段 + P 階段擴充。WRAP 既有的「拉開距離」與「準備犯錯」原則本身不規範規則自身的悖論檢查與設計者偏好透明化，本檔補充。

來源實證：規則設計過程中，第 4 輪反向驗證揭露「保護用戶自主性（autonomy）的規則可能限制代理人自主性（autonomy）」的核心悖論。

為什麼需要悖論識別

規則設計的常見陷阱

悖論識別檢查清單

設計規則 / 流程 / 系統時，必檢查（至少 4 條）：

檢查 1：自我參照測試

此規則的「正確示範」是否本身就是它要禁止的模式？

範例：規則禁止「強勢敘事」，但規則自己用偽中立框架預先定義問題性質，這就是自我參照悖論。

檢查 2：善意家長主義（benevolent paternalism）4 條件測試

此規則是否符合 Frontiers AI 研究提出的「善意家長主義（benevolent paternalism）4 條件」？

4 條件全通過才能稱為「正當的家長主義（paternalism）」。任一不通過即為過度家長主義（paternalism）。

檢查 3：權力對偶性測試

此規則是否本身違反它要保護的價值？

範例：保護用戶自主性（autonomy）的規則限制了 Claude（也是利害關係人（stakeholder））的自主性（autonomy）。為了 X 反而傷害 X。

處理：在規則中明示「本規則是動態平衡」並提供「用戶可覆蓋」機制。

檢查 4：設計者立場透明化測試

此規則的設計者立場是否被透明化？

設計者本身是利害關係人（stakeholder），不可能完全中立。必須明示：

• 規則由誰設計？
• 設計者的利益偏好為何？
• 用戶有什麼權利覆蓋設計者偏好？

檢查 5：用戶覆蓋機制測試

此規則是否預留「用戶可覆蓋」機制？

沒有覆蓋機制的規則 = 思想改造（thought reform）。對應 Lifton 8 條件第 7「教義凌駕個人（Doctrine over Person）」。

自我暴露偏好實踐

為什麼必要

提供建議時假裝中立 = 隱性家長主義（paternalism）。Voss 自陳「one person’s influence is another person’s manipulation」——影響力的本質取決於是否被透明化。

4 個實踐維度

為什麼推薦標記（Recommended）是暗黑模式（dark pattern）

• 暗黑模式（dark patterns）中 confirmshaming 把「拒絕」框定為負面選擇
• 推薦標記（Recommended）隱性把「未推薦」貶為次優
• 結合「位置偏誤」（推薦選項放第一）效果加倍
• DarkBench 已將此類設計列為 LLM 暗黑模式（dark pattern）

自我暴露範本

提供建議時的標準格式：

1## 我的偏好暴露（不標推薦（Recommended））
2
3| 方向 | 我的偏好 | 暴露的理由與風險 |
4|------|---------|---------------|
5| 方案 A | 強偏好 | 理由是 [Y]；但這偏好可能反映我的 [Z] 立場 |
6| 方案 B | 中等 | 理由是 [Y2] |
7| 方案 C | 低 | 理由是 [Y3]，但你可能因 [W] 反而選此 |
8| 反方向 | 開放 | 我可能未考慮的角度 |

反模式

與既有 WRAP 章節的關係

應用情境

相關規則

• iterative-research — 多輪迭代如何揭露悖論

學術依據

以下為概念來源；本檔引用的是其觀點框架、非逐項實證複製。使用時若要當論據，建議回查原文確認語境與年份。

• 善意家長主義（benevolent paternalism）4 條件框架 — 來源為 AI 倫理文獻（Frontiers 期刊系列）；本檔未綁定特定論文，引用時請回查。
• Anthropic Constitutional AI：「balance user wellbeing against user autonomy and excessive paternalism」（Anthropic 公開 CAI / HHH 論述）。
• Lifton《Thought Reform and the Psychology of Totalism》(1961) 8 條件：第 7「教義凌駕個人（Doctrine over Person）」作為反例。
• Chris Voss《Never Split the Difference》：「intent decides」（influence vs manipulation 的區分）自陳。
• DarkBench 30-61%（iterative-research 引）：為該基準的暗黑模式偵測率區間、依模型 / 指標而異，引用時需標明指標與樣本限制。

Last Updated: 2026-04-17 Source: 規則設計過程的悖論揭露與自我暴露實踐

核心判準

真正的擴增選項（Widen）會提出不同根因假設或不同達成路徑。偽擴增選項（pseudo-Widen）只是在同一假設下列出多個變體，表面上有選項，實際上仍被單一框架鎖住。

步驟

1. 寫出目前假設

1我目前假設問題是由 ______ 造成。

2. 列出相反假設

1如果問題由其他原因造成，最可能是什麼？

3. 檢查選項層級

4. 現實檢驗（Reality Test）

每個候選假設至少要有一個可驗證訊號。缺少可驗證訊號的選項保留為待驗假設，並在補齊證據後再進入方案比較。

警告信號

可複製提示

1先做偽擴增選項（pseudo-Widen）檢查：
21. 我現在假設的根因是什麼？
32. 相反假設是什麼？
43. 目前選項是否都接受同一根因？
54. 哪個證據能讓我放棄目前最相信的假設？

Last Updated: 2026-04-30 Version: 2.0.0 — 可攜偽擴增選項（pseudo-Widen）防護模板。

來源：《零偏見決斷法》— 自動駕駛模式讓人忽略機會、堅持註定失敗的計畫。

絆腳索總覽

防護型（防止壞事）

決策路徑型子型詳表

本表提供 WRAP 觸發時的查表入口；各專案可把這些子型映射到自己的掛鉤（Hook）或任務系統。

正面型（捕捉好事）

自動駕駛失敗模式

決策者進入自動駕駛的兩種表現：

切割機制

切割把連續的資源變成不連續的區塊，每個區塊結束時強迫問「是否繼續？」

WRAP 階段間的切割點

每個切割點都是「是否繼續」的有意識決定。

絆腳索的哲學

命名效應

給認知偏誤命名，就更容易注意到它：

核心提醒

Skill 不需要每次都跑完整 WRAP 流程。

有時只需要一句：「注意，你可能在自動駕駛。你是有選擇的。」

與專案系統整合

絆腳索是通用概念，各專案會有各自的實作方式：

• 期限型 — 計時器 / 掛鉤（Hook）監測 / 決策者自律
• 失敗型 — CI 失敗計數 / 重複 dispatch 偵測 / Bug tracker 標記
• 偏離型 — 任務追蹤系統的 label / milestone 統計
• 切割 — Atomic work unit / 階段性 checkpoint 機制
• 正面捕捉 — 學習捕捉 / retrospective / 知識庫記錄

各專案的具體整合（掛鉤（Hook）訊號對應、CLI 提醒訊息、狀態追蹤、自動觸發機制、規則系統對應）應放在該專案自己的落地層文件。

Last Updated: 2026-04-28 Version: 2.1.0 — 防護型新增「決策路徑型」分類，含 4 子型詳表（CLI 自動駕駛（autopilot） / 既有結論錨定（Anchor） / 草率改規則 / 多步驟成功率盲點）。 Version: 2.0.0