Cursor Automations 怎么用 哪些任务别自动跑
Cursor Automations 怎么用？讲清定时、代码库事件、Slack 三类触发器，/automate 的配置方式，以及哪些任务不该交给它自动跑。
Cursor Automations 怎么用，核心是把「发完提示还得守着屏幕」换成「事件发生了它自己跑」。这篇讲清三类触发器分别对应什么、配一条要写什么，以及哪些活儿交出去反而更麻烦。
Automations 把盯着 agent 跑换成了事件触发
手动开一个 agent，你必须在场：发提示、等它跑、看结果、决定要不要合。Automations 挪走的是这个入口。官方定义是它在后台运行 cloud agent，按计划表执行，或响应来自 GitHub、GitLab、Slack、webhook、Linear、Sentry、PagerDuty 的事件，触发后由云端 agent 按你写好的指令做事并自我校验。
创建入口有四个：Agents Window 新建、打开 cursor.com/automations、在本地会话里用 /automate、或从 Marketplace 挑模板改。走哪条路都是同样五步：选触发器、写指令、勾工具、决定接不接仓库、保存激活。
计费口径先看一眼：跑出来的 cloud agent 按 cloud agent 用量算，Team Owned 记团队池，Private 和 Team Visible 记创建者个人。自动化还固定用所选模型的最大上下文窗口，没有开关可调。
三类触发器分别对应什么事件
0 9 * * 1 这种 cron 表达式是定时触发器的精确写法，界面上也有预设周期。官方对它有一条明确说明：可能延迟执行，但不会早于指定时间启动。定时之外天天用的是源码托管事件和 Slack 事件。
| 触发器类别 | 覆盖的事件 | 前置条件 |
|---|---|---|
| 定时 | 预设周期或 cron 表达式 | 不依赖任何外部服务 |
| 源码托管 | 草稿 PR 建立、PR 打开、PR 推新提交、PR 合并、推送到指定分支、PR 顶层评论 | 已接 GitHub、GitLab 或 Bitbucket Cloud |
| Slack | 频道有新消息、指定表情回应、新建公开频道 | 装了 Cursor 的 Slack 应用，只能看公开频道 |
| Webhook | 向自动化的专属地址发一次 HTTP POST | 先保存一次才会生成地址和 API key |
源码托管这一栏三家深浅不同。GitHub 是参照实现，另有 PR 与 Issue 标签变更、CI 完成、Issue 评论、PR 行内评论、review 提交、review 线程解决或重开、workflow 跑完这八条。GitLab 多两条，Bitbucket 只支持 Cloud，Server 与 Data Center 不在范围内。
开源仓库容易撞上一条限制：来自 fork 的 PR 不触发，报错原文是 Fork pull requests not supported，因为用本仓库权限跑外部代码不安全。例外是 PR 合并触发器，它从 merge commit 开始所以照常执行。Slack 那边的默认值也要留意，新消息触发不加过滤时只对频道顶层消息生效，想让线程内回复也触发得加关键词或正则。
用 /automate 一句话配出一条自动化
3.8 版（2026 年 6 月 18 日）加进了 /automate 技能。在本地 agent 会话里输入它，用自然语言描述想自动化的事，Cursor 会把触发器、指令和工具三件都配好，省掉逐项勾选。同一版还允许未配完先保存，方便中途去补 MCP 授权。
/automate 有人在 PR diff 里留行内评论时，做最小改动修掉它，
在原评论下回复改了什么，改完把这条 review 线程标记为已解决。
官方对写指令给的建议里，最容易漏的是「给一条质量线」：说明什么程度才值得开 PR、什么时候应该什么都不做。缺了它，自动化会为了有产出而硬产出。
工具栏默认勾了三项：开 PR、Memories、computer use。Memories 把跨次运行的笔记存成一个命名文件（默认 MEMORIES.md）。它的风险面官方写得很直白：自动化若处理不受信任的输入，恶意内容可能写进记忆并影响后续每一次运行。接外部 issue 或公开频道消息的，建议关掉。
computer use 让 agent 交出能看的产物
同样是 3.8 加的：自动化拉起的 cloud agent 能操作一台自己的电脑，开浏览器、访问内部服务、截图或录屏。它默认对每条自动化开启，你要做的是在指令里明确要求演示，比如改完用户可见的流程后附一段短录屏。
价值在于把「审代码」变成「看结果」。3.8 之前论坛里的抱怨很直接：没有 computer use，agent 修完 bug 你还得自己登进去凑状态、复现一遍才敢合。
前置条件是给这条自动化配好开发环境，agent 得能把服务跑起来才谈得上演示。这和普通 cloud agent 的环境配置是同一套，环境没配好时一半 PR 打水漂里记录过没配对的后果。
什么任务适合自动跑，什么不适合
Cursor 自己在跑的几条可以当参照。安全审查挂在每次推送到 main 上，只把高风险发现推到 Slack；agentic codeowners 按影响面给 PR 分级，低风险自动批准，高风险最多指派两名评审；事故响应由 PagerDuty 事件触发，agent 用 Datadog MCP 查日志、翻近期变更，再给 on-call 发消息并附候选修复 PR。
这些例子共有三个特征：输入边界明确、产出能一眼判断对错、做错成本可控。反过来，判断标准要靠上下文的任务不适合，比如「重构得更合理些」；一次动作不可逆的更不该配，自动 force push、自动改生产配置、自动发布都是。
还有一类是结构上做不到的。有人在论坛问能不能在 PR 超过 24 小时没人 review 时发提醒，官方回答是自动化需要有事情发生，而「某件事没发生」本身不构成事件；绕法是每天跑一条定时自动化，主动收集停滞的 PR 再发消息。
Bugbot 在官方叙述里被当成 Automations 的前身：PR 打开或更新时运行，每天触发数千次，上线至今抓到过数百万个 bug。
国内团队会卡在哪几步
能用的部分先说：定时和 webhook 两类触发器不依赖任何外部 SaaS，只要云端 agent 能拉到仓库就通。自建的告警系统、CI 或内部工单，都可以往自动化的专属地址发一次 POST 来触发。
卡人的是源码托管这一侧。支持列表只有 GitHub、GitLab 和 Bitbucket Cloud，Gitee、Coding 不在其中。用自建 GitLab 的团队要过四道条件：Cursor 侧需要 Teams 或 Enterprise 套餐；GitLab 侧需要 Premium 或 Ultimate，集成依赖的 project access token 在 Free 版没有；实例要接受来自 Cursor 的入站访问并能往外发 webhook；还需要管理员权限创建应用，回调填 https://cursor.com/gitlab-connected，scope 勾 api 和 write_repository。官方建议把三个地址加进白名单：
184.73.225.134
3.209.66.12
52.44.113.131
Enterprise 另有 AWS PrivateLink、Cloudflare Tunnel 和反向代理隧道三种不开入站的接法。这几条链路在国内机房的实际连通性需要自行验证。聊天侧同理：Slack 触发器要装 Cursor 的 Slack 应用且只看公开频道，飞书和钉钉不在集成列表里，想让群消息触发只能自己搭一层转发再打 webhook。跨工具补位一般靠 MCP，给团队统一配 MCP 服务和各家客户端的 MCP 能力差异可以一起看。
常见问题
不接仓库能创建自动化吗？
能。仓库范围有三档，「无仓库」这档 agent 不 clone 代码，适合只用到 Slack、MCP、webhook、Linear 或 PagerDuty 的流程，代价是改不了代码也开不了 PR。Slack 和定时触发器默认不接仓库，源码托管类必须指定。
一条自动化的用量算在谁头上？
看权限范围。Private 和 Team Visible 算创建者，Team Owned 走团队共享服务账号、算团队池。从前两档升级到 Team Owned 会换掉运行身份，带 webhook 触发器的要重新生成 API key，依赖个人 OAuth 的 MCP 也得为服务账号重配一遍。
自动化开的 PR 挂在谁名下？
团队范围的自动化以 cursor 身份开 PR，私有自动化用你自己的 GitHub 账号开。评论、review 批准和指派评审三类动作，无论哪种范围都以 cursor 身份执行，Slack 消息由 Cursor 机器人发出。