9月10日，AI代码编辑器Cursor甩出了一个叫Projects的新功能，目前是beta版。它想干的事很简单：让开发者别再一个个盯着AI智能体干活，而是直接对着任务下命令，剩下的事交给一个“协调者智能体”去调度，哪怕下面有几千个子智能体同时开工。
这个思路被Cursor称为软件开发的“第三纪元”。你可以把它想象成一个大型装修项目：以前你得自己找水电工、泥瓦匠、油漆工，挨个交代活儿、检查进度；现在你只需要告诉工头“我要把这三居室装成北欧风”，工头自己去拆活、派人、盯现场、验收。
Projects的核心，就是这个“工头”角色。
它首先解决的是算力问题。每个Project都跑在独立的云端计算机上，你合上笔记本电脑，它照样干活。本地算力不够？没关系，协调者会自动判断什么时候该把活儿派给本地智能体去测试。
其次是“共享上下文”。听起来抽象，其实就是让所有参与干活的智能体有一个持续同步的文件夹。研究成果、代码库理解、你的偏好设置，都沉淀在里面。干得越久，协调者越懂你，越不需要你反复解释。
第三是“主动找活干”。协调者能盯着Slack频道、按计划自动运行，或者跟踪所有Pull Request（代码合并请求）。一旦发现动静，它不等你开口就行动了。
具体能干什么？三类场景最典型。
第一类是功能开发。智能体先做调研、建上下文，协调者定计划、派活，子智能体并行写代码、跑测试。上线之后还能继续盯日志、修bug。
第二类是大规模迁移。比如框架升级或者样式替换，这种事最怕“开头容易收尾难”。Projects能在几百个代码合并请求里一步步推进。前期人工审查严格一些，等方案跑顺了，协调者就自己往前推。
第三类是日常“园艺”维护。代码质量监控、回归测试这些琐碎但必须做的事，它可以自动提取设计系统组件，甚至在线生成规则。
Cursor官方说，内部团队已经拿Projects深度测试了好几个月，用它处理过涉及数百个代码合并请求的迁移和功能发布。数据挺吓人：用上这个功能的新用户，合并的代码请求数量增加了30%；而那些主要依赖Projects的用户，合并请求数量直接翻了六倍。
目前这个功能还在beta阶段，从9月10日起向所有用户逐步开放。
从“人管AI”到“AI管AI”，Cursor这一步踩中的是一个正在成形的趋势：当智能体数量膨胀到几千个，人类真正的角色不再是操作员，而是任务的定义者和结果的验收者。软件开发的门槛，可能即将从“会写代码”变成“会拆解问题”。