cursor babysit pr 怎么用 迭代到可合并
cursor babysit pr 怎么用？讲清 slash 与 quick-action 触发、云端迭代到可合并的成功条件，以及与 Bugbot、Autofix 的分工。
cursor babysit pr 怎么用：在 Agents Window 对已有 PR 使用 /babysit，或点 quick-action pill，云端 agent 会在远端迭代改分支、回评论、跟 CI，本地会话不被占满。下面按官方 changelog 说明触发方式、怎样算「可合并」，以及和 Bugbot、Autofix 谁负责哪一段。
/babysit 接到 PR 后会做什么
Cursor 3.7 changelog（2026-06-17） 写：/babysit 让 cloud subagent 远程迭代，prepare PR for merge，且不占用 local session。Subagents 文档补充：可点 quick-action pill 或输入 slash，agent 在云端 VM 上持续改代码、推 commit，直到 merge 前置条件满足或需要人工介入。
与 /in-cloud 派「下一条通用任务」不同，babysit 绑在已有 PR 上，目标是让 diff 从「开了 PR」走向「检查通过、评论处理完、冲突解决」。父 agent 仍可在本地或云端并行，babysit 在后台跑。cloud subagent 的 MCP 来自 cursor.com/agents 团队配置，遵循与其它 Cloud Agents 相同的 environment 规则。
官方措辞是 iterate remotely to prepare your PR for merge，重点在「远程迭代」和「不占本地会话」。你仍可继续在 IDE 里写别的功能、开另一条 agent 线程；babysit 则在云端 VM 上读 PR 状态、推 commit、回复 review。若 CI 失败，agent 理论上会再改再推，直到满足你写在指令里的停止条件或触达平台限制。
两种触发入口
官方给出两条等价路径：会话内输入 /babysit，或在 PR 相关界面点 quick-action pill。二者都启动 cloud subagent，不阻塞当前本地窗口。
实操上建议在 PR 已 push、基础 CI 已挂上的阶段再 babysit，否则 agent 可能在空分支上打转。环境快照写在 .cursor/environment.json 里时，云端 boot 更快；没有 snapshot 时，每次迭代可能重复装依赖，拉长 babysit 周期。
babysit 按 cloud agent 用量计费，长迭代会多烧 token。想控制成本，可在指令里写清停止条件，并对照 cursor 云端 agent 怎么省 token 里的 MCP 挂载原则，避免云端 agent 带无关工具空转。
可在 babysit 指令里显式列出 merge criteria，例如「所有 required check 绿且未 resolve 的 review thread 为零再停」。官方 changelog 没给默认模板，指令质量决定 agent 会不会为「有产出」而硬改无关文件。PR 若处于 draft，先确认团队是否希望 draft 阶段也跑 cloud 迭代，避免与人工 review 节奏冲突。
成功合并前的条件清单
官方 changelog 只写到 prepare for merge，没有逐条枚举成功标准。结合文档与 Jigar Joshi 的二手解读（非官方，仅供参考），可把「babysit 算成功」压成下面清单，写进你的 babysit 指令里：
- required CI checks 在 PR head 上全绿。
- 评审 thread 已回复；能 resolve 的已 resolve，设计争议处留说明等人拍板。
- 与 base 分支无未解决冲突，或 agent 已推 merge 修复 commit。
- diff 未偷偷扩大 scope；若需求蔓延，agent 停手并在 PR 留言 @ 人。
- 无新增密钥或明显安全问题（可要求 agent 跑 secret scan 或依赖现有 CI）。
清单第 4、5 条官方未写死，属于团队治理习惯。babysit 不会自动替代人工 approve；branch protection 仍按平台规则拦合并。
可把清单写进 PR 描述或 babysit 首条提示，让 agent 每轮 push 前自检。CI 侧注意区分「检查跑过」与「结论 success」：某些 Bugbot check 默认 neutral，不算失败但也拦不住合并，别误以为 babysit 成功就等于 review 完结。冲突 rebase 若超出 agent 权限或触发保护规则，应在 PR 留言说明并等人处理，而不是无限重试。
Bugbot、Autofix 与 babysit 谁干什么
三条链路都碰 PR，但阶段不同：
| 能力 | 典型触发 | 主要产出 |
|---|---|---|
| Bugbot | PR 更新时自动或 cursor review |
审查评论、CI check |
| Autofix | review comment 等自动化事件 | 按单条意见最小改动 + 回复 |
| /babysit | 会话 slash 或 pill | 多轮迭代直至 merge 就绪 |
Bugbot 负责「找问题」：分析 diff、留带 Fix 链接的评论，默认不自动改代码。开启与触发方式见 Cursor Bugbot 怎么开。Autofix 负责「按条修评论」：Marketplace 模板在 PR review comment 事件上跑六步改码流程，见 Cursor 自动修复 PR 评审意见。
babysit 是更长的 stickiness 环：CI 红了重跑、多条评论分批处理、冲突 rebase 可能串在同一 cloud 任务里。适合 PR 已开、后续还有多轮往返的场景。单条行内意见且 Automations 触发器已配好时，Autofix 更轻，因为它只在 review comment 事件上启动、改完即停。只想审不改，用 Bugbot。
三者可叠加：Bugbot 找、Autofix 或 babysit 改，人最后点 merge。典型分工是：开 PR 后 Bugbot 自动审一轮；评审人留五条行内意见，其中三条机械的交给 Autofix 自动化；剩余两条加 CI 波动，再对整 PR 开 /babysit 收底。babysit 不适合替代 Bugbot 的首次扫描，也不替代 Autofix 对单条 comment 的精确响应，它补的是「多因素同时未就绪」的长尾。
不适合交给 babysit 的情况
下列场景即使用了 /babysit 也难收尾，或风险高于收益：
- PR 描述含糊、成功标准随对话漂移，agent 容易无限扩 scope。
- 改动触及架构走向、权限模型、性能 SLA，需要产品或 owner 签字，babysit 不能代替 approve。
- 环境未收口：无 snapshot、测试命令靠 README 三页 shell，云端每轮 boot 加失败重试，token 和时间都亏。
- fork PR 或平台限制导致 cloud agent 无写权限，迭代会卡在 push。
- 期望 babysit 替代 code review：它准备 merge 前置，不保证业务正确。
若只是「一条命名意见」，用 Autofix 自动化比 babysit 整 PR 更省。若 PR 尚未开、还在本地改，先用 /in-cloud 派通用任务，别过早 babysit 空 PR。
国内团队额外留意：cloud agent 写回 PR 依赖 GitHub/GitLab 集成与云端 egress，控制台与托管平台连通性需自行验证。fork PR 在 Automations 里已有「Fork pull requests not supported」限制，babysit 若遇到无写权限分支同样会卡在 push。长 babysit 迭代前确认 snapshot 与测试命令与 CI 一致，否则 agent 可能在云端测绿、平台 CI 仍红，浪费多轮 token。