簡介： 自動建置失敗後滿版紅字，可能是單一問題引發連鎖反應。本文整理查閱紀錄的順序、重跑的限制，以及AI寫程式加速後的測試瓶頸。
程式改完了，推上去等建置亮綠燈，結果螢幕整片紅。明明快下班，電腦卻剛打開一本長篇推理小說。
一百則錯誤訊息，不一定代表有一百個獨立問題。 某個設定檔讀取失敗，後面的檔案就無法產生，依靠它的工作與測試也跟著失敗。紀錄呈現的是連鎖反應。
鑰匙只掉一把，家族群組卻跳出一百則訊息
假設某個步驟找不到設定檔，下一步等不到輸出，許多測試接著出錯。這是示意情境，並非特定事件。問題看起來到處都有，源頭卻可能只在一個地方。
很像一個人弄丟家門鑰匙，全家開始傳訊息。逐則回覆無法打開門，先找鑰匙比較快。但最早出現的紅字也未必是真正原因；前面的警告，以及平行執行的不同工作，都可能藏有線索。
紀錄要從哪裡讀起？
先找到失敗的工作和步驟，然後追查設定錯誤、缺少的套件、沒產生的檔案，以及測試結果不符等能解釋後續失敗的訊息。
如果同一份程式碼有時成功、有時失敗，應檢查網路、外部服務、執行順序和不穩定的測試。偶爾亮綠燈不代表修好了。逐一修正有根據的原因，再確認同一個版本。分享紀錄給他人或AI之前，要先遮住密碼和存取金鑰。
CircleCI官方文件介紹 'circleci run get --failure-report '，可以先取得失敗步驟的精簡摘要，也能只重跑失敗的工作。少翻紀錄很有幫助，但真正的程式錯誤不會因為多按幾次重跑就消失。
AI寫得更快，為何還是難準時下班？
假設AI十分鐘就完成修改，但建置錯誤的排查和修復又花四十五分鐘，總共仍要五十五分鐘。這是假設數字，說明寫程式快與交付快是兩回事。
餐廳廚房出菜速度快十倍，收銀台卻只有一個，隊伍只會塞在出口。建置、測試和修復也可能是軟體開發的收銀台。
Google DORA的2025年研究觀察到，AI使用與軟體交付量呈正向關聯，與交付穩定性呈負向關聯。這是關聯，不是AI造成加班的因果證明。快速可靠的檢查和小幅修改更值得重視。
藏在失敗背後的加班時間
每天失敗三次，每次復原花二十五分鐘，二十個工作天就累積二十五小時。這只是範例計算，不是產業平均。可分別追蹤失敗率、恢復成功的時間、重複原因，以及沒改程式就重跑成功的次數。
工期過緊、需求改動、人力不足也會造成加班。建置失敗特別麻煩，是因為結束時間難預測。真正該減少的，是從滿版紅字中抓出第一張倒下骨牌的時間。
資料來源：
