AI 協作不只是記憶管理，還有治理（2026-04-27）
🔗 https://www.threads.com/@zarqarwi/post/DXmD3dHAQiS 平台：Threads ｜ 作者：@zarqarwi ｜ 分類：knowledge/references/知識管理工具
維度 1：定性（基本資料）
- 平台：Threads
- URL：https://www.threads.com/@zarqarwi/post/DXmD3dHAQiS
- 作者：@zarqarwi（paulkuo.tw，AI 協作治理實踐者，分享的是 v3 版本的實際運作系統，含具體檔案路徑與 ADR 編號系統）
- 發布日期：2026-04-27（約 20 小時前）
- 互動數據：47 讚 / 5 回覆 / 2 轉發 / 96 分享
- 內容類型：社群貼文型（5 則連串貼文 + 1 張完整架構圖）
- 可信度評估：高——展示有版本號（v3）的實際運作系統，包含真實檔案路徑（spaces/.../memory/MEMORY.md / claude-code/skills/）與具體 ADR 編號（H1-H11，12 個），非泛泛理論
維度 2：讀取記錄
- 讀取方式：Chrome MCP navigate + read_page（完整文字）+ computer 截圖（IMP-058 圖片讀取）
- 內容完整性：完整（5 則貼文全部讀取 + 架構圖截圖分區讀取）
- 讀取限制：已截圖讀取圖片；架構圖 PENDING 清單 #7-#13 以後部分係推斷（解析度限制）
維度 3：核心概念五欄比較
| 概念 | A 是什麼 | B 解決什麼問題 | C 我們目前做法 | D 來源做法 | 比較結論 |
|---|---|---|---|---|---|
| 治理四層架構（憲法→ADR→Skill→Memory） | AI 協作的治理框架，四層各司其職：憲法定原則、ADR 管決策 Why、Skill 管做法 How、Memory 管歷史 What happened | 解決「換視窗就忘光」「Chat 決定 A 到 Code 跑回 B」的跨 Session 一致性問題 | CLAUDE.md（≈憲法）+ decisions/RCF（≈ADR）+ .claude/skills/（Skill）+ memory/（Memory）→ 四層已存在，但未明確命名治理框架，且無版本號 | 明確命名「治理框架」；憲法 v0.2 有版本號；ADR H1-H11 有題號系統；Memory 依 per-space 隔離（user/feedback/project/reference）；⚠️ 跨 space = 汙染（圖中明確標注） | A：高；B：驗證現有做法；C：改善（補版本號）；D：部分採 |
| PENDING.md 跨 Session 交接機制 | 顯式的跨視窗狀態載體，記錄「觀察期/尚未決策」的灰色項目，與 CLAUDE.md 分開獨立存在 | 解決「文件寫了一堆，真要執行時沒有 AI 回頭去對」；特別處理「已知但尚未決策」的懸置項目 | dev/tasks.md 追蹤「確定要做的任務」，無專門的「觀察期/Pending 決策」載體；灰色地帶項目混在 P3 清單 | PENDING.md 獨立於 CLAUDE.md，目前有 4 條：#5 auto-memory 升規管理 / #13 ADR handoff 格式 / #6 引業 ADR / #7 Paul 部署 branch protection；明確保留彈性 | A：高；B：補充缺口；C：改善；D：部分採 |
| Chat→Cowork→Code 三段工作流 | 依工作性質分層的協作模式：Chat=概念探索；Cowork=協作執行；Code=程式碼提交；各段有獨立 per-space memory | 防止不同工作模式的記憶污染，每段 memory 互不干擾 | 所有工作在同一 Claude Code 對話中完成，HARD STOP + 查照協議確保一致性，無模式分層 | 三段各有 memory_chat / memory_cowork / memory_code（per-space 隔離），commit 層有 npm CLAUDE.md 自動帶入 | A：中；B：可參考；C：保留（單一 session + 規則管控更符合 Tim 習慣）；D：不採 |
| 自動化衛護層（git hooks + daily scanner） | 在 git 操作時自動執行治理規則：pre-commit hook / commit-msg hook / governance-bot.sh / daily scanner | 防止規格層變更未被記錄、防止 ADR 未更新、防止 memory 邊界被突破 | 已有 PreToolUse hooks（query-gate + knowledge-hook）；無 commit-msg hook；改善追溯為手動觸發 | 圖中四節點：pre-commit hook → commit-msg hook → governance-lint.sh → daily-scanner；governance-bot 為主動巡邏角色 | A：中；B：可參考；C：改善（研究 commit-msg hook 可行性）；D：不採（現有 hook 已夠） |
維度 4：可採用點（具體行動）
- 【知識庫/KM】建立
knowledge/pending-decisions.md— 記錄「觀察期/尚未決策」項目，補強 tasks.md 只能處理「確定要做」任務的盲點 → 填補跨 Session 灰色地帶，防止懸置決策遺失 → 難度低 → P2 - 【知識庫/KM】在主 CLAUDE.md 頂部加入版本號標記（如「v1.4 | 最後更新 2026-04-XX」），對應「憲法有版本號」做法 → 提升規則文件可追溯性 → 難度低 → P3
維度 5：明確不採用
- Chat/Cowork/Code 三段工作流分離 — 不採用原因：Tim 的工作習慣是單一對話視窗完成全部工作，三段分離增加認知負擔；我們的 HARD STOP + 查照協議已在語意層解決跨模式一致性問題，不需要在 memory 層另行分層
- commit-msg hook — 暫不採用：git 提交說明目前足夠清楚；RCF 規格層已透過查照流程強制記錄變更；新增 commit hook 的維護成本高於收益
維度 6：整體對比判斷
- 與現有系統的關係：驗證現有做法（四層架構本質相同）+ 補充缺口（PENDING.md 概念是我們現在沒有的）
- 最有價值的一點：PENDING.md 作為「尚未決策但正在觀察」的獨立載體，補強 tasks.md 只能放「確定要做」任務的結構性盲點
- 最需要注意的風險：作者系統複雜度（v3，12 個 ADR，多 space memory）遠高於我們目前規模；過度對標可能引入不必要的 overhead
- 整體評分：中等參考（架構高度相似，驗證方向正確；PENDING.md 概念有實際採用價值；三段工作流不適用）
維度 7：立即行動
本次無立即行動，採用點已列入 tasks.md。
維度 8（確認）
- Step A condensed entry 已寫入：knowledge/references/知識管理工具.md ✅
- Step C index 已更新：knowledge/analyses/README.md ✅