校園／企業網路：使用者一鍵診斷、白話解釋與自動報修 — 論文整理

研究日期：2026-09-26（2026-09-27 縮小範圍，改寫為校園／企業版）範圍：主動式AI網管與報修-總覽的 C. 使用者端 情境：學校或公司內部、由 IT 單位（資訊中心／網管）管理的網路。學生、教職員或員工只要按一個按鈕（入口網頁、App 或桌面小工具），系統就會告訴他問題出在哪裡；如果需要網管處理，系統自動開單，再通知他「已經有人負責處理」。 ✅ = 已看過 arXiv 摘要頁或論文 PDF 首頁；⚠️ = 只依搜尋結果整理，尚未讀原文「摘要」是依原文 abstract 所做的繁體中文意譯；論文沒有給數字的地方，這裡也不補數字。

0. 校園／企業網路和 ISP 情境有什麼不同

	ISP／家用網路	校園／企業網路（本篇）
網路端資料	業者看不到使用者家裡	IT 單位同時握有 AP controller、交換器、DHCP、RADIUS（802.1X）、DNS 記錄
使用者身分	匿名客戶	已登入的學生、員工（帳號、裝置、所在大樓都知道）
最常見的問題	家用 Wi-Fi、接取線路	連不上 Wi-Fi（關聯、認證、DHCP）、人多時變慢、DNS 或認證伺服器等共用服務出問題
報修對象	客服中心	資訊中心服務台 → 網管人員

所以按鈕背後的核心能力是：把「這個使用者」對到「他連的 AP、認證記錄、DHCP 記錄、所在區域」，再判斷問題出在使用者裝置、無線環境、網路服務，還是校外連線。

flowchart LR
    U([使用者按下按鈕]) --> C[用戶端量測<br/>訊號 / 延遲 / DNS]
    U --> S[查網路端記錄<br/>AP / 802.1X / DHCP]
    C & S --> D{問題在哪?}
    D -->|使用者裝置或設定| E1[白話說明 + 自行排除步驟]
    D -->|Wi-Fi 無線環境| E2[建議換位置或 AP<br/>必要時通知網管]
    D -->|網路服務 DNS/DHCP/認證| G[同一區域的回報合併]
    D -->|校外連線| E3[說明是對外線路問題]
    G --> T[自動開單並分類給網管]
    T --> N[通知使用者:<br/>已知問題 / 已有人處理]

#	會遇到的問題	對應論文
P1	連不上 Wi-Fi 時，按鈕根本傳不出資料	Client Conduit、WiFiProfiler
P2	連線階段失敗：關聯、802.1X 認證、DHCP	Pei 2017、DHCP 實證研究、PROBE
P3	連上了但很慢，而且常常是 Wi-Fi 這一段	WiFiSeer、WiFi Weakest Link、Cheng 2007（含 Jigsaw）
P4	使用者覺得「網路壞了」，其實是 DNS、認證伺服器等共用服務	Sherlock、NetMedic
P5	診斷結果要讓人看得懂，也要能驗證	NetClinic、Dalal 2019、Chetty 2011、PROBE（LLM 自信度不可靠）
P6	使用者報修內容不準，AI 會被帶偏或硬找故障	FaulT-Bench、SADE
P7	同一棟大樓很多人同時按，工單要合併、分類、派工	NetSieve、iPACK、DeepTriage、SiriusHelper

P1 連不上網路時，按鈕要怎麼回報？

1. Architecture and Techniques for Diagnosing Faults in IEEE 802.11 Infrastructure Networks（Client Conduit）⚠️

作者：Atul Adya, Paramvir Bahl, Ranveer Chandra, Lili Qiu（Microsoft Research）
出處：ACM MobiCom 2004；專案頁

摘要（依專案頁與專利說明）：針對企業 802.11 基礎架構網路提出故障診斷架構。其中的 Client Conduit 在「已經連上網的用戶端」上執行 MultiNet，讓它透過 ad hoc 網路連到「連不上網的用戶端」，把後者的訊息轉送給後端的診斷與復原伺服器；已連線的用戶端不需要中斷自己的連線。

解決什麼問題：使用者最需要按按鈕的時候，往往就是連不上網的時候，這時診斷資料根本送不出去。

貢獻

提出企業 WLAN 由用戶端 + 後端伺服器合作診斷的架構，是企業無線網路故障診斷的早期代表作。
用「旁邊已連線的裝置」當傳輸管道，解決連不上網時資料送不出去的問題。
實作啟示：按鈕應該能先把診斷結果存在本機，恢復連線或改用行動網路時再送出，或者提供離線也能判斷的簡易檢查。

2. WiFiProfiler: Cooperative Diagnosis in Wireless LANs ⚠️

作者：Ranveer Chandra, Venkata N. Padmanabhan, Ming Zhang（Microsoft Research）
出處：ACM MobiSys 2006，PDF

摘要：Wi-Fi 故障或變慢時，使用者往往只能自己手動除錯。WiFiProfiler 讓附近的無線裝置合作診斷，甚至修正問題，不需要額外基礎設施。即使某台裝置和 AP 的連線壞了，它通常仍能直接和附近裝置交換少量資料；系統以此建立共享的「資訊平面」，交換網路設定與連線品質，再比對多台裝置的資訊推斷原因。

解決什麼問題與貢獻

比對多台裝置：「只有我連不上」代表使用者裝置的問題，「整間教室都連不上」代表 AP 或網路端的問題。
在校園裡，這種比對可以直接用 AP controller 資料完成：查同一台 AP 上其他人的狀態就知道。

P2 連線階段失敗：關聯、802.1X 認證、DHCP

3. Why It Takes So Long to Connect to a WiFi Access Point ✅

作者：Changhua Pei, Zhi Wang, Youjian Zhao, Zihan Wang, Yuan Meng, Dan Pei, Yuanquan Peng, Wenliang Tang, Xiaodong Qu（清華 NetMan 等）
出處：IEEE INFOCOM 2017，arXiv 1701.02528

摘要：分析 500 萬名行動使用者連線到 700 萬個 Wi-Fi AP、共 4 億個 session 的資料，找出影響連線建立時間的因素；並另外在 12,472 台裝置上部署細部量測版本，把連線過程拆成各步驟（關聯、認證、DHCP 取得 IP）。最後提出以機器學習挑選 AP 的方法。

成效：連線失敗率從 33% 降到 3.6%；80% 的情況連線建立時間縮短 10 倍以上，優於只看訊號強度挑 AP 的做法。

解決什麼問題與貢獻

用大規模資料證明連線建立階段的失敗非常普遍，並把失敗拆成「逾時」「DHCP 失敗」等類型。按鈕的判斷邏輯可以照這種分類設計。
指出「訊號強」不代表「連得上」，挑 AP 要同時考慮時段、裝置型號、AP 型號等因素。

4. Squeezing the Gap: An Empirical Study on DHCP Performance in a Large-scale Wireless Network ✅

作者：Haibo Wang, Jessie Hui Wang, Jilong Wang, Weizhen Dang, Jing’an Xue, Fenghua Li, Jinzhe Shan（清華大學）
出處：IEEE 會議版（IEEE Xplore），期刊延伸版 PDF（檔名標示 IEEE/ACM ToN 2020，期刊出處待確認）

摘要：DHCP 廣泛用於動態分配 IP，但由於對其行為與效能了解不多，在大型無線網路中很難正確設定租期（lease time）與切分位址池。作者在 T 大學校園無線網路（TWLAN）做了目前已知最大規模的 DHCP 量測，發現效能遠不理想：(1) 未認證的裝置在尖峰時段浪費 25% 的位址；(2) 在現行切分策略下，各位址池的使用率差異很大；(3) 裝置平均有 67% 的租期時間沒有產生流量。不同地點與作業系統的裝置上線模式也不同，統一租期會造成浪費。作者提出考慮認證資訊與上線模式的新租約策略，以及自適應的位址切分策略。

成效：分配位址數減少 24%、平均總租期減少 17%，而且沒有明顯增加 DHCP 伺服器負載。

解決什麼問題與貢獻

解釋了一個常見的校園現象：在餐廳等人多的地方，訊號很強卻連不上，原因可能是 IP 位址被未認證裝置佔光。
對按鈕的啟示：「訊號滿格但拿不到 IP」要能判斷成網路端問題（位址池耗盡），而不是叫使用者重開 Wi-Fi。

5. Evidence-Grounded Ensemble Diagnosis of 802.11 Packet Captures（PROBE）✅

作者：Jerome Henry, Swadhin Pradhan, Miroslav Popovic
出處：arXiv 2606.06871（2026/06）

摘要：探討用 LLM 解讀 802.11 封包擷取（關聯、認證等管理訊框）來診斷 Wi-Fi 問題時的失敗模式，並提出 PROBE：多階段流程，結合確定性的文字正規化、多模型交叉驗證的 ensemble，以及以證據為基礎的可靠度評分。評估方式採用逐欄位斷言，避免用模型產生的參考答案造成偏差。

成效

單次 LLM 分析的加權證據 F1 由專家基準的 0.871 提升到 0.912，但有 35% 的案例漏掉關鍵訊框。
LLM 自評的信心值不論難易都集中在 0.95 左右，因此不能拿來判斷答案是否可靠。
單純多數決的 ensemble 反而掉到 0.842，比基準還差。
PROBE 最終 F1 0.957，96% 的結果可以自動採用。

解決什麼問題與貢獻

802.1X、關聯失敗的根因藏在訊框順序與狀態碼裡，人工判讀很費時。這篇顯示 LLM 可以做，但必須以證據交叉驗證。
對 P5 也很重要：不能讓 LLM 自己說「我很確定」，就直接把結論告訴使用者。

P3 連上了但很慢：Wi-Fi 常是瓶頸

6. Characterizing and Improving WiFi Latency in Large-Scale Operational Networks（WiFiSeer）⚠️

作者：Kaixin Sui, Mengyu Zhou, Dapeng Liu, Minghua Ma, Dan Pei, Youjian Zhao, Zimu Li（清華大學）, Thomas Moscibroda（Microsoft Research）
出處：ACM MobiSys 2016，DOI 10.1145/2906388.2906393，PDF

摘要：Wi-Fi 延遲是影響行動應用使用者體驗的關鍵因素，但過去缺乏大規模研究。作者提出 WiFiSeer，一套系統化方法，用來建模 Wi-Fi 延遲與各種 Wi-Fi 效能指標、裝置特性、環境因素之間的複雜關係。WiFiSeer 用新的 ping 方法（ping2）量測裝置在企業無線網路上的延遲，同時用 SNMP 定期輪詢 AP 既有的資料，推導可能的影響因素。部署在清華校園（約 4 km²、5.3 萬名師生、2,700 多台 Cisco 雙頻 AP），涵蓋超過 4.7 萬台使用者裝置。

成效

Wi-Fi 延遲呈長尾分布，第 90（99）百分位約 20 ms（250 ms）。
量化證實了部分網管的經驗說法，也推翻了另一部分。
超過 1,000 台裝置使用以延遲預測模型為基礎的 AP 選擇服務 2.5 個月，重新連到建議的 AP 後，72% 裝置的延遲降低一半以上。

解決什麼問題與貢獻

與本題最接近的校園實證研究：只用校園網管本來就有的 SNMP 資料加上用戶端量測，就能解釋並改善使用者感受到的延遲。
「建議你改連另一台 AP」就是按鈕可以直接給使用者的具體建議。

7. WiFi Can Be the Weakest Link of Round Trip Network Latency in the Wild ⚠️

作者：Changhua Pei, Youjian Zhao, Guo Chen, Ruming Tang, Yuan Meng, Minghua Ma, Ken Ling, Dan Pei
出處：IEEE INFOCOM 2016，PDF

摘要（部分）：觀察到 Wi-Fi 這一跳可能是往返延遲中最弱的一環：超過 50%（10%） 的 TCP 封包，Wi-Fi 這一跳的延遲超過 20 ms（100 ms）；而且在超過一半的連線中，Wi-Fi 延遲佔整體往返延遲 60% 以上。

解決什麼問題與貢獻

用數據支持「慢通常是 Wi-Fi 這一段，不一定是校外線路」。按鈕的診斷應該分段量測（裝置→AP、AP→校園出口、出口→外部網站），才能講清楚是哪一段慢。

8. Automating Cross-Layer Diagnosis of Enterprise Wireless Networks ✅

作者：Yu-Chung Cheng, Mikhail Afanasyev, Péter Benkő, Patrick Verkaik, Jennifer Chiang, Alex C. Snoeren, Stefan Savage, Geoffrey M. Voelker（UC San Diego）
出處：ACM SIGCOMM 2007，DOI 10.1145/1282380.1282384，PDF

摘要：現代企業網路複雜到連簡單的故障都難以診斷，更不用說短暫中斷或效能下降。企業普遍使用的 802.11 無線接取網路最明顯：除了有線網路的種種複雜性，還要面對共享頻譜、使用者移動與認證管理。很少組織具備拆解這些問題所需的專業、資料與工具。作者提出一套分析技術與模型，精確找出 802.11 網路中從實體層到傳輸層、所有因媒體存取與移動造成的資料傳輸延遲，以及它們之間的交互作用。部分延遲可以直接量測，但 AP 排隊、backoff、競爭等必須推論；因此作者建立詳細的 MAC 協定行為模型，涵蓋 802.11 規格與廠商硬體的實際實作。搭配企業網路（UCSD 校園）的完整無線記錄，產生每個封包的完整延遲拆解，找出限制連線或效能的問題。

解決什麼問題與貢獻

論文開頭描述的情境就是本題的痛點：網管被問「10 分鐘前網路為什麼怪怪的？」時，答案往往是「不確定，現在看起來正常」。
UCSD 一棟新大樓的使用者被短暫但嚴重的效能問題困擾超過一年，在地專家和廠商技術人員都查不出來；作者用此系統找到原因：AP 廠商實作的細微 bug。
啟示：按鈕除了即時診斷，也要記錄當下的證據，事後問題消失才有資料可查。
前身 Jigsaw（SIGCOMM 2006）：在 UCSD 大樓部署分散式監聽，24 小時收集超過 15 億個事件，合併成全域的跨層視角。

P4 使用者覺得「網路壞了」，其實是共用服務

9. Towards Highly Reliable Enterprise Network Services via Inference of Multi-level Dependencies（Sherlock）⚠️

作者：Paramvir Bahl, Ranveer Chandra, Albert Greenberg, Srikanth Kandula, David A. Maltz, Ming Zhang（Microsoft Research）
出處：ACM SIGCOMM 2007，DOI 10.1145/1282427.1282383

摘要：在大型企業網路中找出效能問題的來源非常困難，因為相依關係眾多、複雜，而且是多層的，橫跨網路與運算基礎設施的軟硬體元件。作者提出 Inference Graph 模型，適合描述「使用者感受得到」的問題，包含部分服務劣化與完全故障。Sherlock 系統在實際運作的企業網路中自動發現 Inference Graph、推論關鍵屬性，再用來自動偵測並定位問題。評估包含大型企業網路的原型部署，以及測試平台模擬。

解決什麼問題與貢獻

使用者說「網路壞了」，實際上可能是 DNS、認證伺服器、proxy 或某個網頁服務出問題。Sherlock 從使用者感受到的症狀出發，沿著相依圖往回找根因。
在校園裡，這可以對應成「無法登入學校系統」→ 單一登入（SSO）→ 認證伺服器 → DNS 的相依鏈。

10. Detailed Diagnosis in Enterprise Networks（NetMedic）⚠️

作者：Srikanth Kandula, Ratul Mahajan, Patrick Verkaik, Sharad Agarwal, Jitendra Padhye, Paramvir Bahl
出處：ACM SIGCOMM 2009，DOI 10.1145/1594977.1592597，PDF

摘要：作者研究小型企業網路的報修單後，認為網管需要「細部診斷」：不只診斷一般的效能問題，也要能診斷應用程式特有的錯誤（例如錯誤代碼），並把元兇定位到很細的層級，例如某個行程或某條防火牆設定。NetMedic 利用現代作業系統與應用程式公開的豐富資訊，把細部診斷建模成推論問題，描述行程等細粒度元件之間的行為與互動。

解決什麼問題與貢獻

從真實報修單出發定義診斷需求，這和本題的出發點一樣。
把網路建模成細粒度元件的相依圖，依歷史資料學習元件之間的影響程度，不需要理解每種資料的意義，也幾乎不需要各應用程式的專門知識。
可以診斷使用者電腦本身的問題（例如防火牆設定擋住連線），這正是按鈕在用戶端要做的事。

P5 診斷結果要讓人看得懂，也要能驗證

11. NetClinic: Interactive Visualization to Enhance Automated Fault Diagnosis in Enterprise Networks ⚠️

作者：Zhicheng Liu, Bongshin Lee, Srikanth Kandula, Ratul Mahajan（Microsoft Research）
出處：IEEE VAST 2010，PDF

摘要：診斷運作中網路的故障既令人挫折又耗時。自動診斷工具並不完美：偶爾會漏掉真正的元兇，多半只能把範圍縮小到幾個可能的元兇。這種不確定性，加上工具輸出難以理解，讓多數工具對網管來說不好用。NetClinic 把互動式視覺化和自動診斷引擎（NetMedic）結合，讓網管在不同細節層級驗證自動分析的結果，並能在層級間移動而不失去上下文。

成效：質性使用者研究顯示，即使自動診斷沒有把真正的元兇列入建議，使用者也能用 NetClinic 正確找到元兇。

解決什麼問題與貢獻

據作者所知，是第一個把互動視覺化與自動推理引擎結合來做故障診斷的系統。
重點是：AI 診斷一定會有不確定性，要讓人能檢查證據，而不是只給一個答案。
本題可分兩層：給網管的工單附上 NetClinic 式的證據與候選元兇；給使用者的只保留白話結論和他能做的事。

12. A Preliminary Study of the Role of Language in Home Network Troubleshooting ✅

作者：Amy Csizmar Dalal, Jackie Chan, Kirby Mitchell（Carleton College）
出處：CHI 2019 Extended Abstracts，DOI 10.1145/3290607.3312856

摘要：47 位受試者用開放式卡片分類法，分類 29 個網路排障用語（如 bandwidth、buffering、throttle，以及「goes dark」「hogs the pipe」等口語說法）。結果發現技術術語和口語說法一樣容易讓人誤解。

解決什麼問題與貢獻：研究對象是家庭使用者，但結論可以直接套用到校園的學生與行政人員：不要以為叫 LLM「用白話講」就解決了，說明文字要做使用者測試。

13. Why Is My Internet Slow?: Making Network Speeds Visible ✅

作者：Marshini Chetty 等（Georgia Tech）
出處：ACM CHI 2011，PDF

摘要：設計視覺化工具，顯示家中每台裝置的上下載量，並在 10 個家庭實地試用。發現使用者用「人和用途」理解網路，而不是用 IP 或 MAC（例如會把裝置改名為「Matt’s Desktop」）。

解決什麼問題與貢獻：說明畫面應該寫「你的筆電連在圖書館 3 樓的 AP，這台 AP 目前有 80 人在用」，而不是列出 AP 名稱和 RSSI。

（PROBE 的「LLM 自評信心值永遠約 0.95」見上方 #5，也屬於這一類。）

P6 使用者報修內容不準，AI 會被帶偏

FaulT-Bench（arXiv 2608.27021，2026/08）：200 個排障情境、8 種拓樸，其中 4 種是企業與校園實驗網路。報修內容正確時，agent 表現接近滿分，也不太會被錯誤線索誤導；但網路其實正常、報修內容卻是錯的時，表現大幅下降。報修內容寫得模糊時，表現也明顯變差。
SADE（arXiv 2605.04530，2026/05）：把 Cisco 的經典排障方法寫成 agent 必須遵守的流程，根因 F1 比 ReAct + GPT-5 高 37 個百分點。適合當按鈕背後 agent 的排障流程骨架。

對一鍵按鈕的意義：按鈕的好處是使用者不用自己描述問題，系統直接收集客觀量測，避免 FaulT-Bench 所說的「報修內容不可靠」。但系統仍然必須能回答「網路正常」。

P7 同一區域很多人同時按：工單合併、分類、派工

14. Juggling the Jigsaw: Towards Automated Problem Inference from Network Trouble Tickets（NetSieve）⚠️

作者：Rahul Potharaju, Navendu Jain, Cristina Nita-Rotaru（Purdue × Microsoft Research）
出處：USENIX NSDI 2013，pp. 127–141，PDF

摘要：網路報修單是網管記錄排障步驟的日誌，由固定欄位和自由文字組成，對網路管理很有價值，但很難用來推論問題：固定欄位常常錯誤或不完整，自由文字又是自然語言。NetSieve 結合統計式 NLP、知識表示與本體（ontology）建模，自動從報修單文字推論問題症狀、排障動作與解決方式；由於自由文字可能模糊，NetSieve 也會從人工指導中學習，提高準確度。

成效：在大型雲端業者超過 10,000 張報修單上評估，以專家審查、網管使用者研究與廠商維修記錄三種方式驗證，準確率 89%–100%。已用於分析設備故障趨勢、了解備援為何失效、辨識設備問題症狀。

解決什麼問題與貢獻

資訊中心累積多年的舊報修單可以變成知識庫：哪種症狀通常是什麼原因、怎麼修好。
可以當作 LLM 診斷時檢索相似案例（RAG）的資料來源。

15. Incident-aware Duplicate Ticket Aggregation for Cloud Systems（iPACK）✅

作者：Jinyang Liu, … , Michael R. Lyu（CUHK × Microsoft）
出處：ICSE 2023，arXiv 2302.09520，程式碼

摘要：使用者分散、各自回報，因此很多工單其實是同一個故障。只比對文字相似度不夠，因為同一個故障造成的工單描述可能完全不同。iPACK 結合**使用者端（工單）與系統端（告警、incident）**的資訊來合併重複工單。

成效：Azure 三個區域、81 個服務的資料上，F1 0.871–0.935，比 SOTA 高 12.4%–31.2%。

解決什麼問題與貢獻

某台 AP 或某棟大樓的交換器壞掉時，可能有幾十人同時按按鈕。iPACK 的做法對應到校園就是：依 AP、大樓、網段加上網管告警來合併，合併後通知所有人「這是已知問題，已有人處理」。
校園比雲端容易做，因為使用者所在的 AP 和大樓是已知的。

16. DeepTriage: Automated Transfer Assistance for Incidents in Cloud Services ✅

出處：ACM KDD 2020，arXiv 2012.03665

摘要：把 incident 及時派給正確的負責團隊，是降低停機時間的關鍵第一步。挑戰包括團隊間的分布極度不平衡、資料格式多樣、要能擴展到正式環境規模，以及要取得工程師的信任。DeepTriage 用 ensemble 結合 gradient boosted classifiers、分群與深度神經網路，推薦負責團隊。

成效：Azure 真實 incident 上 F1 82.9%；自 2017 年 10 月起在 Azure 部署。

解決什麼問題與貢獻：資訊中心通常分成網路組、系統組、帳號／認證組、桌機支援等。按鈕開出的單要能自動分給正確的組。

17. SiriusHelper: An LLM Agent-Based Operations Assistant for Big Data Platforms ✅

作者：Yu Shen 等（騰訊、北京大學）
出處：arXiv 2605.00043（2026/04）

摘要：部署在騰訊大數據平台上的 LLM 維運助理。系統先辨識使用者問題的意圖，再導向合適的處理管道，包括 SQL 診斷等領域專屬流程；結合階層式知識組織與多跳檢索處理複雜的排障問題。關鍵設計是自動分析助理失敗的原因（缺少知識，還是路由錯誤），並萃取成標準作業程序（SOP），持續改進系統。

成效：線上工單量減少 20.8%，已在正式環境使用。

解決什麼問題與貢獻

領域不同（大數據平台，不是網路），但架構和本題幾乎一樣：使用者先找助理，助理解決不了才開單。
評估指標值得借用：有多少比例的互動最後仍需開單、整體工單量減少多少。
「從失敗案例自動萃取 SOP」可以對應到資訊中心的知識庫維護。

研究缺口

沒有論文完整做出校園版的「一鍵診斷 → 白話說明 → 自動開單 → 通知」系統。 WiFiSeer、DHCP 研究證明校園網管資料足以解釋使用者的問題；NetSieve、iPACK、DeepTriage 處理工單；SiriusHelper 證明 LLM 助理能減少工單。但沒有人把這些串起來，並以使用者為對象評估。
連線階段失敗（802.1X、DHCP）的 LLM 診斷仍然很新。 PROBE 是少數把 LLM 用在 802.11 封包診斷的研究，而且發現 LLM 的自評信心不可靠。結合 RADIUS 和 DHCP 記錄、讓 LLM 以證據解釋「為什麼你連不上」的研究，目前沒有找到。
連不上網時的回報管道。 Client Conduit 是 2004 年的做法。現在手機可以改走行動網路回報，但缺少相關研究。
給學生與員工看的診斷說明，沒有使用者研究。 NetClinic 的對象是網管；Chetty、Dalal 的對象是家庭使用者。校園或企業的一般使用者看到 AI 診斷後是否理解、是否恰當地信任，目前沒有研究。
可以用的公開資料。 校園 Wi-Fi 故障資料可以用 Toward Realistic Wi-Fi Fault Diagnosis: A Multi-Modal Benchmark（arXiv 2605.22008，在校園辦公環境架設測試平台並自動注入故障，超過 10,000 筆故障樣本，也評估了 LLM 診斷說法是否符合實際狀況）；LLM agent 評估可以用 FaulT-Bench 的企業／校園拓樸。

前一版（ISP 情境）移出的論文

縮小範圍後，以下論文偏向 ISP、家用網路或其他領域，改列為參考：

論文	移出原因	仍可參考的點
Netalyzr（IMC’10）	檢查 ISP 連線功能	一鍵檢測項目清單（DNS、NAT、MTU）
HERMES（SIGCOMM’26）	網際網路規模的測速監控	把使用者按下的測速當成監控訊號
Home Network or Access Link?（PAM’16）	家用 vs ISP 接取	用路由器資料判斷瓶頸位置的方法
MobileInsight（MobiCom’16）	行動網路	手機端能收集的底層資訊
Bronzino（POMACS’19）	ISP 推估影片品質	使用者體感 vs 網路指標的落差
τ²-Bench（2025）	電信客服	AI 引導使用者親自操作時表現下降
TTMPred、停電 ETR（LTT）	雲端與電力	預計修復時間要隨進度更新，第一次預估最不準
Oasis（FSE’23）	雲端 outage 摘要	用 LLM 把內部告警轉成人看得懂的摘要
CEM（SIGCOMM’10）、Twitter 偵測中斷（WOSN’10）	網際網路規模	彙整大量使用者觀察來偵測故障
Grinter（ECSCW’05）、Accessible Network Control（2025）	家用網路	非專業使用者管理網路的困難

使用者端一鍵診斷與報修-論文整理

校園／企業網路：使用者一鍵診斷、白話解釋與自動報修 — 論文整理

0. 校園／企業網路和 ISP 情境有什麼不同

P1 連不上網路時，按鈕要怎麼回報？

1. Architecture and Techniques for Diagnosing Faults in IEEE 802.11 Infrastructure Networks（Client Conduit）⚠️

2. WiFiProfiler: Cooperative Diagnosis in Wireless LANs ⚠️

P2 連線階段失敗：關聯、802.1X 認證、DHCP

3. Why It Takes So Long to Connect to a WiFi Access Point ✅

4. Squeezing the Gap: An Empirical Study on DHCP Performance in a Large-scale Wireless Network ✅

5. Evidence-Grounded Ensemble Diagnosis of 802.11 Packet Captures（PROBE）✅

P3 連上了但很慢：Wi-Fi 常是瓶頸

6. Characterizing and Improving WiFi Latency in Large-Scale Operational Networks（WiFiSeer）⚠️

7. WiFi Can Be the Weakest Link of Round Trip Network Latency in the Wild ⚠️

8. Automating Cross-Layer Diagnosis of Enterprise Wireless Networks ✅

P4 使用者覺得「網路壞了」，其實是共用服務

9. Towards Highly Reliable Enterprise Network Services via Inference of Multi-level Dependencies（Sherlock）⚠️

10. Detailed Diagnosis in Enterprise Networks（NetMedic）⚠️

P5 診斷結果要讓人看得懂，也要能驗證

11. NetClinic: Interactive Visualization to Enhance Automated Fault Diagnosis in Enterprise Networks ⚠️

12. A Preliminary Study of the Role of Language in Home Network Troubleshooting ✅

13. Why Is My Internet Slow?: Making Network Speeds Visible ✅

P6 使用者報修內容不準，AI 會被帶偏

P7 同一區域很多人同時按：工單合併、分類、派工

14. Juggling the Jigsaw: Towards Automated Problem Inference from Network Trouble Tickets（NetSieve）⚠️

15. Incident-aware Duplicate Ticket Aggregation for Cloud Systems（iPACK）✅

16. DeepTriage: Automated Transfer Assistance for Incidents in Cloud Services ✅

17. SiriusHelper: An LLM Agent-Based Operations Assistant for Big Data Platforms ✅

研究缺口

前一版（ISP 情境）移出的論文

延伸閱讀（未整理）