# 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/zh-cn/articles/governance-harness-engineering/ - Language: Simplified Chinese (简体中文) - Translation: AI-translated from the zh-Hant (Traditional Chinese) original - Original (zh-Hant): https://paulkuo.tw/articles/governance-harness-engineering.md - 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 不是可选的礼貌，是结构性的义务。这篇是「[智能与秩序](/zh-cn/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 全部停摆。这个事件的完整工程纪录在[另一篇文章](/zh-cn/articles/resilience-engineering-after-github-suspend/)里，这里只讲跟治理系统相关的部分。 压力测试揭露了两件事。 第一件：治理系统的 SSoT 原则（第一条）救了命。因为所有规则、文件、memory 都在本地 git 里，GitHub 断了只是少了一个 remote，不是少了事实来源。我们在 48 小时内切到 Codeberg + GitLab 双远端，工作流完全没降级。如果 SSoT 当时放在 GitHub Issues 或任何云端服务里，这个故事的结局会完全不同。 第二件：危机加速了制度建设。在帐号被 suspend 到恢复的这段期间，我们做了 12,946 文件的复原演练（从加密备份解压 + 验证），写了[五层韧性架构](/zh-cn/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](/zh-cn/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 的。关键是不要第一次就过度自动化，先观察模式再决定。