improve-feedback-loop

同时观察两类成本作为优化反馈循环的指标：

用户等待 = 排队 + 准备 + 关键路径 + 重试
计算成本 = 各项检查消耗的时间、token 与调用成本之和

以下规则是启发式基线。仓库标准、工具能力和实测数据可以覆盖其中的选择。

过程

1. 盘点：列出本地检查命令和 CI 的 job、step，分别记录排队、准备、执行、重试、输出体量和调用次数。
2. 建立基线：区分冷启动与热缓存。短命令重复测量 3 至 5 次并记录中位数与波动；昂贵 CI 使用一组近期历史运行。
3. 按总成本排序：同时比较墙钟关键路径和累计计算成本，优先处理高频且昂贵的项目。
4. 小步修改：每次只处理一两个已测量瓶颈，保留能够解释变化的数据。
5. 复测：使用与基线相同的条件重复测量。没有稳定收益，也没有可靠性或安全收益时撤销改动。

门禁节奏

• 编辑与返工循环运行受影响测试、局部类型检查和目标边界验证。
• 阶段收口运行一次完整根门禁，最终交付再运行一次。
• 协议、构建配置或共享基础设施变化时，可以提前运行更宽门禁。
• 完整门禁失败后先定向诊断。修复期间回到受影响门禁，阶段收口时再跑完整门禁。
• 受影响范围无法可靠判定时回退到完整门禁，避免假绿。

启发式基线

• 输出噪声：成功路径保持简洁，失败时输出可复现命令、关键错误和产物位置。分钟级长任务保留心跳或阶段进度。
• 冷启动：优先复用监视模式、常驻进程、语言服务和本地增量缓存。先确认启动成本确实位于关键路径。
• 缓存缺失：缓存键覆盖所有会影响缓存产物的输入，包括平台、架构、工具链、依赖锁文件和相关配置。依赖下载缓存可以使用 restore-keys；构建产物需要更严格的键，防止恢复不兼容结果。优先使用 setup-* 的内置缓存。
• 失败淹没：在门禁允许时采用增量语义，突出当前改动新增的错误。预存债务另行记录。
• 超时缺失：根据历史分布设置明确超时。超时应能区分正常慢任务和挂起风险，长任务配合心跳。
• 重试失控：只重试已分类的瞬态或不稳定失败，保留第一次失败并标记重试结果。确定性失败直接进入诊断；每次重试都要产生新证据，并设停止条件。
• 固定等待：端到端测试使用条件轮询和明确截止时间，避免固定 sleep。
• 串行关键路径：没有依赖和资源冲突的检查可以并行。并行后同时观察墙钟时间和累计计算成本。
• 提前终止：同质、冗余的矩阵可启用 fail-fast；需要一次收集多个独立诊断结果时保留其余任务。
• 缓存安全：低信任来源只读共享缓存；缓存中不保存密钥或其他敏感信息。
• 本地与 CI 分叉：本地和 CI 使用同一检查入口、锁文件与工具链配置。CI 只补充环境准备和最终门禁所需步骤。

CI 专项

• 分开查看排队时间、准备时间、执行时间、失败率与重试率。
• 快速且高信号的门禁优先；慢门禁按真实依赖并行或分片。
• 为 job 设置有依据的 timeout-minutes。
• 对已被新提交取代的检查使用并发控制，避免旧结果占用执行容量。
• 依赖、工具链和 GitHub Action 版本由自动更新机制维护。

反模式

• 为低频秒级命令引入远程缓存，维护成本超过收益。
• 每次编辑都运行完整测试套件。
• 只优化单次执行时间，忽略调用轮数、排队和重试。
• 将缓慢或不稳定的端到端测试作为高频编辑门禁。
• 依靠一次修改前后测量判断优化成败。