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 的。关键是不要第一次就过度自动化，先观察模式再决定。
💬 留言讨论
加载中...