用途
experiment-arms 是一种实验臂方法，把一个想法集合变成经过测量并落地的改进。每个假设获得一个小的、可回滚的 PR（即一个 arm），它存在的唯一目的就是被测量。各 arm 与一个做同样工作的共享控制组并行运行，每个 arm 依据在查看数据之前写下的保留标准来判断。胜出项被组合成一个栈，并按仓库允许的自主级别落地。失败项变成关闭的 [negative result] PR 加一行台账记录，避免他人重复尝试。最终报告的数字来自合并后的真实流量，而不是估算值。
流程从 Loop Card（templates/loop-card.md）开始；若还没有，先运行 find-the-loop。
适用与不适用
适用：指标存在运行间噪声，且系统可按需真实运行（CI、性能测试台、评估、基准）；存在多个候选改动，或某个流行技巧尚未在你的环境中测量过；结果必须经得起“跟什么比？”的评审。
不适用：一个确定性测试即可定论的问题（直接写测试）；预期效果小于噪声底且负担不起所需样本量；系统无法按需运行（此时应观察生产环境并说明证据较弱）。
角色
协调者负责 Loop Card、假设表、台账、预算、截止时间和状态；每个 arm 一名执行者，负责一处改动、其 arm PR、测量以及带数字的 KEEP/DROP 报告；另一模型上的评审者负责批评假设表与最终栈。开始编辑代码的协调者即停止协调，应只做编排。
主要步骤
命名称职指标与统计量，使用人实际体验到的数字（如 PR 的 time-to-green 而非单个作业时长），报告 p50 与 p90，并记录不得回退的守护指标。拉取 50–150 个历史样本，拆解并找出最慢的必需通道（关键路径），写入 baseline.md。先做 A/A 测噪声：控制组对自身运行至少 3 轮，其差值分布即噪声底；若保留标准落在其中，先提高 n 或换仪器。编写假设表，每行一个 arm，列出概念、预期 Δ、是否在关键路径、风险、等价性证明、负责人；先读台账，无新理由不重跑已记录的负结果。在任何处理运行前，于 Loop Card 中预登记保留标准；默认标准为：每轮均胜过控制组、配对 Δ 中位数超过阈值且超出噪声底、配对 Δ 的 95% 置信区间不含零、等价性通过。冻结一个测量基准（分支或 SHA），所有 arm 从它分叉。按批次并行构建 arm，受层级通道上限与 budgets.max_parallel_arms 中较小者限制，硬上限 10；每个 arm 获得一个 worktree、一名执行者和一个从 lever/arm-<name> 分支创建的草稿 PR，标题为 [measurement — do not merge] <arm> 并加 do-not-merge 标签，尽早推送以便叠加。控制组必须成本匹配：执行与处理组相同的工作，在每个 arm 和控制组中加入相同的 nonce 变更，使缓存同样失效、路径过滤无法跳过通道；跳过重检查的 arm 应被拒绝。按配对交错轮次运行：每轮同时推送所有 arm 与控制组；先试 3 对，判定用每 arm n ≥ 6（小效果 12），标题数字用 n ≥ 10；少于 6 个完整配对时结论为 INCONCLUSIVE；失败或缺失的处理运行计入该 arm 而非跳过；至少 2 轮。若 main 或测试台损坏，作废该基准上所有轮次，并把修复合并进每个 arm 的测量提交后重跑。用 scripts/arm_stats.py 按第 5 步标准判定 KEEP 或 DROP（--min-pairs 默认 6，先检查可靠性再看速度）；每个 DROP 写入台账、关闭 PR 并改题为 [negative result] <arm>；流行技巧也按普通 arm 复测。按依赖再按实测价值排序胜出项，做约 5 对的整栈确认轮，因效果未必简单相加；交互不明时报告区间。按配置级别落地：打开真实 PR，在确切 head SHA 上验证每个 PR，并交给 landing-plan；arm 保持 L1，胜出项按 docs/autonomy.md 解析的级别落地。合并后在 +24 h 与 +72 h 的真实流量上复测，并排发布估算与实现值。清理所有剩余 arm 与验证 PR，记录后续事项，并把实现与估算的误差反馈到下一个 Loop Card。仅在状态变化时报告，格式为 metric: x → y (Δz%)，含 p50/p90、运行/保留/丢弃的 arm 数、已用预算与证据级别。
可调参数
指标与统计量、保留标准（绝对、相对、成本或可靠性且无回退）、A/A 轮数（默认 3）、每 arm 配对数（试 3 → 判定 6 → 标题 10+）、轮数（默认 2）、最大并行 arm 数（硬上限 10）、API 速率下限（剩余核心调用低于 3,000 时暂停）、轮询间隔（≥ 4 分钟，仅按 head SHA 查询）、每 arm 集驱动数（默认 1）、计算预算（按 arm 报告计费分钟，成本未知时写 unknown 而非 $0）、重跑策略（失败作业最多按人工方式重跑 2 次并计入指标）、基准损坏策略、arm PR 形式（草稿 + do-not-merge，交接时关闭；仅测试台指标可用本地 arm）、负结果处理、胜出项合并权限与截止时间、合并后复测时点。
产出
baseline.md（历史 p50/p90、关键路径、噪声底）；假设表与台账；每个 arm 一个草稿 do-not-merge PR，丢弃项为关闭的 [negative result] PR；带前后对比表、成本差与风险的真实 PR 栈；最终报告（估算与实现、p50/p90、n、成本差）。
该技能自身的反馈循环
估算误差（合并后实现 Δ 与合并前配对 Δ 的偏差）、命中率（保留 arm / 总 arm，接近 100% 说明标准过松）、重复负结果（应为 0）、预算事故（速率耗尽与执行器饥饿，应为 0）。
它防止的失败模式
以历史而非配对控制组作比较，或使用跳过真实工作的廉价控制组；以 n=1 或噪声底内差值宣布胜出；能并行却逐个等待；削弱信号的加速（减少测试、跳过通道、重试掩盖失败）；耗尽共享 API 配额或执行器池；重复团队已否证的思路；把预测当结果报告。
背景案例
某跨两仓库的 CI 提速项目中，79 个 do-not-merge 实验 PR 在约 1.5 天内产出 27 个保留改动；合并后真实流量上 p50 time-to-green 分别下降 43% 与 34%。首个控制组是空提交，路径过滤跳过重通道，2.25 分钟即变绿——控制组必须做与处理组相同的工作。项目起于一个流行的 Windows Dev Drive 技巧，它在两次配对运行中均失败并破坏检出凭据；同时“缓存损坏”实为页面文件耗尽（失败率 15.2% → 0%），速度工作也发现了可靠性缺陷。智能体轮询 CI 曾在 3 小时内发出约 4.5 万次 API 调用并拖垮无关工具，速率下限、轮询间隔与 arm 上限由此而来。