ci-speedup

CI 加速

找出从推送到部署期间变更在哪个阶段等待，用数据解决该阶段的问题，并记录有哪些变化以及何时重新检查。

• **是：**衡量变更从推送到部署期间在哪些环节等待；流水线的关键路径；检查项在各个泳道中的放置位置以及必需检查集；合并队列的容量规划或合并后的设计；主分支健康状况的检测、归因和回滚；无需人工介入、能够回滚、重新落地并修复的 Agent 式合并循环；不稳定测试的策略；部署吞吐量；每项合并变更的成本；台账。
• 不是：
  • 单个 PR 的构建失败、冲突或单次重新运行（pr-babysitter）
  • 软件包发布（autoship）
  • 检查项清单、规则执行、钩子接线、受保护路径，或无人值守 Agent 任务的沙箱规则（codebase-architecture）；此技能负责调度这些任务并决定回滚、合并和部署的合并控制器
  • 精简测试（test-audit）
  • 审查工作流差异（tidy）
  • 尚无流水线的仓库（scaffold-cli、scaffold-nextjs）
  • 要运行多少个 Agent，或编写仓库的合并风险策略（此技能读取该策略，但不负责制定）

模型

目标是X = 每小时合并并部署的变更数，同时遵守三项预算和一项硬性限制：

符号	预算
R	每周主分支红灯分钟数
C	每次合并变更的运行器分钟数：PR 运行 × 推送次数、包括已丢弃推测结果在内的队列运行、主分支运行、重跑，以及每次推送触发的审查机器人
F	从推送到作者可据以采取行动的判定结果的 p90 时间；Agent 在等待期间上下文会逐渐失效

无论 X 的代价如何，不可逆损害（破坏性迁移、基础设施问题、密钥泄露）都必须保持为零。

所有文件中使用的符号：λ = 到达率（合并次数/小时）；T = 合并路径 CI 分钟数；p = 合并后代码树上的失败率，包含偶发故障；p_mb = 头部检查通过时的合并破坏率；B = 批次大小；D = 推测深度。

找出约束。 拉取每个 PR 的时间戳：打开、就绪、头部检查通过、已批准、入队、已合并、主分支判定结果和已部署。将每个阶段标记为 WAIT 或 WORK；审查和排队时间属于等待。每周排队分钟数最多的阶段就是约束，Little 定律（WIP = λ × 周期时间）可用于核对计算。充分利用该约束，让其他阶段服从它，然后提升该约束的能力；每次修复后重新测量，因为约束会移动。如果 CI 不是约束，缩短 CI 时长只是成本杠杆，而非吞吐量杠杆。

流水线时长。 当流水线是约束时，其墙钟时间取决于最慢的依赖作业链，而不是所有作业时间的总和。若某个杠杆节省的是该链以外的运行器分钟数，它降低的是 C，而非 F，账目中应将其记为成本节省。

通道与放置位置。 每项检查都在一个通道中运行：作者推送前、PR 门禁（精确头部）、合并路径（合并后的代码树，或不运行）、合并后主分支（合并同类运行；驱动自动回滚）、部署前（精确产物）或夜间（绝不作为合并判定）。按以下顺序确定每项检查的放置位置：发布后是否会造成不可逆后果（合并前阻止，高风险层级）；是否会被合并破坏，也就是与其他 PR 合并后结果可能改变（在合并后的代码树上运行；否则仅在 PR 头部运行）；是否具有确定性（只有此类检查可驱动自动回滚）；以及它对 T 的增加量与能捕获的问题之间的权衡。分类表和 YAML 文件位于 references/lanes.md。

默认架构：不使用合并队列。 PR 根据其精确头部的检查证据合并；主分支在合并后通过合并同类运行来验证自身，因此每次运行都是一个批次；确定性失败由代码定位并回滚，重新落地、冲突和偶发故障修复则作为新任务交给 Agent；部署跟随最新的已验证提交；高风险层级、紧急停止开关和抽样审计由人工负责。这是 Anthropic 每天运行 30,000 次以上合并所采用的模式，低流量下也同样适用，此时每个批次就是一个提交。绝不要回答“要求分支保持最新”或“合并前要求主分支通过”：这两种做法都会让合并串行化。只有在红灯预算无法满足、部署无法限制为已验证提交、故障大多不可确定，或主分支无法回滚时，才切换到合并队列；切换条件和队列计算见 references/merge-path.md，GitHub 实现见 assets/github/ 和 references/github-build.md。

参考文件

文件	何时阅读
references/flow.md	步骤 1，或用户询问 PR 在哪里等待：阶段定义、WAIT 与 WORK、Little 定律、健康指标、每项合并变更的成本、解读 ci-flow.sh 输出
references/measuring.md	流水线时长是瓶颈，或步骤 5 将一次运行后的数据计入功劳：运行、作业和步骤的耗时、三个比率、关键路径、merge_group 运行、失败与重跑占比、排队时间、运行后规则
references/levers.md	选择时长优化手段：设置、执行、工具链和镜像构建方面的优化手段、每项优化成立的前提，以及需要避免的问题
references/lanes.md	放置检查；编辑 on:、if:、needs: 或 concurrency:；更改必需检查；检查未检查任何内容却仍然通过的门禁
references/merge-path.md	翻转条件是否要求使用合并队列、队列容量、积压队列、移出队列、冲突、合并策略
references/main-health.md	主分支变红，或设计检测、归因、自动回滚或重新合入机制
references/merge-loop.md	设计 Agent 式合并系统：由代码决定什么、由 Agent 修复什么、合并后批处理、Agent 任务约定、自主性阶梯、循环健康状况，以及 Agent 运行时（Claude in Actions、eve、Devin）。与 main-health.md 和 bots.md 一起阅读
references/github-build.md	在 GitHub 上安装或改造循环：将 Anthropic 的设计映射到规则集和工作流、设置顺序、控制器如何保持状态、检出成本、验证安装
assets/github/	github-build.md 安装到 .github/ 的模板：merge-loop.json、loop.sh 控制器、Managed Agents Agent 和环境，以及 pr、main-verify、merge-loop、agent-task、deploy、superfan 和 audit-sample 工作流，以及规则集和 CODEOWNERS
references/bots.md	构建或更改任何会写入内容的机器人：回滚、修复、重新入队、重新合入
references/flakes.md	间歇性失败、重试或隔离策略，以及批处理或二分之前
references/deploy.md	部署是瓶颈，或部署进度落后于合并
references/ledger.md	步骤 6：台账、流量指标趋势、合并路径决策记录、指令文件行
scripts/ci-flow.sh	步骤 1：已合并 PR 的各阶段中位数、p90 和每周分钟数，并包含 CONSTRAINT 行；--since、--base、--workflow、--environment、--json
scripts/ci-timings.sh	步骤 2，流水线：单次运行的作业、步骤和关键路径，或使用 --runs N 获取每个作业的中位数、p90、失败、重跑和排队等待时间；使用 --event merge_group 查看队列运行
scripts/ci-health.sh	步骤 2，主分支：主分支上的变红时段及其首个错误和最后一个正常的 SHA、每周变红分钟数和疑似不稳定测试

每个脚本都是只读的，接受 --repo owner/name（或 GH_REPO），并通过 --help 输出其格式。evals/evals.json 保存了用于比较更改此技能前后的场景；任务运行时不会加载它。

工作流

复制此清单以跟踪进度：

CI speedup progress:
- [ ] Step 1: Find the constraint (per-stage WAIT and WORK minutes per week)
- [ ] Step 2: Measure the constraint stage (pipeline, merge path, main, or deploy)
- [ ] Step 3: Decide with numbers (predicted X, R, C; one option; its flip condition)
- [ ] Step 4: Change it on a branch; re-time locally; dry-run every bot
- [ ] Step 5: After-measurement from the branch's own runs or a bot replay
- [ ] Step 6: Ledger, decision record, instruction-file lines, re-measure date

步骤 1：找到瓶颈

对默认分支运行 scripts/ci-flow.sh，并用一句话指出瓶颈：哪个阶段、WAIT 还是 WORK、每周分钟数，以及与下一阶段相比如何。范围明确的需求（单个测试套件、单个作业）可直接跳到步骤 2 的流水线分支。若统计窗口内合并的 PR 少于约 20 个，则根据工作流配置和用户提供的数量进行分析，并将每个数字标注为预测。

步骤 2：测量约束阶段

• **流水线：**运行 scripts/ci-timings.sh --runs 20 --workflow ci.yml，获取每个作业的中位数和 p90；然后运行单次执行形式，测量各步骤和整条链路。提出任何建议之前，先将关键路径上的每一分钟归类为工具链、门控、设置或执行。
• 合并路径：merge_group 运行会给出 T、p 和剔除数；步骤 1 中的到达数据会给出 λ。
• 主分支：scripts/ci-health.sh 会给出红色事件、R，以及哪些检查在同一 SHA 上通过后又失败。
• **部署：**将部署耗时与合并时间对照，并统计每次部署包含多少次合并。

步骤 3：用数据做决定

说明 X、R 和 C 的预测变化，给出一个推荐选项，以及会促使你改变决定的测量结果。如果墙钟时间缩短而 Runner 分钟数增加，说明大约增加多少，以及仓库是否需要为这些分钟付费。

步骤 4：在分支上进行更改

在一个分支中编辑工作流、测试和 Bot 配置，并在本地重新计时所有无需推送即可测量的内容。某项更改导致分片失败，这是一项发现，而不是跳过该分片的理由。对每个会写入数据的 Bot 进行试运行：重放步骤 2 中的红色事件，并列出它会还原、修复或重新排队的内容。构建合并循环：在 GitHub 上，按照 references/github-build.md 中的设置顺序安装 assets/github/，根据仓库调整 merge-loop.json 和设置操作，先在临时仓库中验证，然后以第 0 档上线，并且仅依据重放数据逐步提升档位。

保留保护措施。变更检测、并发组、合并检查和部署门控通常都是为应对过去的事故而设立的；调整它们的位置，但不要删除，并在保护措施旁保留引用该事故的注释。

步骤 5：查看测量后的结果

该分支自身的运行结果就是测量后的数据；在认可某项杠杆的效果前，先应用 references/measuring.md 中的运行后规则。预测与实测不符时，先查明原因，再添加另一项杠杆。若某项更改需要等待用户负责的仓库设置，则在重新测量日期获取测量后的数据，并在台账中注明这一点。重复步骤 2 至 5，直到约束转移到另一个阶段，或剩余选项需要由用户做出决定。

步骤 6：台账和决策记录

将 references/ledger.md 中的台账写入仓库文档：变更前的数据、所做更改、变更后的数据及运行 ID、流量指标趋势行、注明变更条件的决策记录、列出未采纳选项及其各自等待事项的队列，以及重新测量日期。添加指令文件中的相应行，防止布局回退。

权限和完成标准

无需事先确认即可执行以下操作，因为它们均为只读、仅限分支或可撤销：通过 gh 读取、运行脚本、本地重新计时、推送工作分支，以及创建 PR（包括还原 PR）。

以下事项由用户决定，因为它们会产生费用，或改变其他所有更改必须满足的条件：

• 费用：付费 Runner、提高计量套餐中的队列并发度或推测执行深度
• 仓库设置：规则集、必需检查、启用合并队列
• 创建 GitHub App、存储其密钥和模型密钥、创建 Managed Agents Agent 和环境、启用 Claude Code Review，以及将 MERGE_LOOP_RUNG 提升到 0 以上
• 将任何内容合并到主分支

完成意味着有一项可合并的更改、来自真实运行或 Bot 重放的测量后数据、一份注明变更条件的决策记录，以及一条注明重新测量日期的台账记录。

注意事项

• 对于 PR 几分钟内就通过 CI、随后却等待数小时才得到审核或合并的流水线，分片不会改变 X。在调整流水线之前，先用 ci-flow.sh 测量从提交到部署的耗时。
• 修复之后，瓶颈会转移：只重新计时刚修复的阶段，会显示有所改善，但 X 仍然持平。每次改动后都重新运行 ci-flow.sh。
• 在 main 上设置 cancel-in-progress: true，会在部署过程中取消被取代的运行，导致已合并的提交没有结果；在 PR 上设置，则会在后续推送到达时丢弃你自己的测量运行。只取消 PR 上被取代的运行，并等待测量运行完成后再推送。
• turbo run、pnpm -r run 和 lerna run 会跳过缺少相应脚本的工作区，因此根目录命令通过并不能证明这些工作区没问题。检查每个工作区的输出。
• 如果工作流步骤调用了包装脚本，修改工作流中的那一行不会有任何改变，因为真正的命令由包装脚本负责。重新计时之前，先找到命令实际运行的位置。

相关技能

• pr-babysitter 用于处理一个未通过、有冲突或需要重新运行的 PR，也适用于跟进这项工作创建的 PR。
• autoship 用于软件包发布及其 CI。
• codebase-architecture 用于确定应有哪些检查、如何强制执行规则、如何接入钩子、如何保护路径，以及无人值守的 Agent 任务运行在哪个沙箱中。
• 如果测试套件因包含无法证明任何问题的测试而变慢，请使用 test-audit；精简测试是它的职责，计时是本技能的职责。
• tidy 用于审查本技能生成的工作流差异。
• 如果仓库还没有流水线，请使用 scaffold-cli 和 scaffold-nextjs；本技能从时间戳入手，而新仓库没有这些时间戳。