Cursor Projects 实操：用协调者 Agent 管住数月级的大规模开发

协调者不写代码，它只管派活

Cursor 上线 Projects 功能，目前以 beta 形式逐步开放给所有用户。它的核心设计是项目里的协调者 Agent：协调者本身不写代码，负责规划工作、把任务委派给实际实现的子 Agent，再把完成的成果交回来给你检查。因为它是委派而非执行，所以不会被单个任务阻塞，始终能响应新指令。

要跑起来，前置条件有三样：客户端更新到最新版本（旧版本里没有这个入口）、订阅档位至少到 Pro（底层由云端 Agent 驱动，免费档不含该权益）、以及可用的网络与支付方式。入口在编辑器左侧导航栏，暂时看不到属于正常现象，功能在滚动推送中，不需要额外申请。

按实际顺序走完一遍

第一步是新建 Project 并描述你要做的工作。官方定位是承载更大的工作体：一个完整功能、一次代码迁移，甚至一整个应用。建议第一次选一件平时要拆成十几个小步骤的活，比如给现有服务加一个导出功能。

第二步是写清目标和验收标准。经验做法是按背景、目标功能、技术栈、约束、交付标准五个维度写，篇幅三五百字。Project 名字建议和实际业务强相关，因为协调者会把它当作全局上下文的一部分。

第一批任务不要超过 10 个，先跑通整个调度链路再逐步增加并发数。

第三步让协调者生成任务树。可以明确要求：任务拆到文件级，每条包含目标、涉及文件、前置依赖和验收标准，这一轮不用写代码。第四步只检查任务划分是否合理、依赖关系是否正确、有没有明显遗漏或重复，不需要看具体代码。第五步在协调者面板里分批启动任务。

三个容易踩的坑

第一个是并发失控。有人一开始就把几十个任务拉满，结果子 Agent 之间互相踩文件，改得乱七八糟，最后不得不全部回滚。分批启动应当是铁律。第二个是把共享上下文当摆设。每个 Project 都维护一组跨云端与本机同步的文件，一个 Agent 摸索出某项服务的测试方法后，后续所有 Agent 都能直接沿用；如果你每次开新任务都重新交代一遍背景，等于把这个机制浪费掉。

第三个是把它当成一次性工具。协调者可以监视 Slack 频道、按计划运行，或跟踪所有 PR，在它们打开或合并时修 CI 并采取动作，也就是不必等你下提示词。官方提到的三种典型用法是功能开发、大规模迁移和园丁式维护，最后一种正是针对永远做不完的活，比如维护代码质量和盯回归问题。