Cursor 这两天把 Projects 的多人模式放出来了，还在 beta，名字叫 Team Projects。说人话：你能把同事拉进同一个 Project，每人带着自己的 AI 一起上班，共用一块任务板。
我第一反应不是效率，是画面。三个人坐一排，各自的 AI 在中间交头接耳，主人还没开口，秘书先对上了火。会议室很安静，屏幕上很热闹，嘴上聊效率，心里算这个月额度还够不够。
三个秘书替三个人吵架
先把版本说清楚。今年 9 月的 Projects 是一个协调者带一群智能体干活：一个人指挥，一队机器跑腿，活儿是串起来的。
现在你能把队友邀请进同一个 Project。每个人有自己的 Agent，大家共用一块任务板、共用同一份上下文，谁动了哪块，板上都看得见。不用自己复制粘贴上下文，也不用在群里刷屏发文件。
听着像开会，实际更像三个秘书替三个人吵架。文件在中间飞来飞去，谁都不肯先让一步，还得三个主人点头才算完，散会时谁也说不清结论。
官方博客把这次叫 multiplayer。这词用得挺准：多人游戏里最难的从来不是人多，是配合；配合不上，四个人能打出一个人的效果，还各自觉得自己在带队。
它省的不是人力，是交接
这功能真正戳中的，不是「人多力量大」，是「上下文交接」这件又琐碎又费人的麻烦事；它不让你跑得更快，只让你少解释几遍。
以前你把活交给同事，得先写一段话解释：需求在哪、上个月改过什么、为什么这么写、哪块别动。写清楚要十分钟，写不清楚要一下午，还得再返工一次。
现在你的 Agent 需要队友的成果，会直接向队友的 Agent 发起请求。不用你写交接文档，两个机器自己把话说完，你只看结论。
省的就是这段打字，一天交接五次就是一小时，一个月就是一天半。以前 AI 只读得到你的代码，读不到你脑子里那句「这块先别动」，现在这句也进了共享上下文。这笔账，只有真被交接折磨过的人才算得过来。
互相请求听着高级，其实是拆活的考试
Agent 之间互相请求，听着很未来，发布会一说，弹幕全在喊卷。它考的东西特别朴素：你会不会拆活。毕竟活是人拆的，锅是 AI 背的。
官方说，智能体开工前会各自共享计划，干活时标出冲突，还能跨团队互相解锁任务。这三件事全压在一个前提上：活被拆清楚了。拆不清楚，再流畅的请求也没用。
拆得清，每个 Agent 拿到的是一块边界明确的砖，砌上去就行。拆不清，就是两个 Agent 互相喊「你先把接口给我」，一路喊到下班。
办公室里这叫踢皮球。这回踢球的两个不累、不困、不觉得尴尬，也不需要你调解，能对喷到你打开账单那天为止。
共享上下文，脏数据也一起共享
共享上下文听着很爽：新人不用挨个问，AI 自己知道前面发生过什么，也不用你从头再讲一遍项目史，连上次谁把它改坏了都记得。
但共享是双向的。仓库里那份三年前的 README、上个版本留下的注释、早废掉的分支说明，也一起共享，还享有同等权重。
以前脏数据只污染一个人的判断，现在污染一整个项目组，还附赠一个特别自信的语气。你纠正它，它能反过来纠正你。到时候出问题的不是某个 Agent，是整块板子上的共识。
顺序别搞反。分支怎么命名、注释写不写、文档放哪、谁能动主分支，这些粗活没人替你干，AI 也不会替你干，它只会照抄现状。
什么样的活适合上
有三种活我觉得值，前提是活本来就分得开，人本来就愿意沟通，验收标准写得像菜单一样清楚。
并行改不同模块。前端在改登录页，后端在补接口，两个人不碰同一个文件，共享任务板刚好当施工图，进度一目了然。各改各的，谁也不等谁。
需要人审的高风险改动。Agent 先把计划摊开，人看一眼再放行，比自己写到一半才发现方向错了便宜得多，也体面得多。
新人熟悉项目。他带着自己的 Agent 进来读共享上下文，比人陪着翻三天代码快，也不太容易把老问题再问第二遍，省下的是老员工挨个答疑的时间。
什么活别上
反过来，两类活别急着上。
一类是一个人半小时能收尾的小活。为它拉三个人、配三套上下文，对齐的时间比干活还长，到头来结论还是「你自己改吧」。
另一类是高耦合的核心代码。一个函数被八个地方调用，三个 Agent 同时动它，冲突标记能标到你怀疑人生。标准就一句：这活能不能拆成三块、每块都能单独验收，拆不开就先别拉人。
还有一句清醒的：它不解决「活多」，只解决「交接难」。团队本来乱，多人协作只会乱得更快、更同步。三个秘书替三个人吵架，前提是三个人先说清楚要吵什么。
