CI 失败最小修复 PR 说明
你是 CI 修复助手。根据失败 job 日志与相关 diff，起草中文「可审 PR」说明：最小修复意图、复现步骤、本地/CI 验证说明。禁止建议自动合并或绕过保护分支；禁止输出真实密钥；若属删测/加 skip/弱化断言，必须标红「破坏性改动·待人审」。
输出：
## 失败簇与根因假设
## 最小改动摘要
## 复现与验证
## 风险与标红项
## 非目标（不自动 merge、不推生产）
输入：
{{ci_failure_bundle}}场景说明
主干 CI 红灯堆积时，单人排队修测例效率低。约定一组工程 Bot：各自认领失败 job，拉取日志与相关 diff，尝试最小修复（测例、超时、依赖锁定、脆弱断言），每修一处开独立可审 PR 并附复现步骤与本地/CI 绿过说明。与 175（跨工具编排多 PR）、189（额度换可审 PR）不同：本条是多 Bot 机群专修 CI 失败。硬约束：不自动合并；密钥与生产凭据不进 Bot 上下文；破坏性改动（删测、跳过断言）须标红等人审；失败不可复现则只开诊断 issue，不瞎改。
案例叙事
01他们做了什么
X 上 X Freeze（@XFreeze）记述 SpaceXAI 工程师 Lingxi 的机群用法：五个专长工程 Bot（iOS/共享移动、桌面、Android、基础设施、Grok Bot harness）各自可拉起云端编码 Agent，检视 transcript/截图，并把失败任务打回继续修；共用 Notion PR 库，约每 30 分钟扫描失败 CI、安全发现与合并冲突——有问题则派 Agent 再修，看起来过关则触发下一轮代码审阅。帖称此前人工大约能盯约 15 个云端 Agent，机群可并行管理逾 200 个，并配合运营 Bot「Jenny」做晨间同步与剧本更新，隔夜审计后早上留下待人审的 PR。另转述团队他人自述量级（如单月大量 PR、数周内搭基础能力等）。公开帖未给出「自动合并生产」流程，也未披露生产事故率。
国内落地收成「CI 失败队列 → 多 Bot 认领最小修复 → 带复现说明的可审 PR → 人审 diff/CI 后手动合入」：同一失败簇只派一个 Bot；密钥与生产凭据不进 Bot 上下文；破坏性改动（删测、skip 断言）标红。硬约束：合入与推生产须人审；禁止自动 merge、禁止机群点合并或绕过保护分支；失败不可复现则只开诊断 issue，不瞎改。
02实际效果
- 源未披露生产环境自动合并对照下的事故率、回滚次数或主干红灯平均修复时长等量化；公开帖侧重「多专长 Bot + 定时扫 CI/安全/冲突 → 隔夜留下可审 PR」的机群叙事。
- 作者自述（帖内转述 Lingxi 机群）：五类工程 Bot 约每 30 分钟扫描失败 CI 等并打回修复；机群并行管理逾 200 个云端 Agent（相对此前约 15 的人工上限），早上留下待审 PR；并列举团队他人 PR/工期量级（帖文陈述，非我方实测，不可外推）。
- 工程团队可把堆积红灯收成「最小修复可审 PR」队列；是否合入、是否推生产仍由人依据 diff 与保护分支规则决定，机群无权自动 merge 生产。
03值得知道
- 公开源未给出可复用的 CI 修复质量基线，上线后用自有失败簇与回滚演练复盘，勿把「并行 Agent 数」写成质量或稳定性承诺。
- 硬约束：合入与推生产须人审；禁止自动 merge、禁止绕过保护分支；禁止密钥/生产凭据进 Bot 上下文；删测/skip 等破坏性改动须标红等人审；不可复现失败只开诊断 issue。
- 模型可能用跳过断言「假绿」；PR 模板强制自检「未删测、未加 skip、未改生产密钥」；同一失败簇避免多 Bot 抢修重复开 PR。
04可复制提示词
飞书/企微合入检查表
把机群开出的 PR 压成飞书/企微合入检查表（≤180 字）：PR 链接、CI 状态、是否触及删测/skip、是否含密钥变动、是否可复现。必须出现「人审后手动合入｜禁止自动 merge 生产」。不要编造通过率。
PR 摘要：
{{pr_digest}}怎么做
- 监听 CI 失败队列，按 job/包拆分给多个工程 Bot
- 各 Bot 据日志做最小修复并开带复现说明的可审 PR
- 人审 diff 与 CI 状态后手动合并；机群无权点合并或绕过保护分支
实用提示
- 同一失败簇只派一个 Bot，避免重复开 PR 抢修同一测例
- PR 模板强制勾选「未删测、未加 skip、未改生产密钥」自检项