Cursor 自动化：始终在线的编码智能体实操指南

软件开发的真正瓶颈已不再是写代码，因为几乎任何规模的团队中，每位开发者至少都有一个智能体在协助交付。编码智能体已经内嵌到日常工作流中，实现阶段不再是系统中最慢的部分。

Cursor Automations 正是为弥合这一差距而构建。与其反复向智能体发起提示，您可以预先定义它何时行动。触发器被激活，指令指导其执行方式，随后它就会自主运行。有人打开了一个 Pull Request，它就会被审查；一个缺陷报告落在 Slack，它就会被处理；定时任务触发，就会生成报告。

在本教程中，我将向您展示如何端到端搭建 Cursor 自动化。您将构建两个自动化：一个 PR 审查，以及一个定时的测试覆盖率监控。在此过程中，我会讲解如何编写结构清晰的指令，并连接工具与 MCP，以确保自动化按我们的预期运行。

开始之前先说明一下。Automations 仍在开发中，位于 cursor.com/automations 的控制台也在不断演进。如果您阅读时某些菜单标签或按钮位置有所变化，底层逻辑依然一致。

什么是 Cursor Automations？

Cursor automations 是一个系统，可让 Cursor 的云端智能体自动运行，由您的开发工具中的事件或您定义的日程触发。

在 Cursor 的 Agent 模式中，正如我们在 Software Development with Cursor 课程中所介绍的，您每次会话都从打开聊天并输入提示开始，且智能体只在您陪伴的时间里于本地机器上运行。

在自动化中，启动信号来自您技术栈中的其他位置，智能体会在云端沙箱中完成其工作，无需您监控。

自动化包含 触发事件（我在下表中做了总结），您也可以使用 Webhook 设置自定义触发器。一个自动化可以包含多个触发器，只要其中任意一个被激活，它就会运行。

上述每种触发器类型都能替代您日常工作中的某个时刻——此前您需要先注意到某件事，切换上下文进入 Cursor Agent 模式，再提出请求。

Pull Request 触发器最可能是您首先构建的。下面展示在为仓库添加自动化前后，单个 PR 的生命周期将如何变化。

第二列的变化，不在于单个步骤的速度，而在于您的注意力不再成为整个流程的限速器。

Cursor Automations 的底层工作原理

每个自动化在底层都遵循相同的流水线。当您定义的触发器被激活时，Cursor 会启动一个全新的云端沙箱，将您的仓库克隆到其中，并启动一个智能体，使用已配置的工具、MCP 连接和模型，按照您的指令执行。该仓库不必托管在 GitHub：托管在 Cursor Origin（Cursor 自有的 Git 平台）上的仓库，同样可与云端智能体与自动化配合使用。

智能体在结束前会验证其输出，然后将结果发布到您配置的位置，无论是 PR 评论、Slack 消息、Linear 工单，还是通过创建新的 Pull Request。

有两个特性决定了您构建的每个自动化：

• 沙箱完全在 Cursor 的云端运行，而非您的笔记本。即使您的机器关闭，它仍会继续运行。
• 每次运行彼此隔离。多个自动化可并行运行，互不干扰。Cursor 也表示其内部每小时可运行数百个自动化。

另有一个内存工具，如下图预览所示，可让您的自动化在多次运行之间持久化状态。在稍后构建定时覆盖率监控时，这一点会变得很重要。

当您构建定时覆盖率监控时，我会再回到这一点。

Cursor Automations 与 Agent 模式对比

如果您已在经常使用 Cursor，关键问题在于何时应使用自动化而非 Agent 模式。我不会将 Automations 用于一次性任务。它旨在处理重复性工作或依赖外部事件的工作。

当选择并不明显时，下表的对比很有帮助：

我是这样判断的：若一个任务以“每当（whenever）”或“每次（every time）”开头，它就属于 Automations。

例如：“每次打开 PR，或每当 #support 收到缺陷报告，就创建一个 Linear 工单。”触发器是重复且可预测的。

如果是“我现在需要重构这个模块”，那就属于 Agent 模式。“现在”由您决定。

若您想在深入自动化之前先了解 Cursor，我们的 Cursor 2.0 完整指南将带您了解 Agents 界面、Composer 和基于完整 Python 项目的多智能体工作流。

访问 Automations 控制台

Cursor 自动化控制台位于 cursor.com/automations。使用您的 Cursor 账号登录，即可进入如下所示的主控制台：

我们来拆解一下控制台上看到的内容。

顶部概览磁贴或状态指示

这些磁贴提供您所有运行情况的健康快照，包括：

• 自动化总数（您已配置的数量）
• 成功（已完成的运行及成功率）
• 失败（出错的运行）
• 运行历史（点击可查看一段时间内的运行量）

指令输入框

该输入框是无需打开完整设置表单即可快速创建新自动化的方式。我们描述任务，Cursor 会生成自动化结构。

如果您刚开始，我建议从这里入手。先明确您想自动化的内容，然后为智能体编写结构化的指令，让它在每次触发时都能遵循。

点击箭头按钮后，Cursor 会使用这些指令为您生成自动化，并预填名称、触发器和所需工具。

我不建议将这些指令视为普通提示，而应将其当作每次运行的规范。我会在稍后展示如何构建您的第一个自动化时再回到这一点。

“我的 / 团队”切换与 + 新建自动化按钮

该切换可在您的自动化与团队自动化之间筛选。

点击+ New按钮会打开新自动化的配置页面：

+ New Automation按钮是相对于内联输入框的长表单替代方案，如果您希望从零开始手动配置触发器、指令与工具连接，可以使用它。

现有自动化列表

该表格显示我们已创建的所有自动化，包括所用工具与运行历史。

点击任一项即可打开其设置页面与运行历史：

推荐模板

在历史自动化列表下方是模板卡片网格。模板提供预构建的自动化，您可以在此基础上修改，而无需从零开始。

Cursor 自动化模板是第一天快速搭建自动化的最快方式。如果这是您的第一个自动化，我建议先查看是否有与您需求匹配的模板，再据此开始。

这些模板还能为您提供关于优质指令应如何编写、需要哪些工具或 MCP 连接的参考意见。

账号与成本考量

Cursor 自动化运行在 Cursor 的云基础设施上，需要云端智能体访问权限，该权限包含在付费方案中。每次运行会根据所用模型和执行时长消耗积分。

自动化支持三种可见性层级，详见其 权限模型：

• Private： 仅您可见，费用计入您的账户。
• Team Visible： 他人可以查看您的自动化和运行历史，但费用仍计入您。
• Team Owned。 自动化的费用计入团队共享池，由团队管理员管理。

选择正确层级很重要，因为它决定了自动化每次运行消耗谁的积分。将试验保持为私有，直到您信任其输出为止。一旦自动化成为团队工作流的一部分，您可以将其移至团队所有层级。

最主要的失败模式是在过早阶段让自动化运行得过于宽泛。如果它在一个繁忙的仓库上对每次推送都触发，很可能在您未注意到的情况下快速产生大量用量。建议从窄范围开始，让它运行几天，审查其触发频率，再决定是扩展还是缩放。

构建您的第一个 Cursor 自动化：PR 代码审查

PR 代码审查是合适的第一个自动化，因为反馈回路短，且一次错误运行的后果较小。如果智能体发布了有用的评论，我们会立刻在 PR 上看到；如果偏离主题，我们忽略即可，不会有内容被合并。

我将通过五个步骤带您构建首个自动化：

1. 连接您的 GitHub 仓库
2. 设置 GitHub 触发器
3. 编写智能体指令（结构清晰，以及需要避免的点）
4. 添加 GitHub Pull Request 评论工具
5. 部署自动化

步骤 1：连接您的 GitHub 仓库

在智能体可以审查 Pull Request 之前，它需要访问仓库。Cursor 通过原生 GitHub App 集成访问您的仓库。若未连接，自动化智能体无法查看您的代码、读取 PR diff 或给出反馈，因此无法正常工作。

如果您尚未完成：

1. 安装 Cursor GitHub App 到您的 GitHub 账号或组织，并授予其对您希望由自动化监控的仓库的访问权限。
2. 在 控制台的 Integrations 选项卡中连接您的 GitHub 账号。

连接激活后，您在配置自动化触发器时即可选择相应仓库。

步骤 2：设置触发器

在自动化控制台中：

1. 点击+ New Automation 开始创建自动化。
2. 为自动化命名。您可以命名为 PR Code Review – Open & Push – Comment Only
3. 在触发器部分，点击Add trigger 并选择 GitHub。将 PR opened 和 PR pushed 都选为触发事件。
4. 选择目标仓库。

如果您跳过了步骤 1，或这是您首次将 GitHub 连接到 Cursor 自动化，系统会提示您进行身份验证。

在下方预览中，我展示了授权完成后如何进行配置并选择目标仓库：

注意： 当不同事件触发时指令不变，我们可以将多个触发事件打包到一个自动化中。但若审查的深度或目的会因事件不同而变化，则应使用独立的自动化。

至此，自动化已知道何时运行。下一步是告诉它做什么。

步骤 3：编写有效的自动化指令

指令是决定自动化能否产出有用结果的最大杠杆。智能体依靠指令来学习什么是“好”。指令含糊，结果就会不一致。

在编写指令前，我们必须理解自己在定义什么。我们不是在给出一次性提示，而是在设定每次触发时智能体要遵循的行为。自动化的质量取决于我们对该行为的规定有多清晰。

我推荐的结构如下：

• 定义角色： 确立视角与语气。例如：“您是一名 Pull Request 的安全审查员。”
• 定义目标： 明确成功标准。例如：“发现并清晰解释真实的漏洞。”
• 限定范围： 明确智能体应聚焦何处。例如：“仅审查新增或修改的代码。”
• 梳理流程： 提供清晰的任务路径。例如：“检查变更、追踪输入并验证防护。”
• 设定排除项： 明确说明要忽略什么，以减少噪音。
• 规定行为与输出： 如何行动、结果应如何呈现。
• 设定边界： 绝不可做的事情。

编写自动化指令的方式应如同撰写 Runbook：具体、有序，具备清晰的验收标准与明确的边界。

良好指令示例

以下是我在本次 PR 代码审查自动化中使用的指令。您可以复制到您的指令输入框中，但请根据您的用例进行修改：

You are a code reviewer for pull requests triggered on PR open and push. Focus on identifying real issues that could introduce bugs, security vulnerabilities, or maintainability problems if merged. Review only added or modified code, and use surrounding context only when required to validate impact.

Check for:
- Logic errors such as incorrect conditions, edge cases, null handling, or wrong return values
- Security issues including injection, XSS, auth flaws, unsafe deserialization, or hardcoded secrets
- Contract changes such as modified APIs, response shapes, or schemas without corresponding updates
- Missing error handling or tests introduced by the change

Ignore style, formatting, naming preferences, and any pre-existing issues not introduced by this PR. Report only concrete findings with evidence from the diff, and post inline comments directly on changed lines. If no issues are found, respond: “Automated review complete: no issues found in this diff.” Do not approve, merge, push, or open PRs.技术支持

下面是在指令输入框中的样子：

该提示虽已简化，但仍遵循清晰且具体的结构。

不良指令示例

避免类似以下含糊的指令：

Review this PR and give feedback on any issues you notice.技术支持

缺少结构、约束与优先级时，智能体会被迫去猜“问题”意味着什么，导致泛泛而谈、浮于表面的反馈，而非可靠的产出。

步骤 4：添加工具

打开自动化编辑器内的工具面板。对于本次自动化，我们前往 GitHub 区域并选择 Comment on Pull Request 工具。确保关闭 PR 审批，如下方预览所示，这样自动化只能发表评论，不能批准变更。

Comment on Pull Request 工具允许智能体将发现反馈回 PR。它无需单独连接，因为该功能由您在步骤 1 授权的同一 Cursor GitHub App 提供。

如果我们希望将输出发送到其他服务（如发到 Slack），可以选择相应工具或添加 MCP 连接。对于本次自动化，评论工具已足够。

步骤 5：部署并监控首次运行

当触发器、指令与工具设置就绪后，点击 Create 保存自动化，这会打开该自动化的设置页面，如下图所示：

既然我们已部署自动化，就需要触发一次运行并观察智能体的产出。

在已连接的仓库中打开一个草稿 Pull Request。这将触发 PR opened 事件，几秒内您应能在运行历史中看到一条新记录，如下图所示：

打开该次运行并检查三点：

• 执行时长：运行耗时多久。它会随 diff 大小、模型与指令复杂度而变化。
• 工具调用：使用了哪些文件与工具？若智能体读取了不相关的文件，请审查您的指令。
• 输出：回发到 GitHub 的内容。对照您的指令进行比较。

下图是我这次自动化运行的概览。可以看到它运行了 6 分钟，执行了部分操作，并使用 PostReviewCommentOnPr 工具发布了 PR 审查：

下面是该智能体在我的 PR 上发布的示例评论：

有时输出可能不尽如人意，这通常是指令的问题。我们修改控制目标行为的那段指令，推送新的提交以触发再次运行，并审查结果。

在这些早期运行中，应尽量保持简单以降低风险。在本例中，我们将自动化限定为“仅评论”，这样可以安全地确认其行为。一旦输出稳定一致，我们将其用于真实场景，然后在 GitHub 之外连接其他工具，扩展其能力。

通过 MCP 连接更多工具

我们刚构建的 PR 审查自动化运行在 GitHub 上。它读取 diff，并通过 GitHub 的 Comment on Pull Request 工具向 Pull Request 发表评论。但如果希望智能体做的不仅是代码审查，我们需要连接其他工具——这正是 Model Context Protocol（MCP）的用武之地。

MCP 是一个标准接口，让智能体无需自定义集成即可使用外部工具。若没有它，每个工具都需要独立的设置与维护。

借助 MCP，一旦我们在自动化的工具面板中连接受支持的工具，智能体便可通过同一接口使用它们。

MCP 让同一个自动化能做更多事，并在其他工具中采取行动。您的 PR 审查自动化已能在 GitHub 上评论；添加 Slack 后，它可以向频道发布更新；添加 Linear 后，它可以创建工单；添加 Datadog 后，它可以拉取日志。每增加一个连接，都能扩展自动化的能力，而无需更改其核心逻辑。

Cursor 自动化内置了 一组 MCP 集成，如 Slack、Linear、ClickUp、Datadog、Notion 等。由于 MCP 是开放标准，我们可以用相同方式连接任何兼容工具。

您可在自动化设置页面的 Tools -> MCP server 下找到 MCP。点击 + New Connection 按钮进行浏览，然后安装并连接所需工具。

下面是添加它们的预览：

下一节中，我将指导您如何为 PR 代码审查自动化添加 Slack MCP 连接。

添加 Slack MCP 连接

GitHub 让自动化能够读取并评论我们的代码；Slack 则让它能与团队沟通。

在工具面板中，点击 Add Tool or MCP，选择 MCP Server，然后点击 +New Connection。在打开的面板中搜索 Slack，并选择 Slack MCP server。

Slack 通常已预装，若没有，请安装并按照 OAuth 流程授权您的工作区。连接完成后，它会出现在您的工具面板中，如下方概览所示：

在连接设置时我们不会选择目标频道。MCP 会赋予自动化智能体对所有公共频道的工作区级访问权限。我们通过在指令中指定频道来精确控制其发帖位置，例如：“若发现任何高或严重级别的问题，请发送一条 Slack 消息至 #pr-alerts。”

注意：Slack MCP 仅适用于公共频道，且目标频道必须先邀请 Cursor 机器人，自动化才能发帖。完成 OAuth 后，您的 Slack 工作区中应出现一个 Cursor 机器人。前往频道并运行 /invite @Cursor 以添加它。

如果您未看到 @Cursor 机器人，可能是授权失败。前往 dashboard -> integrations，点击 Slack 旁的 Manage，重新执行 OAuth。

若您想更深入了解 MCP，本平台的 FastMCP 2.0 教程将从零开始演示构建自定义 MCP server 并将其集成到 Cursor 中。

组合触发器与工具

连接了 Slack MCP 后，我们可以扩展 PR 代码审查自动化。我们保留相同的 GitHub PR 触发器和 GitHub 评论工具。但现在智能体还可以通过 Slack MCP 将严重问题发布到 #pr-alerts。

将以下区块追加到步骤 3 中为首个自动化编写的指令末尾：

Additionally:  
If you find any issue at severity high or critical, send a Slack message to #pr-alerts containing: the PR title, the author, a one-sentence description of the most severe finding, the severity label, and a link to the PR. If no high or critical issues are found, do not post to Slack at all.技术支持

最后一句话比看起来更重要。没有它，#pr-alerts 很快就会被“全部正常”的通知淹没，失去价值。在我看来，告诉智能体“何时不应行动”与“何时应行动”同样重要。

下面是我在仓库上进行测试 PR 运行的输出。

这是自动化在 GitHub 上（通过 GitHub PR 评论工具）在 PR 打开时发布的评论视图：

这是同一次运行中自动化智能体通过 Slack MCP 连接在我 #pr-alerts 频道里发送的通知视图：

至此，您已拥有一个可用的自动化：它审查每个 PR，在 GitHub 上发表评论，并将严重问题升级到 Slack。这就是核心范式。

下一节中，我们将沿用相同流程再构建一个自动化：确定触发器、编写指令，并添加智能体生成输出所需的工具。

构建第二个自动化：定时测试覆盖率监控

我们构建的 PR 代码审查自动化对 GitHub 事件作出响应。定时自动化则不同。我们定义智能体应何时运行，它会在该时刻执行，无论仓库中发生了什么。

本次要构建的自动化将在每天上午 9 点运行，审查过去 24 小时合并到主分支的代码，找出测试覆盖不足的区域，并将摘要发布至 Slack 的 #repo-coverage 频道。

设置 cron 触发器与工具

在自动化控制台中：

• 点击 + New 创建一个新自动化。
• 命名为 Daily Coverage Check – Main Branch。

配置触发器

• 在Triggers 下选择Scheduled。
• 选择Every... > Day，时间设为9:00 AM。
• 如果您需要不同格式（如仅工作日），请选择Custom (cron)
• 由于定时触发不会推断仓库，请选择目标仓库与分支（main）。

添加 Send to Slack 工具

这里，我将向您介绍自动化设置中提供的 Send to Slack 工具。它与之前使用的 Slack MCP 不同。我们用它向指定频道发送消息，而 Slack MCP 提供工作区级访问权限，并允许智能体向指令中定义的任意频道发帖。

要添加 Send to Slack 工具，请在工具部分中选择它，并指定该自动化输出的目标频道。如下所示：

为定时任务编写指令

在 PR 审查自动化中，智能体对 Pull Request 做出反应并发布反馈。对于定时自动化，则没有传入输入。智能体会自行启动任务，因此我们需要明确从哪里开始、检查什么以及发布什么。

内存工具在这里很重要。只有当智能体知道昨日数据时，覆盖率对比才有效。我们必须告诉它应读取哪个键、对比什么，以及最终要存储什么。如果不明确，结果会在多次运行间产生波动。

以下是我使用的指令集：

You are a daily test coverage monitor for this repository. Run every day at 9 AM on the main branch.
Identify PRs merged to main in the last 24 hours.For modified files, check if changed code paths have test coverage.Run tests with coverage:  pytest --cov=src --cov-report=json.Parse the report and record the overall coverage and per-file coverage for modified files.Read yesterday's coverage from memory (daily_coverage_latest: If none exists, post a green status and skip comparison.Compare coverage: If it drops by >1%, post a warning to #repo-coverage Slack Channel with today's value, yesterday's value, delta, and affected files. Otherwise, post a green status with today’s value and delta.Save today’s coverage to memory (daily_coverage_latest).技术支持

下面展示我在上午 9 点的定时自动化输出。

这是自动化的概览。在我的案例中，覆盖率保持在阈值之上，因此只是在 Slack 频道发布了“绿色”状态：

这是 Slack 消息。由于这是第一次测试覆盖率运行，我并不期待太多。同时您也能看到该次运行已保存到内存，作为下次对比的基线：

回看上述运行，指令中有两点值得注意。

第一，它同时定义了告警路径与绿色路径。绿色路径必不可少。若我们只定义“有问题时”该做什么，那么在一切正常时自动化会保持沉默。在监控频道中，沉默看起来像失败；绿色状态则确认运行已完成。

第二，对内存的读取与保存是显式的。智能体虽有内存工具，但若未指明，它并不会稳定地用于对比。若将其隐含，结果会在不同运行间波动。我们必须明确指定要读取的键、对比的内容与要保存的内容。

在下图中，您可以看到智能体保存了我的自动化：

接下来，我将介绍常见陷阱与最佳实践，帮助您更好地使用自动化。

Cursor Automations：常见陷阱与最佳实践

大多数自动化问题都源自少数可预测的错误。一旦了解它们就很容易避免，但在不清楚的情况下排查代价很高。

应避免的常见错误

• 指令含糊： 这很常见。诸如“审查代码”“检查问题”“总结变更”等表述会迫使智能体去猜您的意图，导致输出不一致。如果一句话只有动词而缺少清晰的宾语或条件，请在部署前重写。
• 范围过大： 不要把安全检查、风格检查、性能检查与测试覆盖率合并到一个自动化里。这会让问题更难定位。范围更窄的自动化更易于理解与维护。
• 跳过校准阶段： 不要在早期启用自动批准或自动合并等设置。至少让早期运行仅限评论。这些运行会暴露您代码库中的边界情况。将此阶段视为投产前的验证。
• Slack 频道配置： Slack 触发器仅适用于公共频道，因此如果 Slack 自动化看起来没有反应，请检查频道的可见性，并确保在该频道邀请了 @Cursor 机器人。

可靠自动化的最佳实践

• 一项自动化只做一件事： 每个自动化应完成一项清晰定义的任务。这使得问题更易隔离，修复更易实施。
• 从干净状态开始： 在让智能体做出更改前提交您的工作树，这样您始终可以对比清晰的 diff。
• 将前几次运行视作校准： 早期可能会有些噪音；请审查输出、调整指令并复跑，直到行为稳定。
• 使用清晰、可描述的名称： 如 PR Code Review – Open & Push – Comment Only 等名称，比通用标签在日后回顾时更有用。
• 频繁查看运行历史： 在最初几周，这能帮助您建立对“正常行为”的直觉，从而更易在后期发现问题。

结语

Cursor Automations 将智能体编码从交互式工作流转变为事件驱动系统。在 Cursor Agent 模式下，我们打开聊天并提示智能体审查代码、重构函数或调查问题；在自动化中，我们不再直接启动工作。Pull Request、Slack 消息或日程等触发器会自动启动智能体，它会自主完成任务。核心转变在于：例行工作从人工队列转移到在后台运行的系统中。

本文指导您构建了两个自动化：PR 代码审查与定时覆盖率监控。它们特意保持简单，但提供了合适的起点，因为它们在不增加复杂性的情况下展示了系统行为。一旦您熟练，便可实现更高级的工作流。

核心思路是：从一个范围狭窄的自动化开始，像写 Runbook 一样编写指令，以低风险模式运行，仅在其行为可靠后再扩展。价值不在于您构建了多少自动化，而在于每一个是否足够稳定一致。

若您想在本文基础上继续深入，以下是推荐的下一步：

• 通过我们的Software Development with Cursor 课程，加深对 Agent 模式与更广泛 Cursor 工作流的理解。
• 查看Cursor 3.0 的最新变化。