如何使用 Cursor Projects

HN 中文独立开发 AI 2026-09-14T11:34:43.060047

Cursor 于 2026 年 9 月 10 日推出 Projects。它不再让你为每个任务单独开一个聊天窗口，而是让你在一个长时间保持打开的会话里，和一个「协调者」agent 对话，直到工作全部结束。协调者本身不写代码。它负责规划任务、把活派给其他 agent，再把结果带回来给你验收。

Projects 目前处于 beta 阶段，正在向所有人逐步开放。Cursor 通过一篇博客和一条 changelog 宣布了这件事，参与开发它的人也在发布当晚在 X 上答疑。我读完了那篇公告，也看了不少相关讨论，这份指南就是从中整理出来的。

一个任务一个聊天窗口，问题出在哪

用过一段时间 Cursor 的人都知道侧边栏长什么样：几十个聊天窗口，一半标题还是自动生成的、一模一样。某个窗口里你搞清楚了怎么跑测试套件，某个窗口里你找到了那个没人写文档的配置文件——可你根本分不清哪个是哪个。

每开一个新聊天，都是从头开始。新 agent 对上一个 agent 学到的东西一无所知，于是你得重新解释项目、粘贴一段摘要，或者指望它自己摸索出来。小修小补倒是无所谓。但如果是横跨十个 PR 的功能、涉及几百个文件的迁移，或者你想让它在你睡觉时继续跑的任务，这种模式就行不通了。

Projects 给这类工作提供了一个固定的去处，里面的 agent 记得这里发生过什么。Cursor 的设计负责人 Ryo Lu 把它形容为「为你那些大想法服务的长期 agent」。读后面的内容时请记住这个定位：它不是用来做小修小补的，而是给那些活不过一个聊天窗口的工作准备的。

一个 Project 是什么

你和协调者对话。它读完你的需求，制定一套计划，然后创建其他 agent 去执行。由于它是派活而不是自己动手，所以永远不会卡在等构建或等测试跑完上，你随时可以给它发新消息，它都能回你。

为了试试看，我在一个空仓库上创建了一个 Project，把 Data Vault 的规格说明贴了进去。Data Vault 是一个小巧的自托管个人数据存储，我一直想把它做出来。协调者（coordinator）把这份规格说明存为项目上下文，然后启动了一个 worker，让它在自己的机器上把这套东西整个搭起来，并告诉我 PR 一就绪就会通知我：

真正写代码的是它创建的那些 agent。协调者可以按任务需要创建任意数量的 agent，让它们并行运行。Cursor 团队的 Fatih Arslan 写道，他的协调者每个都能管理几十个 agent，而且这些 agent 可以在本地、远程和云端启动。

你可以打开其中任意一个 agent，看它干活。下面这个 Data Vault worker 正在写 query.ts 和 auth.ts，而协调者待在另一个标签页里，随时可以接收我的下一条消息：

worker 完成后，协调者总结了结果，并给我一个 Try Live 链接。点开后，右侧会打开这个 Project 的云端电脑，浏览器里运行着已经做好的 Notes 应用：

每个 Project 还会维护一组共享上下文文件，同步到 agent 运行的每一台机器上。agent 会把自己学到的东西写进去：怎么跑测试、某个服务在哪里配置、你希望 PR 怎么组织。下一个 agent 启动前会先读这些文件，这就解决了上一节提到的冷启动问题。

在我的例子里，第一个上下文文件就是产品规格说明本身，保存为 docs/project-context.md，显示在右侧的 Project 面板里：

你可以让协调器盯着某个 Slack 频道、跟进你的 PR，或者按计划定时运行。Cursor 把这套机制叫做订阅（subscription）。一旦有事发生，协调器就自己动手，不用等你发话。

Cursor 的 Andrew Milich 用一句话总结了这个设计：用一个智能体跨多个 PR 干活，配合订阅、共享文件系统和记忆。

默认跑在云端，需要时才回到本地

每个 Project 都跑在云端的一台独立计算机上，所以合上笔记本也不会中断。这也意味着协调器不受你本地硬件的限制。你的笔记本跑几个智能体就开始卡，而云端的机器能并行跑更多，每个子智能体还能分到一台独立的虚拟机，各自持有一份干净的代码仓库副本。

当某件事必须在你本机上做时——比如一个依赖本地数据库的测试，或者浏览器里的手动检查——协调器会在本地启动一个智能体来跑。你不用手动搬任何东西。

如果你更想让云端智能体跑在自己掌控的硬件上，我在《在自己的 Mac mini 上运行 Cursor 云端智能体》里写过做法。

怎么创建第一个 Project

先把 Cursor 升级到最新版。Project 位于 Agents 视图里，也就是左侧边栏有 New Chat、Search 和 Automations 的那个窗口，不在 IDE 中。如果你整天泡在编辑器里，是看不到它们的。打开 Agents 视图（本文所有截图都来自这个视图，你可以用右上角的 IDE 链接跳回去），在侧边栏找新增的 Projects 区块。如果没有，说明这波推送还没轮到你，上线当天就有不少 Linux 用户反馈过这个问题。

接着：

1. 点左侧导航里的 Projects，新建一个。

2. 连接你要动手改的代码仓库。

3. 描述你想做出来的东西。

之后协调器会读代码库、写方案，然后开始创建智能体。

每个 Project 还有自己的页面。它会跟你打招呼，让你把聊天记录或文件拖进来当作输入，并列出正在运行的智能体和它们的状态。下图是我的 Project 刚跑几分钟的样子，一个 worker 正按照规格说明搭建，还有一个 PR 悬着等待处理：

我的建议是从小处着手，先交给它一个有明确完成状态的任务，而不是第一天就扔给它一整个应用：

为计费模块添加测试覆盖。目前只测试了正常流程。
需要覆盖退款、部分退款以及 webhook 重试逻辑。每个领域一个 PR。

然后先别管它。让它完成委派，让子代理去干活，等它汇报结果时再回来。

协调器会从每一轮反馈中学习。如果你告诉它 PR 太大了，下一批就会小一些。如果你告诉它开 PR 之前一定要跑 linter，它会记下来，之后每个代理都会照做。

免费 · 无需付费

学习用 AI 构建软件

6 门免费课程，涵盖 AI 代理、技能、MCP 和本地运行模型。另有 81 门课程讲解 AI 生成代码仍然依赖的基础知识，以及 17 本书和 222 个浏览器工具。全部免费。

把已有对话移入 Project

你可以把 Project 当作对话的文件夹。从侧边栏把已有对话拖进 Project，协调器会知道你拖了它们进来，并能读取它们的记录。

已完成的对话也值得移入。两周前那个搞清楚了如何测试某个服务的代理已经完成了任务，但它的对话记录现在成了 Project 里每个未来代理的上下文，而不是孤零零地躺在侧边栏里。

来自读者的反馈：对话只能一个一个拖，目前还没法一次性把整个仓库的对话都移进去，而且至少有一位用户反映只有当对话已经是云代理时拖拽才有效。我预计这两点都会改变，但目前 beta 版就是这样。

应该创建多少个 Project？

每个仓库一个 Project，还是多个？取决于你觉得怎样合理。你可以为同一个应用建多个 Project，一个做性能优化，另一个开发新功能，以此类推。

有一种说法我很认同：按“要做成什么结果”来给聊天分组，而不是按代码仓库。一个塞满无关任务的 Project，协调者根本不知道该往哪儿使劲；而一个叫“checkout redesign”的 Project，它一眼就知道哪些活儿该放在这里。

如果只有一个代码仓库，我会这样建 Project：每个跨多个 PR 的功能建一个，每次迁移建一个，日常维护建一个。小的临时修复，还是放普通聊天里就行。

Cursor 内部常用的三种模式

Cursor 内部已经用 Projects 跑了好几个月。那篇博客介绍了三种模式，基本覆盖了工程师们的大部分工作场景，而且和你最终要写的提示词能对应上。

功能开发

一个功能往往从调研开始。智能体先摸清系统，把发现写进共享上下文。接着协调者做规划，派多个智能体并行去实现和测试不同部分。

到了试用阶段，协调者可以在你本机启动一个智能体，跑起来看效果。功能上线后，同一个 Project 还能盯日志、处理 bug 反馈，而且完整保留着“当初为什么这么设计”的历史记录。

这类工作的提示词长这样：

我们需要在现有密码登录之外，再加一套 magic link 登录。
先调研现在会话是怎么工作的，写进项目上下文。
然后把活儿拆成一个个 PR，让我能逐个 review。

迁移

迁移这事儿，开头容易，收尾难。前十来个文件你干得兴致勃勃，剩下四百个就永远搁那儿了。

Cursor 用 Projects 在几百个 PR 里完成了框架升级和样式系统替换。你先和协调者商量出一套稳妥方案，再让它按这套方案小步推进，铺满整个代码库。刚开始每个 PR 都仔细看，改法稳了之后就看得松一些。

把 src/components 下所有组件从 styled-components
迁移到 Tailwind。先从最简单的五个开始，让我确认一下方案。
每个 PR 控制在 300 行以内。src/legacy 下的东西别动。

日常养护

有些活儿永远干不完：保持设计系统一致、盯着回归问题、收拾别人 PR 留下的烂摊子。

Cursor 有一位工程师就是这么跑设计系统 Project 的。它会跟进每个新 PR，把该进设计系统的组件挑出来，同一个错误看到第二次就加一条 lint 规则。照这个节奏，它每天能碰 20 到 100 个 PR。工程师只在需要关注的地方介入，其余交给代理自己跑。

这时候就该订阅出场了：

跟进这个仓库里所有新 PR。如果某个 PR 写死了颜色或间距值，
就开一个后续 PR，把它替换成设计令牌。只有拿不准该用哪个
令牌时，才通知我。

订阅

订阅功能在 Cursor 8 月 19 日发布的云端代理版本中推出，Projects 就是在它之上构建的。代理订阅某个事件源，那里一有动静就被唤醒。目前支持的事件源有：

• 你的拉取请求（开启、合并、CI 失败、审查评论）

• 某个 Slack 频道或话题

• 定时计划

把 Slack 接上，让协调者代理盯住 bug 反馈频道，每来一个 bug，它就开始派发修复任务。告诉它跟进你的 PR，它就会自动修 CI、回复机器人评论，不用你开口。

定时计划是我用得最多的。一个每天早上跑一次的协调者，检查几件事，要么什么都不做，要么开一个小 PR，成本极低，还能防止代码库慢慢跑偏。

谁来合并？

Project 刚起步时，每个 PR 你都得自己审。Cursor 对迁移类任务就是这么建议的，换我也会对所有任务都这么做。

等协调者摸清了你的偏好，PR 也一直干干净净地落地，你就可以松一松了。Cursor 团队里有些人已经让 Project 自己合并自己的 PR，合并完再审查。

我不会一上来就这么干。先给协调者开 PR 的权限，合并权攥在自己手里，等它攒够了靠谱的记录，再往后放。讨论串里日文区有人问得特别到位：“开 PR”和“绿灯就合并”之间的边界到底在哪？答案是 Cursor 并没有发布默认设置，这条线得你在指令里自己划。

Projects、Grok Bot 和普通聊天的区别

Cursor 在发布公告里把 Projects 和 Grok Bot 做了对比：后者是一个永远在线的代理，会调动子代理来推进工作，并随时间不断改进。

普通聊天只解决一个任务、产出一个结果。你要代码，审核完就走人。

Project 面向的是代码仓库里的一整个工作流。它住在 Cursor 里，了解你的仓库，会开 PR，必要时还能在你本机跑代理。

Grok Bot 则是一个带常驻计算机的通用助手。它能登录你的各种应用、跑固定流程、处理与代码无关的工作，也能驱动编码代理。发布当晚就有用户搭了一个 Cursor 协调器，让 Grok Bot 直接跟它对话，而不是自己另起一个代理。

所以，“接下来一个月把这个仓库改造一遍”属于 Project；“打理我的业务运营”属于 Grok Bot。拿不准的时候问自己一句：这件事是发生在代码仓库里的吗？是的话，就放进 Project。

下面是我实际会怎么把任务分给两者。

适合放进 Cursor Project 的任务：

• 跨代码库的迁移，比如把站点从 Netlify 迁到 Cloudflare Pages

• 一个牵涉很多文件、需要拆成多个 PR 才能落地的功能

• 保持 CI 绿灯，并回复 PR 上评审机器人的评论

• 仓库的日常打理：清理死代码、升级过期依赖、补齐测试、统一代码风格

• 定时检查：一旦发现代码有问题，就自动开一个小 PR

属于 Grok Bot 的任务：

• 起点在仓库之外的任何事情：读客服邮件、盯 Slack 频道、看 Notion 页面、看分析数据

• 需要浏览器和登录态的固定流程，比如每天早上查一次仪表盘

• 压根跟代码无关的工作：调研、写摘要、行政事务、买个域名

• 以聊天为界面、用一个 JSON 文件当数据库的个人自动化

• 从多个系统收集上下文，然后把一个干净的任务交给编码代理

最后一个就是两者相遇的地方。Grok Bot 可以充当外层循环，负责判断哪里需要改；Project（或者一个普通的 Cursor 对话）则是内层循环，负责实际动手改。如果一个 bug 报告出现在 Slack 里，Grok Bot 可以读它、在浏览器里复现它，然后写下任务。接下来交给 Project，因为真正的修复发生在代码仓库里。

两者的重叠范围，比官方公告听起来要小。Projects 了解你的代码和 PR。Grok Bot 了解你的应用和收件箱。按工作从哪里开始来选。

粗糙的边缘

Projects 还是个 beta，发布帖子里照例是兴奋与抱怨齐飞。动手之前，有几条值得先知道。

成本被提得最多。云端 agent 比在本地编辑器里干活贵，而一个协调者在云端跑二十个子 agent，用量消耗很快。第一个 Project 做的时候盯着点配额，按自己的套餐来安排工作量。

问得最多的技术问题是：这个持久线程怎么防止几个月下来变得臃肿？一部分答案在共享上下文文件——agent 会把摘要写在那里，而不是把所有东西都塞进一段对话里；协调者只管派活、不逐条读 diff，所以能保持精简。但 Cursor 没有公开 Project 内部的压缩机制是怎么运作的，所以这个问题目前还没定论。

Linux 用户反馈第一天看不到 Projects。等几天就好。至少有一位用户直接说这整个东西有 bug——对一个野心这么大的 beta 来说很正常，所以第一个 Project 挑那种搞砸了也重做得起的工作。

还有一点：Cursor 之前就用 “project” 表示你打开的那个文件夹。大写 P 的 Projects 是新的 agent 功能。接下来一段时间，文档和论坛里出现混淆是难免的。

我会怎么用它

我用了半天。写这篇文章时它才上线一天。但我已经知道它会放在我工作流的哪个位置。

第一个用途是打理站点。这个站点大约有 2,000 篇博客文章，我每天安排发布两篇新文章。每篇上线前，我都想确认内部链接能正常跳转，也没有截图是 1024px 缩图后上传的。现在我是想起才做，一次集中检查一批。如果有一个协调器（coordinator）订阅每日计划，它就会每天早上跑一遍，发现问题时开一个小的 PR。

第二个是那些我总在往后拖的迁移工作。这个站点在 6 月从 Netlify 迁到了 Cloudflare。迁移本身很快。但清理旧的 Netlify 函数、弃用的依赖和陈旧的文档，一直拖到 8 月，都是穿插在其他工作之间的小提交。如果用一个迁移 Project，几天后台作业就能搞定。

我不会用它来做的事：任何涉及支付或课程访问 webhook 的部分。这些我会走正常聊天流程，由人工合并。

Projects 让我不满意的地方

Projects 是围绕云端 agent 构建的，而我个人并不喜欢用云端 agent。让 agent 跑在我自己的电脑上，能访问我的文件、终端和运行中的开发服务器，对我来说是更好的工作流。出了问题我就能当场查看。

我也不会在一个任务上跑成千上万个 agent。一个协调器要分发到数百个子 agent，会消耗大量 token；我更倾向一次做一件事，控制力更强，还能在 agent 干活时实时看到它在做什么。

另外我不使用 PR 或 issue。我直接提交到 master 然后推送。Projects 围绕跟进 PR、修复 CI、回应评审意见所做的大部分事情，都不适用于我的工作方式。

所以我想，我干活的规模比 Projects 面向的场景要小。这没关系。不是每个功能都适合每个人，接下来几个月我会试试它，看能不能改变我的想法。

在哪里了解更多

• Introducing Projects，发布帖，内含内部使用模式

• changelog 条目

• Cloud Agents and Cursor Harness Improvements，订阅和云端子 agent 最早在这里出现

• 团队在 X 上的侧边栏提示和发布帖

• Ryo Lu 的一句话总结：为你的宏大构想提供长期存活的 agent

想让我聊聊你的产品？可以赞助本站。

免费电子书

想深入了解？订阅我的邮件通讯，即可打开我的免费下载库，里面有书、课程和软件。

关于 AI 的相关文章：

• 软件开发的价值从来不等于投入的工时

• 当越来越多人在造软件，软件的价值还剩多少？

• 如何让 AI 工具少说废话

• 深入剖析 tldraw

• AI 与编程的乐趣

查看原文