Cursor 新增 GitHub Actions 工作流完成触发器后，CI 失败可以自动进入日志分析、原因定位和修复建议流程。本文用一个 Node.js 项目演示如何配置自动分诊，并给出可直接复用的智能体指令和安全边界。

---

CI 红灯出现后，最耗时间的往往不是修代码

一次 Pull Request 提交后，GitHub Actions 报错了。

开发者通常要打开 Actions 页面，找到失败任务，展开日志，再从几百行输出里识别第一条有效错误。如果问题涉及依赖版本、测试环境或多个文件，后面还要切回编辑器搜索代码。

一个五分钟能修好的错误，前面的定位过程可能先花掉十几分钟。

Cursor 在 2026 年 6 月发布的自动化更新中，增加了 Workflow run completed 触发器。GitHub Actions 工作流在分支或 PR 上运行结束后，可以触发常驻智能体继续处理。官方还提供了失败 Actions 分诊模板。需要注意的是，“运行结束”不等于“运行失败”，自动化指令仍要明确过滤成功、取消和跳过状态。Cursor 更新日志

这类功能最合适的定位不是“让 AI 自动改完并合并”，而是先替开发者完成重复的第一轮分诊。

准备一个可以复现的 CI 工作流

假设项目使用 Node.js，测试命令已经写入 package.json。在仓库中创建：

.github/workflows/ci.yml

写入下面的工作流：

name: Node CI

on:
  pull_request:
    branches:
      - main
  push:
    branches:
      - main

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm test

GitHub 要求工作流文件放在 .github/workflows 目录，使用 .yml 或 .yaml 扩展名。GitHub Actions 工作流语法

这里有两个值得保留的细节：

• 使用 npm ci，让 CI 严格按照锁文件安装依赖；
• 默认只授予 contents: read，测试任务本身不需要写仓库。

如果项目没有 package-lock.json，npm ci 会直接失败。这个失败并非坏事，它把“开发环境能装、CI 环境装不了”的隐患提前暴露出来了。

用 /automate 创建失败分诊任务

更新 Cursor 后，在本地智能体会话中输入 /automate，然后描述需要自动化的任务。根据官方说明，它会据此配置触发器、指令和工具。

触发条件建议选择：

GitHub → Workflow run completed

不要只写一句“CI 失败后帮我修复”。这类指令权限太宽，也没有规定交付格式。可以使用下面这份提示词：

当 GitHub Actions 工作流运行完成时执行。

处理规则：
1. 读取 workflow、branch、commit、PR 和 conclusion。
2. 如果 conclusion 不是 failure 或 timed_out，立即停止，不创建评论或 PR。
3. 获取失败 job 和失败 step 的日志，只围绕本次运行分析。
4. 找出第一条具有因果意义的错误，不要把后续连锁报错当作根因。
5. 在仓库中定位相关代码、配置、依赖文件和最近变更。
6. 输出以下内容：
   - 失败位置
   - 根因判断
   - 支持判断的日志证据
   - 最小修复方案
   - 建议执行的验证命令
   - 当前判断的置信度
7. 置信度低于 0.8 时，只提交分析，不修改代码。
8. 不修改密钥、发布流程、权限配置和生产环境文件。
9. 不自动合并 PR，不绕过测试，不删除失败测试。
10. 如果是明显且低风险的代码错误，可以创建修复分支和草稿 PR；
    PR 中必须列出改动文件、验证结果和仍需人工确认的风险。

这份提示词的核心不是让智能体“更大胆”，而是把它的动作拆成观察、判断、修改和交付四层。

我更建议第一次运行时删掉第 10 条，只让它输出分析报告。连续观察几次，确认日志读取、根因判断和权限范围都符合预期，再允许创建草稿 PR。

判断日志时，先找第一条有效错误

下面是一段常见的测试失败输出：

FAIL tests/order.test.js
Expected: 200
Received: 500

TypeError: Cannot read properties of undefined (reading 'id')
  at createOrder (src/services/order.js:42:18)

低质量分诊可能只复述“期望 200，实际返回 500”。

有效的分诊应该继续追到：

src/services/order.js:42

检查 id 所属对象为什么是 undefined，再结合本次提交的 diff 判断是测试数据缺失、参数结构变化，还是业务代码没有处理空值。

可以把排查顺序固定成一条工作流：

这里的“第一条有效错误”很重要。编译失败后，测试、覆盖率和产物上传可能一起失败，但后三项只是连锁反应。智能体如果同时处理所有红色日志，很容易把一个简单问题修成一次大范围改动。

三道边界比“自动修复”更重要

只允许最小改动

自动化最怕顺手重构。

提示词应明确限制修改范围：不升级无关依赖、不调整公共接口、不格式化整个仓库。一个空值错误只改必要代码和对应测试，不要顺便重写服务层。

不接触生产权限

GitHub 官方特别提醒，基于 workflow_run 启动的后续工作流可能获得密钥和写入令牌；如果运行不受信任的代码，可能引入缓存投毒或意外权限暴露风险。GitHub 事件文档

因此，测试阶段应使用只读权限。任何部署密钥、发布步骤和生产配置都不应交给首次上线的自动分诊任务。

修复必须重新验证

智能体创建修复后，至少重新运行：

npm ci
npm test

项目存在 lint、类型检查和构建任务时，再补充：

npm run lint
npm run typecheck
npm run build

验证失败就保留日志，不要通过删除测试、降低覆盖率阈值或添加忽略规则制造“绿灯”。

一次合格的自动分诊应该交付什么

开发者最终需要的不是一句“发现测试失败”，而是一份可以直接做决定的报告：

失败任务：Node CI / Run tests
根因位置：src/services/order.js:42
日志证据：order.user 为 undefined，读取 id 时抛出 TypeError
关联变更：本次 PR 修改了 createOrder 的参数结构
最小方案：调用处传入 user，服务层增加输入校验
验证范围：单元测试、lint、构建
置信度：0.91
人工确认：空用户应返回 400 还是业务错误码

看到这份报告，维护者可以快速判断：直接接受修复、补充业务规则，还是交给原作者处理。

这才是自动化真正节省的时间——不是省掉敲几行代码，而是压缩从“CI 红了”到“知道该怎么修”的路径。

如果长期使用 Cursor、ChatGPT Plus、Claude Pro、Gemini Advanced、Grok 或 Kiro，也可以通过 gpt108.com 了解相应会员充值需求。它的定位是第三方 AI会员充值平台，不替代工具本身；使用前应看清套餐、账号和售后规则。

结论：先自动分诊，再逐步开放修改权限

Cursor 的工作流完成触发器值得用，但不适合第一天就接管修复和合并。

更稳妥的行动顺序是：先配置只读分诊，观察三到五次真实失败；确认它能识别根因而不是追逐连锁报错后，再开放最小代码修改和草稿 PR 权限。生产部署、密钥配置与最终合并继续保留人工审核。