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 不是可選的禮貌，是結構性的義務。這篇是「AI 與人類秩序」系列的一部分，探討的就是這種秩序如何在人機協作中被重新建構。

第四條，記憶層次。 一筆事實只在一個負責層存放，禁止跨層複製。同一層內，每筆 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 的。關鍵是不要第一次就過度自動化，先觀察模式再決定。