TL;DR — 一個人同時跟四個 AI 視窗協作，自律在第一次趕 commit 時就失靈了。這篇記錄我如何從真實事故中演化出一套治理系統：憲法五條、governance-lint pre-commit hook、75 端點契約測試、12,946 檔案復原演練——每一層制度都有對應的事故編號。

2026 年 5 月 22 日，我的 commit 被擋下來了。

不是被同事擋的，團隊裡沒有其他人類。擋住我的是一個 229 行的 bash 腳本——governance-lint.sh，掛在 git pre-commit hook 上。它冷冰冰地吐出 Strict fails: 4：兩份 handoff 文件缺少 status frontmatter 欄位，也沒有 ## Consequences 章節。

有意思的是，這個腳本是我自己叫 AI 寫的。規則也是我自己定的。但當我趕著把 48 個檔案一次 commit 的時候，我自己沒發現違規。機器替我記住了。

這不是什麼了不起的技術故事。這是一個非全職工程師，在跟四個 AI 視窗協作的過程中，一路踩坑、一路補洞，最後長出一套治理系統的紀錄。

同一天爆三個洞，為什麼「小心一點」不夠用？

故事要從 2026 年 4 月 19 日說起。那天我同時在用 Chat、Cowork、Code 三個視窗處理 paulkuo.tw 的專案。到了下午，三個問題幾乎同時浮出水面：

第一個，session-handoff 這個 skill 在 repo 層是 v5.3，但在雲端層還停在 v4.13。兩邊都以為自己是最新的，沒有人知道對方存在分裂。

第二個，Cowork 視窗引用了一串「已驗證」的事實來做判斷，但追溯回去，那些事實從來沒有人跑過驗證指令。整條推理鏈建立在空氣上——我們後來叫它「castle in the sky」。

第三個，同一筆 memory 在 CLAUDE.md 和 memory 檔案裡各存了一份，內容不完全一樣。改了一邊，另一邊不知道。

三個問題的共同根源不是誰偷懶，而是架構上沒有機制確保「誰說了算」。當你只有一個 AI 對話視窗的時候，這種問題不存在。但當你的工作流是 Chat 做規劃、Cowork 做偵察、Code 做實作、Paul 做拍板——四個參與者各自有記憶、各自會產出結論——「事實一致性」就變成一個必須被工程化的問題。

我試過在 CLAUDE.md 裡多寫幾行規則。有用，但很快發現：注意力在趕 commit 的壓力下會失守。被動文件不等於主動防線。

所以我們做了一件聽起來有點荒謬的事：寫了一部憲法。

人機協作憲法的五條到底在管什麼？

「憲法」不是修辭。這份文件的結構確實參考了憲政設計的邏輯：先定身份（誰是參與者）、再定權限（誰能做什麼）、最後定爭議解決機制（出事了怎麼辦）。

五條的設計，每一條都對應我們踩過的坑：

第一條，SSoT 原則。 paulkuo.tw repo 的 git HEAD 是所有規則、skill、治理文件、memory、待辦佇列的唯一事實來源。這不是設計偏好，是排除法的結果——我調查了 Anthropic 官方文件，上面明白寫著「Custom Skills do not sync across surfaces… You’ll need to manage and upload Skills separately for each surface」。業界方案也一面倒指向 git-first。所有人都在用 git 當 SSoT，因為沒有其他選項。

第二條，載體對等。 雲端（Claude.ai）永遠是下游 mirror，不進協作主幹。這條是針對 skill 分裂事件立的。v5.3 跟 v4.13 的分裂就是因為雲端層被當成了「另一個正本」。

第三條，權責分工。 這條最精妙，也最容易被誤解。它不是把權限鎖死——Chat 只能做 X、Code 只能做 Y。它是「主責彈性 + 核查剛性」：誰負責什麼可以調整，但交叉驗證的義務是剛性的。Code 寫完的東西 Cowork 必須驗，Cowork 的偵察結論 Code 必須能重現。這跟三權分立的憲政設計邏輯一致——行政、立法、司法之間的 check 不是可選的禮貌，是結構性的義務。這篇是「智能與秩序」系列的一部分，探討的就是這種秩序如何在人機協作中被重新建構。

第四條，記憶層次。 一筆事實只在一個負責層存放，禁止跨層複製。同一層內，每筆 memory 必須原子化——一個檔案講一件事。這條是針對 memory 重複事件立的，也是後來整個 memory 系統重構的依據。

第五條，記憶擴充。 要接新的記憶載體（比如 Mem0、Letta、MCP memory server），必須走正式的 ADR（Architecture Decision Record）流程。不能因為某天覺得「這個工具好用」就直接接上去。

拍板那天，我跟 Cowork 視窗從下午四點討論到五點，v0.1 寫完立刻發現不夠，馬上修到 v0.2。整部憲法是在同一天的危機中誕生的。

從文件到防線：governance-lint 怎麼把規則變成程式碼？

憲法寫完後，日子平靜了六天。然後 4 月 25 日，又踩坑了。

一批 handoff 文件的 frontmatter 格式不統一，有的缺 status、有的沒有 ## Consequences 章節。這些在 CLAUDE.md 和憲法裡都有規定，但就是會漏。原因很簡單：規則寫在文件裡，而文件不會在你 git commit 的時候跳出來攔你。

這讓我們想清楚一件事：自律（autonomy）不夠，需要他律（heteronomy）。governance-lint 就是這個思路的產物——一個 bash pre-commit hook，229 行，負責在 commit 階段檢查機器可以檢查的規則。

目前啟用兩項硬性檢查。第一項掃描所有 handoff 文件，確認 frontmatter 有 status（只接受 Draft / Accepted / Superseded / Deprecated 四值）且內文有 ## Consequences 章節。第二項掃描文章的 pillar 欄位，確認值在 ai | circular | faith | startup | life 五個合法值之內——之前有篇文章填了 circular-economy，build 直接爆炸。

設計上有幾個刻意的決定。歷史文件有豁免機制——憲法之前的 handoff 不受新規則約束，這是一次性的赦免。但新文件必須合規。如果你真的需要繞過，可以用 --no-verify，但必須在 commit message 裡標注 [skip-lint-recovery] 並說明原因。逃生門存在，但逃生的代價是留下紀錄。

5 月 22 日的那次攔截是它第一次在生產環境真正發揮作用。48 個檔案的大批 commit，人眼漏掉了四處違規，機器沒漏。修完再 commit，13 個 commit 全部通過 governance-lint。

這套系統的演化路徑很典型：CLAUDE.md 裡的一行規則 → 被違反三次以上 → 升級為 pre-commit hook。我們叫這條路「事故驅動制度演化」——先觀察，再自動化。不要第一次就過度工程化。

GitHub 斷線：治理系統的壓力測試

2026 年 4 月 29 日，我的 GitHub 帳號 zarqarwi 被 suspend 了。沒有預警、沒有說明。

repo 沒有遺失——本地端完整。但整套工作流瞬間斷了：Pages 自動部署死了、Issues 追蹤器沒了、GitHub Actions 全部停擺。這個事件的完整工程紀錄在另一篇文章裡，這裡只講跟治理系統相關的部分。

壓力測試揭露了兩件事。

第一件：治理系統的 SSoT 原則（第一條）救了命。因為所有規則、文件、memory 都在本地 git 裡，GitHub 斷了只是少了一個 remote，不是少了事實來源。我們在 48 小時內切到 Codeberg + GitLab 雙遠端，工作流完全沒降級。如果 SSoT 當時放在 GitHub Issues 或任何雲端服務裡，這個故事的結局會完全不同。

第二件：危機加速了制度建設。在帳號被 suspend 到恢復的這段期間，我們做了 12,946 檔案的復原演練（從加密備份解壓 + 驗證），寫了五層韌性架構，上線了 75 端點的契約測試設計，強化了 commit-msg hook 的跨子專案影響偵測。不是因為有時間做，是因為「如果連 GitHub 都能斷，還有什麼不能斷」這個問題逼著你把每一層防線都想清楚。

韌性架構跟治理系統的交會點在這裡：韌性處理的是「外部服務斷了怎麼辦」，治理處理的是「內部協作亂了怎麼辦」。兩者的共同信念是同一條——不能讓任何單一節點的失效導致整個系統停擺。五層韌性架構的第一原則「No Single Point of Control」，跟憲法第一條的 SSoT 原則，本質上是同一件事的外部版和內部版。

事故轉制度：每一層防線的身世

回頭看整條時間軸，有一個清楚的模式：

2026 年 4 月 19 日，三個治理漏洞同時爆發 → 當天寫出憲法 v0.2。 4 月 20 日，給三個 AI 視窗考憲法考試 → 發現 Cowork 只考了 70%，Code 考了 97%。 4 月 25 日，handoff 格式違規累積到 N≥3 → governance-lint pre-commit hook 上線。 4 月 29 日，GitHub 帳號 suspend → 韌性架構五層全面建置。 5 月 10 日，Worker API 安全審計發現 75 個端點 → 契約測試三層架構設計。 5 月 12 日，自動優化系統停擺七週 → 正式退役 + 範式轉移到分散式 autoresearch。

每一層制度的出生證明上都有一個事故編號。沒有哪一層是「預先設計好等著用」的。

這讓我想到一個命名。我們叫這套東西 Governance Harness——不是 governance cage（籠子），是 harness（安全帶）。安全帶的功能不是限制你的行動，是讓你可以更大膽地跑。governance-lint 攔住 commit 不是為了懲罰粗心，是為了讓你在趕工的時候不用分心記規則。契約測試每天自動跑不是因為不信任，是因為 75 個端點的安全狀態不應該靠人類記憶維護。

升級階梯是固定的：觀察到問題 → 先寫進文件當軟規則 → 觀察 1-2 週 → 如果同類問題重複 N≥3 次 → 升級為自動化。governance-lint 從 CLAUDE.md 裡的一句話走到 pre-commit hook，花了六天。commit-msg hook 的跨專案影響偵測，從衝擊地圖文件走到自動化，花了兩週。速度不是重點，模式是重點：先止血，再根治。觀察夠了才自動化。

考試揭露的盲區

讓我用一個故事收尾。

憲法寫完隔天，我們做了一件可能沒什麼人做過的事：給三個 AI 視窗出了一份治理考試。15 題，分事實題、判斷題、情境題三個層級。

結果是 Code 97 分、Chat 77 分、Cowork 70 分。

最低分的是 Cowork——而 Cowork 在我們的架構裡扮演的是「司法」角色，負責驗證和仲裁。最該懂規則的角色，考最差。

原因很具體：Cowork 的沙盒環境物理上看不到某些檔案的即時狀態，所以涉及精確行數、版本號碼的事實題，它只能靠記憶回答——而記憶會漂移。Chat 的問題更根本：它根本沒有 Read 能力，所有「精確事實」都是二手的。

這個結果直接導致了兩項制度修正：限制 Chat 回答精確事實查詢的權限，以及在 Cowork 的工作流裡強制加入「sandbox 數據不等於 Mac 本機數據」的核實步驟。

治理不是寫完規則就結束的事。它跟你協作的每一天，都在考試。

常見問題

Q: 為什麼人機協作需要治理系統？直接用不就好了？

單一 AI 對話不需要。但當你同時用 Chat 做規劃、Cowork 做偵察、Code 做實作、Codex 做審計，四個視窗各自有記憶、各自會犯錯、各自會產出跟其他視窗矛盾的結論。沒有治理系統，你會花大量時間在「上次做到哪」「這個數字是真的嗎」「誰說了算」這些問題上。治理系統讓你把注意力放在真正重要的判斷上，而不是重複核對。

Q: governance-lint pre-commit hook 具體檢查什麼？

目前啟用兩項檢查：第一，handoff 文件的 frontmatter 必須包含 status 欄位（只接受 Draft/Accepted/Superseded/Deprecated 四值）且內文必須有 Consequences 章節；第二，文章的 pillar 欄位必須在五個合法值內。違規時 commit 會被擋下，必須修正後才能推。這是 229 行的 bash 腳本，掛在 git pre-commit hook 上。

Q: 這套治理系統適用於團隊還是只適用於個人？

目前是為一個人 + 多個 AI 視窗設計的。但底層邏輯——SSoT 原則、交叉驗證義務、事故驅動的制度升級——在小型團隊場景同樣成立。差別在於團隊需要處理人與人之間的權限和信任問題，而這套系統處理的是人與 AI 之間的事實一致性問題。

Q: 事故驅動制度演化的升級階梯是什麼？

觀察到問題 → 先寫進文件當軟規則 → 如果同類問題重複出現 N≥3 次 → 升級為自動化（hook、cron、腳本）。governance-lint 就是這樣從 CLAUDE.md 裡的一行文字變成 pre-commit hook 的。關鍵是不要第一次就過度自動化，先觀察模式再決定。