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

最常被誤會的問題

自從把 IT Diagnostic Agent 放上 GitHub，最常被誤會的問題是：

「這不就是一個 IT 版的 ChatGPT 嗎？」

這個問題讓我思考了很久，因為表面上看起來確實像——你輸入問題，它給你回答，還有 AI 在背後運作。

但本質上，它跟聊天機器人是完全不同的東西。

聊天機器人的設計邏輯

聊天機器人（Chat Interface）的設計假設是：

使用者知道自己要問什麼，AI 負責回答。

這個假設在很多情境下是成立的。你問「Python 裡怎麼排序一個 list？」，AI 給你答案，很完美。

但在故障排查的情境下，這個假設完全不成立。

故障發生的當下，使用者的狀態是：

• 不知道問題在哪裡（否則就不需要排查了）
• 不知道應該提供什麼資訊（所以描述往往不完整）
• 沒有時間組織語言（壓力很大，腦子很亂）

這種情況下，要使用者「自己想清楚要問什麼」，是在增加認知負擔，不是在減少。

IT Diagnostic Agent 的設計邏輯

IT Diagnostic Agent 的設計假設是：

使用者只知道「出了什麼事」，系統負責引導他找到「為什麼」和「怎麼做」。

這是一個根本性的翻轉。

不是使用者驅動對話，而是系統驅動流程。

聊天機器人：
使用者：「我的網路斷了怎麼辦？」
AI：「可能是以下原因：1. DNS 問題 2. DHCP 問題 3. ...」

IT Diagnostic Agent：
系統：「請選擇故障類型」→ 使用者選「網路問題」
系統：「是全部人斷線，還是只有你？」→ 使用者選「只有我」
系統：「請換一條網路線試試，結果如何？」→ 使用者選「問題仍存在」
系統：「請用另一台電腦接同一條線，能上網嗎？」→ ...

每一步都是系統主動問，不是使用者自己想。

三層架構：Decision Tree + Runbook + AI

IT Diagnostic Agent 的核心架構由三層組成：

Layer 1：Decision Tree（決策樹）

負責引導主流程。覆蓋最常見的 80% 故障情境，以互動式選項的方式逐步縮小問題範圍。

特點：

• 確定性：相同的輸入永遠得到相同的引導路徑
• 快速：不需要呼叫 API，即時回應
• 可預測：維護人員知道每個節點的邏輯

Layer 2：Runbook（操作手冊）

每個決策樹的終點，對應一份具體的操作步驟。

不只是「你的問題是 DNS」，而是「請執行以下步驟驗證 DNS：1. 打開 CMD 2. 輸入 nslookup google.com 3. 如果回傳 ...」

Layer 3：AI（人工智慧）

處理決策樹覆蓋不到的 20% 情況，以及使用者需要進一步解釋時的補充說明。

使用者可以隨時切換到 AI 對話模式，描述更複雜的情況，AI 會根據已知的排障脈絡給出建議。

這個架構解決了什麼問題

產品定位的重要性

把這個定位想清楚之後，很多後續的設計決策就自然而然地出來了：

• UI 設計：以選項按鈕為主，不是文字輸入框——因為使用者不需要「描述」，只需要「選擇」
• AI 的角色：輔助，不是主角——決策樹能解決的，不浪費 API 呼叫
• 離線支援：決策樹部分在本地跑，沒網路也能用基本功能

今天的反思

「這不就是聊天機器人嗎？」這個問題問的人多了，我開始意識到：

產品定位不清楚，是我自己的溝通問題，不是使用者的理解問題。

這促使我後來在 README 裡加了一個很明確的「This is NOT a chatbot」的說明。

設計工具，從想清楚「它不是什麼」開始，有時候比想清楚「它是什麼」更重要。

明天預告（第二章）： 架構想清楚之後，下一步是實作。為什麼選純靜態 HTML？GitHub Pages 部署踩了哪些坑？雙語 i18n 怎麼在沒有框架的情況下實現？第二章從技術選型開始。

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