# Governance Harness：一個人和四個 AI 視窗的治理工程實踐 > 一個非全職工程師如何與四個 AI 視窗建立治理系統：從協作憲法五條、governance-lint pre-commit hook、75 端點契約測試到 12,946 檔案復原演練，記錄每一層制度如何從真實事故中長出來。 - Author: Paul Kuo（郭曜郎） - Date: 2026-05-28 - Pillar: 智能與秩序 / Intelligence & Order - Tags: AI 治理, 人機協作, governance engineering, pre-commit hook, 韌性架構, 分散式協作, Claude - Canonical: https://paulkuo.tw/articles/governance-harness-engineering/ - Site index for LLMs: https://paulkuo.tw/llms.txt --- > **TL;DR** — 一個人同時跟四個 AI 視窗協作，自律在第一次趕 commit 時就失靈了。這篇記錄我如何從真實事故中演化出一套治理系統：憲法五條、governance-lint pre-commit hook、75 端點契約測試、12,946 檔案復原演練：每一層制度都有對應的事故編號。
▶ 聽摘要
AI 合成語音・作者本人聲線克隆
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 官方文件](https://docs.anthropic.com/en/docs/agents-and-tools/claude-code/skills)，上面明白寫著「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 必須能重現。這跟[三權分立的憲政設計](https://en.wikipedia.org/wiki/Separation_of_powers)邏輯一致：行政、立法、司法之間的 check 不是可選的禮貌，是結構性的義務。這篇是「[智能與秩序](/topics/ai/)」系列的一部分，探討的就是這種秩序如何在人機協作中被重新建構。 **第四條，記憶層次。** 一筆事實只在一個負責層存放，禁止跨層複製。同一層內，每筆 memory 必須原子化：一個檔案講一件事。這條是針對 memory 重複事件立的，也是後來整個 memory 系統重構的依據。 **第五條，記憶擴充。** 要接新的記憶載體（比如 Mem0、Letta、MCP memory server），必須走正式的 [ADR（Architecture Decision Record）](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions)流程。不能因為某天覺得「這個工具好用」就直接接上去。 拍板那天，我跟 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 全部停擺。這個事件的完整工程紀錄在[另一篇文章](/articles/resilience-engineering-after-github-suspend/)裡，這裡只講跟治理系統相關的部分。 壓力測試揭露了兩件事。 第一件：治理系統的 SSoT 原則（第一條）救了命。因為所有規則、文件、memory 都在本地 git 裡，GitHub 斷了只是少了一個 remote，不是少了事實來源。我們在 48 小時內切到 Codeberg + GitLab 雙遠端，工作流完全沒降級。如果 SSoT 當時放在 GitHub Issues 或任何雲端服務裡，這個故事的結局會完全不同。 第二件：危機加速了制度建設。在帳號被 suspend 到恢復的這段期間，我們做了 12,946 檔案的復原演練（從加密備份解壓 + 驗證），寫了[五層韌性架構](/articles/resilience-engineering-after-github-suspend/)，上線了 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](/articles/autoresearch-degenesis-personal-ip/)。 每一層制度的出生證明上都有一個事故編號。沒有哪一層是「預先設計好等著用」的。 這讓我想到一個命名。我們叫這套東西 **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 的。關鍵是不要第一次就過度自動化，先觀察模式再決定。