双宪法、任务文件夹、handoff：多 AI 协作的最低秩序

多 AI 协作治理手记

一个人同时用三个以上 AI 做长期工程，半年之后我才看清——最容易丢的不是能力，是秩序。

能力并不缺。Claude 能讨论、能写长文、能拆架构；Codex 能跑脚本、能改测试、能搞 CI；Kimi 能啃中文长文档；GPT 和 Gemini 也都各有一手。摆在一起，理论上是个小型团队。每一个单独看都顶半个工程师，三个并行听起来等于一个半。

但真正用起来你会发现，团队感是假的。每个 AI 都是孤岛，会话之间没有记忆，跨工具之间更没有共识。下一次进来的那个 AI，永远在问同一组问题：上一个 AI 改了什么？为什么改？我能继续吗？还是要从头再来？这套配置真的稳定，还是上一次只是侥幸跑通？

这些问题，没人回答得了，只能我自己记。记不住的那一部分，就直接变成返工。跑到第十次你会发现，你不是在用 AI，你是在做 AI 之间的人肉中转站——一边复制上下文，一边解释昨天发生过什么，一边核对它们没有彼此踩到对方的脚。

我后来不再想"怎么让 AI 更聪明"，而是反过来想：怎么用最少的几件东西，把这种孤岛之间的接力兜住。不是搞一套华丽的治理框架，是搞最少够用的那种秩序——少一件就会塌，多一件就开始拖。

每个 AI 都是孤岛，痛点是真的

我一度以为只是工具差异，磨合几次就好。磨了几个月才发现，这是结构性的——不是哪个产品做得不够好，是这个范式本身就这样。

每个 AI 的会话是独立的。今天和 Claude 谈完一个方案，明天打开 Codex，它什么都不知道。我得手动复制一段背景，再贴一段上一轮的结论，再说明现在要做什么。十次里有八次，我贴的背景是不全的——不是我懒，是我记不清上一次到底走到了哪一步。回头去翻聊天记录又特别低效，因为聊天里夹了一大堆探索性的废话，真正的决策只占其中一小段。

更麻烦的是跨工具之间。Claude 改过的文件，Codex 不知道改过；Codex 跑过的脚本，Kimi 不知道有结果；Kimi 整理过的中文资料，Claude 不知道存在。三个 AI 各自有一份"它眼中的项目"，三份合不到一起。你问任何一个：现在项目处于什么状态？它都会给你一个非常自信的答案——而且三个答案互相打架。

最痛的一次，我让 Codex 改一段配置，它跑得很顺。第二天我让 Claude 看同一个模块，它告诉我"建议你改成 X"——而 X 正好是 Codex 昨天改掉的那种写法。两个 AI 都没错，错在中间没有任何东西能让它们彼此知道。如果我没注意，听了 Claude 的建议改回去，过两天 Codex 又会被某个测试踩中、再改一遍——一个事实上的死循环，每一轮都在"修复"上一轮的"修复"。

还有一类痛感更隐蔽：信息没冲突，但是断片。Codex 跑测试通过了，结论留在它那一次会话里；下一次我用 Claude 讨论下一步，它根本不知道测试通过过——它会很谨慎地建议"先跑一次测试确认"。这种谨慎本身没错，但对我来说就是无效来回。AI 在反复确认我早就确认过的事，因为它没有任何渠道知道我确认过。

这种事跑几次就会让人想放弃并行，回到单 AI。但回去的代价更大——等于放弃 70% 的算力，也放弃了"不同 AI 各擅长不同事"的那个核心好处。所以问题从来不是"要不要并行"，而是"并行的最低秩序在哪"。

三件事兜住整个协作链

半年下来我留下的是三件东西。不是因为我设计得多精，是因为再减就真的撑不住，再加又会变成行政开销。

第一件是双宪法。两份顶层规则文件，一份管行为，一份管知识。行为那份写：任务怎么走、文件怎么改、什么动作要先停下来问、CHANGE 怎么记录、哪些是红线、哪些是默认放手做。知识那份写：东西怎么入库、命名规范是什么、内容血缘怎么标、Feed 分几层、什么材料属于哪一层。

我试过合成一份，两个月之后放弃。行为规则和知识规则性质完全不同：行为是"该不该做"，是一种判断；知识是"放在哪、叫什么名字"，是一种规约。判断和规约硬塞一起，AI 读的时候会两个都不准——要么把行为规则当 metadata 处理，把"先停下来问"读成"在文件元数据里加一行 status: pending"；要么把命名规范当道德约束执行，看到一个不规范的命名就拒绝继续，哪怕这只是过程文件。分成两份反而都清楚了：它读行为那份时，知道自己在做判断；读知识那份时，知道自己在做归档。

这里还有一个朴素的好处：两份分开，每份都可以独立演进。行为规则我大概一两个月动一次，任务模式会变；知识规则更稳，三五个月动一次就够，命名和分层一旦定下来就不该乱改。合在一份的时候，每次想动其中一半都得通盘考虑，结果就是两边都不敢动。

第二件是任务文件夹。每个跨 AI 的任务，在共享文件系统里有一个独立目录。目录里固定四件：

• README——这个任务到底要干什么，验收是什么，依赖什么。一页纸，不超过。
• notes.md——追加式日志。每个 AI 干完一件事就在末尾追加一条：做了什么、结论是什么、下一步给谁、关键文件在哪。不覆盖，只追加。
• handoff.md——交接给下一个 AI 的时候写。当前状态、已经做了什么、还没做什么、接手要注意什么、关键文件路径。
• outputs/——这次任务真正产出的东西。脚本、报告、数据、改过的代码片段。

第三件是handoff（交接 / 接手动作）本身。它是任务文件夹里那一份 handoff.md 的使用方式：前一个 AI 干完一段，写一份 handoff 留下来；下一个 AI 接手时，按 README → notes 最新几条 → handoff 的顺序读，五分钟进入状态，然后继续干。handoff 不是日志，是路标——它告诉接手者"你现在站在这里，下一步该往那边走"。

这三件加起来很轻——一份目录模板、一种追加格式、一个交接动作。但顺序不能乱：宪法定边界，任务文件夹定上下文，handoff 定接力。少哪一件，链就断在哪一段。没有宪法，AI 不知道哪些事它不该自己决定；没有任务文件夹，AI 不知道项目走到哪一步；没有 handoff，AI 知道项目在哪、却不知道自己该从哪一步接。

为什么是这三件，不是别的

刚搭这套的时候我加过很多东西。状态板、看板、每日总结、跨 AI 通知、版本号 manifest，全试过。三个月之后大部分都被我删了。

留下的标准很简单：减掉它之后，秩序会不会塌。会塌的留，不会塌的删。

没有双宪法会塌。AI 不知道边界的时候，它会替你做决定——而且做得很自信。它会越界写入"它觉得应该改"的文件，会把"它觉得该归档"的东西移走，会在没有授权的情况下重命名一批资料。每一次都不是恶意，每一次都是它在用自己的判断填补空白。空白不填，AI 一定会自己填，这是它的本能。双宪法填的就是这个空白：哪些动作要先停，哪些资料要按什么命名，哪些目录是不能动的根。它不需要写得多详细，但必须存在——存在本身就是一个信号，告诉 AI "在这条线之外，你应该问我而不是自己决定"。

没有任务文件夹也会塌。上下文散在聊天里，每一次切换工具都是一次记忆重启。我曾以为能记住"上一轮跑到哪一步"，但跑十个任务并行的时候根本记不住。任务文件夹的作用，是把上下文从我脑子里取出来，放到磁盘上。这样下一个 AI（或者一周后的我自己）打开目录，就能从一个确定的位置开始，而不是从我的记忆碎片开始。最有意思的是：它解决的其实不是 AI 的记忆问题，是我的记忆问题。AI 的记忆有没有都不重要，反正它每次都是冷启动；但我的记忆是有限的，需要有一个地方存放它。

没有 handoff 会塌得最快。任务文件夹里有 README、有 notes，理论上下一个 AI 也能看明白——但实际上看不明白。notes 是追加式的，三十条之后没人会从头看；README 写的是任务定义，不是现状。两者都不告诉你"此刻你应该做的下一件事是什么"。handoff 就是专门解决这个问题的。它取代了那个"我在两个聊天窗口之间手动复制粘贴上下文"的笨动作——而且取代得很彻底，因为它写下来的瞬间就持久化了，不像聊天那种一关窗口就消失的状态。

三件东西分别管三件不同的事：边界、上下文、接力。它们的关系不是冗余，是分工。这也是为什么我把别的都删了——别的要么在重复这三件里的某一件，要么在解决一个其实不存在的问题。比如我以前搞过一个跨 AI 通知系统，让一个 AI 干完就给另一个 AI 发消息。听起来很合理，但实际上没用：下一个 AI 不会因为收到通知就更聪明，它还是要去读 README 和 handoff 才能进入状态。通知反而多了一个失败点。

再比如版本号 manifest。我曾经想给每个任务标版本号，方便回滚。后来发现根本不需要——任务文件夹里的 notes 是追加式的，本身就是带时间戳的演化记录；要回滚就回滚到某一条 notes 描述的状态，不需要单独维护版本号。多一层 manifest 反而要多维护一份东西。

所以这三件之所以是"最少"，不是我主观觉得少，是我把所有我加过又删过的东西摆在一起，剩下来唯一不可压缩的就是这三件。任何一件去掉，都有一类问题没人接；任何一件再加，都有更轻的方案能覆盖。

规则在收敛，不是在扩张

"双宪法"听起来容易越长越厚。我一度也担心。但实际走下来，方向是反的。

最早那一版写得最满，效果却最差。我列了厚厚一沓——什么场景该问、什么场景该做、每种文件该放哪里、每种动作该怎么记录，连"修改注释也算修改文件"都写了进去。AI 读完反而更谨慎，什么都来问一遍：要改一行注释问、要新建一个临时文件也问、要删掉一个明显废弃的占位文件还问。规则太密的时候，它们会变成形式主义——AI 不是在按规则判断，是在用"问一下"来回避所有可能踩线的事。

后来我开始反向修。每次出问题，先问"缺规则，还是规则太多淹没了关键那条"。十次里有八次是后者。规则就一轮一轮被压缩：从"列举所有该做的事"压到"列出几条不能动的红线 + 风险分层 + 几种任务模式"。中间还加过一版"风险分级 L0-L3"，挺漂亮，但实操时 AI 经常分不清当前动作算哪一级，结果还是来问。下一版我干脆把分级砍掉，只保留"绝对不能做"和"做之前打个招呼"两类，剩下全是默认放手。AI 的判断准确率立刻上去了。最近这一版只剩四条边界加一张三栏动作表。

这个收敛过程，倒不是变懒，是看清了一件事：宪法不是用来规定一切，而是用来兜底。日常 90% 的判断 AI 自己能做对，宪法管的是另外 10% 它会出错的地方。把规则写得太满，反而会把 90% 的部分也僵化掉——本来 AI 能直接做的事，现在它要先停下来对照规则；本来不需要确认的小事，现在它要先来问一句。这不是更安全，是更慢，而且更慢的代价最后还是我承担。

现在我的 Inbox 里还压着十二份修宪提案——有的提议加，有的提议减，有的提议把某条边界改成动作清单，有的提议引入一个新的中间层。我没急着裁决。它们摆在那里说明这套秩序还活着，被自己质疑、被自己改写、被自己推翻。一份不再被质疑的宪法，反而是危险的——那种宪法不是因为完美才不被质疑，是因为没人再认真读它了。

半年跑下来的几条判断

这三件东西真正用了六个月，我有几条比较稳的判断：

双宪法工作得很好。行为和知识分开是对的，没有一次让我后悔。AI 在做行为决策时只读那一份，在做归档命名时只读另一份，两份互不打扰，准确率比以前合在一起的时候高得多。这件事最反直觉的地方：分两份，反而比合一份省脑子。大概是因为——同一份文档里夹杂两种性质完全不同的规则时，AI 的注意力会被稀释：它读"该不该做"时还在想"放在哪一层"，两件事都做不准。分开就各自独立加载，简单粗暴但有效。

任务文件夹是命脉。90% 的协作问题都在这一层解决。只要这一层做到位——README 清楚、notes 持续追加、outputs 都在目录里——下一个 AI 接手基本不出错。这一层一旦塌掉，宪法再好也救不回来。AI 没有上下文，光有规则没法工作。规则告诉 AI "不该做什么"，但不告诉它"现在该做什么"——"现在该做什么"只能从上下文里读出来。

handoff 是最常被偷懒的那一件。每次干完一段，我都想直接关掉，下次自己再接着干。脑子里的声音是"反正能记住"——结果记不住。等到下次想接的时候，我得花二十分钟在 notes 和 outputs 里翻，才能拼回上一次的状态。这种"翻回去"的成本，永远比"当时多写五分钟 handoff"要大。我知道这个道理，但还是经常偷懒，这件事我自己也在反复纠正。最近我开始用一个小约定——任务暂停之前必须先写完 handoff 才能关窗口，否则下次自己一定会后悔。这个约定有效，但维持它本身又是一件需要自律的事。

这套秩序有适用范围。它适合"一个人 + 三个以上 AI + 长期工程"这种组合。如果你只用一个 AI 做短期任务，这套是冗余的——上下文塞在一次会话里就够了，没必要搞文件夹。如果你是一个团队在多 AI 协作，这套又太轻，需要加权限、加 review、加正式归档，因为有人和人的协作维度，光靠 markdown 不够。它卡在中间那个特别尴尬的位置——比个人手记重，比团队治理轻。我是为了自己卡在这个位置，才搭的。它不一定适合所有人，但对处于同一种结构里的人，应该有参考价值。

结尾：还在被自己质疑

我不想把这篇写成"我设计了一套完美的多 AI 协作秩序"。它不完美。十二份提案还压在 Inbox 里没裁；handoff 我自己经常偷懒不写；双宪法之间偶尔还是会有边界不清的地方需要现场判断；规则还在向"最小边界"的方向继续收敛——也就是说，现在这一版还会再被推翻一次。

但有一件事我比半年前确定多了：多 AI 协作的核心问题不在 AI 本身，在中间的那一层秩序。这一层做得对，三个 AI 像团队；这一层做得乱，三个 AI 比一个 AI 还累。

这一层不需要复杂的东西兜住。一份管行为的宪法、一份管知识的宪法、一个任务文件夹的目录约定、一次老老实实写完的 handoff——就是这些。