AI 不写代码改当包工头，PR 合并量翻 6 倍

9 月 10 日，AI 编程工具 Cursor 发了个新东西，叫 Projects，公测版，向所有用户滚动推送。

这玩意儿跟以往「AI 帮你写代码」的套路不太一样——它直接把 AI 升了职：AI 不自己动手写代码了，改当包工头。

听着像个段子，但背后的数据挺唬人：据 Cursor 官方披露，用 Projects 的新用户，合并的代码变更（PR）数量多了 30%；那些把 Projects 当主要干活方式的用户，PR 合并量直接翻了 6 倍。

这活儿到底是怎么派下去的？咱们拆开看看。

一个工头，一群工人

先说清楚这个新架构长什么样。

以前用 AI 编程工具，节奏是这样的：开一个对话框，交代背景，等它吭哧吭哧写完，再开下一个对话框。跟雇了个钟点工似的，每次来都得重新介绍一遍你家哪里漏水。

Projects 把这个模式改了：你面对的不再是「干活的人」，而是一位协调者代理（coordinator agent）。这位工头有个特点——它自己一行代码都不写。

你跟它说需求，它负责把大活儿拆成小任务，然后派给底下一群子代理（subagents）去并行干活。因为工头只管派活儿不干活，它永远不会被某个难题卡住。你随时能插话：「哎，这个方向不对」，它立马调整派工。

用装修来打比方：以前是你自己拿电钻，现在是你在跟一个装修队长开会，队长手底下有水电工、瓦工、油漆工，各干各的，你只管验收。

工头派活：协调者拆解任务，四个子代理并行开工

这个架构里最狠的一点，是云端执行。

每个 Project 跑在一台独立的云端机器上。你合上笔记本睡觉去了，它照样推进。只有需要在你本机上做测试的时候，它才会临时拉起一个本地代理。

这意味着什么？意味着「等 AI 跑完」这件事，第一次不再占用你的时间。以前你开着电脑盯它跑，现在你该下班下班，明早回来看结果。

这还没完。Projects 还有个「订阅」机制：工头可以盯着一个 Slack 聊天频道、跟踪所有代码合并请求、或者按固定时间表跑任务。发现信号就主动干活，不用你一遍遍催。

比如：用户报了个 bug 在群里，工头看见了，自动派个代理去查、去修，然后提交修复。整个过程你可能在开会。

关机不关工：人下班了，云端的服务器还在跑

第三个设计叫共享上下文，我觉得是整个东西里最有含金量的。

每个 Project 维护一组持续同步的文件。任何一个子代理在干活过程中搞明白了什么——比如「这个服务该怎么测试」——都会写进这组共享文件。后面所有接手的代理，自动就能看到。

换句话说，第一个代理踩过的坑，第二个代理不用再踩一遍。

这事儿的妙处在于：老程序员值钱就值钱在脑子里那点「这个项目哪里有雷」的经验，新人入职慢也是因为得从头攒这个经验。现在有个角色专门负责把这经验写成小本本，谁来干活都能翻——等于项目组配了个不会离职、记性还贼好的资料员。

Cursor 自己团队内部用了几个月，据公开报道，他们拿它跑过横跨几百个 PR 的大迁移，还有一个「园艺」项目：盯着每一个新提交的代码，自动把该收进设计系统的组件归档，发现同样的错误犯两遍就自动补一条检查规则。这个项目据说一天能处理 20 到 100 个 PR。

共享小本本：一个代理踩过的坑，后面的代理不用再踩

说到这儿，得泼半盆冷水——工地的活儿也得验收。

前面那些数据（+30%、6 倍）都是 Cursor 自己统计自己用户的，没有第三方审计。而且有个关键问题：PR 合并量涨了，不等于代码质量涨了。改得快和改得好，是两回事。

官方公告里没有公布 bug 率、回滚率这些质量指标。「几千个子代理」的说法，也没有给出典型任务里到底同时跑多少个、烧多少钱。

所以我的结论是：方向是真的，数据留个心眼。这种「工头带施工队」的模式，最怕的是工头看走眼——第一个 PR 你盯得紧，第七个、第八个你越来越松，等出了问题才发现它前面早就跑偏了。人管人尚且如此，何况 AI 管一堆 AI。

说句实在的，如果你不写代码，这事儿跟你有关系吗？

有，但不是「你也能用 Cursor」——它的门槛还是在程序员那边。

真正值得留意的是这个信号：AI 编程工具的竞争，已经从「谁家 AI 写代码更准」，卷到了「谁家 AI 会管团队」。写代码这件事正在被拆成两层：动手的一层便宜又量大，动脑的一层负责拆解、派工、验收。

以后衡量一个 AI 工具好不好用的标准，可能不再是它一次能写多少行代码，而是——你敢不敢关上电脑去睡觉。

今天的活儿你安排出去了吗？评论区聊聊你的 AI 用法。关注老魏，程序员的活儿，我给你翻译成人话。

数据来源：Cursor 官方博客及多家科技媒体报道（2026 年 9 月 10 日至 14 日），部分数据为厂商自测，未经独立审计。