一个团队怎么和 AI 一起跑 · 总纲
我们四个人是怎么和 AI 一起干活的
谁开工、谁拍板、活怎么派、做完留哪、何时停——四人一套跑道。
一个四人团队，三条业务线，每条线上都有 AI 在开工、出单、验收。这一页不讲哪个模型好，讲我们给它铺了一条什么样的跑道——谁开工、谁拍板、活怎么派、做完留在哪、什么时候停手。
都是跑过的，没跑过的最后一节单说。
一、缺的不是能力，是机制
一个人用 AI，卡的是提示词、上下文、工序——《工作流入门》那一页讲的就是这个：把重复的活写成工序单，AI 才接得住。
一个团队用 AI，卡的是另一层：四个人、几个 AI，谁先动手？它说的算不算？做完的东西放哪？出了错谁喊停？ 这几个问题没答案的时候，每个人手上的 AI 都很好用，合在一起就是一团乱——今天这个改了口径，明天那个照着旧口径又改回去，谁也说不清哪一版是真的。
不是 AI 不好用，是没人给它一条固定的跑道。
跑道就五件事：谁开工、谁拍板、活怎么派、做完留在哪、什么时候停。下面一件一件讲，每件都只讲我们实际在跑的那个版本。
二、判的人不能是做的人
人只有一种角色分工：一个拍板的（我们这里是架构师），其余是成员。成员开单、验收、提问题，不拍口径；拍板始终是人，不是 AI。
AI 分两种，且刻意分开。
- 脑——一个带长期记忆的 AI 工作台。它读整个仓库和每条线的留痕，出任务单，核回执。它不动手改东西。
- 双手——一个 AI 编程助手。它拿到单子照着改，改完把输出贴回来。它不评价自己改得对不对。
为什么非要拆成两个？因为判的人不能是做的人。让同一个 AI 又写又验，它验的是自己写的，每次都会说「已确认」。拆开以后，脑核的是双手的产出，双手跑的是脑写的判据——两边互相不能糊弄。
这条在同一家厂商的两个产品之间也一样成立：分的是角色，不是牌子。
| 人 | 脑 | 双手 | |
|---|---|---|---|
| 做什么 | 拍板、审、合并 | 读全局、出单、核回执 | 照单改、贴输出 |
| 不做什么 | 不亲手改码 | 不动手 | 不自评、不越单 |
| 记什么 | 决定 | 长期记忆＝留痕 | 只记这一单 |
三、先诊断，再动手，然后停下
每个脑都有一句触发词——比如「财务开工」「官网开工」。说这一句，它做的头一件事不是干活，是对齐：
- 先对齐——把本地和远端拉到同一个点。本地与远端不一致，就还没开始。
- 凭文件报实况——上一轮做到哪、待办有哪些、这一轮该接什么，全部从留痕和仓库里读出来报，不凭记忆。记忆会漂，文件不会。
- 停下等指令。
第三步最反直觉：一个把仓库都读完了的脑，明明知道下一步该干什么，为什么要停？因为开工不等于授权。它报完实况，拍板的人一句话，它才动——这样每一轮干了什么，起点是清楚的。
「先诊断再动手」是每个脑的头一条，写在它的配置里，不是可选项。我们有一次脑开工时报出「本地领先远端十六个提交」，它没有自作主张去合，先问——那正是我们要的形态。
四、一张单只做一件事
脑出的任务单，四样必须齐：
- 圈定范围——这一单只做哪一件事，一句话说清。
- 逐条判据，每条带期望值——做完了拿什么证明，数字先写在单上。
- 明确不改——哪些东西这一单碰都不碰，写出来。
- 分支与提交说明——改动落在哪条分支、提交说明照抄哪一句。
四样里缺任何一样，双手就会自己补——而它补的往往是你最不想让它碰的那部分。
颗粒度宁小勿大。 单越小，回执越能逐条对；单一大，回执就变成「已完成」三个字，什么都对不上。我们的经验是：一张单改一两个文件、五到十条判据，是双手能跑稳、人能一眼审完的尺寸。
五、进度只有一份
每条线自己有一份收工留痕，最新的在最上面。接手的人只读顶上那一条，就知道上一轮做到哪、拍了什么、下一步是什么——留痕就是脑的长期记忆，换一台机器、换一个账号，重新连上仓库它就接得上。
这里有一条我们判过的病根：进度只能有一份。
排产表只记「该做什么」，不记「做到哪了」；团队协同工具只发问题和播报，不记进度；聊天记录里的口头指令只管当轮，不进配置。两份进度必然漂移——我们踩过：文档写着「已挂钩」，代码里那一处其实从没接上，前后近两个月，靠留痕一条条往回翻才定位到那一天。
所以规矩是三个「只认一处」：账本只认业务系统，口径只认仓库，进度只认各线留痕。 其它地方出现的任何一份，都是镜像，不是权威。
六、停手规则优先于完成任务
任务单最后一节，不是「完成」，是「停手规则」——它排在完成任务前面。
- 对不上就停。 判据实跑出来和期望值不一样，停下报回，不圆过去。「差不多」不是判据。
- 判据贴实跑输出。 回执里贴的是命令跑出来的那几行，不是「已确认」「已检查」。写「已确认」的回执，视同没验。
- 范围外一律不碰。 顺手看见的问题记下来报回，不顺手修。
我们实际用下来，双手停下来的次数远比出错的次数多，而且几乎每一次都停对了：期望值写错了、这条命令在它那台机器上跑不起来、要改的文件不在它的授权范围——这些都是出单的人的错，靠双手停下来才暴露出来。 一个不会停的执行者，会把这些错默默做成。
判据本身怎么写才算数——绿灯到底证明了什么、没设的项为什么从来不会红——这一页不展开，《你没看到它写代码》那一页专讲这个。
七、三周，三条线，一套跑道
以上不是设计稿，是实跑记录。三个在场证据：
其一，三条业务线在同一套机制上跑了三周。 财务、内容、官网三条线各有一个脑、各自的触发词、各自的留痕；三周里合并进主干的改动请求近百个，每一个都走了同一条路——出单、执行、判据、审、合并。
其二，两名非技术出身的成员，各用一天装好自己的脑，当天开出自己的头一个合并请求。 装脑走的是同一份五段清单：凭据、钥匙、副本、三格配置、开工验收。前一位由架构师带着走，后一位由架构师带着走、前一位在旁——「一名成员能独立带完下一名成员」是我们给自己设的下一道验收线，还没过，如实记着。
其三，一次漏账，靠留痕定位到那一天。 上面第五节讲的那件事：一处入口的账本挂钩，文档先于代码写了「已接」，代码一直没接。发现时已过去近两个月。定位靠的不是记忆，是往回翻留痕——哪一轮写的文档、哪一轮该写的代码、中间少了哪一步，一条条对出来，当天出止血单、当天上线。
八、没做过的事，不当做过的讲
已实跑：上面七节全部。
未实跑：
- 团队之外的协作方接入——让团队之外的人用同一套跑道，我们设计了隔离方式，还没有真人走过。
- 数据自动回流——运行数据自动喂回配置与内容，现在这一段仍靠人手周期性回填。
这两件在后面的篇目里也不会被当成「已经做了」来讲。
本包后续
- 给成员装一个脑
- 活怎么排、谁来拍
- 脑的配置怎么维护不腐烂
- 协同工具怎么配才不成第二权威源