自動化測試失敗時，畫面最後只留下了一行：

TimeoutError: operation did not complete within 120 seconds

AI Log Assistant 很快給出幾個方向：

• 檢查 Network
• 延長 Timeout
• 確認遠端 Service 是否忙碌

都合理。

工程師也先去看 Network。

沒有異常。

又把 Timeout 從兩分鐘拉到五分鐘。

還是一樣。

直到有人回到測試報告，從 Failed Case 一路往前看 Traceback。

第一個真正有意義的 Source Frame 出現在很前面。

一個必要的執行參數根本沒有成功建立。

後面的流程沒有正確 Target，只是不斷等一個永遠不會回來的結果。

Timeout 確實發生了。

但它只是最後被看見的 Error。

不是第一個失敗的地方。

最後一個 Error 通常最醒目

Log 從上到下跑。

人也很自然從最後一行開始看。

尤其 Error Message 如果很具體：

Connection refused
Timeout
Assertion failed
File not found

它很容易直接變成 Root Cause 的名字。

AI 也會被這個訊號吸引。

因為最後一個 Error 往往最像一個可以直接回答的問題。

但 Automation Framework 裡，一個前層失敗可能一路傳下去。

例如：

Target resolve failed
↓
Execution got empty target
↓
Remote call never completed
↓
Timeout

如果只處理最後一層，最多是讓症狀換一種方式出現。

診斷順序不是「先猜最可能的原因」

Package 裡的 Log Analysis Rule 沒有要求 AI 一開始就做 Root Cause Prediction。

順序反而很普通：

HTML / test report
→ failed case
→ traceback
→ first meaningful source frame
→ failure stage
→ deeper logs only if needed

重點不是一定要從最上面開始讀所有 Log。

而是先找到：

哪一層第一次從正常狀態變成失敗狀態？

這和「最後哪一行報錯」不是同一題。

後面的 Error 仍然有用。

它能告訴你失敗最後如何表現。

只是不能因為它最醒目，就自動把它升格成第一個 Root Cause。

多抓 Log 不一定會讓答案更準

第一次排查時，團隊還做了另一件很常見的事：

把所有 Debug Log 全開。

資料量一下多了十幾倍。

AI 也能讀。

但如果 Failure Stage 還沒定位，大量 Log 只是把更多看起來可疑的訊號一起丟進來。

所以後來流程改成：

先利用 Test Report 和 Traceback 確認哪個 Stage 先失敗。

只有那一層證據不夠時，再往更深的 Log 展開。

這樣不是為了省 Token 而已。

更重要的是，避免「資訊越多，Root Cause 候選越多」最後又回到猜測。

Timeout 沒有被忽略，只是被放回它的位置

那次問題修掉後，團隊沒有建立新的 Timeout 規則。

真正被改的是前面那個 Target Resolution。

測試再跑一次：

沒有 Timeout。

後續 Remote Call 也正常完成。

下一次再遇到一行很醒目的 Error，AI 的回答順序也改了。

它不再先列五個「常見原因」。

而是先說：

Observed final error: Timeout
First failing stage currently identified: target resolution

兩句都是真的。

差別只是從那天開始，大家不再把「最後看到的錯誤」當成「最早壞掉的地方」。