几个 AI 一起干活

先看出事的那一刻

E2E Review 这个网站，是两个 AI 轮流做出来的。7 月 28 日到 8 月 2 日，它的每个提交末尾都签着名，有的签 Claude，有的签 Codex：7 月 28 日一天里换了两次手，7 月 30 日和 8 月 2 日又各换了一次。

两个 AI 共用一份设计规范 docs/DESIGN.md。从 7 月 28 日建立到 8 月 2 日，它一共经手 16 次提交：Claude 5 次，Codex 11 次。7 月 30 日凌晨，Claude 把它定为全站唯一的设计依据；当天上午，接手的 Codex 把它重写成了自己的一套，其中一条是：

全站颜色只使用以下五个根令牌。组件不得另起 --red、--teal、--accent 或品牌色体系。

二十分钟后，Codex 按新规范换掉了全站的样式。两天前 Claude 画的那批示意图，颜色大多靠 10 个变量，比如 var(--teal)、var(--red)、var(--amber)；这一次删掉了其中 7 个。新规范讲配图的那一节，写了对齐、图注和图该表达什么，没提这批图在用哪些颜色。

8 月 2 日上午，Codex 又用一个多小时交了 9 个提交，把整站换成另一套风格，剩下的颜色定义也在这次改版里删光了。随后站长换 Claude 来审查，打开章节页一看：示意图里的车辆和标签变成了黑块。

第 15 课从"隐形依赖"讲过这件事的技术原因。这节课换个角度看：每一步都是某个 AI 照着它当时手里的信息做的，单看都没错。错在交接：图依赖哪些颜色，只体现在画图那次写的代码里，规范里没有；后来改规范、删样式的几次提交，说明里也都没提到这批图。

同一次审查还查出另外三处问题：一个写错的章节地址会让整站白屏，31 个术语图解丢了样式，多出一整层营销装饰。四处都在上线前修好了，前后不到一个小时。

这节课要回答的是：几个 AI 一起做同一个项目，它们之间靠什么交接？怎么分工，才不会互相拆台？

装备几个词

为什么要懂

它们之间，只共享文件

每个 AI 知道的，只有它自己的上下文窗口里的东西：这场对话，加上它读过的文件。换一个工具、开一个新窗口，就是换了一个没听过前情的同事。

几个 AI 之间真正共享的，只有项目里的文件：代码、文档、提交记录。所以要让下一个 AI 知道的事，都得落在文件里。E2E 这次事后补了两样：

1. 依赖：把"图形组件依赖哪些颜色变量"写进设计规范，删样式之前先对照这份清单。
2. 禁用清单：把这次删掉的营销装饰列成清单写进规范，防止下一个 AI 再加回来。

共享文件本身也要有人管。这份设计规范被定为唯一依据，可接手的 AI 照样可以把它整个重写。规则文件和规范改了什么、为什么改，要在交接时写明，并且由你点头；Codex 读 AGENTS.md、Claude Code 读 CLAUDE.md，两个一起用时，让其中一份引用另一份，别维护两份内容。

派活：一份说明进去，一段汇报出来

不管是你开一个新窗口、换一个工具，还是 Agent 自己派出子 Agent，形状都一样：干活的一方只看得到你给的说明和项目里的文件，你也只看得到它交回的汇报。中间怎么做的，你看不到。

所以说明要写全：

这个网站 9 月 28 日就派过一次活：检查入门课时，发现全站有些加粗没渲染出来，于是另开一个会话去修，说明写了前四项，"交回"只写了一半：渲染层修不了先问站长，合并前给站长看。其中"/e2e 的正文是快照，不手改"这条边界起了作用：修到最后，剩下一处问题正好在快照里，那个会话没有动它，而是交回来问站长；后来回到上游仓库改了一个字符，再重新导出，才算真正修好。

但这份说明也有漏洞，下面的找茬就用它。

同时干活：先划地盘，再约好怎么合

这个网站的 Vibe Coding 和自动驾驶两个板块，是两个会话同时在改的。开工前，方案里先写好了几条规矩：

1. 文件归属：各管各的页面、内容、组件和数据文件。
2. 共用文件少碰：根目录说明、内容集合配置、全局样式、布局、构建配置、依赖清单这些，尽量不碰；非改不可时单独一个小提交，只改自己那一节。
3. 各用各的分支：推送后各看各的预览地址。
4. 合并前先对齐：拉取最新的 main，把自己的提交变基到它后面（相当于把自己的改动挪到别人最新的改动之后，再重放一遍），重跑构建和死链检查，再合并。

从方案写好到写这节课，main 上进了 41 个提交，没有一个同时改动两边的文件，历史一直是一条直线。自动驾驶那边还多做了一步：把自己在共用配置里的那一节，搬进了自己的目录，之后再改就不用碰共用文件了。

还有一条是事后补上的：改了大家共用的东西，要告诉别人。修加粗的会话换掉了全站的 Markdown 渲染方式，依赖跟着变了。它在汇报里写明：拉取之后要先按锁文件重装一次依赖，否则本地预览会报错。后来派给自动驾驶会话的说明里，就多了这一句。

换一个 AI 来审

8 月 2 日那四处问题，是换一个 AI 审查时查出来的。审查的 AI 没参与改版，不知道改版时的来龙去脉，反而更容易看见结果本身。

前提是它真的去看了结果：那次改版的状态报告里，"Mintlify 视觉检查"一栏写着"通过"，审查的 AI 没有停在这一栏上，而是打开章节页去看。让另一个 AI 审查时，给它和作者同样的规则文件和验收标准，让它看页面、跑检查，而不是读汇报。

找茬

 1  # 派给修加粗会话的任务说明（2026-09-28，节选，略有简化）
 2  问题：正文里的加粗 **…** 在部分位置没有渲染，页面上直接露出两个星号。
 3  复现：构建后，对 dist 下所有 .html 去掉标签，统计 \*\*[^*\n]{1,40}\*\* 出现的次数。
 4  根因（先核实再动手）：收尾的 ** 前面是中文标点、后面紧跟汉字时，不算分界，于是闭合不了。
 5  要求：
 6  1. 优先在渲染层统一修，能统一修就不要逐篇改内容。
 7  2. /e2e 的正文是从上游仓库导出的快照，不手改；要改就回上游改，再重新导出。
 8  3. 博客文章的路径和格式不要动，发布脚本依赖它。
 9  4. 渲染层修不了，再讨论逐篇改写，先问站长。
10  验证：构建通过；上面的扫描结果为 0；站内死链为 0；抽查几页，确认加粗确实显示成粗体，也没有把正常的星号误渲染成加粗。
11  在新分支上做，推送后看预览；站长同意后再合 main。

快测

判断时刻

带走