Cursor 自动修复 PR 评审意见：谁来复核
Cursor 自动修复 PR 评审意见的完整链路、触发器的平台范围、哪些意见该交给 agent，以及改完之后 CI 与二次评审怎么兜底。
评审人留了句「这个变量名换掉」，几分钟后 PR 分支上多出一条 commit，线程里也回复了。Cursor 自动修复 PR 评审意见能省掉这轮往返，但改完的代码仍然算在提交人头上。
一条意见从留言到被改完的六步
官方 Marketplace 上的模板叫 Autofix PR review comments，配置极简：一个触发器（PR Review Comment），一个工具（PR Comment）。模板自带的 prompt 把执行过程写死成六步。
第一步读触发事件的 payload，取出评论作者、评论正文、评论 URL 和 PR 编号。第二步在需要时用评论 URL 或 gh 命令拿到文件路径和行号。第三步判断这条意见要什么，模板列的类别是 bug、风格、漏判、命名。第四步查看周边代码，做最小的正确改动。第五步 commit 并推到已有的 PR 分支，明确禁止另开 PR。第六步在评审线程里回复改了什么，完全解决就把线程 resolve 掉。
官方 workflows 页把这条链路概括成三个动作：触发、调查、回报。回报的产物只有两种，一条改好的 commit，或者一句说明为什么需要人接手。
触发器的平台范围比想象中窄
源码类触发器分两档。核心触发器 GitHub、GitLab、Bitbucket Cloud 三家都有，包括草稿 PR 创建、PR 创建、PR 有新提交、PR 合并、推分支、PR 顶层评论。
这条自动化依赖的不是核心触发器。diff 行内评论对应的 PR review comment 属于 GitHub 独有的扩展触发器，和 Issue comment、PR review submitted、Review thread updated、Workflow run completed、CI completed、标签变更一起，在 3.8 版本（2026 年 6 月 18 日）加入。GitLab 在核心之外只多了标签变更和 MR 批准两项，Bitbucket 只多了 PR 批准一项，且支持范围限定在 Bitbucket Cloud，Server 与 Data Center 不支持，也没有行内评审评论触发器。
还有一条限制值得写进团队约定：来自 fork 的 PR 不触发自动化，报错文案是 Fork pull requests not supported，官方解释是分支只存在于 fork 上，用仓库权限跑外部代码不安全。例外只有 PR 合并触发器，它从合并提交开始。
哪些意见适合让它先改一遍
模板的两条硬约束划出了适用面：只改这条评论要求的代码，并且沿用现有写法。符合这个形状的意见大致是命名、格式、明确点名的重复模式、评审人已经写清楚怎么改的漏判分支。
官方给的调优建议里有一条挺实在：把触发范围先收窄到一个仓库、一个分支或者一个标签，跑顺了再扩。还有一条是把质量线提高，不自信的时候让它留评论而不去动代码。
批量放开的风险在另一头：一堆机械小改动把 diff 撑大，评审人越读越快，最后谁都没真看。同一类取舍，怎么避免 AI 生成一堆废代码 里聊过。
哪些必须留给人
模板 prompt 自己就把线划出来了：意见含糊、属于设计问题、需要人的判断时，回复说明哪里有歧义，禁止猜；改不动就讲清楚缺什么条件；不许批准 PR，不许顺手处理无关评论。
对应到实际评审，架构走向、边界条件的语义、性能与可读性的取舍这三类该留给人。这类意见一句话背后往往压着没写出来的前提，比如某个字段为空是业务允许的状态还是上游 bug，agent 从 diff 附近的代码看不出来。
有一种折中办法：让 agent 先把这条意见涉及的调用链和触发条件查清楚、贴在线程里，人看完再决定改法。这种「先定位再动手」的用法，和 用 Cursor Agent 模式排查问题 里的思路是一致的。
改完谁复核：CI 和二次评审省不掉
Bugbot Autofix 的官方博客给了一个数字：超过 35% 的 autofix 改动被合进原 PR。反过来读，多数自动改动没被直接采纳。同一篇还提到，合并前的问题解决率从 52% 涨到了 76%。
CI 这一层要看清楚判定口径。Bugbot 在 GitHub 上发一个名为 Cursor Bugbot 的 check，问题发现默认是 neutral 结论，所以把这个 check 设成分支保护必需项，只能保证评审跑过，并不会因为存在未解决的发现而拦下合并。开了 Autofix 之后 GitHub 还会多出一个 Cursor Bugbot Autofix check，那个只有 success 和 neutral 两种结论。
写回策略也决定复核成本。Create New Branch 是官方推荐档，修复进单独分支；Commit to Existing Branch 直推 PR 分支，每个 PR 最多尝试 3 次以防打转。
责任归属最后落在身份上。GitHub 评论、批准和指派评审人都以 cursor 身份发出，团队所有的自动化开 PR 也是 cursor，而 private 自动化开 PR 用的是你自己的 GitHub 账号。云端 agent 交回来的东西怎么收，云端 agent 环境没配好会交出半成品 PR 里有更具体的例子。
自建 GitLab 和 Gitee 的团队怎么替代
两套能力的仓库接入范围不一样，别混着算。Bugbot 文档列出的接入方式包括 GitHub（含 Enterprise Server）、GitLab（含 Self-Hosted）、Bitbucket（含 Data Center）。Automations 的源码触发器文档只写了 GitHub、GitLab、Bitbucket Cloud，并明确排除 Bitbucket Server 与 Data Center。自建 GitLab 在 Automations 侧是否可用，文档没有明说，需要自行验证。Gitee 不在任何一张列表里。
用不上原生触发器的团队，有三种替代路径。
第一种是 webhook 触发器。Automations 支持 webhook 类型的触发器，自动化保存之后会生成一个私有 HTTP 端点和一把 API key，向它 POST 就能启动一次运行。自建 GitLab 的评论事件可以经内部服务转发过去。要留意 payload 结构跟模板 prompt 假设的 GitHub 字段对不上，prompt 得跟着改写。
第二种是本地跑 /review-bugbot。它在 Cursor 3.7 及以上和 cursor.com/agents 可用，会记下被评审 diff 的 patch ID，后续远端 Bugbot 看到同样的 patch ID 会跳过重复评审。
第三种最笨也最稳：把评审意见连同文件路径、行号原样贴进本地 agent 会话，让它照模板那六步走一遍，改完自己 push。少了自动触发，但责任链条反而更清楚。
上线之前先定的四个设置
权限范围顺带决定计费。Team Owned 用团队共享服务账号运行，用量记团队池；Private 和 Team Visible 记在创建者头上。从 Private 升到 Team Owned 会换运行身份，用了 webhook 就要重新生成 API key，靠个人 OAuth 的 MCP 也得换成团队服务账号的凭据。
工具面保持最小。Comment on pull request 默认只能发评论，打开 approvals 之后 agent 才能批准、request changes 和撤销评审。想让二次评审有意义，这个开关就别开。
仓库范围是必填项。源码触发器必须指定单仓库或多仓环境，其余触发器默认不带仓库，不带仓库的自动化改不了代码也开不了 PR。
最后一项容易被忽略：Memories 默认开着，跨运行持久化，默认写在 MEMORIES.md 里。文档提醒处理不可信输入时要当心，恶意输入可能写进记忆并影响后续运行。评审评论恰好是外部可写的入口，仓库对外开放时把这项关掉更省心。