身為在越南、柬埔寨、台灣三地跑的 IT 工程師,最常遇到的狀況就是:
凌晨被電話叫醒,腦子還沒清醒,就要開始排查「全公司斷網」或「Exchange 郵件全卡住」。
市面上的 IT 診斷工具幾乎都是英文,而且大多數是 SaaS 訂閱制,對中小企業來說成本不低。更重要的是,很多企業有資安疑慮,不想把內部 IT 問題送上雲端。
所以我做了這個:IT Diagnostic Agent — 互動式決策樹 + AI 診斷,純靜態 HTML,可以完全離線部署。
👉 https://richchang0721-boop.github.io/it-diagnostic-agent
📦 https://github.com/richchang0721-boop/it-diagnostic-agent
| 系統 | 涵蓋範圍 |
|---|---|
| Active Directory | 帳號鎖定、GPO、DC 複寫、FSMO 轉移 |
| SQL Server | 連線失敗(error 18456)、效能優化、備份還原 |
| Exchange Server | 郵件佇列、SPF/DKIM、遷移至 M365 |
| Office | ODT 部署、KMS 授權、修復安裝 |
| Outlook | Autodiscover、OST 修復、OAuth 2.0 |
npm install,不需要後端,下載就能用index.html,約 1,500 行。
為了讓工具不被單一 AI 服務綁死,使用 Adapter Pattern 設計 LLM 呼叫層:
// 統一入口,不管背後是哪個模型
async function callLLM(messages, systemPrompt) {
switch(currentProvider) {
case 'claude': return await callClaude(messages, systemPrompt);
case 'gemini': return await callGemini(messages, systemPrompt);
case 'openai': return await callOpenAI(messages, systemPrompt);
case 'ollama': return await callOllama(messages, systemPrompt);
}
}
目前支援四個 Provider:
| Provider | 說明 | 需要 API Key |
|---|---|---|
| Claude (Anthropic) | 預設,診斷品質最佳 | ✅ |
| Gemini (Google) | 速度快,成本低 | ✅ |
| OpenAI 相容介面 | 支援任何 OpenAI 格式的服務 | ✅ |
| Ollama(本地) | 完全離線,零成本,隱私無疑慮 | ❌ |
對有資安疑慮的企業,可以用 Ollama 在本機或內網跑模型:
# 安裝 Ollama
curl -fsSL https://ollama.com/install.sh | sh
# 下載模型(推薦 Gemma 3)
ollama pull gemma3:12b
# 啟動服務
ollama serve
工具設定填入 http://localhost:11434,不需要任何 API Key,完全離線運作。
所有文字都存在一個 i18n 物件裡,切換語言只需要重新渲染 DOM:
const I = {
zh: { navNet: '網路問題', navHw: '硬體問題', ... },
en: { navNet: 'Network Issues', navHw: 'Hardware Issues', ... }
}
包含 AI 的 System Prompt 也會跟著切換語言,中文模式下 AI 用繁體中文回覆,英文模式用英文。
用 CSS 變數實作,body.light class 覆蓋所有顏色 token:
:root {
--bg: #0d0f12;
--text: #e2e8f0;
/* ... */
}
body.light {
--bg: #f0f2f5;
--text: #1a1f2e;
/* ... */
}


坦白說一開始只是想解決自己的問題。
在東南亞出差的時候,網路品質不穩定,雲端 AI 服務有時候連不上。而且很多客戶的環境是隔離內網,根本沒辦法用外部服務。
Ollama + 本地模型這條路讓我想到:如果工具本身也是靜態的、可以離線跑,那在任何環境下都能用。
另一個動機是:華文圈這類工具真的太少了。英文的 IT runbook 工具一堆,但專門為繁體中文 IT 環境設計的幾乎沒有。CCTV、NAS、Exchange 這些台灣中小企業的標配,在英文工具裡往往是配角。
MIT License,可以自由 fork、修改、商業使用。
歡迎 PR,特別是有其他診斷場景想補充的朋友 🙌
如果覺得有用,歡迎到 GitHub 給個 ⭐,或是分享給身邊的 IT 同行!
請問能用小模型嗎?
像是 Qwen3.6-35B-A3B 或 Gemma 4 E2B 、E4B...
可以的!工具使用 Ollama 作為本地模型介面,只要 Ollama 支援的模型都能用。
Qwen3.6-35B-A3B 和 Gemma 4 E2B/E4B 都可以,在設定頁面的 Ollama 分頁填入:
端點:http://localhost:11434
Model 名稱:填入你在 Ollama 下載的模型名稱(例如 qwen3:8b 或 gemma4:e2b)
小模型在 IT 診斷這種結構化任務上表現其實很不錯,速度也快很多,歡迎試試看並回饋效果如何!
好人一生平安
感謝您
請問這個介面使用情境在公司主要的使用者還是MIS嗎?
主要目標使用者是 MIS / IT 工程師,但設計上希望讓非技術背景的人也能用。
實際上有幾個不同的使用場景:
MIS / IT 工程師:自己排障時當作快速 Checklist,尤其是凌晨被叫起來腦子還沒清醒的時候,決策樹幫你確認不漏掉步驟。
IT 主管:把常見故障的 SOP 整理進去,交給一線同仁使用,減少每次都要找人問的狀況。
Helpdesk / 一線支援:遇到不熟悉的問題時,照著決策樹走可以縮小範圍,再決定要不要升級給二線。
簡單說:MIS 是主要使用者,但這個工具更大的價值是把 MIS 的經驗「複製」給整個 IT 團隊用。
請問:用本地大模型可解決資安外洩問題,有些需要確認的問題,所需的帳密權限,要如何控管?
好問題!這是企業導入本地模型最常被問到的議題。
目前工具本身是純前端靜態頁面,帳密控管這層需要搭配基礎架構來處理,有幾個常見方式:
網路層控管(最簡單)
Ollama 服務只綁定在內網 IP,外部無法存取,只有在同一個內網的人才能呼叫,不需要帳密機制。
Nginx 反向代理 + Basic Auth
在 Ollama 前面架一層 Nginx,加上 HTTP Basic Authentication,需要帳號密碼才能存取 API endpoint。
VPN 控管
員工需要連上公司 VPN 才能存取 Ollama 服務,帳密控管交給 VPN 系統處理(通常已經整合 AD)。
整合 Active Directory(企業級)
透過 OpenID Connect 或 LDAP 讓 Ollama 的存取權限跟 AD 帳號綁定,這條路比較複雜但最符合企業現有架構。
大多數中小企業用網路層 + VPN這個組合就夠了,不需要額外開發。
小弟沒有很專業,純分享,謝謝。
我覺得這是一個很好的想法,可以做初步排除。
但是,在現階段它最大的問題是 AI的幻覺及錯誤率。
所以,想分享一下跟AI的討論,謝謝。
( 謝謝樓主的分享,真的很有幫助,有了主頁面就可以再去調整成適合自己的用法,謝謝。)

感謝您提出這個核心問題,這也是我在設計這個工具時思考最多的地方。
您說得完全正確——AI 幻覺在 IT 排障場景裡是真實的風險。一個錯誤的指令,可能讓原本可以五分鐘解決的問題變成兩小時的災難。
這也是為什麼這個工具的設計重心不是「讓 AI 給答案」,而是**「決策樹先縮小範圍,AI 再補充細節」**。
具體來說:
決策樹的部分是固定邏輯,不會幻覺,每一步都是人工整理的排障流程
AI 的角色是在你已經定位到問題範圍之後,提供具體的指令和步驟
使用者仍然需要判斷 AI 給的指令是否合理,工具不會替你做最終決定
換句話說,這個工具假設使用者有基本 IT 判斷力,AI 是輔助而不是替代。
您提到的「菜鳥照著 SOP 正確收斂症狀後再派單給資深 IT」這個場景,我覺得說得非常到位,這確實是它最適合的使用方式。
請問::IT Diagnostic Agent 這個 純靜態 HTML 的結構是固定的嗎?
還是可以讓AI自己去新增修改結構?
目前版本的決策樹結構是固定的,內容寫在 HTML 裡,需要手動修改程式碼來新增節點。
「讓 AI 自己修改結構」這個方向非常有趣,技術上是可行的,大概有兩個層次:
短期可行的做法
讓 AI 根據對話內容動態生成診斷步驟,不改變決策樹結構,但在 AI 回應裡自動整理成步驟清單。這個版本現在其實已經有一部分了。
進階做法(在規劃中)
讓使用者描述一個新的故障場景,AI 自動生成對應的決策樹節點,存進 localStorage 或後端,下次遇到同樣問題直接用。這其實就是「自學習 Runbook」的概念。
不過要讓 AI 修改結構有一個風險:AI 生成的流程不一定可靠,需要人工審核才能正式加入決策樹,否則幻覺問題又回來了。
所以比較理想的設計是:AI 提案,人工審核,確認後才寫入結構。
謝謝作者的回覆,因為我第一時間看到的介面,讓我想到一個很棒的公司知識庫的解決方案!畢竟 AI Token 就是新台幣。新台幣 影響 老闆的決策。
您說得很精準!Token 成本是企業採用 AI 工具最現實的障礙之一,尤其是知識庫這種需要大量查詢的場景,費用很容易失控。
本地模型的優勢就在這裡——一次硬體投資,之後查詢不計費。結合 Ollama 跑 Gemma 或 Qwen 這類開源模型,IT 知識庫的場景完全可行。
如果您有興趣把公司的 SOP 整合進來,歡迎聊聊,這正是我在規劃的企業客製化方向