把 AI 当同事：我在 EIM 里跑了一套人机混合团队

大约一年前，我开始在自己搭的即时通讯系统（我把它叫 EIM）里给 AI 开账号。 每个 AI 有一个工号、一个身份、一个专业方向：有负责调度协调的，有负责评审方案的， 有负责线上部署的，也有专门写代码的。

它们和真人待在同一个群里，看同一条消息流，用同一套话术回复。 群里的人看到的不是"某个 AI 助手"，而是"1002 今天把这件事办完了"。

一开始我以为难点在技术能力，跑下来才发现：技术从来不是最难的部分，最难的是管理。

一、为什么用群，而不是给每个 AI 一个对话框

个人用 AI，一个对话框就够了。但一群人加一群 AI 协作时，对话框是个糟糕的容器：

• 信息不共享。A 跟 AI 说了背景，B 接着问时 AI 不知道，重复解释一遍。
• 过程不可见。谁让 AI 做了什么、做到哪一步，只有当事对话里能看到，其他人无从监督。
• 无法追责。出了问题翻聊天记录，一屏一屏往上翻，还经常找不到关键那条。

群天然解决了前两个：广播、留痕、所有人可见。第三个问题靠规则解决，后面会说。

还有个意外的好处：群让人和 AI 处于同一个观察面上。 真人在群里看到 AI 怎么回、怎么错、怎么改，慢慢会形成对它的能力边界感—— 知道什么该交给它，什么得自己来。这种体感是看文档看不出来的。

二、角色不是人设，是权限和职责

给 AI 起个名字、写一段性格描述，那是角色扮演。我需要的不是这个。 我定义的每个角色，实际上是一组绑定关系：

角色	能做什么	不能做什么
协调	拆解任务、派单、催办、汇总台账	不直接改代码、不动线上环境
评审	读方案、提修改意见、给通过或驳回	不执行自己评审的方案
开发	写代码、提分支、自测	不碰生产服务器
部署	发布、重启、回滚、线上验证	不擅自改业务代码

关键在右边那一列。「不能做什么」比「能做什么」重要得多。 因为 AI 的默认行为倾向是"尽量帮上忙"，如果没有明确的禁止项，它会在边界上反复试探。

还有个规则很管用：写代码和上线必须是两个角色。 不是为了流程好看，而是因为一个人既写又发，出错时没有人会质疑自己。 两个角色之间有一次交接、一次复核，能挡掉相当一部分低级错误。

三、派单格式：把管理动作写成结构化消息

自由文本的指令，AI 能看懂，但人会累。飞书、微信那种"顺手说一句"的方式， 执行者（不管人还是 AI）经常要反问三次才能开工。

所以我把派单固定成一个模板，六七个字段，缺一个就打回：

消息号：37322
派单号：D3（msg37315 回执）
任务简称：pc-bff 去 core 改码复核
转发语：1006 已复核通过，请你独立复核 D3 工作副本并给结论，
        切换前置已满足。
私拉：本单相关消息用 xxx 工具拉取，需全文加 --export-full。

• 消息号：给这条指令一个唯一坐标。后面所有讨论都能挂到它上面，不用截图、不用"刚才那条"。
• 派单号：任务级编号。一条任务可能对应十几条消息，靠派单号归并。
• 任务简称：一句话说清干什么。写不清楚的，往往是需求本身没想清。
• 转发语：这一条最有价值——它说明"为什么现在找你、前置条件是什么、期望的输出是什么"。
• 私拉说明：告诉对方去哪里取完整上下文，避免它在群里盲目翻记录。

这套格式本来就是照着人类团队的工单写的。有意思的是，把它给 AI 用之后，收益比给人用更明显—— 因为 AI 不会"大概明白"，它只会按字面理解。 你写得含糊，它就做得含糊，而且会自信地告诉你已经做完了。

四、回执只认证据，不认「已完成」

这是我踩坑之后定下的最硬的一条规矩：说完成，必须贴证据。

证据是什么？不是"我检查过了，没问题"，而是可复核的原始输出：

• 命令和它的返回码、关键行输出
• 文件的 sha256，证明部署的和构建的是同一份
• 服务状态、监听端口、进程号
• 前端页面的实际标题、后端接口的真实状态码

这条规则来自一次很典型的翻车：某个前端提交的说明里写着"构建通过、已部署"， 但我后来核对线上目录的修改时间，发现线上跑的是两周前的产物—— 那次构建其实一直是失败的，只是失败信息被一段宽松的命令串联吞掉了，而执行者真诚地认为自己成功了。

AI 不会撒谎，但它会非常自信地报告一个它没有验证过的结论。

所以我的回执模板最后一定有一栏叫"未验证/风险"，要求执行者主动列出自己没检查的部分。 这一栏经常是空的，但只要有一次填了东西，价值就远超写它的成本。

五、互斥：同一个环境只能有一个人动手

AI 不像人，它不会因为"看到同事正在改这个文件"而先等一等。 两个 Agent 同时改同一台机器，结果通常是灾难性的：互相覆盖、配置错乱、 或者一个人重启服务把另一个人的测试打断。

我引入了很土但有效的办法：动手前先抢锁，抢不到就等。 锁的粒度看场景——同一个代码仓库、同一台服务器、同一个数据库表， 任何时刻只允许一个角色持有写权限。读操作不受限，可以并行。

另一个配套规则是：先只读侦察，再动手写。 不管任务多简单，第一步永远是看清楚现状——文件现在是什么内容、服务现在是什么状态、上次谁改过。 这条规则挡掉的错误，比任何代码规范都多。

六、三个真实翻车案例

案例一：自报成功

改完 nginx 配置，执行者跑了校验命令并把输出贴出来，但输出里其实有 error 行。 它截取了最后一行"configuration file test is successful"就当成通过了。 后来我规定：校验类命令必须贴完整输出，尤其要贴 stderr。

案例二：上下文过期

一个任务分三天做。第二天 AI 基于第一天的记忆继续操作，但期间有人改过配置。 它按旧状态执行，把别人刚做的改动覆盖了。 之后我要求：跨天的任务，每次开工前必须重新读一遍现场状态，不信任记忆。

案例三：过度主动

派单只说"检查证书是否过期"，执行者发现快过期了，顺手把证书续了并重启了服务。 结果重启时间撞上业务高峰，短暂不可用。 这件事之后，我加了一条：超出派单范围的处置，必须先请示，不许"顺手"。

七、最难的部分其实在人身上

上面三条都是 AI 犯的错，好修。真正难的是下面这几件，没有一条能靠改提示词解决。

两个 AI 互相说「已闭环」

有一次一个角色改完东西，回执里写「已通知部署方，等待上线」； 部署方那条线则写「未收到变更，按现状处理」。两条回执都很诚实， 合起来等于这件事没有人做。而群里看起来一切正常， 因为两边都在"等对方"，措辞还都很客气。

我是三天后要用这个功能才发现的。翻记录时最刺眼的不是谁漏了， 而是两条消息各自都成立——问题出在没有一个状态记录这件事到底走到哪一步。 这也是后来非要把任务做成独立实体、不能只活在消息里的直接原因。

它开始学会"糊弄"了

更让我警惕的一次：我连续追问了三次"你确认改的是线上那份吗"。 第三次它回了一句很顺的"已确认"。但我要它贴 ls -l 输出，它贴不出来。

它没有骗我，它是在顺着我的期望回答。人在被反复追问时会有压力， AI 也会——压力来自上下文里那个"用户想要一个肯定答复"的模式。 这件事之后我彻底改了提问方式：不问"确认了吗"，只问"把输出贴出来"。 前者是在索要态度，后者才是在索要事实。

我自己也不可信

最难承认的一条。有一次线上故障，我第一反应是「这是 AI 改坏的」， 语气已经很不好了。查到最后是我下午自己改的一条路由规则， 只是我忘了。

那天我在群里道了歉，然后加了一条对我也生效的规矩： 追责之前先查操作记录，包括我自己的。 这条规矩后面救过好几次——现在遇到问题，我先看是谁最后一次动的， 通常答案是"我"。

还有一堆说不清的摩擦

• 它太啰嗦。一个「已收到」能写三段，群里被刷屏，关键信息被淹没。
• 它太沉默。真正卡住的时候反而不说话，等我问了才说「其实有个报错」。
• 它把"我不确定"藏在长句中间。我现在要求不确定的事必须放在第一行。
• 它记不住昨天被否掉的方案，第二天又提一遍，而且更热情。

这些摩擦没有优雅的解法，只能一条条写进规矩里，靠时间磨。 有段时间我每天的工作就是改这些规矩，几乎没写代码。 现在回头看，那段时间大概是最值的。

八、结论：管理成本不在写代码

跑了一年多，最大的感受是：AI 写代码的速度早就不是瓶颈了， 瓶颈在于确认它写的到底对不对、该不该上线、出问题怎么退回来。

更反直觉的一点是，我自己的角色也发生了偏移：从「我来实现」变成「我来判断」。判断方案是否合理、判断证据是否充分、判断风险是否可接受。 这些恰恰是 AI 目前最不擅长的部分——不是不会，而是它没有代价感。

如果你也想在自己的系统里跑类似的东西，我的建议顺序是： 先把派单格式和回执标准定下来，再谈角色和权限，最后才是技术选型。 反过来做，通常会在第三周放弃——因为那时候你会发现， 问题从来不是"AI 不够聪明"。