如果你的 Cursor 还停留在「开一个 chat、改一个文件」的用法，9 月 10 日的这次更新值得你认真看一眼：Cursor 正式发布 Projects（beta），把 AI 编程的工作单位从「一次对话」上移到了「一个可以活数周甚至数个月的项目」。
这不是又一个加长上下文的 Chat。Projects 的核心是一个只委派、不写代码的协调者（coordinator）智能体：你向它描述目标，它负责调研、制定计划，然后把实现工作拆分给成千上万个并行运行的子 Agent，最后把完成的 PR 交回给你审查。官方说法是「从管理智能体，升级为指挥工作本身」。
一、Projects 到底改变了什么
先看一张对比表，理解它和已有形态的区别：
| 维度 | Chat / Composer | 云端 Agent 会话 | Projects |
|---|---|---|---|
| 工作单位 | 一轮对话 | 一次任务 | 一个跨多月、跨数百 PR 的项目 |
| 上下文 | 会话内 | 会话内 | 共享上下文文件，跨会话持续累积 |
| 谁来调度子 Agent | 你自己 | 你自己 | 协调者自动创建、并行、回收 |
| 关机后是否中断 | — | 视配置而定 | 云端执行，合盖不中断 |
| 触发方式 | 手动 | 手动 | 手动 + 订阅（Slack / 日程 / PR 事件） |
支撑 Projects 的是三项关键设计：
- 默认跑在云端，需要时切回本地。 每个 Project 运行在自己的云端计算机上，所以合上笔记本不会中断它，能并行运行的子 Agent 数量也不再受你的机器限制。当某一步必须在你本机验证时，协调者会拉起一个本地 Agent 来跑。
- 共享上下文。 每个 Project 维护一组在所有云端和本地机器之间同步的文件。Agent 会不断往里补充调研结论、产出物，以及它们对代码库和你偏好的理解——某个 Agent 摸清了「这个服务怎么测」，后面所有 Agent 都能直接沿用这份说明。上下文随项目生长，协调者越用越准。
- 订阅（Subscriptions）。 协调者可以监听一个 Slack 频道、按计划定时运行，或跟踪你的全部 PR——PR 一打开或合并，它就修 CI、跟进缺陷，不需要你再把工单复制粘贴进对话框。
二、从零创建一个 Project：完整步骤
入口在 Cursor 左侧导航栏（beta 正在分批向所有用户放出，看不到就先更新到最新版再等几天）。流程本身很朴素，但每一步的「给什么」有讲究：
第 1 步：新建 Project，写清楚「做什么」和「做到什么程度算完」。 协调者的第一份输入质量直接决定后续数百个 PR 的方向。一个合格的任务描述至少包含四要素：
项目目标：把订单模块从 REST 迁移到 tRPC，行为保持不变
完成标准：全部端点完成替换；现有测试套件 100% 通过；无新增 any 类型
边界条件：支付回调与库存扣减两个端点本期不动，保持旧实现
工作方式：每个 PR 不超过 300 行；先调研并写出迁移方案给我确认再动手
第 2 步：让 Agent 先调研，再让它把调研写进共享上下文。 协调者会先派 Agent 摸底系统，把「仓库结构、测试怎么跑、坑在哪」沉淀成共享文件——这一步的产物是整个 Project 的地基，值得你先读一遍、纠正错误认知，再让它进入计划阶段。
第 3 步：确认计划，然后放手并行。 协调者把实现和测试拆开，派多个子 Agent 并行推进不同部分。你的角色从「写代码」变成「审查 PR」：前期逐个细看，等修复经受住考验，再逐步放宽审查粒度——Cursor 官方内部就是这么完成数百个 PR 的框架替换和样式迁移的。
第 4 步（可选）：配置订阅，让它在你离开时继续干活。 把协调者接入缺陷反馈的 Slack 频道，或让它跟踪所有新打开的 PR：每个新缺陷、每个新 PR 都会自动触发委派，而不是等你回来再粘贴工单。
第 5 步：需要本机验证时，让它切本地。 功能可以试用时，协调者会在你的电脑上启动一个本地 Agent 运行和验证；9 月 23 日的 changelog 还补上了「云端 Agent 实时环境通过端口转发直接在浏览器里预览」，预览链路又短了一截。
三、官方内部在用的三种模式
Cursor 自己用 Projects 数月，工程师的用法大致落在三类，可以直接对号入座：
- 功能开发。 为一个较大的功能建一个 Project：先调研沉淀上下文，协调者出计划、并行实现与测试，你逐轮反馈。上线后同一个 Project 继续看日志、接缺陷报告——它带着当初所有决策的上下文，不是另开一个失忆的会话。
- 迁移。 迁移类工作「开头容易、收尾难」，正是 Projects 的主场。先和协调者敲定一套稳妥方案，再让它按方案在代码库里增量推进；前期仔细审每个 PR，后期修复站得住就放手让它自己跑完。
- 园丁式维护。 那些永远不会「做完」的工作：盯回归、维护代码质量、保设计系统一致。Cursor 团队有位工程师用设计系统 Project 走出了完整的放权曲线——起初人工审每一处修复；如今协调者扫描每个新 PR、抽出属于设计系统的组件，并在同一个错误出现第二次时自动补一条 lint 规则。这个 Project 的预期节奏是每天触达 20 到 100 个 PR：协调者负责组织，人只在需要注意力的地方介入。
四、数据与边界：兴奋之前先泼两盆冷水
官方给出的自述数据是：新用户合并的 PR 数量提升 30%，主要使用 Projects 的用户合并量达到原来的 6 倍。注意这是产品方的内部数据，没有经过第三方审计，不能直接外推到你的仓库规模、评审制度和发布节奏上——你的迁移项目能不能受益，要用一个真实的小项目试出来。
边界同样要写清楚：
- 「协调者不写代码」不等于「结果已经正确」。 实现仍由子 Agent 完成，PR、CI、线上回归照旧要人看。Basecamp 5 的教训是：AI 批量产出的代码如果缺架构审查，会退化成「瑞士奶酪」—— Projects 放大了产出速度，也就同比例放大了审查责任。
- 别把一次性任务硬塞进 Project。 改一个文件、答一个问题，普通 chat 更快。Projects 的价值在「活过单次会话」的工作：跨多 PR 的功能、有明确收尾标准的迁移、以及需要长期值守的维护。
- beta 意味着能力在滚动放出。 订阅、云端并行规模等具体能力以你账号实际看到的为准；企业内网场景可留意 9 月 2 日 changelog 里的 Self-hosted machines（把工具执行留在自己的网络），它与 Projects 调度云端子 Agent 是互补关系，不是同一件事。
常见问题
Q：Projects 会替代 Claude Code 这类终端 Agent 吗？ A：它们是不同维度的竞争。Claude Code 强在单次推理深度（2026 年 4 月 JetBrains 开发者调查里其满意度 CSAT 达 91%），Projects 强在项目级持续记忆与调度。真实的答案是混用：用 Projects 管长周期项目，用终端 Agent 做需要深推理的单点攻坚。
Q：上下文文件会不会越积越乱、反而误导子 Agent？ A：会，这正是第 2 步要你亲自把关调研结论的原因。把「事实」和「某 Agent 的猜测」分开存放、定期让协调者清理过时条目，是这个工作流里人仍然不可替代的部分。
Q：免费用户能用吗？ A：beta 分批向所有用户放出，但云端计算机和并行子 Agent 消耗的都是真金白银的算力——重度使用的成本结构以官方定价页为准，团队试用前建议先拿一个月度量「每个合并 PR 的成本」。
小结
Projects 把 AI 编程的抽象层抬高了一级：你不再管理一个个 Agent 会话，而是向一个永不阻塞的协调者描述「要做到什么程度算完」。三项设计——云端独占计算机、跨机器生长的共享上下文、对 Slack / 日程 / PR 事件的订阅——让「合盖之后项目继续推进」第一次成为默认形态。它最适合的战场也很明确：跨数百个 PR 的功能开发、开头容易收尾难的迁移、以及每天 20 到 100 个 PR 的园丁式维护。但请记住最后一条纪律：放权曲线要和质量证据同步——先审每一个 PR，再谈让它自己跑。