cheat-retro

---

name: cheat-retro description: 復盤 + 把新觀察寫入 rubric_notes。這是校準循環的反饋環節——不復盤的預測等於占星。觸發詞："復盤 [path]"/"retro this"/"這次迭代復盤"/"bug 修好了"/"迭代 #N 完成"/"程式跑通了"/"功能完成了"。 argument-hint: [— iteration: N] allowed-tools: Bash(*), Read, Edit, Write, Glob, Grep, Skill

/cheat-retro — 迭代復盤

不復盤的預測等於占星。每次 bug 修復後立刻復盤，不批量補、不跳過。

概述

[用戶："bug 修好了" / "迭代 #N 完成" / "程式跑通了"]
  ↓
[Phase 0: 確認預測文件 + 識別復盤類型]
  ↓
[Phase 1: 收集本次迭代實績]
  ↓
[Phase 2: 對比預測——哪裡對、哪裡錯]
  ↓
[Phase 3: 修正剩餘 K/RW 預測]
  ↓
[Phase 4: 落盤到預測文件]
  ↓
[Phase 5: 若最終復盤，填完整分析 + bump 觸發檢測]

復盤類型區分

迭代復盤（每次 bug 修復後）：

• 觸發詞："bug 修好了"、"迭代 #N 完成"、"又出問題了"
• 只填一個迭代段，不填最終復盤
• 必須更新剩餘 K/RW 預測數字

最終復盤（程式完整跑通 / 功能 ship 後）：

• 觸發詞："程式跑通了"、"功能完成了"、"代碼合入了"
• 填最終 K/RW 實際數值 + 完整分析

Phase 0: 確認文件

1. 讀取 prediction 文件，確認存在
2. 確認 ## 預測 段存在，immutable——絕不修改
3. 掃描已有迭代段，計算當前迭代數（新迭代命名為 ### 迭代 #N）

Phase 1: 收集迭代實績

從對話上下文自動提取，或詢問用戶：

1. Bug 描述：什麼壞了？
2. 根因：為什麼會這樣？（AI 邏輯錯誤 / API 誤用 / 版本不兼容 / 規格不清）
3. 修復方法：怎麼改的？
4. 這段代碼是 AI 生成的還是自己寫的？
5. 修復花了多少時間（粗估）？

Phase 2: 對比預測

從 prediction 文件的推理因素表找出本次 bug 所在模組，判定：

• 預測評估該模組「高槓桿/低風險」但實際出錯 → ❌ 預測失敗，說明哪個假設錯了
• 預測評估該模組「高風險」且實際出錯 → ✅ 預測命中，驗證假設

格式：

**對比預測**:
| 項目 | 預測 | 實際 | 判定 |
|---|---|---|---|
| [模組名] | [預測說什麼] | [實際發生什麼] | ✅/❌ |

Phase 3: 修正剩餘預測

基於本次迭代新信息，更新剩餘未測試部分的 K/RW：

• 「被認為安全」的地方出問題 → K 中樞下修，RW 中樞上修
• 「被認為危險」的地方比預期輕微 → K 中樞上修，RW 中樞下修
• 完全未預期的風險維度 → 記錄為新發現，標記為新風險類型

格式：

**修正預測（迭代 #N 後）**:
- K 中樞：[前值] → [新值]（原因：[一句話]）
- RW 中樞：[前值] → [新值]（原因：[一句話]）
- 新增風險：[如有，否則寫"無"]

Phase 4: 落盤（迭代復盤格式）

追加到 prediction 文件的 ## 復盤（迭代式） 段（如不存在則新建）：

### 迭代 #N — [Bug 一句話描述]

**發生時間**: YYYY-MM-DD，[觸發情境]
**Bug**: [具體錯誤訊息或現象]
**根因**: [技術根因]
**修復**: [修復方法]

**對比預測**:
| 項目 | 預測 | 實際 | 判定 |
|---|---|---|---|
| [模組] | [預測] | [實際] | ✅/❌ |

**校準更新**: [這次學到什麼，對 AI 能力的認識有何更新]

**修正預測（迭代 #N 後）**:
- K 中樞：X% → Y%（原因）
- RW 中樞：X% → Y%（原因）
- 新增風險：[如有，否則寫"無"]

**迭代 #N 狀態**: [已驗證 / 尚未驗證]

Phase 5: 最終復盤（功能完成後）

追加 ### 最終復盤 段：

### 最終復盤

**完成時間**: YYYY-MM-DD
**總迭代次數**: N 次

**實際 K（AI 保留率）**: X%
**實際 RW（返工率）**: X%
**實際 Bucket**: [高槓桿/中槓桿/低槓桿/反效果]

**預測 vs 實際**:
| 指標 | 初始預測中樞 | 最終修正預測 | 實際 | 偏差 |
|---|---|---|---|---|
| K | X% | Y% | Z% | [+/-]P% |
| RW | X% | Y% | Z% | [+/-]P% |

**關鍵校準假設驗證**: [初始押注的假設成立了嗎]

**本次最大校準發現**: [一句話，對未來預測最有價值的新認識]

**Prompt 分析**:
- 最有效的 Prompt：[原文 + 為什麼有效]
- 最差的 Prompt：[原文 + 問題在哪]

**AI 失敗模式分類**（勾選本次出現的）:
- [ ] API 使用順序/細節錯誤（AI 知道 API 但不知使用禁忌）
- [ ] 語言版本行為差異（AI 訓練資料的版本行為不同）
- [ ] 冷門套件幻覺（AI 編造不存在的 API）
- [ ] 邏輯理解偏差（AI 理解了需求但設計錯了）
- [ ] 規格不清導致跑偏（SP 太低，這是 Spec 的問題）
- [ ] 其他：___

**下次同類任務的 Spec 建議**: [給自己的改進提示]

Bump 觸發

連續 ≥3 次預測同一模組「安全」但實際出問題 → 提議 /cheat-bump 重新評估 LV 維度評分邊界

Key Rules

1. 預測段 immutable——絕不修改 ## 預測 段，只追加復盤段
2. 每次迭代獨立落盤——不批量補，不跳過
3. 修正預測必須給數字——不能說「差不多」，K/RW 必須更新具體數值
4. 觀察可追溯——每條校準更新必須引用具體 bug 或數據，不許寫「感覺更難了」
5. 不在復盤裡 bump——Phase 5 只提議，實際升級走 /cheat-bump