盯公告這件事，人工做只有兩種結局：每天花半小時翻披露平台，或者乾脆不翻、錯過重要披露。自動化做也有兩種結局：設計得好，它只在有實質變動時找你；設計得差，它每天推三十條無關緊要的通知，兩週後你把整個頻道靜音——然後在靜音的第三週錯過一份盈利警告。
這篇講的就是怎麼做出第一種。核心設計目標只有一句話：重要的事一定到得了你眼前，不重要的事一定到不了。 這兩個「一定」的實現方式完全不同：前者靠白名單與漏報自檢，後者靠分級過濾。先講清楚：本文是資訊管線的設計方法，不構成對任何公司或證券的評價與建議。
監控什麼：三類目標、三種節奏
| 目標類型 | 來源 | 節奏 | 雜訊特徵 | 漏報代價 |
|---|---|---|---|---|
| 公告與法定披露 | 披露易（HKEXnews）等法定披露平台 | 交易日每天都有新檔案 | 檔案數量中等，雜訊在「不重要的例行公告」 | 高——重大事項的第一手來源 |
| 研報 | 券商研究、獨立研究服務 | 不定期 | 觀點重複度高，同一事件多家跟進 | 中——錯過的是視角，不是事實 |
| 新聞與輿情 | 財經媒體、社交平台 | 即時 | 雜訊最高，轉述失真多 | 低——新聞能追到的，公告通常也有 |
三類目標的處理原則是同一條：下層做觸發，上層做確認。 新聞觸發關注，回到公告確認事實；研報觸發問題，回到財報驗證數字。資訊源的可信度分層見 港股調研資訊源地圖：披露易、年報與第三方數據。
開始前的合規提醒：自動化抓取前，先確認目標網站的使用條款與爬蟲協議，控制請求頻率、避免對網站造成負擔；抓取內容的個人使用與再散布授權因來源而異，機構使用請諮詢你所在機構的合規部門或合格顧問。本文只描述設計方法，不替任何具體抓取行為背書。
抓取策略：輪詢、去重與失敗處理
增量輪詢。 定時抓取目標的「列表層」（公告標題清單、研報目錄），與本地的已知集合比對，只對新項目做後續處理。頻率按目標節奏設定：法定披露可以每小時一巡，新聞類可以更高頻，研報每日一巡通常夠用。
識別與指紋。 每個檔案需要兩樣東西：
| 機制 | 用途 | 說明 |
|---|---|---|
| 穩定識別子 | 判斷「是不是同一份文件」 | 優先用來源提供的正式標識（檔案連結、編號）；沒有穩定識別子時，用內容雜湊值當指紋 |
| 內容指紋 | 判斷「同一份文件有沒有被改過」 | 識別子相同但指紋變化，代表出現了修訂版——這本身是一個值得通知的事件，而不是新事件 |
實現載體。 三條路線，按團隊技能與目標複雜度選擇：
| 路徑 | 代表工具 | 適合 | 注意 |
|---|---|---|---|
| 無代碼工作流平台 | n8n 等 | 快速原型：定時觸發、抓取、條件分支、推送通知，一天內能拼出來 | 對帳這類需要狀態的邏輯在節點裡彆扭；自託管時別忘了平台自身的備份 |
| 自寫腳本＋排程 | Python 加 cron 類排程 | 生產級：日誌、對帳、心跳完全可控 | 需要維護能力；腳本悄悄死掉的風險要靠外部心跳兜住 |
| Agent 框架 | OpenClaw 等 | 沒有固定版面的頁面、需要「瀏覽—理解—決策」迴路的來源 | 成本與不確定性都更高；白名單規則部分仍應落在確定性代碼裡 |
實務上通常混合：抓取、去重、白名單匹配這些確定性步驟用腳本或工作流平台；只有灰區分類與摘要經過模型。能用規則做的不要交給模型——這是成本問題，更是可靠性問題：規則的行為可預測、可審計，模型不是。
失敗處理，比成功處理更重要。 監控系統最常見的實際故障不是誤報，而是悄悄死掉：網站改版導致解析失敗、反爬機制擋住了請求、排程任務停了——然後系統每天「正常」報告沒有新東西。三道保險：
- 心跳：即使沒有任何新項目，每天固定發一條「今日巡檢正常，抓到 N 條、新增 0 條」的心跳訊息。心跳消失本身就是警報
- 抓取日誌：每次輪詢記錄時間、抓到數量、失敗原因。事後要能回答「那天為什麼沒抓到」
- 對帳：每天用另一個獨立路徑（例如人工打開列表頁掃一眼）核對系統抓到的總數與來源實際總數是否一致。對帳差異觸發警報——這是「漏報自檢」的機械化版本
變動偵測：過濾雜訊的三道閘
不是每個新檔案都值得通知你。過濾分三道閘，順序執行：
閘一：去重。 比對識別子與指紋，擋掉重複出現的同一份文件。純機械操作，不需要 AI。
閘二：分類。 把新項目分成三堆，每堆的預設處理不同：
| 分類 | 處理 | 類別示例 |
|---|---|---|
| 白名單（高關注） | 立即推送 | 業績公告、盈利警告或正面盈利預告、配售與供股、回購、更換核數師、董事變動、重大訴訟、關連交易、停牌與復牌、與除牌程序相關的公告 |
| 灰區 | 進入每日摘要 | 一般業務公告、無法一眼歸類的文件 |
| 低優先 | 只歸檔，不推送 | 例行股東大會通告、標準格式的定期申報文件 |
分類的實現紀律：規則先行，模型墊後。 白名單關鍵詞（標題匹配）直接命中、直接推送，不經過任何模型判斷；只有關鍵詞無法分類的項目，才交給 LLM 做初篩。原因很直接——模型偶爾會把「更換核數師」歸成人事類例行公告，而關鍵詞規則不會。LLM 初篩的結果要保存分類理由，供定期校準（見後文「平衡術」一節）。
閘三：影響評估。 對白名單與灰區項目，生成「與既有認知的差異」：這家公司的這個公告，相對於你已有的記錄（上一份業績、最近的股權變動）改變了什麼。輸出的是一句差異描述，例如「本季首次出現盈利警告類公告」，而不是任何買賣方向的評價。
摘要與影響評估：LLM 的用法與界線
摘要環節最容易引入幻覺，界線要畫死：
| 規則 | 理由 |
|---|---|
| 每條摘要必須附原文連結與披露時間 | 摘要的價值是幫你決定「要不要點開原文」，不是替代原文 |
| 只拿到標題時，摘要必須標注「僅基於標題」 | 模型會用標題腦補內容——腦補的部分就是幻覺（見 AI 在金融場景的幻覺風險：三種最貴的錯誤） |
| 摘要不得添加原文沒有的因果與動機 | 「因銷售下滑導致盈警」——如果公告沒寫原因，這半句就是編的 |
| 過濾只影響推送，不影響存檔 | 所有抓到的項目全量歸檔。分類錯誤的代價因此從「永久丟失」降為「晚點看到」 |
| LLM 不擁有「丟棄」權限 | 模型可以決定優先級，不能決定存在性。刪除權只在人 |
影響評估的進階做法是把新公告與你的研究記錄（你的第一個投研工作流：從提問到可回溯結論 裡的證據卡）做比對：新資訊支持還是削弱既有結論？比對不上的，列為「待人工裁定」。這一步產出的是研究線索，不是交易信號。
推送管道與通知分級
三個層級，各走各的管道：
| 層級 | 管道 | 時效 | 內容規格 |
|---|---|---|---|
| 立即 | IM 機器人或郵件 | 分鐘級 | 分類＋三句摘要（標注資訊完整度）＋原文連結＋披露時間 |
| 每日摘要 | 固定時間一封郵件或訊息 | 日 | 灰區與低優先項目的清單，每條一行；附當日心跳與對帳結果 |
| 每週歸檔 | 本地存檔或知識庫 | 週 | 全量索引、抓取統計、分類校準報告 |
立即推送的訊息格式，給一個具體示例（內容為教學用假設示例）：
【立即｜盈利警告類】教學用假設公司（代碼 00000）
摘要：披露盈利警告類公告。全文尚未取得，本條僅基於標題。
披露時間：2026-09-30 17:08
來源：披露易公告列表（附連結）
系統狀態：今日巡檢 3 次正常；對帳一致；本條為白名單規則命中，未經模型分類。
最後一行是刻意設計的：讓每條通知自帶「我是怎麼產生的」——規則命中還是模型分類、基於標題還是全文。這樣當某條通知事後被證明有誤時，你能立刻定位問題出在哪一層，校準也才有對象。
兩個細節決定這套系統能不能長期活著：
- 安靜時段：立即推送設免打擾窗口。如果你發現自己需要半夜接收某一類通知，把它單獨列為「喚醒級」，其餘一律排隊到早上——喚醒級清單越短越好。
- 通知的固定格式：每條通知的結構一模一樣（什麼事、摘要、來源、時間）。格式穩定，你的眼睛才能訓練成「掃描器」，十秒決定一條通知要不要展開。
平衡術：「不漏」與「不煩」怎麼同時成立
這兩目標表面衝突，實際上是靠不對稱設計化解的：
| 原則 | 做法 |
|---|---|
| 誤報便宜，漏報昂貴 | 白名單寧可過寬：多推一條「不重要的更換董事公告」的代價是十秒鐘；把盈利警告歸檔的代價不可估量。分類猶豫時，一律向上歸檔 |
| 過濾可撤銷 | 全量存檔意味著任何過濾錯誤都能被挽回——被過濾的項目永遠查得到 |
| 漏報有自檢 | 心跳＋每日對帳（上一節），確保「系統沒抓到」與「沒有新東西」兩種狀態可以區分 |
| 分類會退化，定期校準 | 每月回顧一次：當月每日摘要裡有沒有「事後證明重要」的項目？有，就把對應模式升進白名單。這個回顧是防止三道閘隨時間失效的唯一機制 |
| 通知疲勞有指標 | 如果你連續一週沒打開每日摘要，說明灰區太寬——正確動作是收緊分類，錯誤動作是靜音頻道 |
還有一個常被忽略的雜訊源：同一事件的重複報導。一份公告觸發了立即推送，隨後幾家媒體跟進報導，又各自觸發新聞告警——你收到五條通知，講的其實是同一件事。解法是事件級去重：新資訊先嘗試掛到既有事件上，只有「事件出現了新事實」才值得再次推送，單純的轉述與評論只進歸檔。
一句話總結這套設計哲學：把「不漏」交給機械（白名單、全量存檔、對帳），把「不煩」交給分級（推送、摘要、歸檔），兩邊都留下校準的迴路。
AI 會在這裡出錯
| 出錯形態 | 場景 | 防法 |
|---|---|---|
| 摘要失真 | 添加原文沒有的因果、把「可能」寫成「已經」 | 摘要與原文並存；抽樣人工比對；重要公告永遠讀原文 |
| 標題腦補 | 只抓到標題就生成內容豐富的摘要 | 強制標注資訊完整度；「僅基於標題」的摘要不得包含內容細節 |
| 分類失誤 | 把白名單類別歸入例行公告 | 關鍵詞規則優先於模型；分類理由留檔供校準 |
| 時間戳混淆 | 把抓取時間當披露時間，新舊公告排序錯亂 | 兩個時間分開存；通知中顯示披露時間 |
| 監控本身悄悄死掉 | 抓取失敗但系統不報錯 | 心跳、日誌、對帳三道保險 |
| 用舊記憶補充現況 | 模型在摘要裡混入訓練資料中對該公司的舊印象 | 摘要只允許基於本次抓到的內容生成，禁止引入外部記憶 |
最後提醒：監控 Agent 的輸出屬於「發現層」，不屬於「結論層」。它告訴你哪裡發生了變化，變化意味著什麼，仍然要走 你的第一個投研工作流：從提問到可回溯結論 的查證流程。把監控管道直接接上交易決策，是所有環節裡最危險的自動化。涉及證券資訊發布與使用的監管面向，見 投研 AI 的合規邊界：免責、留痕與可回溯。
下一步
- 港股調研資訊源地圖：披露易、年報與第三方數據：監控目標的完整資訊源地圖與可信度分層。
- 金融數據 API 調研：為 Agent 框架注入市場數據能力：用數據 API 取代部分抓取的選型研究。
- 財報電話會議紀要轉投資要點：監控抓到業績公告之後，下一條高價值資訊流——財報電話會議的處理方法。
- AI 在金融場景的幻覺風險：三種最貴的錯誤：摘要環節所有防線的理論基礎：三種最貴的幻覺錯誤。