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

知識的兩種形式

我在 IT 圈做了二十年，腦袋裡裝著很多東西。

但這些東西大多是「隱性知識」（Tacit Knowledge）——我知道怎麼做，但很難說清楚為什麼這樣做。

比如說：看到某個交換器燈號閃的方式，我大概知道是哪裡出問題。但如果你問我「你是怎麼判斷的？」，我可能說不清楚，只能說「做久了就知道」。

把隱性知識變成顯性知識，是做 IT Diagnostic Agent 最難的部分。

從網路故障開始拆解

我選擇從最常見的案例開始：網路故障。

這是每個 IT 工程師每週至少遇到一次的問題，也是最容易說清楚排障邏輯的類型。

第一步：收集真實案例

我回顧了過去幾年處理過的網路故障，大致分成這幾類：

1. 特定使用者無法上網
2. 特定區域全部斷線
3. 全公司斷線
4. 能連內網但不能連外網
5. 能連外網但特定服務無法使用
6. 速度很慢但沒有完全斷線

第二步：找出每類問題的「最快驗證點」

真實的排障不是逐一排除所有可能性，而是找到能最快縮小範圍的驗證點。

以「特定使用者無法上網」為例，最快的第一個問題是：

「換一條網路線，或換到隔壁 Port 試試。」

為什麼這是第一步？因為：

• 成本低（30 秒可以驗證）
• 如果解決了，節省大量診斷時間
• 如果沒解決，至少排除了線材和 Port 的問題

這個原則叫做**「最低成本、最高資訊量的驗證優先」**。

第三步：把流程畫成樹狀結構

網路故障
│
├── 特定使用者無法上網
│   ├── 換線/換Port → 解決 → ✅ 線材或Port問題
│   └── 換線/換Port → 未解決
│       ├── 其他電腦接同一條線能上網？
│       │   ├── 能 → 問題在使用者電腦（OS/驅動/設定）
│       │   └── 不能 → 問題在網路設備端
│       │       ├── 能 ping 到 Gateway？
│       │       │   ├── 不能 → 交換器或DHCP問題
│       │       │   └── 能 → 能 ping 到 8.8.8.8？
│       │       │       ├── 不能 → 防火牆或路由問題
│       │       │       └── 能 → DNS問題（能連但不能解析網域）
│
├── 特定區域全部斷線
│   ├── 該區交換器燈號正常？
│   │   ├── 燈號異常 → 交換器電源/硬體問題
│   │   └── 燈號正常 → Uplink Port 連線狀態？
│       └── ...
│
└── 全公司斷線
    ├── 能 ping 到 Core Switch？
    │   ├── 不能 → 內網核心設備問題
    │   └── 能 → 能 ping 到 Router/Firewall？
    │       ├── 不能 → Core Switch 到 Router 鏈路問題
    │       └── 能 → ISP 線路問題

決策樹的設計原則

做了幾週之後，我整理出幾個設計決策樹的原則：

1. 每個節點只問一件事
不要在一個問題裡塞兩個驗證步驟，使用者會搞混。

2. 選項要互斥且完整
每個分支的選項，要能覆蓋所有可能的情況，不留「以上皆非」的空白。

3. 終點要給出具體動作
決策樹的葉節點不能只說「可能是 X 問題」，要給出「請執行 Y 動作」。

4. 考慮非技術使用者
不是所有人都知道什麼是 Gateway，措辭要能讓非專業人員理解。

從網路到其他類別

網路故障的決策樹做完之後，我用同樣的方法擴展到其他類別：

• 硬體問題：電腦無法開機、藍白畫面、硬碟異音
• 帳號問題：AD 帳號鎖定、密碼過期、無法登入 VPN
• 印表機問題：離線、卡紙、無法找到印表機
• 軟體問題：應用程式當機、無法啟動、授權錯誤

每一個類別，都是從「最常見的症狀」出發，往下拆解到「最具體的操作」。

今天的反思

把二十年的經驗變成決策樹，這個過程本身就是一種自我審視。

有幾次我發現，我過去的某些排障習慣其實並不是最有效率的，只是「習慣了」。

把知識結構化的過程，同時也是優化知識的過程。

這或許是做這個工具對我自己最大的收穫之一。

明天預告： 決策樹確立之後，下一個問題是：IT Diagnostic Agent 跟聊天機器人有什麼本質上的不同？這個定位的釐清，影響了後來所有的設計決策。

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