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

一切從一個下午的挫敗開始

那是一個普通的星期三下午，辦公室的網路突然斷了。

不是完全斷，是「某些人能用、某些人不能用」那種最難搞的斷法。

我打開瀏覽器，問了 ChatGPT：「公司網路部分使用者無法上網，可能原因是什麼？」

它給了我一份漂亮的清單：

• DNS 解析問題
• DHCP 衝突
• VLAN 設定錯誤
• 防火牆規則
• 交換器 Port 問題
• ...（還有七條）

每一條都正確。每一條都沒辦法直接用。

因為它不知道我的網路架構、不知道哪些人斷線、不知道我剛才已經 ping 過 gateway 了。它只是在「回答」，而不是在「排障」。

自由問答 vs. 故障排查，是兩件完全不同的事

我在 IT 這行做了二十年。從台灣到越南、柬埔寨，管過工廠、辦公室、飯店的基礎建設。

這二十年裡，我處理過的網路故障、伺服器當機、AD 帳號問題，少說也有幾千件。

每一次排障，其實都是在走一棵決策樹：

1. 收窄範圍：是全部人還是部分人？是有線還是無線？
2. 定位層級：是 L1（線路）、L2（交換器）還是 L3（路由/防火牆）？
3. 驗證假設：ping、tracert、查 log、看 DHCP 租約。
4. 執行動作：重啟服務、換線、改設定。

這個流程不是靠「聰明」，是靠經驗的結構化。

AI 工具很聰明，但它不知道「現在應該問哪個問題」。

為什麼我決定自己做一個工具

市面上有很多 IT 工具、ITSM 系統、知識庫平台。

但我觀察到一個現象：這些工具，現場工程師很少主動用。

原因很簡單——障礙發生的當下，你沒有時間去搜尋知識庫、打開 ITSM 系統開票、等待指派。

你需要的是：一個能立刻告訴你「下一步該做什麼」的東西。

這就是 IT Diagnostic Agent 的起點。

第一行程式碼不是 HTML，是一張流程圖

很多工程師遇到問題的直覺反應是：「我來寫個程式解決它。」

我以前也是。

但這次我做了一個不同的決定：先不寫程式，先畫流程圖。

我在腦海，開始回想之前排障經驗，並在腦中畫流程圖：

網路故障
├── 全部人斷線
│   ├── 能 ping 到 gateway？
│   │   ├── 能 → 問題在 gateway 外（ISP / 防火牆）
│   │   └── 不能 → 問題在內網（交換器 / DHCP）
│   └── ...
└── 部分人斷線
    ├── 同一樓層？同一交換器？
    └── ...

這張流程圖，才是 IT Diagnostic Agent 真正的第一版。

產品思維先行，程式只是實現方式

這個決定改變了整個專案的走向。

因為我先想清楚了：

• 誰在用：現場 IT 工程師、不一定有深厚技術背景的維護人員
• 什麼情境：障礙發生的當下，時間緊迫
• 需要什麼：快速引導、下一步動作、不需要背景知識也能用

有了這三個答案，後來所有的技術決定都變得很清晰：

• 為什麼用純靜態 HTML？因為不需要帳號、不需要網路（可以本地跑）
• 為什麼加 AI？因為決策樹覆蓋不到的情況，AI 可以補
• 為什麼支援多語言？因為現場工程師不一定看得懂英文文件

程式是最後才決定的事，不是第一步。

今天的反思

如果我當初直接打開 VS Code 開始寫，現在的 IT Diagnostic Agent 大概會是一個功能很多、但沒人想用的工具。

因為我會優先解決「我想解決的技術問題」，而不是「使用者在現場真正遇到的問題」。

這個教訓不只適用於 IT 工具，適用於所有你想做的任何東西。

明天預告： 我會深入分析現有 AI 工具在故障排查上的根本限制，以及為什麼「太會回答」反而是個問題。

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