系列：從現場踩坑到 AI 工具 — IT Diagnostic Agent 開發實錄

先問一個問題

你有沒有遇過這種情況：

問 AI「我的電腦無法上網怎麼辦？」，它給你一份完整的 12 步排障清單，但你試了前三步之後，問題就解決了。只是你不知道應該從哪三步開始。

這就是現有 AI 工具在故障排查上的核心矛盾：它什麼都知道，但不知道現在該做什麼。

我測試了三個主流 AI 的回答模式

為了設計 IT Diagnostic Agent，我花了一段時間系統性地測試 GPT-4、Claude 3、Gemini Pro，用同樣的故障情境問它們問題。

測試情境：「公司有 3 位使用者無法連線到內部伺服器，其他人正常，請協助排查。」

GPT-4 的回答模式

GPT-4 給了一份非常完整的回答，分成五大類、共 15 個可能原因，每個原因都附上了排查方法。

優點： 覆蓋面廣、邏輯清楚。
問題： 如果我是一個剛入行的 IT 工程師，我根本不知道要從哪個開始。這 15 條的優先順序是什麼？哪些可以快速驗證、哪些需要較長時間？

Claude 的回答模式

Claude 的回答更有結構，它會說「請先確認這幾件事，再根據結果決定下一步」。

優點： 比 GPT 更接近真實的排障流程。
問題： 它的「下一步」是靜態的，不會根據你的回答動態調整。你說「我確認了 A」，它不會記得，下一輪還是從頭問。

Gemini 的回答模式

Gemini 傾向於給出更精簡的回答，有時會直接說「最可能的原因是 X，建議先試試 Y」。

優點： 直接、不廢話。
問題： 太快跳到結論，跳過了「收窄範圍」的步驟，有時候猜錯方向反而浪費更多時間。

三個 AI 的共同問題：缺乏狀態記憶

這三個工具，在故障排查情境下都有同一個根本問題：

它們不記得你告訴過它什麼。

真實的故障排查是一個對話過程：

我：「3 個人不能連線。」
IT：「他們在同一個樓層嗎？」
我：「是，同一個樓層。」
IT：「有線還是無線？」
我：「有線。」
IT：「那先去看一下那個樓層的交換器，燈號正常嗎？」

每一步都依賴上一步的答案。

但一般 AI 對話工具沒有「故障排查狀態機」的概念，每次回答都是基於當前的問題，不是基於整個排障脈絡。

自由問答 vs. 結構化排障：根本上是兩種需求

我把這兩種需求列出來對比：

IT Diagnostic Agent 要解決的是右邊那欄，而不是左邊。

AI 在排障中真正有用的地方

這不是說 AI 在排障中沒用，而是它有用的地方不是「一次給完整答案」。

AI 真正強的地方是：

1. 非標準問題的語意理解：決策樹覆蓋不到的情況，AI 可以根據描述給出合理推測
2. 錯誤訊息解讀：把 Event Log 或 syslog 的原始錯誤訊息翻譯成人話
3. 指令生成：「我要查 Windows 事件 ID 4625，指令怎麼下？」這種問題 AI 很擅長

所以 IT Diagnostic Agent 的設計是：決策樹負責引導流程，AI 負責補足決策樹的邊界情況。

兩者各司其職，才能真正有用。

今天的反思

很多人看到 AI 很強，就想讓 AI 做所有事。

但「讓 AI 做所有事」往往等於「讓使用者自己想清楚該問什麼」，這在緊急故障的當下根本行不通。

工具設計的本質是：替使用者承擔認知負擔，而不是把負擔轉移給他們。

明天預告： 我會介紹 Runbook 是什麼，以及為什麼它在英文圈是 SRE 的標配，在華文 IT 圈卻幾乎沒人整理。

作者：Rich Chang | IT 基礎建設工程師 | 越南・柬埔寨・台灣