RCF-015：improvements.md 三次閾值升規觸發機制 + 季度盤點規則老化複查

日期：2026-04-28 狀態：有效 觸發條件：條件 1（修改 HARD STOP 規則）+ 條件 4（修改 SKILL 核心步驟）來源：@shareuhack Threads 貼文「AI Agent 自我修改工作手冊」採用點 1+2（2026-04-28 Step 9）

決策內容

變更一：improvements.md 閾值觸發機制

修改的檔案：

knowledge/improvements.md — 新增「格式規格」章節：分類標籤 + 出現次數 兩個新欄位、完整狀態值定義、同類判斷標準（兩條件 AND）、掃描範圍限制（最近 30 條）、已升規條目排除規則
主 CLAUDE.md 品質自查 Step 6 — 新增 IMP 三次閾值觸發行為：同類比對 → 遞增計數 → ≥3 強制輸出升規建議 → 未確認標記「升規待確認」

IMP 格式新增欄位（IMP-064 起適用）：

分類標籤：8 個預定義類別（查照程序/部署流程/格式規範/文件同步/程式碼規範/資料讀取/對外內容/其他）
出現次數：同類錯誤累計計數，初始值 = 1

同類判斷標準（AND 關係）：

分類標籤相同
錯誤核心動詞/名詞至少一個重疊

觸發升規：出現次數 ≥ 3 且狀態不是「✅ 已升規」→ 品質自查強制輸出升規建議文字

變更二：季度盤點 SKILL Step 2.5 規則老化複查

修改的檔案： .claude/skills/季度盤點.md — 在 Step 2 和 Step 3 之間插入 Step 2.5

執行方式（A+B 雙軌）：

A：git log --since="60 days ago" 掃描 SKILL 檔 + 部門 CLAUDE.md（排除主 CLAUDE.md）
B：Tim 手動瀏覽主 CLAUDE.md 快速索引表

輸出：⏰ 待複查清單 → 季度反思報告末尾加「六、規則複查清單」

背景與動機

問題 1：improvements.md 升規延遲

improvements.md 已累積 64 條觀察，但沒有「同類錯誤計次」機制，導致同類問題可能重複出現而未被升規。現有流程：觀察 → 寫入 IMP → Tim 定期瀏覽決定是否升規。缺口：沒有自動提醒機制，IMP 會靜默積累。

問題 2：規則老化無意識

CLAUDE.md 的 prompt 有「保質期」（@shareuhack：約兩週）。系統沒有任何機制提醒哪些規則可能已過時，Tim 和 Claude 都依賴「沒有問題就繼續用」的默認邏輯。

觸發來源

@shareuhack Threads 貼文（2026-04-26）核心觀點：

「與其寫完美的初始 prompt，不如設計讓 agent 從錯誤中學習的機制」
「初始 prompt 的保質期大概兩週，但學習機制可以讓它自己跟上變化」

考慮過的方案

閾值機制方案對比

方案	描述	選用/棄用
全自動	同類錯誤 ≥3 → 自動寫入 CLAUDE.md 規則	❌ 棄用：可能產生衝突規則，缺乏品質把關
半自動（選用）	≥3 → 輸出建議文字 → Tim 確認後才寫入	✅ 保留自動觸發 + 人工判斷
純手動（現有）	Tim 定期瀏覽 improvements.md	❌ 棄用（作為主機制）：無提醒，升規延遲

老化複查方案對比

方案	描述	選用/棄用
章節層級 timestamp	每個 CLAUDE.md 章節加最後更新日期	❌ 棄用：維護成本極高，每次修改都要手動更新
git log 全檔掃描（含主 CLAUDE.md）	git log since 60 days	❌ 棄用：主 CLAUDE.md 每次收尾都被 commit，永遠顯示最新
A+B 雙軌（選用）	git log（SKILL + 部門）+ 主 CLAUDE.md 手動	✅ 資料準確，且可執行

選擇理由

半自動優於全自動：

Dimension 6 風險分析已指出：「自動加規則若不受人工確認，可能產生衝突規則或疊床架屋」
系統原則：高影響、不可逆動作（修改 CLAUDE.md）保留 Tim 確認步驟
半自動保留觸發的自動化（≥3 必定提報），確認的人工化（Tim 決定品質）

A+B 雙軌優於其他方案：

主 CLAUDE.md 因收尾七件事而每次都被 commit，git log 無法反映章節層級老化
SKILL 和部門 CLAUDE.md 是獨立檔案，git log 結果可信，可機械化執行
Tim 手動瀏覽主 CLAUDE.md 雖主觀，但頻率合理（每季一次）

影響範圍

影響對象	影響內容
`knowledge/improvements.md`	新增格式規格章節；IMP-064 起適用新欄位
主 `CLAUDE.md`	品質自查 Step 6 新增閾值觸發行為說明（HARD STOP 文字修改）
`.claude/skills/季度盤點.md`	Step 2 後插入 Step 2.5（規則老化複查）
各部門 CLAUDE.md	無影響（Step 6 文字僅在主 CLAUDE.md，Grep 已確認）
所有技術系統（官網/看板等）	無影響

後記

本次 RCF 的查照過程本身就是「閾值觸發」設計價值的最佳示範。Tim 連續五輪追問「足夠嚴謹嗎」，共發現缺口 A-F（11 項），其中兩個 Critical 缺陷（出現次數遞增機制未定義 + Step 2.5 資料來源不存在）分別在第三、四輪才揭露。這證明了：複雜機制設計需要多輪壓力測試，而不是一次性靜態審查。