让两个 AI 搭伙干活：怎么立规矩、怎么防埋雷

一句话摘要：AI 是好员工，但你得先当好管理者。这篇文章讲我怎么用一份 md 文档，给两个 AI 立好规矩、划好分工、防住”顺手改坏”的雷。

今天被老板说了一顿：没做好管理者，不敢要求下属。

晚上回头想，还挺巧——我白天刚干完一件事：给两个 AI 立规矩。人难管，因为规矩说不出口；AI 好管，因为规矩可以白纸黑字写下来。而这一天的实战让我确认了一件事：管 AI 的那套东西，本质上就是管理者该干而没干的事。

一颗真实的雷

先讲事故。我现在的开发模式是两个 AI 搭伙：一个负责写代码，一个负责审核把关。协作的枢纽是一份 md 格式的交接文档（下文叫”交接书”），记录项目背景、业务规则、接口约定和任务清单，两个 AI 都靠它干活。

某天下午，两个 AI 同时在编辑这份交接书。一个在往里插新章节，另一个在写进度记录。等我去看的时候，进度记录多了两条我没安排的内容——另一个 AI 干完活在”记账”，而我完全不知情。

万幸没互相覆盖。但我后背一凉：这不就是同事天天抱怨的那个坑吗——**AI 改 A 的时候，顺手把 B 也改了。更糟的是改错了，最糟的是错了没人知道。**雷就这么埋下了，等哪天系统出问题，翻半天 git 才发现根源在三个星期前一次”顺手”。

这事给我最大的教训：问题不在 AI，在我。我没立规矩，AI 就只能自由发挥。

两个 AI 搭伙，最容易犯的错是让一个 AI 又写代码又自查。自己查自己等于没查。

我的分法是三权分立：

关键点就一条：编码的 AI 不许自己宣布”完成”。它的产出要过了审核、我点了头，才算数。这一条斩断了”AI 自我感觉良好”这个最大的质量漏洞。

规矩不是口头说说，全部写进交接书，两个 AI 每次开工前必须先读。核心六条：

1. 事实来源定权威等级。 文档之间打架听谁的？我的排序：原型代码 > 数据库表结构 > 接口契约文档 > 交接书本身。冲突时按等级裁决，裁决完必须把错的那份改回来。没有这条，AI 会挑它”喜欢”的那份当依据。

2. 一次只做一件事。 做完、编译通过、自验通过，再做下一件。禁止一口气把整个任务包写完再验——错了不知道错在第几步。

3. 禁止”顺手”。 这是防雷的核心。不顺手优化、不顺手重构、不顺手升级依赖版本、不碰标注”不碰”的模块。发现旁边的代码有问题？可以提，不许改。

4. 改前重读，改后回写。 动文档之前必须重新读全文（防并发编辑），改完立刻在进度账本里记账：谁、什么时间、改了什么、为什么。今天那次险情之后，这条从”建议”升级成了”铁律”。

5. git commit 粒度对齐任务。 一条任务一个 commit，信息格式统一（比如 模块: 任务#N-端点简述）。改坏了回退这一个 commit 重做，不带病前进。commit 粒度就是你的后悔药粒度。

6. 歧义即停。 规则冲突、状态流转拿不准、业务逻辑存疑——停下来问人，不许自行拍板。AI 最危险的不是不会做，是不会做还硬做。

规矩是第一层，但光靠禁令不够，我实际是三层防线：

三层下来，“改 A 顺手改 B”从”常态”变成了”必被发现的小概率事件”。

不是所有事都要问人，那样你会被烦死。我给 AI 画了一张分级表：

可以直接改：错别字和注释、报错信息明确指向的 bug、明显的代码风格问题、在既定规则内的填充实现。

必须先确认：改接口契约（出入参、路径）、改数据库表结构、改业务规则（状态流转、权限）、任何形式的”顺手”——哪怕看起来再合理。

判断标准一句话：**这个改动的影响范围，超出当前任务了吗？**超出了就停，先问。

被老板说完，我晚上整理这套规矩的时候突然反应过来：

我不敢要求下属，本质上是没把要求写下来、说清楚。而我对 AI 敢立这么多规矩，恰恰因为它们写在文档里：边界在哪、听谁的、什么能做什么必须问、干完怎么验收——清清楚楚。

这些不就是管理者该给团队的东西吗？岗位职责、决策权限、汇报机制、验收标准。

所以这篇文章的标题虽然是”让两个 AI 搭伙干活”，但真正想说的是：AI 是练手管理的好对象——它不会闹情绪、随叫随到、立了规矩立刻执行。在 AI 身上把”当管理者”这件事练熟了，回到人身上，那些说不出口的要求，也许就写得出来了。

规矩文档我都替你准备好了，上面六条直接抄。剩下的，就看你敢不敢用了。

同一主题的其他复盘

《双 AI 协作开发，我们三到底如何分工，如何协作》 —— 下一篇，讲规矩立好之后具体怎么干

《特事特办：一个 AI 把紧急任务一口气做完的 2 小时 12 分》 —— 规矩被打破的那一次