前一天我們談的是模型如何把財務資料整理成每日報告。今天把同一個思路搬到社群情報：不是每天打開十個網站，憑印象說「最近大家在討論 AI」，而是建立一條可以重跑、可以驗證、也知道何時失效的資料管線。

對一家做企業 WiFi、IT 委外、企業 AI 與 NAS／備份的公司來說，社群雷達不是追新聞而已。它要回答三個實際問題：客戶正在問什麼、競爭者正在推出什麼、哪些技術值得放進自己的服務方案。

從手動巡站開始

最初的做法很直覺：每週找時間瀏覽 X、Reddit、Facebook 社團與幾個技術網站，把看到的連結貼到筆記裡。這個方法的問題不是不努力，而是無法穩定重現。

同一個人這週可能先看 X，下週先看 Reddit；有些貼文被重複記錄，有些只有標題沒有正文；遇到登入失效或上游網站改版時，報告仍然看起來像正常完成。最後產出的不是情報，而是「這次剛好看到的東西」。

因此我把流程拆成四層：收集、清理、判讀、驗證。每層都保留自己的證據，某一層失敗時不能假裝整條管線成功。

第一層：多來源收集

目前的來源大致分成四類：

收集器不應直接產生結論。它只需要留下來源 URL、標題、作者或社群、時間、原始文字，以及抓取狀態。若正文讀不到，就標記為讀不到，不用模型補寫一篇看似合理的內容。

第二層：清理與去重

同一則消息常會同時出現在官方文章、轉貼與討論串。若全部送進模型，報告很容易把同一件事寫成三個趨勢。

清理階段會先做幾件事：移除沒有正文的項目、標準化 URL、保留原始發布時間、用標題與正文指紋做近似去重，再把轉貼和原始來源建立關聯。去重不是刪掉所有相似內容；如果不同社群對同一事件有明顯不同反應，仍要保留各自的觀點。

這裡有一個重要的資料狀態：thin upstream。意思是上游仍然回應，但有效內容數量異常少。若平常可以取得三十筆，今天只拿到兩筆，程式的 exit code 仍可能是 0，卻不代表報告可信。

因此我會同時記錄：請求數、成功數、正文可讀數、去重後數量、各來源占比，以及與近期基準的差距。低於門檻時，報告必須明確標示資料不足，必要時切換備援來源或停止產出結論。

第三層：八段式判讀

清理後才交給模型做歸納。固定框架比每次臨時問模型更重要，因為固定框架才能比較今天與昨天。

1. 今日最重要的訊號是什麼
2. 哪些內容只是重複新聞
3. 哪些訊號和 ZoneTech 的客戶或服務直接相關
4. 背後反映的技術或商業變化
5. 有哪些反方證據或不確定性
6. 對企業 WiFi、IT 委外、AI 與備份服務的可能影響
7. 今天可以採取的最小行動
8. 需要持續觀察的指標與來源

模型的工作是排序與解釋，不是替收集器填空。每個重要結論都要能回指至少一個實際來源；只有模型說「市場正在轉向」而沒有來源的句子，不應進入正式報告。

第四層：送出前品質檢查

社群報告最危險的錯誤，往往不是完全虛構，而是半真半假：連結存在，但內容不支持結論；數字有出處，但統計範圍被改變；昨天的熱門貼文被重新包裝成今天的趨勢。

所以送出前至少檢查以下項目：

如果上游健康檢查失敗，正確作法是回報「本次資料不足」，不是用舊報告補滿篇幅。舊資料可以作為背景，但必須明確標示日期，不能冒充今日新訊號。

真正有用的輸出

每天最後交付的不是一大串連結，而是少量、可執行的訊號。例如：某個開源 Agent 框架的認證機制在多個社群出現相同抱怨，工程 owner 可以安排測試；某種備份方案在企業管理者社群被反覆詢問，業務可以把它加入客戶訪談問題；某個熱門工具只有大量轉貼、沒有實際部署證據，就先列入觀察而不是立即採購。

這種輸出把社群雷達接回公司的決策流程：情報負責縮短發現時間，工程負責驗證，業務負責確認客戶需求，管理者決定是否投入。Agent 不代替這些角色，而是讓他們不用每天從零開始找資料。

實際證據與目前限制

這條管線的完成標準不是「模型產生了一篇報告」，而是：

第一，本機留下原始收集資料、清理結果與最後報告，能夠重跑與追查。

第二，每次執行都有來源統計與健康狀態，能分辨正常結果、thin upstream 與認證失效。

第三，報告中的連結可以讀回，主要結論能對應到實際來源，沒有把推測寫成事實。

目前仍有平台權限、登入 session 與動態載入等限制，所以不同來源不會假裝擁有相同可靠度。這反而是自動化系統必須面對的現實：知道自己沒有資料，比產出一篇完整但不可驗證的報告更有價值。

下一篇會談多平台整合。當情報、財務、客戶訊息與內容產製都開始自動化後，真正的問題就不再是「能不能接 API」，而是如何讓同一個 core 在不同平台上安全地工作。