案例重點
系統唔係預測股票，而係將有時效的訊號、會員權限與通知流程變成一致、可追查的營運服務。
客戶過去逐隻打開 TradingView 圖表，檢查自研指標，再按行業整理訊號及回覆會員。股票池與會員數增加後，盤中、午休、收市、隔夜與重複訊號令人工標準難以保持一致。
項目改用原生 Alert 與 Webhook 接收結構化事件，再由同一份狀態支援 Telegram 查詢、會員分級、個人 Watchlist、使用分析與問題報告。
逐圖檢查可以應付小規模，但無法穩定處理訊號時效與大量會員查詢。
人員要記錄燈號與價位、判斷訊號是否過期或被新狀態取代、比較現價與風險水平，再回覆單股或多股問題。同一批資料經常要重新核對。
項目早期測試過瀏覽器自動化與畫面辨識，但登入狀態、頁面更新、載入速度及影像判讀都會影響結果。改用 TradingView 原生事件後，系統直接保存事件時間、價位與來源。
每次 Webhook 先保存為事件，再用市場時段、有效期與後續訊號計算目前狀態。
系統整理港股前置零、美股代號與不同訊息格式，並保留原始輸入。交易時段利用最近事件判斷訊號是否仍活躍；午休、收市與隔夜則使用符合當時情況的保留規則。
同色延續、轉燈、歷史定型與重複 Webhook 都有明確規則。規則修改先用歷史資料重播，再到 staging 及 shadow mode 驗證，避免直接改正式結果。
Telegram 查詢、會員分級與 Watchlist 共用同一套權限與最新狀態。
會員輸入一隻或多隻股票代號後，系統讀取最新訊號、行業資料、價格與限制，再按既定格式回覆。資料不足時會說明缺少哪一部分，不用推算值冒充已收到的事件。
普通會員看不到未開放功能，即使用戶手動輸入指令，伺服器仍會重新檢查會員資格與有效期。合資格會員可以保存個人 Watchlist，啟用時先建立 baseline，避免一次過收到舊訊號。
先發 Telegram 等確認，未確認先進入受限電話升級判斷。
Watchlist 出現全新而完整的訊號時，流程先發訊息與已見到按鈕。只有用戶未在指定時間確認，系統先考慮電話升級；接通、忙線、失敗、取消、未知結果、用戶確認或關閉監察都會停止後續。
電話流程已完成設計、整合與受控驗證，但真實電話仍受安全閘、緊急停止、配額及 shadow 檢查限制，唔應該寫成已向所有會員全面開放。
案例沒有量度投資回報、勝率或預測準確度，所有輸出保持教育用途及非投資建議界線。
已正式使用、受安全閘限制與仍在 shadow 的功能分開交代。
正式環境使用中
Webhook 訊號處理、Telegram 單股及多股查詢、會員權限、後台分析與問題報告。
已接入但受限制
個人 Watchlist 頁面、名單保存、新訊號評估與確認流程。
Shadow 或受控驗證
一般會員啟用監察、未確認訊息後的真實電話升級與正式人工修正審批。
客戶估算訊號監察、整理、回覆與異常追查效率提升約 80%。
客戶內部估算每月節省約 60 個人工作時，會員亦可以自行取得一致格式的查詢結果。管理員在同一介面處理會員、使用趨勢與問題報告。
60 小時與 80% 應配合最少一個完整月份的前後記錄再核對。公開數字只反映營運效率，並不代表任何投資表現。
常見問題
呢套系統會唔會自動買賣股票？
唔會。系統接收及整理客戶本身的指標事件，提供會員查詢與通知，並不代客落盤。
電話通知係咪已全面上線？
唔係。流程完成整合及受控驗證，但真實電話仍然受安全閘、配額與 shadow 檢查限制。
點樣避免一開 Watchlist 就收到舊訊號？
啟用時先記錄現有訊號作 baseline，之後只有全新而且完整有效的事件先會建立提醒。
EXPERT AUTOMATION CONSULTATION
你公司都有一條重複、容易出錯嘅流程？
同我哋講現時點做、每月工作量同最常見例外。我哋會先判斷邊一段值得自動化，再提出可驗收嘅第一階段。