| name | cheat-retro |
| description | 復盤 + 把新觀察寫入 rubric_notes。這是校準循環的反饋環節——不復盤的預測等於占星。觸發詞:"復盤 [path]"/"retro this"/"這次迭代復盤"/"bug 修好了"/"迭代 #N 完成"/"程式跑通了"/"功能完成了"。 |
/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: 確認文件
- 讀取 prediction 文件,確認存在
- 確認
## 預測 段存在,immutable——絕不修改
- 掃描已有迭代段,計算當前迭代數(新迭代命名為
### 迭代 #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
- 預測段 immutable——絕不修改
## 預測 段,只追加復盤段
- 每次迭代獨立落盤——不批量補,不跳過
- 修正預測必須給數字——不能說「差不多」,K/RW 必須更新具體數值
- 觀察可追溯——每條校準更新必須引用具體 bug 或數據,不許寫「感覺更難了」
- 不在復盤裡 bump——Phase 5 只提議,實際升級走
/cheat-bump