用Gemini生成多站點無線健康週報

一句話結論：在有人投訴之前一個星期，你的無線控制器就已經記錄下了 14 號分店的問題——重啟、頻道變更、關聯失敗。Gemini 要做的，是把那份導出文件壓縮成一頁帶排序的無線健康週報，點名本週該關注哪三個站點、以及為甚麼。它是架在你本來就擁有的數據之上的一個報告層，不是監控系統，也不能取代實時告警。

一家擁有 26 間分店的零售集團，所有站點都跑 Ubiquiti UniFi，由總部一名網絡經理一個人管全部。週四下午，14 號分店的店長打來電話：倉庫的手持掃描器總是掃到一半掉線，「已經兩個星期了」，能不能派人來看看。

他打開 UniFi Network Application，篩選到 14 號分店，四分鐘就找到了。有一台無線接入點——裝在倉庫捲閘門附近那一台——在十五天裡重啟了十一次，其中兩次還是同一個晚上。旁邊那台 AP 一直在反覆切換頻道，而在靠外牆的 5 GHz 射頻上，這通常意味著觸發了 DFS 雷達偵測。

這些信息一樣都沒有被藏起來。控制器在事情發生的當下就把每一條事件都記錄了下來，而且全都躺在他剛剛打開的那個儀表板裡。沒人看見的原因只有一個：14 號分店只是二十六個站點中的一個，每個站點每星期產生幾百條事件，而一個人的工作週裡，根本不存在「通讀二十六份事件日誌、去找一個還沒引發投訴的規律」這種時間。

真正的缺口就在這裡。不是數據缺失，是數據沒人讀。

為甚麼 14 號分店的無線問題是以投訴、而不是以告警的形式出現

控制器的告警是圍繞狀態設計的：一台接入點要麼在線，要麼離線。它掉線了，你就收到通知。這套機制是有效的，它能抓住那些已經構成中斷的故障。

它抓不住的是劣化，因為劣化沒有可以跨越的狀態邊界。一台每三十六小時重啟一次的接入點，在你任何一個瞬間去看它時，都是在線的。一台因為 DFS 命中而不斷換頻道的射頻，行為完全符合設計。一個因為有人把貨板堆到牆邊、導致客戶端平均信號強度在兩個月裡下滑了八 dBm 的站點，從頭到尾甚麼都不會觸發。

於是，真正會產生服務台工單的那三類無線問題——反覆掉線重連的接入點、覆蓋在悄悄變差的站點、每個工作日下午兩點就擠塞的那個頻段——恰恰就是閾值告警一個都不會響的那三類。

再乘以站點數量。二十六個地點，每個有四到十二台接入點，每台都在產生關聯事件、漫遊事件、DHCP 失敗、頻道變更和固件通知。整個網絡一星期的導出文件輕輕鬆鬆就是幾千行。從頭讀到尾，得花一個下午。沒人有這個下午，所以它不會被讀，所以第一個真實的信號，是一位已經忍了兩個星期的店長打來的電話。

Gemini 拿到一份控制器導出文件，到底能做甚麼

Gemini 是 Google 的助手家族，可以通過 Gemini 應用、Google AI Studio，以及 Google Workspace 中的 Gemini 使用，後者能直接處理 Drive 裡的文件或 Google Sheets 裡的表格。這裡真正要緊的能力是大上下文窗口——一份很長的結構化導出文件可以一次讀完，而不必切塊——加上對表格數據靠譜的處理能力。具體上限隨模型和級別而不同、也經常變動，所以在圍繞某個文件大小設計流程之前，請先查當前文檔。

先說兩點前提。Gemini 不會連接 UniFi 或 Meraki；這裡描述的任何一步都不是集成。你導出，它讀你導出的內容。而且除了那份文件裡有的東西，它對你的網絡一無所知，所以一個它沒見過的站點名稱，在它眼裡就只是一串字符。

把一份原始事件導出變成一份帶排序、讀得下去的摘要

有用的輸出不是對整份導出文件做總結，而是排序。給它二十六個站點一星期的事件，值得問的問題是：哪三個站點本週比上週更差、具體是哪幾台接入點造成的、證據是甚麼。

這本質上是一個計數、分組和比較的問題——按站點和設備給事件歸類，發現全網十九次意外重啟裡有十一次來自 AP-14-03，注意到 22 號分店的關聯失敗數在週一早上翻了三倍。只要導出文件裡有支撐這些動作的欄位，模型處理得相當穩，而且它會用分店營運經理不需要懂甚麼是 DFS 也能讀的句子把結果寫出來。

在演變成中斷之前，發現那條慢慢長起來的曲線

第二件值得讓它做的事是看趨勢，而趨勢需要不止一星期的輸入。把最近八星期的導出留著，並且明確地要求對比：哪些站點在八星期裡重啟次數在上升、哪些站點平均信號強度在下降、哪些站點存在按時間反覆出現的規律。

14 號分店的故事，本來就該在這裡拐向另一個結局。十五天十一次重啟，在單獨一星期的日誌裡是看不見的——它就一兩行，和噪音沒甚麼區別。但攤在八星期的導出上，它就是某一台設備上一條明顯向上的線，讀出來是「AP-14-03 在最近八星期裡有七星期發生過重啟，且次數在上升」——那是一次你可以排期的上門，而不是一次你被迫應對的緊急事件。

一套可落地的流程：從每星期一份導出，到營運真的會讀的摘要

1. 在自動化任何東西之前，先把「導出文件」這件事定死。欄位定一次：時間戳、站點、設備名稱、設備 MAC、事件類型、嚴重級別，以及——如果你的平台提供——客戶端數量和平均信號。Cisco Meraki 的控制台提供定時匯總報告和 REST API；Ubiquiti UniFi 有自己的 API，若干視圖下也支援 CSV 下載。走哪條路都可以。不可以的是每星期拿到一個形狀不一樣的文件，因為那樣本週的摘要就沒法和上週比。

2. 用你們業務自己的叫法來命名站點。如果控制器裡叫 "UK-STR-014-AP03"，而分店叫「14 號店」，那每一份摘要讀的人都得先翻譯一遍。要麼在控制器裡把命名改掉，要麼在提示詞裡附一張對照表。在「有沒有人真的會讀這份輸出」這件事上，這是影響最大的一個改動。

3. 寫一條提示詞，然後把它凍住。大致是這樣：*「附件是本週 26 間零售分店的無線事件導出。請把最需要關注的五個站點按從壞到好排序。每個站點給出：站點、具體的那台接入點、支撐這個排序的事件計數，以及一句關於可能原因的判斷。另外單獨列出連續第三星期進入前五名的接入點。忽略常規的客戶端漫遊。如果某個站點沒有值得說的事，就不要提它。不要開場白。」*具體措辭沒那麼重要，重要的是它永遠不變——一份摘要有用的前提，是本週的能和上週的比。

4. 附上最近八星期的導出，而不只是本週的。價值的大頭在趨勢，而趨勢需要歷史。把它們放在同一個 Drive 文件夾裡，文件名帶日期，這樣每次重新附上都很容易。

5. 要求把數字寫進句子裡。「22 號分店出現不穩定」是一句你沒法據此行動的話。「22 號分店：AP-22-01 在週一 09:00 到 11:00 之間記錄到 47 次關聯失敗，而該站點週均為 6 次」，則告訴了你該去哪裡看、大概該看哪個時間窗。

6. 發出去之前，對著控制器核實排第一的那一條。每星期一條：打開控制器，確認那個數字是真的。這要花兩分鐘，而它正是「一份大家信得過的摘要」和「一份在第二次說錯之後就被悄悄跳過的摘要」之間的分界線。

7. 用「做了甚麼」來閉環。每一條給出三種結果之一：已修復、已排期、觀察中。下星期的摘要從上星期的「觀察中」清單開始。沒有這一步，同一台接入點會被連報六個星期，讀的人自然就學會了跳過它。

AI 匯總摘要 vs 控制器原生儀表板 vs 託管無線服務商的報告

Gemini 匯總的每週摘要。便宜、上手快，而且完全貼合你自己的網絡和你自己的站點命名。它讀的是你本來就擁有的數據，把它變成一個不懂網絡的人也能據此行動的東西。它按定義就是回溯性的、上限取決於那份導出、產不出任何有合約效力的東西，而且依賴於每星期真的有人去跑那份導出。正確用法：讓緩慢劣化變得可見的每週覆盤。
控制器自己的儀表板和告警。權威、實時，也是三者中唯一能告訴你「此刻正在發生甚麼」的一個。它還握著任何摘要都必然會丟掉的全部細節——單客戶端歷史、射頻數據、抓包級工具。它不做的事，是把二十六個站點互相排序，或者呈現橫跨兩個月的趨勢，因為它被設計出來是回答「這個站點現在怎麼樣」，而不是「我週四該把時間花在哪」。正確用法：實時告警，以及你用來核實的事實來源。
託管無線服務商的報告。它附帶一個人，這個人的工作就是讀它、處理它，做不到還要承擔後果——而這恰恰是另外兩者都不提供的部分。它通常包含主動的固件管理、射頻調優、合約內的硬件更換，以及 7×24 的後端升級支援，並且產出的是你可以拿去要求供應商負責的報告。它要花錢，而且報告是按服務商的模板、而不是按你的模板做的。正確用法：當無線對足夠多的站點已經是業務關鍵，以至於「讀得懂一份摘要」和「有能力去處理它」完全不是一回事的時候。

每週摘要不夠用的地方

真正的中斷需要實時告警。如果一台接入點在週一 09:40 掛了，週五的摘要不是處理它的機制。把控制器告警配置好、並且路由給一個真的會看到它的人，然後把摘要嚴格當作增量。

物理故障需要有人到現場。一個快壞的 PoE 供電模組、一根受損的天線、一條被貨架壓住的線、一台為了給展示機充電而被拔掉的接入點——這些沒有一樣是靠更好的報告能修好的。摘要的職責是告訴你該往哪個站點派人，到這裡它的職責就結束了。

導出文件展示不了它從未記錄過的東西。控制器側的數據描述的是基礎設施，它描述不了客戶端的體驗——那台無線驅動過舊的手持機、那個讓性能變差卻不產生任何事件的干擾源、某一款行為糟糕的設備型號的漫遊表現。當摘要乾乾淨淨、用戶卻還在抱怨時，答案是做一次現場勘測，而不是寫一條更長的提示詞。

把這件事做對——網絡數據敏感性、告警歸屬，以及甚麼時候該讓 IT 介入

在第一次導出之前，就決定甚麼可以離開你的網絡。一份無線事件導出裡可能包含客戶端 MAC 地址、帶員工姓名的設備主機名，以及事實上一張你物理網點的地圖。把你不需要的欄位去掉——絕大多數摘要在完全刪掉客戶端標識符之後照樣跑得很好——並且把這個決定在公司層面做一次，而不是每個人每星期各做各的。

搞清楚你在用哪個級別、它的條款是甚麼。消費級和企業級 AI 級別在數據保留、以及是否可用於訓練上是不一樣的，而且這些條款會變。如果要把營運中的網絡數據放進去，就用你們機構真正審過的那個級別。

給摘要裡的每一條都指定一個負責人和一個下一步動作。失效模式不是摘要做得差，而是一份做得不錯的摘要被讀了、被點了頭，然後被忘了。五條，每條後面都跟一個名字，下星期結掉。

判斷一個助手在網絡運維裡究竟該放在哪個環節，並且把提示詞和流轉規則做得足以扛過糟糕的一個星期，屬於 AI+ 支援的工作範疇。它底下那套無線網絡——多站點雲端管理、主動的固件與射頻調優、7×24 後端維護——則屬於託管無線網絡的範疇，由同一個接到 14 號分店電話的 IT 支援服務台交付。如果你的問題是覆蓋而不是趨勢，部署前的那一面在我們這篇用 Gemini 解讀 Wi-Fi 勘測數據裡講過；同樣的「每星期導出」手法用在語音上，見分析雲端 PBX 通話日誌。

常見問題

這會取代實時無線告警嗎？

不會，而且很重要的一點是別讓它慢慢滑向那個角色。控制器的告警，是那個告訴你「09:40 有一台接入點掉線了」的東西。摘要是回頭看一整個星期，去找那些從來沒跨過告警閾值的問題——隔一天重啟一次的 AP、信號質量在漂移的站點、每個工作日下午都擠塞的頻段。兩者都留著，並且在所有人心裡把它們清楚地分開。

這套做法支援哪些無線平台？

任何能導出結構化事件或統計數據的平台，實際上也就是所有主流平台。Cisco Meraki 提供定時匯總報告和 REST API；Ubiquiti UniFi 有自己的 API 和 CSV 下載；Aruba、Ruckus 等也有等價的導出或 API 路徑。AI 這一側是平台無關的，因為它從頭到尾沒有碰過平台。要緊的是導出文件每星期欄位一致，而不是它出自哪家廠商。

它能在接入點壞掉之前預測故障嗎？

在任何嚴格的意義上都不能，而且如果有人就這類數據宣稱能做到，你應該保持懷疑。它做的是讓趨勢更早地顯形——一台在最近八星期裡有七星期重啟過、而且次數還在上升的接入點——這往往足以讓你在設備徹底失效之前把更換排上日程。那是靠計數得來的早期預警，不是靠建模得來的預測。它看不見一個正在衰敗的電源，也看不見一處還沒產生任何事件的入水問題。

這和我們託管無線服務商已經在發的報告有甚麼不同？

主要區別在於誰去處理它。服務商的報告按他們的模板做、按他們的節奏發、覆蓋他們合約裡承諾覆蓋的範圍——但它附帶一位有義務對報告內容採取行動的工程師。自建的摘要貼合你的站點和你的命名，除了跑它的時間之外不花錢，而且嚴格來說只是一個報告層：它不對任何人產生義務。如果你已經有託管無線合約，更有用的問題通常是：你服務商的報告裡有沒有你需要的排序和趨勢，以及要求他們加上。