北京
Latchkey 的 CTO 兼联合创始人 Kay 在构建可自动修复 GitHub Actions 失败的产品之前，先做了一件事：从八个生产级开源代码库中拉取三个月内全部失败的 GitHub Actions 运行记录，总共 156,808 次，然后逐条阅读日志。
他原本对“红色构建”的理解很直接：有人把代码搞坏了。但读完几千条日志后，这个模型在多数场景下并不成立。
真实失败往往来自环境：包注册中心返回 500，Docker Hub 触发限流，Runner 磁盘被 Gradle 缓存占满，Node 进程触及默认堆上限后收到 SIGKILL、以 exit 137 退出，或者有人在 package.json 里改了 packageManager，导致 pnpm 不再位于 PATH 中。
这些都不是代码缺陷，也没有哪个提交能“修复”它们。正确的做法是修复运行环境，然后重新执行当前步骤。但现实是，很少有人系统性地修复这些问题，更多是开发者手动打开运行记录，翻完一堵日志墙，判断一句“这应该是 flaky”，然后点击重跑，再等 11 分钟。每个团队每天都在重复这个过程。Kay 认为，真正的成本不是算力，而是打断。
他们能写出确定性检测器的故障类别，只是“可被确定性识别”这一更窄的范围，并不等于所有故障类型。换句话说，检测器只覆盖那些能够稳定、无歧义判断为环境故障的模式，不会对所有红灯都动手。这也是很多“AI 修复 CI”方案容易翻车的地方。
一旦工具能重试步骤，重试所有东西就变得非常简单，但后果可能是灾难性的。一个只靠反复重跑失败测试直到通过的工具，不是在修复 CI，而是在给 bug 盖上绿色对勾。类似的还有 --legacy-peer-deps、pip install --no-deps 和 || true，它们都只是清除症状，却让真正的原因随代码一起上线。
因此他们定下一条边界：系统可以修复环境，但绝不能修复代码，也不能隐藏任何结果。编译错误、类型错误、断言失败、panic 等属于代码问题，不在这套系统的自动修复范围内。
这次分析最重要的结论或许是：CI 红灯并不总是产品质量信号，很大一部分是开发环境在拖后腿。修复这些问题的收益不在于省下几次点击，而在于把工程师从重复、低信息的判断中解放出来。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
