Cursor Projects 现在还挂着 beta 的标签，但它盯上的活儿一点都不轻：功能开发、代码迁移、常年没人愿意碰的维护性改造。真正有意思的地方在于，Projects 里的那个协调者智能体，自己一行代码都不写。它只负责拆活、派活、收活，动手的是被它调度出去的数千个子智能体，并行开工，各管一摊。把 AI 编程从"补全一个函数"推到"承包一个季度"，中间隔着的并不是模型能力，而是调度。
一个不动手的智能体，凭什么指挥成千上万个干活的
它的活儿只有一件：把大象切开
给模型下"重构整个鉴权模块"这种指令，它多半会还你一份听上去很合理、真跑起来处处踩坑的方案。Projects 绕开了这条路。协调者先读仓库，摸清模块之间的依赖，把目标切成边界清晰、能独立验证的子任务，再逐个派发。切分质量直接决定后面几百上千个智能体是在干活，还是在互相制造冲突。所以协调者这一层最像的并不是程序员，是那个每天在白板上画依赖图的项目经理——只不过它带的团队规模是四位数。
子智能体不是一段 prompt，是一份带分支的工作副本
每个子智能体分到的东西，是自己的仓库副本、自己的分支、自己的运行环境。它能编译，能跑测试，能随便改文件，不会碰到别人正在改的那一行。彼此之间不共享中间状态，只能通过代码和测试结果对话。这种设计看上去极其浪费——同一份仓库复制上千遍——但它是让并行真正成立的前提。反过来做，让所有智能体共享一个工作区，最后得到的只会是一堆互相覆盖的修改和一条读不懂的提交历史。
派出去容易，收回来才是真难题
子智能体跑完之后，交上来的不是一段解释，而是可以逐行对比的改动。协调者要理清这些改动之间的冲突，判断哪些能合并、哪些得打回重做。这一步做不好，前面拆得再漂亮也白搭——一千个互不兼容的补丁堆在分支里，比什么都不动更糟糕。Projects 的价值有一大半压在这个收敛环节上。
跑得久、铺得开、收得回来
先砍掉"人盯着"这个环节
以前用智能体有一套固定动作：下指令，看它跑，它卡住了补一句，如此循环。Projects 想删掉的就是中间那几轮往返。任务派出去之后，智能体会自己判断哪块做完了、哪块要重试，中途不需要人喂下一步指令。对于动辄几十万行的迁移任务来说，人盯不盯得住，就是能不能跑通的差别。人的注意力是有限资源，而机器的耐心接近无限。
上千个并行，难的不是启动
官方给出的量级是数千个子智能体同时执行。听着像算力炫耀，实际上这是编排问题：哪些子任务之间有硬依赖必须先做，哪些可以同时开，某个子智能体失败之后要不要重派、派给谁。模型本身在这里反而退居其次，真正的变量是调度层的判断力。并行度越高，一次错误切分的代价就越大。
审查与合并被单列成一项能力，这个信号值得琢磨
官方介绍里把审查和合并当成独立能力来讲，说明产品默认你会怀疑它的产出。于是 diff 视图、逐块确认、冲突处理被做成了第一等公民。换句话说，Projects 没有假装自己能交付"直接上线"的代码，它交付的是排好队、等你签字的改动。这种诚实，比任何跑分都更能说明它现在处在什么位置。
内部数据比宣传语更值得看
Cursor 先拿自己开刀
判断一个 coding agent 产品的成熟度，最省事的办法是看它敢不敢把自家仓库交出去。官方在介绍里放了内部使用数据，关注的维度无非几项：任务持续了多久，产出了多少改动，其中多少能顺利合入主干，人工介入了多少次。这些数字指向同一个结论——横跨多个模块、需要多轮迭代才能收尾的工作，才是 Projects 的目标场景。写个工具函数、改段文案，用它纯属杀鸡用牛刀。
什么规模的工作配得上它
判断标准其实很朴素。一件事如果一轮对话就能说清楚，不需要 Projects。如果它需要一份排期表、需要几个人分工、需要跑上好几天，那才轮到它上场。代码迁移、框架升级、积压已久的技术债清理，形态上都对得上：目标明确，但执行路径长，而且天然可以切成很多块。
生成越强，验证越像瓶颈
评审带宽是最硬的那道墙
子智能体可以一夜之间产出上千个改动，能读懂这些改动的还是人。代码评审的吞吐量不会因为 AI 变快而变快，反而会因为提交量暴涨而堵死。Projects 把问题从"要不要让 AI 写代码"换成了"你打算怎么消化 AI 写的代码"。前一个问题有标准答案，后一个没有，每个团队得自己摸。
签字的还是人，这一点没变
合并进主干的那一刻，代码是谁写的已经不重要了，重要的是谁签的字。并行智能体会让归属变得模糊——一个功能可能由几十个子智能体各写一部分，提交历史里看不出完整的作者脉络。所以团队得提前想清楚：谁审、审到什么程度、线上出了问题谁负责。这不是产品能替你解决的，是流程和组织问题。
小团队和平台团队，会用出两种不同的东西
小团队更容易把它当成超级外包，一个人指挥一群智能体，顶过去三个人的排期。规模大一些的团队更可能把它塞进 CI 和评审流程里，让协调者只管产出分支，人类守着合并的那道闸门。两种用法没有高下之分，但决定了 Projects 对你来说是一个效率工具，还是流程里的一个环节。这个区别，比 beta 标签重要得多。
