這段時間我在此電子報系列中寫了不少關於 LangGraph 的概念，也分享了幾個像 YouTube 轉貼文之類的小玩具。
雖然寫玩具很有趣 (因為都是自己想要寫，而不是被別人拿著客戶需求追著我寫的)，但作為一個打工仔，心裏始終有把聲音跟我講：
你會的這些東西只拿來做玩具不會太浪費嗎？
嗯…好像是有點？
其實幾個月之前，我就在團隊負責的一條 CI (Continuous Integration) 管道中，試著塞了一個用 AI 「猜」錯誤原因的功能。
當時的想法很簡單，其一是想找地方練練手，其二是想讓 AI 幫忙看看日誌寫個小總結，不用每次有錯誤都要點開連結打開網頁，等網頁載日誌，再搜尋關鍵字看發生什麼事。
此 AI 功能運作了幾個月，除了剛開始能用來自嗨一下之外，基本上沒什麼價值。
一個月前左右，我根據同事們的「溫柔回饋」，把整張流程圖重寫了一遍，並在昨天成功部署到 CI 上。雖然因為保密協議的關係，我沒辦法把程式碼貼上來給大家看，但我能分享一下我的思路，以及經過幾次用 LangGraph 寫 AI 應用的感受。
為什麼第一版會失敗？
在講新版的思路前，先容我介紹一下這條 CI。
這是一個跑端到端 (E2E) 測試的管道，它自動安裝公司最新版本的系統，跑一堆測試案例，然後回報結果。
我做的第一版 AI 分析器，充其量只能算是個概念驗證 (POC)，它能做的事情很少：
測試掛了 → 抓日誌 → 丟給 AI → 然後把 AI 的答案貼到 Slack 上
然而，很多時測試失敗了，AI 都只會說：
這看起來像超時，也許加長 Timeout 可以解決？
問題就在這裏：AI 說的都是廢話。
開發團隊看到「超時」這 2 個字，大概只會翻個白眼說：
我當然知道是超時，我想知道的是為什麼？是今天網絡不穩定？是系統程式碼有 Bug？還是案例本來就是個 Flaky Test？
第一版因為缺乏上下文 (Context)，AI 得到的資料少，叫它分析其實也分析不了什麼。最大的功用只是把幾十行的日誌縮短成 1-2 句的總結，算是省了工程師幾十秒去看長長的日誌。