AI Agent 自我修改工作手冊：錯誤閾值觸發機制（2026-04-26）
🔗 https://www.threads.com/@shareuhack/post/DXk4f5cCbTV 平台：Threads ｜ 作者：@shareuhack ｜ 分類：knowledge/references/AI工具.md
維度 1：定性（基本資料）
- 平台：Threads
- URL：https://www.threads.com/@shareuhack/post/DXk4f5cCbTV
- 作者：@shareuhack（台灣 AI 自動化實作創作者，標籤分類「自動化」）
- 發布日期：2026-04-26
- 互動數據：按讚 11 / 回覆 3 / 轉發 2 / 分享 2（2,373 次瀏覽）
- 內容類型：社群貼文型（四則連串，共約 300 字）
- 可信度評估：中。實作者親身分享，有具體案例（審稿 agent + 統計標注規則），但無系統名稱、無技術細節，難以獨立驗證。觀點層面可信，工程實現層面需補充
維度 2：讀取記錄
- 讀取方式：Chrome MCP navigate + read_page（accessibility tree）+ screenshot 截圖確認
- 內容完整性：完整（四則串文全部讀取，截圖確認無圖表、無卡片）
- 讀取限制：無。此貼文為純文字串，accessibility tree 已涵蓋全部正文
原始內文（全文）：
1/4：原本以為 AI agent 的工作流程需要人定期調整，結果我們的 agent 開始自己改自己的工作手冊了。不是隨便改，是它自己分析「最近十次任務裡，同一類錯誤出現三次以上」，然後在自己的 checklist 加一條新規則。
2/4：舉個例子：我們的審稿 agent 連續幾次漏檢了一種問題 — 文章裡引用的數字來自平台自己的統計，但沒有標注「這是平台自述」。第三次出現的時候，它自動在自己的審查流程裡加了一條：「平台自有統計需加標注」。從那之後就沒再漏過。
3/4：更有趣的是，不同 agent 演化出不同的「直覺」。負責研究的會越來越擅長判斷來源可信度，負責審稿的會發展出交叉比對的嗅覺。我們沒有設計這些差異，是它們各自在自己的領域裡累積經驗後自然長出來的。
4/4：做到現在最大的體悟：與其花時間寫完美的初始 prompt，不如設計一個讓 agent 能從錯誤中學習的機制。初始 prompt 的保質期大概兩週，但學習機制可以讓它自己跟上變化。
維度 3：核心概念五欄比較
| 概念 | A 是什麼 | B 解決什麼問題 | C 我們目前做法 | D 來源做法 | 比較結論 |
|---|---|---|---|---|---|
| 錯誤閾值觸發機制 | 同類錯誤出現三次以上，agent 自動在 checklist 新增一條規則 | 防止「已知問題被遺忘、下次再犯」；讓規則從經驗中自動生長，不靠人工記憶 | improvements.md 記錄觀察（IMP-XXX），由 Tim 手動決定是否升規為 CLAUDE.md 規則；無自動計次機制 | Agent 自己追蹤錯誤頻率，超過閾值自動提案加規則 | A：高相關；B：我們有此問題（IMP 累積但升規延遲）；C：保留手動確認步驟；D：部分採——加入「出現次數」欄位 + 三次自動標旗 + 品質自查中提報建議規則文字 |
| 初始 prompt 保質期概念 | 完美初始 prompt 的有效期只有約兩週；學習機制能讓系統自己跟上變化 | 打破「寫好 prompt 就沒事了」的假設，認識到維護成本存在 | CLAUDE.md 有版本號，但無明確「複查期限」或「章節過期標記」 | 接受 prompt 有保質期，以學習機制取代靜態維護 | A：高相關；B：我們有此盲點（CLAUDE.md 部分章節已數週沒更新）；C：改善；D：部分採——季度盤點加入「規則老化複查」步驟 |
| 各 agent 領域專化直覺 | 不同 agent 因為在各自領域累積錯誤記錄，自然演化出不同能力（研究 = 來源判斷、審稿 = 交叉比對） | 讓系統具備不同專業縱深，而不是每個 agent 都一樣 | 各部門 CLAUDE.md 已定義各部門職責邊界，但 Claude 是單一 agent，不存在多 agent 分化 | 刻意多 agent 架構，讓各 agent 在領域累積不同規則 | A：中；B：我們是單 agent，問題不同；C：保留；D：不採——多 agent 架構超出當前邊界，但「各部門 CLAUDE.md 獨立維護」已是同等概念的靜態版本 |
維度 4：可採用點（具體行動）
【知識庫/KM + 開發部/DEV】improvements.md 新增「出現次數」欄位 + 三次觸發自動標旗機制：每次 improvements.md 掃描時，Claude 追蹤同類錯誤出現次數，達三次在品質自查中強制輸出「建議升規規則文字（可直接貼入 CLAUDE.md）」供 Tim 確認 → 讓 IMP 從靜態記錄變成有自動演化機制的規則生長器 → 難度：低 → P2
【策略部/STR】季度盤點加入「規則老化複查」步驟：季度盤點 SKILL 中加入「列出 CLAUDE.md 各章節最後修改日期，超過 60 天未更動的章節標記為『待複查』」→ 難度：低 → P3
維度 5：明確不採用
- 多 agent 並行架構（各 agent 獨立演化直覺） — 不採用原因：我們是 Tim × Claude 單對話架構，無法實現真正的多 agent 並行；且目前規模（1 位顧問、9 個系統）尚不需要多 agent 複雜度，成本遠超效益。我們的等效做法是「各部門 CLAUDE.md 獨立定義」，已能達成專化效果的靜態版本
維度 6：整體對比判斷
- 與現有系統的關係：補充缺口——我們有 improvements.md 但缺少「計次觸發」的自動化機制；我們有 CLAUDE.md 版本號但缺少「規則老化意識」
- 最有價值的一點：「與其寫完美的初始 prompt，不如設計讓 agent 從錯誤中學習的機制」——直接描述了我們 improvements.md → CLAUDE.md 升規流程的設計哲學，也點出流程裡的缺口：三次才觸發，但目前沒有計次
- 最需要注意的風險：「自動加規則」若不受人工確認，可能產生衝突規則或疊床架屋。作者沒提及此風險——我們的設計要保留 Tim 確認步驟，不做全自動
- 整體評分：高價值。對我們的 improvements.md 機制有直接且低成本的改善方向
維度 7：立即行動
本次無立即行動。採用點為中難度（需修改 improvements.md 格式 + 品質自查步驟），已交由步驟九 Tim 確認後寫入 tasks.md。
維度 8（確認）
- Step A condensed entry 已寫入：knowledge/references/AI工具.md ✅
- Step C index 已更新：knowledge/analyses/README.md ✅
- Step 9 採用點確認（2026-04-28）：採用點 1（improvements.md 閾值觸發機制）✅ 已執行；採用點 2（季度盤點 Step 2.5 規則老化複查）✅ 已執行；RCF-015 已建立