把系統 Log 全丟給 AI 寫報告？一場因「無腦依賴 AI」引發的客訴災難

最近，我的團隊發生了一場因為「盲目依賴 AI」而引發的職場災難。主角不是剛入職的菜鳥，而是一位資深工程師；他因為無腦使用 AI，沒有進一步追查系統問題的根本原因，最終讓問題發酵，換來了客戶的嚴厲客訴。

透過這個真實發生的血淚故事，我想和大家重新探討我們與 AI 的關係：AI 到底是用來幫助我們的「工具」，還是反而讓我們喪失思考能力的「毒藥」？

一場由 CPU 99% 引發的系統異常

故事是這樣的。某天，我們的服務團隊接獲客戶緊急通知：團隊開發的系統突然當機了。經客戶初步查修後，發現資料庫伺服器（Database Server）的 CPU 使用率飆升到了可怕的 99%，系統資源被徹底榨乾，導致服務全面停擺。

接獲通報後，我們立即派出負責該系統的資深工程師進場處理。

看到 CPU 使用率過高，這位資深工程師直覺的反應是「重啟相關服務」，希望能藉此釋放資源，讓 CPU 恢復正常水平。事情確實如他所願，在重啟了幾個服務後，系統順利恢復了運作。

然而，這次當機影響了眾多使用者，客戶當然不可能接受「重啟治百病」的作法。他們嚴格要求我們交出一份詳細的事故報告，釐清問題發生的根本原因，並制定具體的改善方案，以防止未來再次發生。

從 IT 管理的角度來看，客戶的要求極其合理且必要。找出真正的原因，才能避免未來爆發更嚴重的災難。

事故解決後，這位資深工程師很快地提交了一份報告給客戶。但沒想到，客戶收到報告後，立刻氣急敗壞地聯繫我要求給個說法。我趕緊調閱那份報告，這才發現，這是一份明顯由 AI 生成、且毫無邏輯可言的「災難級報告」。

那些看似精美，卻讓人啼笑皆非的 AI 報告

我第一時間找來這位資深工程師了解狀況。他坦白告訴我，事故發生後，他看了半天系統的 Log（系統紀錄），卻依然毫無頭緒，不知道到底發生了什麼事。

於是，他靈機一動，直接把所有的系統 Log 複製貼上丟給 AI，並下指令：「請根據這些 Log 幫我寫一份事故原因說明報告。」

AI 快速閱讀了這些 Log 後，瞬間產出了一份排版精美、看似專業的報告。這位工程師看都沒仔細看，就直接把它發給了客戶。

這份由 AI 生成的報告到底出了什麼問題？我總結出以下三大致命傷：

1. 只描述了「現象」，卻沒有給出「原因」

報告中煞有其事地寫著：「事故原因是 Connection Pool（連線池）耗盡」，或是「短時間內有大量系統請求導致崩潰」。

這聽起來很有道理，但客戶想知道的是：「為什麼無緣無故會出現大量請求？」 是系統遭到駭客攻擊了嗎？還是程式碼有 Bug 導致無限迴圈？報告對此隻字未提。

2. 提出了「解決方案」，但邏輯讓人滿頭問號

報告給出的「治本方案」，是粗暴地將系統的所有資源與參數無腦調高。例如，直接建議將 Buffer Pool Size 從原本的 2G 一口氣加大到 8G。

對於資源有限的企業來說，這種解法根本不切實際。更糟的是，報告中完全沒有解釋「為什麼 2G 不夠？」以及「為什麼改成 8G 就一定夠？」，這種缺乏數據支撐的建議，根本無法說服客戶。

3. 活在 Log 的平行時空，完全脫離現實的使用者行為

AI 是根據 Log 來說故事的，但在缺乏外部數據（如：當下有多少使用者上線、異常的造訪痕跡等）的情況下，一切推論都只是空談。

系統異常通常與現實世界的某些事件息息相關。AI 報告指稱某個時間點有大量請求，但現實中，客戶端並沒有舉辦任何活動，也沒有異常流量的痕跡。這讓報告的可信度瞬間跌至谷底，甚至顯得荒謬。

當工程師退化成「肉體機器人」

這份報告，就像是告訴客戶：「因為雨下太大所以淹水了，解決方案是把馬路無限加寬。」 這種報告不僅無法說明排水系統為何失效，給出的解法更是毫無意義。

其實，這位工程師平時的技術能力並不差，但他有一個致命傷：習慣草草了事，遇到麻煩總想找捷徑。

AI 的出現，簡直成了他逃避思考的完美避風港。只要遇到不想處理的燙手山芋，他的直覺反應就是把問題直接丟給 AI，換取一份「看似精美」的答案來交差。久而久之，他大腦裡的「思考開關」被無意識地關閉了。看著他，我甚至覺得他反而變成了被 AI 操控的「肉體機器人」——只負責搬運指令，卻喪失了身為專業工程師最寶貴的除錯與解析能力。

看著這份荒謬的報告，我除了無奈，更知道當務之急是給客戶一個真正的交代。於是，我親自帶著他和其他同事，重新把這個查修流程走了一遍。

這一次，我們沒有把幾萬行的 Log 盲目丟給 AI，而是將現實的各種情境與變數餵給 AI，讓它輔助我們思考。當 AI 提出可能的原因後，我們立刻進行實測；若驗證不符，就馬上把結果回饋給 AI，要求它修正推論方向。

我們與 AI 進行了多輪的「提出假設 ➔ 實際驗證 ➔ 給予回饋」，最終，終於揪出了導致系統崩潰的真正兇手：一段執行過慢的 SQL 查詢，加上一位因為畫面卡頓而不斷狂按「重試」的使用者。這兩者疊加在一起，瞬間塞爆了連線池，把 CPU 榨到了 99%。

找出了真正的原因後，我們立即向客戶清楚說明，並火速上線了經過嚴格驗證的修正方案，這才成功平息了這場客訴風暴。

有了 AI，你更需要學會「思考與提問」

為什麼這位資深工程師會翻車？因為他把 AI 當成了「取代自己思考」的機器，而不是「協助自己工作」的工具。

上述的災難其實完全可以避免，前提是你必須與 AI 進行有深度的互動，而不是把 Log 丟給它後就雙手一攤。以下是我總結出與 AI 協作的三個關鍵：

1. 拒絕「盲目接收」，請逐字審閱

當 AI 生成報告後，很多人只會快速滑過，覺得「看起來很專業」就直接複製貼上。這種工作態度非常危險。

我自己的習慣是，一定會仔細檢查「所有」由 AI 產出的內容。這不僅能確保我自己看懂了報告，也能及時抓出 AI 胡說八道的錯誤。

2. 不斷深思與追問，逼出有價值的答案

在閱讀 AI 產出的內容時，遇到覺得不合邏輯或看不懂的地方，絕對不能得過且過。你應該直接要求 AI 解釋清楚。

在不斷向 AI 追問的過程中，AI 會根據你的引導自我修正，讓內容越來越精準、有意義；同時，這也是你釐清自身思路的過程。這樣一來，當客戶質疑報告內容時，你才能給出合理的解釋，而不是啞口無言。

舉個例子，與其問 AI：「為什麼系統會崩潰？請給我報告。」這種無腦指令，你更應該這樣追問：「你剛剛提到連線池耗盡，但考慮到我們同時在線人數不到 50 人，這不合理。請幫我從 Log 中檢查，是否有其他原因而引起連線池被一直佔著不放，或者有沒有異常流量不斷請求服務，以此於讓我們系統的服務中斷？」

透過這種帶有自身邏輯的「引導式追問」，AI 才不會給你套版式的廢話，而是真正成為你排查問題的得力助手。

3. 補足 AI 缺乏的「現實上下文」

AI 只能看到你給它的 Log，但它不知道現實世界的狀況。

如果你在下指令時，只丟 Log，AI 很可能會誤判是「遭到大量外部攻擊」。但如果你能提供足夠的背景資訊，例如：「系統當時並無對外活動，內部只有約 30 位使用者，且早上的流量與下午並無差異。」有了這些「上下文」，AI 就能立刻排除外部攻擊的可能，且更可能往更合理的方向去排查。

後記：不要讓 AI 變成你的大腦

AI 的普及徹底改變了我們的工作方式。每個人身邊都多了一個萬能的智囊，隨著 AI Agent 的發展，它甚至成了能幫你跑腿的超級秘書。但正因為如此，作為「大腦」的我們，角色變得前所未有地重要。

現在很多科技公司都在塑造一種「AI 很簡單」的形象，彷彿只要隨便說兩句話，AI 就能幫你完成所有複雜的工作。但我想告訴大家：除非你要做的是高度重複性的日常瑣事，否則，模糊的指令永遠只會帶來平庸、甚至災難性的結果。

這讓我想到之前看過一篇關於「Vibe Coding」的文章，作者提到一個核心觀念：提示詞（Prompts）終究只是指令，如果你自己都無法清楚表達、甚至理清你的需求，再多的提示詞技巧也無法解決問題。

換句話說，在 AI 時代，我們在發出指令前，需要比過去花費「更多」的時間去思考、組織與釐清邏輯。

AI 能夠幫你寫出漂亮的文字，但只有你的「獨立思考」與「深度提問」，才能賦予這些文字真正的靈魂與價值。