简介： 一次构建失败却出现几百行红字，往往是连锁反应。了解如何阅读日志、什么时候重跑有用，以及 AI 写代码提速后可能出现的修复瓶颈。
代码写完，提交后只等构建变绿。结果终端刷满红字，到了下班时间，电脑却像刚开始播一部悬疑连续剧。
一百条报错不等于一百个独立故障。 配置文件没读到，后面的文件就生成不了，相关检查又接连失败。日志记录的是整串后果。
一个人丢钥匙，全家群聊炸出一百条消息
假设某个步骤找不到设置文件，下一步等不到结果，随后许多测试一起报错。这是说明原理的假设场景。表面上到处都坏了，源头可能只有一处。
就像一个人把家门钥匙弄丢，家庭群马上多出一百条消息。逐条回复不如先找钥匙。不过，最早出现的红字也不一定是真凶：前面的警告，或多个并行任务各自发生的问题，都值得检查。
先看失败步骤，再追连锁反应
先找失败的任务与具体步骤，寻找能解释后续问题的消息：配置错误、依赖缺失、文件未生成，或者测试结果与预期不符。
同一版本有时成功、有时失败，就要调查网络、外部服务、执行顺序和不稳定的测试。一次重跑成功只是线索，并不代表彻底修复。每次修改一个有根据的原因，用同一版本复查。把日志交给他人或AI前要遮盖密码和密钥。
CircleCI官方介绍了 'circleci run get --failure-report '，可汇总失败步骤的精简记录，也支持只重跑失败工作。少读无关日志能节省时间，但点击重试无法修复真正的代码错误。
AI 写得越快，为什么还可能加班？
假设AI用十分钟写完修改，构建错误的排查和修复又用了四十五分钟，总共仍是五十五分钟。这些只是示例数字，但写代码快，不等于交付完成也快。
就像厨房出菜快十倍，收银台只有一个，长队只会挪到出口。构建、测试和修复可能成为开发中的收银台。
Google DORA在2025年的研究中观察到，AI使用与软件交付量呈正向关联，与交付稳定性则呈负向关联。这是相关性，不是AI直接造成加班的证据。小步修改、可靠测试和及时反馈因此更重要。
别只统计写代码的时间
若每天失败三次，每次恢复用二十五分钟，二十个工作日就会花二十五小时。这是示例计算，不是行业平均。团队还应跟踪失败率、恢复到成功的时间、重复出现的原因，以及原样重跑就通过的情况。
紧张的排期、不断变动的需求、人手不足也会带来加班。构建失败尤其烦人，因为很难预测什么时候能结束。真正耗时的也许是从一百条报错中找到最初倒下的那块骨牌。
资料来源：
