長期 AI 協作治理工作流 v1.0
讓專案可攜、可維護、可追溯、不易漂移
核心觀念
長期 AI 協作不能只靠聊天記憶，也不能只靠靜態規則。
只要一個專案會跨多次對話、跨不同模型、累積大量決策，或牽涉高代價判斷，就需要建立一套可攜式治理工作流。
這套工作流由三部分組成：
Governance：治理文件，定義規則與位階
Protocol：互動協議，定義如何觸發 AI 正確工作
Self-check：自檢機制，防止 AI 當次回答偏離規則
一句話：
治理文件防「規則漂移」；互動 protocol 防「啟動失敗」；自檢機制防「執行漂移」。
一、適用場景
只要專案符合以下任一條件，就不建議只靠聊天紀錄：
專案會跨很多次對話
會更換不同 AI 模型
會在不同 project、不同工具間移植
會累積很多結論與決策
錯誤代價高
使用者未來可能忘記當初為什麼這樣決定
AI 可能因 token 壓縮、上下文不足或模型差異而偏移
暫時想法、正式決策、草案規則容易混在一起
二、先定義專案的「是什麼」與「不是什麼」
長期協作專案一開始，不只要定義目的，也要定義邊界。
1. 這個專案是什麼？
本專案的目的：
建立一套可長期維護、可交接、可追溯、可由 AI 協助但由人類裁決的工作系統。
2. 這個專案不是什麼？
本專案不是：
1. 不是讓 AI 取代人類做最終決策。
2. 不是追求一次產出完美答案。
3. 不是把所有靈感都升級成正式規則。
4. 不是讓新模型重新發明整個專案。
5. 不是為了最大化自動化，而是為了降低遺忘、漂移與衝突。
3. 為什麼要寫「不是什麼」？
AI 很擅長延伸，但也容易過度延伸。
「是什麼」提供方向；「不是什麼」提供邊界。
三、建立 Governance：治理文件
治理文件回答的是：
最高原則是什麼？
哪些內容不能被短期情緒推翻？
哪些內容可以自由修改？
哪些修改需要冷靜期？
衝突時誰優先？
AI 發現矛盾時應該怎麼提醒？
建議建立：
01_META_GOVERNANCE.md
治理文件不是專案內容本身，而是「管理專案內容的規則」。
四、建立 Fact Base：事實基準
AI 很容易忘記專案目前服務的對象、現況與限制。
所以需要一份可定期更新的事實基準。
建議建立：
02_FACT_BASE.md
內容包含：
專案目的：
目前狀態：
資源限制：
時間限制：
重要外部條件：
已知風險：
目前進度：
不可忽略的現實約束：
重要原則：
事實基準可以更新事實，但不能偷渡新原則、新策略或新目標。
五、把規則分層，不要混在一起
不要把最高原則、具體數字、操作策略、靈感、草案、正式決策全部放在同一層。
建議分層：
1. PROJECT_PROTOCOL AI 如何協作、如何回報、如何提醒
2. ROOT_PRINCIPLE 不可輕易違背的核心原則
3. ROOT_NUMERIC 長期目標、門檻、比例、量化條件
4. CROSS_RULE 多條規則互相衝突時的優先序
5. TACTICAL_PRINCIPLE 特定情境下的操作邏輯
6. TACTICAL_NUMERIC 戰術層的具體數字
7. TEMPORARY_NOTE 暫時想法、靈感、未確認假設
8. PENDING_CONFIRMATION 等待二次確認的候選規則
核心原則：
討論過，不等於定案。
寫下來，不等於生效。
Pending，不等於 Active。
Temporary，不得自動升格。
六、每次新增規則，都先過三道海關
任何新規則進場前，都先檢查三件事。
1. 歸層
它是：
分析 / 事實更新 / 核心原則 / 數字規則 / 戰術規則 / 暫時想法 / 待確認候選 / 修憲提案
2. 相容性
檢查：
是否違反最高原則？
是否與既有規則衝突？
是否只是用新語言偷渡高風險決策？
是否把 temporary 當 active？
3. 狀態
標記為：
Active / Pending / Temporary / Deprecated / Superseded
七、建立修改門檻
不同層級要有不同修改難度。
最高治理規則：二次確認＋冷靜期＋書面理由
核心原則：二次確認，不因情緒性誘導修改
核心數字：可改，但要記錄理由與版本
戰術規則：可調整，但要留時間戳
暫時想法：自由記錄，但不得自動升格
特別規則：
降低風險：可較快生效，但仍須留痕
提高風險：需要冷靜期，不得在情緒性衝擊當下定案
提高風險包括但不限於：
提高槓桿
提高單一項目上限
降低安全防線
放寬停損或中止條件
提高承諾成本
允許借貸或外部資源投入高風險事項
延後原定降風險動作
八、建立數字履歷
任何重要數字都不應只是孤立的值。
每個數字至少記錄：
數字 ID：
目前值：
理由：
資料來源：
實證級 / 自評級：
建立日期：
修改紀錄：
下次檢查時間：
核心原則：
數字不是答案，是有身世的決策痕跡。
九、建立 Decision Log
這是防止跨對話重吵的關鍵。
每次重要結論都要記錄：
日期：
討論來源：
決策摘要：
影響層級：
新增 / 修改 / 降級 / 廢止：
牽涉規則 ID：
是否觸發衝突檢查：
是否需要冷靜期：
後續提醒：
核心原則：
避免 A 對話講好，B 對話重吵。
十、建立 Interpretation Cases：判例區
當 AI 或使用者發現灰色地帶時，不要每次都直接改規則。
先記錄一次「適用解釋」。
欄位：
日期：
爭議點：
涉及規則：
裁定：
理由：
是否需要升級為正式修訂：
核心原則：
灰色地帶先解釋。
條文不足才修訂。
十一、建立 AI Handoff Snapshot
交接給新 AI 模型時，不要直接丟一大包聊天紀錄。
先給一份 1～3 頁的交接摘要。
內容包含：
這個專案的目的：
這個專案不是什麼：
最高原則：
目前有效規則：
目前待確認事項：
不可自行修改的內容：
可以協助調整的內容：
發現衝突時 AI 應該怎麼做：
最近三個重要決策：
給新 AI 的第一句指令：
請先讀取本專案的治理規格與目前有效規則。
不要把暫時想法當成正式決策。
不要用新建議直接覆蓋既有原則。
若發現矛盾，請先提出衝突點與歸層建議。
十二、定義新舊 AI 判斷不一致時的仲裁順序
不同 AI 模型可能會有不同判斷。
新模型可以挑戰舊結論，但不能直接覆蓋舊結論。
建議仲裁順序：
已封裝的有效文件
> Active Registry
> Decision Log / Interpretation Cases
> 當前對話中的人類明確指示
> 新 AI 的推論建議
核心原則：
AI 有挑戰權，沒有逕自改憲權。
十三、加入 Self-check：自檢觸發
治理文件能防規則漂移，但不一定能防 AI 當次回答時的執行漂移。
所以使用者需要一個自檢觸發句。
範例：
請自檢：你剛剛的回答是否遵守本專案治理 protocol？
請列出：
1. 本任務歸層
2. 是否做過衝突掃描
3. 是否涉及提高風險、提高承諾或降低防線
4. 目前狀態是 Active / Pending / Temporary
5. 是否需要冷靜窗口或人類二次確認
6. 若有偏離，請修正回答
核心原則：
防得了規則漂移，還要防執行漂移。
十四、防止治理本身肥大化
治理系統本身也可能變成負擔。
如果規則越來越多、文件越來越厚、每次協作都變成儀式，治理就開始反噬專案。
加入一條反官僚化原則：
治理規則的存在，是為了降低摩擦與防止漂移。
若治理本身造成過高維護成本，應優先簡化，而不是繼續新增規則。
核心原則：
治理也要受治理。
十五、最小可行檔案結構
AI_Project_OS/
├ 00_README_FOR_AI.md
├ 01_META_GOVERNANCE.md
├ 02_FACT_BASE.md
├ 03_ACTIVE_REGISTRY.md
├ 04_PROJECT_PROTOCOL_ACTIVE.md
├ 05_ROOT_PRINCIPLE.md
├ 06_ROOT_NUMERIC.md
├ 07_CROSS_RULE.md
├ 08_TACTICAL_RULES.md
├ 09_TEMPORARY_AND_PENDING.md
├ 10_DECISION_LOG.md
├ 11_INTERPRETATION_CASES.md
└ 99_EXPORT_SNAPSHOT.md
一句話總結
長期 AI 協作不能只靠聊天記憶。
要把 AI 當成會換班、會壓縮記憶、會受上下文影響的協作者，替它準備一套可讀、可查、可交接、可修訂、可自檢的專案治理系統。
