上周三凌晨，我的晨间简报链路已经连续三天没有生成。
没有报错，没有弹窗，日志里一片祥和。我是自己某天早上没收到推送，才发现流程早就停了。修好之后我去查原因：一个共享的命令行工具卡住了，整条链路静默地坏掉，谁都没发现。
我当时第一反应是查那个工具。后来才想明白，工具从来不是问题——我给自己接了十几个 AI，却没有一个角色负责"确认昨天那件事真的做完了"。
这就是"用 AI"和"带 AI"的分界线。
用 AI，是一个人对着一件乐器
大多数人对 AI 的想象，还停留在"问答"。
打开窗口，输入问题，拿到答案，关掉窗口。下一次任务，再开一个新窗口，AI 对上一次的事一无所知，你也懒得告诉它。用完就扔，扔了再用。
这套模式没有错，它只是有一个隐藏的假设：任务永远是一次性的，你永远只用一个 AI。
一旦这个假设不成立——你手里同时挂着写代码的、整理知识库的、盯着日报和自动化的好几个 AI——事情立刻变了味。
有的事被做了两遍。有的上下文只活在某一个会话里，换个窗口就死了。有的文件谁都能改，于是谁都可能改乱。有的任务本该先有人拍板，却被直接推进了执行。
表面看是协作问题。往底下看，是没有人在"带"。
带 AI，是把它们当团队管
人类团队里，一旦项目复杂到一定程度，会自然长出项目负责人、交接文档、权限边界、日报。这些流程都有成本，但没有它们，每个人都可能把自己那一块做对，整个项目却一起失控。
多 AI 协作，也一样。
我现在管自己那支 AI 舰队，靠的是三件事。
第一，单点入口。 所有长期任务先落一个地方，判断这件事现在该往哪走：是先想清楚，还是直接做；需要读哪些材料；结果最后写到哪一层。没有这道入口，几个 AI 其实是在抢同一个驾驶位。
第二，写入分层。 草稿层随便写，共享层以追加为主，核心产物默认只读、要提案才能改。多 AI 协作最容易出大事故的地方，从来不是内容生成，而是共享写入——某个执行型 AI"顺手帮你优化一下"，碰到了它根本不该碰的主文件。
第三，交接文档。 单个 AI 靠会话记忆还能硬撑，多个 AI 一进场，上下文立刻碎成好几瓣：背景在 A 那儿，执行记录在 B 那儿，失败原因只存在于 C 的某次对话里。没有交接文档，所谓协作，只是几个会话轮流失忆。一份可用的交接单不用长，但至少要写清楚：这次只做什么、接手前必须看什么、能改哪些东西、用什么判断已经做完、完成后回写给谁。
这三件事背后是同一句话：多一个 AI，不等于多一份产能，没有控制层，只会多一份混乱。
分工之外，还有一道门禁
带团队不只是分工，还包括谁能"发出去"。
我的舰队里有专门写内容的 agent，也有专门审内容的 agent——分工写作和把关这两件事，故意交给不同的角色，谁也不能自己写完自己签发。这道门禁挡住的不是错别字，是那种"看起来已经很完整、其实没人真正为它负责"的稿子。
它也没能挡住所有事故。就在不久前，两个各自负责不同渠道的 agent，为同一个选题各写了一版稿子，彼此完全不知道对方的存在——直到我对着两份几乎同源却各自往前走了一段的稿子，才发现协作在哪个环节断了线。这件事后来变成了这个博客的第一篇"走火"记录。带团队和带 AI 一样，事故不是意外，是没设好门禁的必然结果。
这就是这间博客要写的东西
野火接下来会长期写两条线。
走火，编号连载，记录舰队真实翻车的事故——现象、根因、修正、一条能带走的带队原则。教程可以编，事故编不了，这是这个栏目唯一的信用来源。
守则，把走火里攒下来的原则沉淀成一页页可复用的东西，不是空谈方法论，是从真实事故里逼出来的边界。
思考，写 AI 带不走的那部分——判断力、品味、"为什么这么干"——这些东西外包不出去，因为责任本来就不是平均分配的。
用 AI，是随用随扔的工具关系。带 AI，是要负责、会出事、需要复盘的团队关系。
如果你也挂着不止一个 AI 在跑，先别急着再接一个。
先想清楚，谁在带这支队伍。