配了 Cursor Automations 之后，PR 再也不用等人 Review 了

ofox
5 阅读7分钟

上周五 Cursor 悄悄上了个新功能叫 Automations，当时没太在意，随手配了一个"每次 PR 自动 review"的规则。结果这周一打开 GitHub，发现周末两天我同事提的 3 个 PR 全被 Agent 审完了，还各留了一段挺像样的 review comment。

说实话，有点被震到。

先说结论

功能说明实用度
PR 自动审查每次开 PR 触发 Agent 审代码⭐⭐⭐⭐⭐
Slack 触发修 Bug群里说一句就开始修⭐⭐⭐⭐
定时巡检Cron 定时跑安全扫描⭐⭐⭐⭐
Webhook 自定义接外部系统事件⭐⭐⭐
自动写测试合并后补测试覆盖⭐⭐⭐⭐

一句话总结：Cursor 从"你问它答"变成了"它自己干活"，这个转变比 Background Agent 那次更大。

Automations 到底是啥

如果你用过 GitHub Actions，理解起来就很快——Cursor Automations 就是把 AI Agent 塞进了 CI/CD 管道里。

区别在于：GitHub Actions 跑的是你写好的脚本，Cursor Automations 跑的是一个有上下文理解能力的 AI Agent。它能读懂你的代码、理解你的项目结构、还能记住之前跑过的结果（有个 Memory 机制）。

核心流程就三步：

  1. 选触发器：什么事件触发（PR、Slack 消息、定时、Webhook...）
  2. 写 Prompt：告诉 Agent 干什么
  3. 配工具：给它开 GitHub、Slack、MCP 等权限

实操：配一个 PR 自动审查

这是我觉得最实用的场景，手把手走一遍。

第一步：打开 Automations 面板

进 cursor.com/automations，点 Create Automation。

第二步：选触发器

选 GitHub → PR opened。这样每次有人开 PR 就会触发。

我还勾了 Commits pushed，这样 PR 更新代码后也会重新审一遍。

第三步：写 Prompt

这步最关键，Prompt 写得好不好直接决定 review 质量。分享一下我调了好几轮才定下来的版本：

你是一个资深代码审查员。请审查这个 PR 的改动，重点关注：

1. 安全问题：SQL 注入、XSS、硬编码密钥、不安全的依赖
2. 逻辑 Bug：边界条件、空值处理、并发问题
3. 性能隐患：N+1 查询、大循环里的 API 调用、内存泄漏风险

审查规则：
- 只报告你有 80% 以上把握的问题，不要报一堆"建议优化"的废话
- 每个问题标注严重等级：🔴 必须修 / 🟡 建议修 / 🟢 可选
- 如果没发现问题，就说"LGTM"，别硬凑

输出格式用 GitHub review comment，定位到具体代码行。

第四步：开权限

  • ✅ Comment on pull request（必须，不然没法留 review）
  • ✅ Open pull request（可选，如果你想让它自动提修复 PR）
  • ✅ Memories（建议开，它会记住你项目的代码风格）

配好点 Create，完事了。

效果

我截了一个真实的 review 结果（脱敏过的）：

🔴 [严重] src/api/users.ts:47
这里直接拼接了 userId 到 SQL 查询里，存在 SQL 注入风险。
建议改用参数化查询：
- const result = await db.query(`SELECT * FROM users WHERE id = '${userId}'`);
+ const result = await db.query('SELECT * FROM users WHERE id = $1', [userId]);

🟡 [建议] src/utils/cache.ts:23
这个 Map 没有设置上限，长时间运行可能导致内存持续增长。
建议用 LRU Cache 或者定期清理。

说实话这个 review 质量，比我们团队一些人随手点的 Approve 强多了（别问我怎么知道的）。

进阶玩法：Slack 一句话触发修 Bug

这个场景更骚。配置 Slack 触发器，关键词过滤设成 bug|fix|修一下|报错，然后 Prompt 写：

收到一条 bug 报告。请：
1. 在代码库中定位可能的问题根因
2. 如果能确定修复方案，直接开一个 fix PR
3. 在原 Slack 消息所在频道回复进度

注意：如果不确定根因，只做分析不要动代码。

实测效果：同事在群里说"登录页面点注册按钮没反应"，Automations 自己去翻代码、定位到是一个 onClick handler 里的 async 没 await，然后自动开了个 PR 修了。全程 3 分钟。

定时安全巡检

另一个我在用的：每周一早上 9 点自动跑一次安全扫描。

Cron 表达式：0 9 * * 1

对整个代码库做一次安全审计，重点检查：
1. 依赖中已知的 CVE 漏洞
2. 硬编码的密钥、Token、密码
3. 不安全的 HTTP 调用（应该用 HTTPS）
4. 过时的加密算法

生成报告发送到 #security Slack 频道。如果发现高危问题，同时 @channel 提醒。

这个替代了我们之前用 Snyk + 自定义脚本搞的那一套，配置量少了 90%。

省钱技巧：模型选择

Automations 跑在 Cursor 的云 Agent 上，按 token 计费。如果你跑的任务比较简单（比如格式检查），其实不需要用最强的模型。

我的做法是对不同任务配不同模型：

# 用 AI API 聚合服务做后端的话，可以按任务智能路由

import openai

# 简单任务用轻量模型
client_light = openai.OpenAI(
    base_url="https://api.ofox.ai/v1",
    api_key="your-key"
)

# 复杂审查用强模型
client_heavy = openai.OpenAI(
    base_url="https://api.ofox.ai/v1",
    api_key="your-key"
)

def review_pr(diff: str, complexity: str):
    client = client_heavy if complexity == "high" else client_light
    model = "claude-sonnet-4-20250514" if complexity == "high" else "gemini-2.5-flash"

    response = client.chat.completions.create(
        model=model,
        messages=[
            {"role": "system", "content": "你是代码审查专家"},
            {"role": "user", "content": f"审查以下 diff：\n{diff}"}
        ]
    )
    return response.choices[0].message.content

像 ofox.ai 这种聚合接口的好处是改个 model 参数就能在不同模型间切换，不用改 base_url 和 key，同一套代码搞定。我 PR review 用 Claude Sonnet，格式检查用 Gemini Flash，成本直接砍了一半。

踩坑记录

坑 1：Prompt 太泛导致 Agent 疯狂输出

一开始我的 PR review prompt 没写"只报高把握的问题"，结果 Agent 每个 PR 都留二三十条 comment，全是"建议用 const 替代 let"这种无关痛痒的。同事直接炸了，说 review 通知快把邮箱撑爆了。

解法：Prompt 里加置信度阈值 + 严重等级分层，低于"建议修"的一律不报。

坑 2：Slack 触发器误触发

有人在群里说"这个 bug 真搞笑"（分享别的项目的 bug），结果 Automations 就跑起来了，在我们代码库里疯狂找 bug...

解法：关键词过滤改成正则，加上频道限制。我现在只监听 #dev-bugs 频道，不监听闲聊频道。

坑 3：Memory 占用越来越大

Memories 默认是开的，Agent 每次跑完都会存一些"学到的东西"。跑了一个月发现存了好几百条，有些还相互矛盾（比如早期说"这个项目用 Tailwind"，后来又说"改用了 CSS Modules"）。

解法：定期清理 Memory，或者在 Prompt 里写明"以最新一次运行的记忆为准"。

坑 4：权限配太大翻车

有一次不小心给 Automations 开了 "Open pull request" 权限，然后它在审完代码后，自作主张地把它觉得有问题的代码改了提了个 PR。改得倒是没毛病，但没人让它改啊...

解法：最小权限原则。纯 review 任务只给 Comment 权限，不给 Write 权限。

和 Background Agent 的区别

很多人搞混这两个，简单说：

Background AgentAutomations
触发方式手动启动事件/定时自动触发
运行环境你本地的项目上下文Cursor 云沙箱
适合场景一次性的大任务重复性的自动化流程
需要盯着吗最好盯着配好就不用管

Background Agent 是你的"远程结对编程搭子"，Automations 是你的"值班运维机器人"。

小结

用了一周 Cursor Automations，最大的感受是：AI Agent 终于从"对话式"进化到"事件驱动"了。

以前是你有问题去问 AI，现在是 AI 自己盯着你的代码库，有事它自己处理。这个转变看着不大，但对团队工作流的影响其实挺深的——至少我们团队现在 PR 从提交到有人看的平均时间从 6 小时降到了 3 分钟。

当然也别过度依赖，Agent 审出来的问题最终还是要人来判断要不要改。但它至少帮你把那些"一眼就能看出来但总有人漏掉"的问题拦住了。

推荐配置优先级：PR 审查 > 定时安全扫描 > Slack 触发修 Bug > 其他。先把最高频的场景自动化，效果立竿见影。

avatar
文章
阅读
粉丝