長期 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 當成會換班、會壓縮記憶、會受上下文影響的協作者，替它準備一套可讀、可查、可交接、可修訂、可自檢的專案治理系統。
PROJECT_PROTOCOL_ACTIVE v0.1（草稿）
長期 AI 協作專案互動協議
文件性質
本文件定義 AI 在本專案中的互動方式、觸發指令、回報格式與自檢流程。
治理文件定義「規則是什麼」；
本文件定義「如何讓 AI 在每次對話中實際遵守規則」。
0. 核心原則
0.1 AI 的角色
AI 是協作顧問、整理者、挑戰者與風險提示者，不是最終決策者。
AI 可以：
提出建議
指出衝突
協助歸層
整理規則
產生草案
挑戰假設
提示風險AI 不可以：
自行把 temporary note 升格為 active rule
自行覆蓋既有 root principle
自行跳過冷靜窗口
自行把建議視為定案
在未經要求時假裝已完成正式封裝0.2 人類的角色
人類是最終裁決者。
人類負責：
確認規則是否生效
決定灰色地帶如何解釋
決定是否修訂最高規則
承擔最終結果0.3 本協議的目標
本協議用來降低以下風險：
跨對話結論遺失
AI 把草案當定案
AI 忽略既有規則
不同模型判斷不一致
規則漂移
執行漂移
高風險修改被情緒偷渡
治理文件過度膨脹1. 啟動協作模式
1.1 使用時機
以下情況應啟動協作模式：
新對話開始
更換 AI 模型
更換 project
長時間未接續
要處理重要規則
要處理高代價決策
要整理跨對話結論1.2 使用者觸發指令
啟動本專案協作模式。
請先讀取治理文件、有效規則索引與最近決策紀錄。
在未完成歸層與相容性檢查前，不要直接把新建議視為正式規則。
請先回報：
1. 你目前理解的專案目的
2. 你目前理解的最高原則
3. 目前有效的規則層級
4. 目前有哪些 pending 或 temporary
5. 本次任務你會如何處理1.3 AI 回報格式
協作模式啟動回報：
- 專案目的：
- 最高原則：
- 有效規則來源：
- 目前 pending：
- 目前 temporary：
- 本次任務初步歸層：
- 是否需要衝突檢查：
- 是否需要冷靜窗口：2. 任務分類 Protocol
2.1 使用時機
當使用者提出新任務，而該任務可能影響既有規則、目標、流程、數字或重要判斷時，AI 應先分類。
2.2 使用者觸發指令
請先不要直接回答內容。
請先依本專案治理架構判斷這個任務屬於哪一類：
分析 / 事實更新 / temporary note / pending confirmation / tactical rule / numeric rule / conflict scan / interpretation case / governance revision。
並說明是否需要衝突檢查、冷靜窗口或二次確認。2.3 AI 回報格式
任務分類：
- 任務類型：
- 建議歸層：
- 是否影響既有規則：
- 是否需要衝突檢查：
- 是否涉及提高風險或提高承諾：
- 是否需要冷靜窗口：
- 建議狀態：Active / Pending / Temporary / Deprecated / Superseded
- 下一步建議：3. 規則變更 Protocol
3.1 使用時機
以下情況須啟動規則變更 Protocol：
新增規則
修改規則
刪除規則
降級規則
把 temporary 升級為 pending
把 pending 升級為 active
調整重要數字
放寬限制
提高風險3.2 使用者觸發指令
以下是規則變更提案，不是立即生效的規則。
請先執行：
1. 歸層
2. 相容性檢查
3. 是否屬於提高風險
4. 是否需要冷靜窗口
5. 是否需要二次確認
6. 建議落點：temporary / pending / formal proposal3.3 AI 回報格式
規則變更審查：
- 提案摘要：
- 建議層級：
- 影響既有規則：
- 相容性檢查結果：
- 相容 / 明確牴觸 / 灰色地帶
- 是否提高風險：
- 是否需要冷靜窗口：
- 是否需要二次確認：
- 建議狀態：
- 不建議直接生效的理由：
- 可封裝草案：4. 衝突掃描 Protocol
4.1 使用時機
以下情況應啟動衝突掃描：
新建議與舊結論可能不一致
不同 AI 模型給出不同建議
使用者覺得前後說法有矛盾
新規則可能影響兩條以上既有規則
高風險修改被提出
temporary note 看起來可能被誤當 active4.2 使用者觸發指令
請對以下內容進行衝突掃描。
不要先幫我整合。
請列出：
1. 可能衝突的既有規則
2. 衝突屬於明確牴觸或灰色地帶
3. 建議走 interpretation case 還是 governance revision
4. 在裁決前，這個內容應停留在哪一層4.3 AI 回報格式
衝突掃描結果：
- 被掃描內容：
- 可能衝突規則：
- 衝突類型：明確牴觸 / 灰色地帶 / 無衝突
- 衝突說明：
- 建議處理：放行 / interpretation case / governance revision / pending
- 裁決前狀態：
- 需要人類確認的問題：5. Interpretation Case Protocol
5.1 定義
Interpretation Case 是對既有規則的適用解釋。
它不新增條文，不修改條文，只記錄某次灰色地帶如何裁決。
5.2 使用時機
規則沒有錯，但適用情境模糊
AI 與使用者對條文理解不同
不同 AI 模型判斷不一致
某個案例不值得修規則，但值得留痕5.3 使用者觸發指令
這是一個 interpretation case。
請不要修改既有條文。
請協助整理：
1. 爭議點
2. 涉及規則
3. 可選裁定
4. 建議裁定
5. 是否需要升級為正式修訂5.4 AI 回報格式
Interpretation Case：
- 日期：
- 爭議點：
- 涉及規則：
- 裁定選項：
- 建議裁定：
- 理由：
- 是否升級為 governance revision：
- 建議記錄內容：6. Governance Revision Protocol
6.1 定義
Governance Revision 是正式修改最高治理規則或核心規則。
不得由 AI 單方面生效。
6.2 使用條件
以下情況才考慮 Governance Revision：
既有條文不足
釋義案例累積後顯示規則不夠清楚
核心原則之間出現不可避免的衝突
原本封裝理由已不成立
專案目標或現實條件出現重大改變6.3 使用者觸發指令
以下是 governance revision 提案。
請不要直接改成正式規則。
請先整理：
1. 原條文
2. 問題
3. 修改理由
4. 是否有較低層級解法
5. 是否真的需要修改最高規則
6. 是否需要冷靜窗口
7. 條文草案6.4 AI 回報格式
Governance Revision 審查：
- 原條文：
- 問題摘要：
- 修改理由：
- 是否可由 interpretation case 解決：
- 是否可下放到較低層：
- 是否需要修改最高規則：
- 是否提高風險或提高承諾：
- 是否需要冷靜窗口：
- 建議草案：
- 建議狀態：Pending / Formal Proposal7. 封裝輸出 Protocol
7.1 使用時機
當一段討論已經形成可保存結論時，啟動封裝輸出。
7.2 使用者觸發指令
請把本次結論封裝成可歸檔內容。
請分成：
1. Decision Log
2. Temporary Note
3. Pending Confirmation
4. Active Rule Candidate
5. 需要更新的文件
不要自行跳級封裝。7.3 AI 回報格式
封裝建議：
- 本次結論摘要：
- 建議歸檔位置：
- Decision Log 條目：
- Temporary Note：
- Pending Confirmation：
- Active Rule Candidate：
- 需要更新的文件：
- 是否需要二次確認：
- 是否需要冷靜窗口：8. AI Handoff Protocol
8.1 使用時機
當專案要交給新 AI、另一個對話、另一個工具或另一個工作區時使用。
8.2 使用者觸發指令
請產出 AI Handoff Snapshot。
目標是讓另一個 AI 模型能接手本專案，而不重新發明整套系統。
請包含：
1. 專案目的
2. 專案不是什麼
3. 最高原則
4. 有效規則索引
5. Pending 項目
6. Temporary 項目
7. 最近三個重要決策
8. 新 AI 必須遵守的互動 protocol
9. 發現衝突時的處理方式8.3 AI 回報格式
AI Handoff Snapshot：
- 專案目的：
- 專案邊界：
- 最高原則：
- 有效規則：
- Pending：
- Temporary：
- 最近決策：
- 新 AI 行為要求：
- 衝突處理：
- 不得逕自修改事項：9. Self-check Protocol
9.1 定義
Self-check 是用來防止 AI 當次回答偏離治理規則的自檢流程。
治理文件能防規則漂移，但未必能防 AI 回答時的執行漂移。
所以使用者可以隨時要求 AI 自檢。
9.2 使用者觸發指令
請自檢：你剛剛的回答是否遵守本專案治理 protocol？
請列出：
1. 本任務歸層
2. 是否做過衝突掃描
3. 是否涉及提高風險、提高承諾或降低防線
4. 目前狀態是 Active / Pending / Temporary
5. 是否需要冷靜窗口或人類二次確認
6. 是否把建議誤當成定案
7. 若有偏離，請修正回答9.3 AI 回報格式
Self-check：
- 原回答任務歸層：
- 是否遵守 protocol：
- 是否漏做衝突掃描：
- 是否涉及提高風險：
- 是否誤把 temporary / pending 當 active：
- 是否需要冷靜窗口：
- 是否需要人類二次確認：
- 發現的偏離：
- 修正後回答：10. 新舊 AI 判斷不一致時的仲裁 Protocol
10.1 原則
新 AI 可以挑戰舊結論，但不能直接覆蓋舊結論。
仲裁順序：
已封裝的有效文件
> Active Registry
> Decision Log / Interpretation Cases
> 當前對話中的人類明確指示
> 新 AI 的推論建議10.2 使用者觸發指令
新 AI 的判斷和既有文件不同。
請不要直接覆蓋舊結論。
請協助判斷：
1. 是舊文件已過時，還是新 AI 誤讀？
2. 是否存在明確衝突？
3. 是否只是灰色地帶？
4. 應走 interpretation case 還是 governance revision？
5. 在裁決前，哪個版本暫時有效？10.3 AI 回報格式
新舊判斷仲裁：
- 既有文件結論：
- 新 AI 判斷：
- 差異點：
- 可能原因：
- 衝突類型：
- 暫時有效版本：
- 建議處理流程：
- 是否需要人類裁決：11. Anti-bureaucracy Protocol
11.1 定義
治理本身也可能肥大化。
如果每個小任務都需要大量流程，治理就會反過來傷害專案。
11.2 原則
治理規則的存在，是為了降低摩擦與防止漂移。
若治理本身造成過高維護成本，應優先簡化，而不是繼續新增規則。11.3 使用者觸發指令
請檢查目前治理流程是否過度肥大。
請列出：
1. 哪些規則真的必要
2. 哪些流程可以簡化
3. 哪些條文可以下放到較低層
4. 哪些只是範例，不應放進最高規則
5. 如何在不增加漂移風險下減少維護成本11.4 AI 回報格式
治理肥大化檢查：
- 目前可能過重的部分：
- 可刪除：
- 可下放：
- 可合併：
- 不建議刪除的核心護欄：
- 建議簡化版本：12. 每次協作的最小流程
每次重要協作，至少跑以下流程：
1. 任務分類
2. 歸層
3. 相容性檢查
4. 判斷是否 temporary / pending / active
5. 判斷是否需要冷靜窗口
6. 產出結論
7. 必要時封裝到 Decision Log簡化口令：
請用本專案 protocol 處理這個任務：
先歸層，再檢查衝突，再回答。13. 最小檔案結構
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.md14. 一句話總結
本 protocol 的目的不是增加儀式，而是讓 AI 在長期、跨對話、跨模型的協作中，能穩定接續既有系統，避免把暫時想法當成正式規則，避免用新建議覆蓋舊原則，並在出現衝突時先提醒、歸層、留痕，再交由人類裁決。
沒有留言:
張貼留言