AI Social API
更新於 2026-09-18 · Chad

投訴帖喺財經台、上班台先得十幾個回覆,幾時先燒到時事台?用 LIHKG-scraper 跨關鍵字全站搜尋撒早期預警網

一句話: 連登好多投訴帖一開始淨係喺財經台、上班台呢類版度得十幾個回覆,遠遠未去到時事台先算「爆咗」——用 LIHKG-scraper 嘅搜尋模式一次過鋪十幾個關鍵字(品牌名、屋苑名、公司名),因為搜尋本身就係全站搜(唔使揀分類),先真正撒到一張跨分類嘅早期預警網。

本文含 Apify 推薦連結(不影響你的費用)。文中的成本與比較都據實列出,包含 Apify 不划算的情況。

得十幾個回覆嘅投訴帖,同真係上頭條之間有幾遠

連登其中一個分台可以搵到一篇投訴:樓主話有客戶投訴金管局之後,ZA Bank隨即封咗佢個戶口(原帖)。呢類單一用戶嘅指控,喺官方未回應之前唔應該當佢係事實——但佢示範緊一件事:呢類帖一開始好靜,唔會自動彈去財經新聞版。如果你淨係睇財經新聞或者淨係滑時事台,好可能完全唔知呢篇帖存在。

另一篇喺連登出現嘅帖,樓主指啟盈苑有業主懷疑私下拆牆改動間隔,留言區都有講房屋局話會跟進(原帖)。獨立嘅新聞報道其後確認:房屋局突擊稽查9個單位,發現7個單位嘅廚房防火門被拆除,但無發現結構牆被拆(星島頭條,2026年9月5日)。留意論壇帖入面講嘅戶數同官方稽查結果嘅單位數對唔上——呢個落差本身就係要持續追蹤先睇得到嘅嘢,睇一次新聞唔會知道原始投訴同後續官方行動之間嘅出入有幾大。

現有《壽司郎當日道歉、陳曉東隔日回應》嗰篇處理嘅係「已經知道係邊單」嘅退燒判斷;呢篇處理緊嘅係更早一步——邊單會爆,喺變成新聞之前根本唔知道要監測邊個關鍵字。兩個係唔同階段嘅問題。

三個真實情境,三種 ordermaxItemsdateFrom 組合

LIHKG-scraper 嘅搜尋模式唔止呢篇講嘅早期預警撒網一種用法——同一個mode: "search"ordermaxItemsdateFrom呢三個欄位點揀,要睇你落緊邊個情境:仲未知邊單會爆嘅廣撒網、已經知道係邊單話題嘅退燒判斷,定係已經有具體個案要整理蒐證時間軸。三個情境嘅設定同時機對照如下:

早期預警撒網(本文)已知話題退燒判斷Deepfake蒐證時間軸
orderdesc_create_time(揸實岩岩開嘅新帖)desc_reply_time(input schema標明嘅監控用排序,睇仲有冇人接話)desc_create_time(按發文時間整理時間軸)
maxItems細(例如10,撒網控成本)30(配合dateFrom持續追蹤已知話題)100(一次過盡量攞晒相關帖做蒐證)
dateFrom通常留空(仲未知時間範圍)設(例如3d),配合desc_reply_time提早停頁慳成本選填(例如1w,只想追新增討論先加)
幾時用未知邊單會爆,廣撒多個唔相關關鍵字揪候選訊號已經知道係邊單,追蹤討論係漲緊定已經冧已有具體受害人/個案,整理有日期有連結嘅公開討論時間軸做輔助蒐證

點樣用 LIHKG-scraper 撒一張跨分類嘅早期預警網

Step 1 — 用搜尋模式鋪一批關鍵字,唔使揀分類

{
  "mode": "search",
  "keywords": ["某品牌", "某屋苑", "某公司", "某產品"],
  "order": "desc_create_time",
  "maxItems": 10
}

modesearch就已經係全站搜尋標題(品牌、產品、地產商名),唔使亦都冇得揀分類——input schema入面catIds淨係分台列表模式(thread-list)先用得到。keywords最多可以鋪50個,每個關鍵字各自查一輪,一次run就可以同時撒晒多個唔相關嘅候選詞。orderdesc_create_time(最新發文優先),揸實岩岩開嘅新帖——呢個同追蹤已知話題退燒嗰篇揀desc_reply_time嘅原因唔一樣:早期預警要嘅係「岩岩出現」,唔係「仲有人回緊」。maxItems揸細啲(例如10)控制成本,因為呢步嘅目標係撒網,唔係窮盡每個關鍵字底下所有帖。

Step 2 — 排程重複執行同一批關鍵字

用Apify內建嘅Schedule功能,或者外部工具(例如n8n、cron),每隔幾個鐘或者每日執行一次同一組keywords。每次執行都會回傳當下符合條件嘅帖子,欄位包括thread_idtitleauthorreply_countcreated_atthread_urlscraped_at

Step 3 — 比對前後兩次結果嘅thread_id,揪出新出現嘅候選

新出現嘅thread_id就係新訊號,記落一份追蹤清單。之後對呢幾條真正想長期釘實嘅帖,先轉用《壽司郎當日道歉、陳曉東隔日回應》嗰篇教嘅方法——order改揀desc_reply_time,配合dateFrom(例如3d),持續比對reply_countlast_reply_at嘅變化,睇討論係仲喺度漲定已經冇人接話。

Step 4(進階)— 唔想自己手動diff thread_id,可以改用asia-social-listening

{
  "brandKeyword": "某品牌",
  "searchAliases": ["某品牌英文名", "某品牌簡稱"],
  "platforms": ["lihkg"],
  "deltaMode": true,
  "deduplication": true
}

brandKeyword係必填嘅單一主詞,searchAliases可以加埋最多10個同一個品牌嘅額外搜法(英文名、簡稱、常見錯拼);deltaMode開啟後會用命名嘅key-value store記低已經見過嘅mention_id,跨run自動比對,只回傳「上次執行之後」嘅新mention,唔使自己維護一份清單。platforms["lihkg"]就淨係監控連登(呢個actor仲支援同時監控PTT、HardwareZone、Telegram,但跨平台唔喺呢篇範圍)。留意呢個模式係圍住「一個品牌嘅唔同叫法」設計,如果你要盯嘅係好多個完全唔相關嘅候選詞(唔同屋苑名、唔同公司名),Step 1嘅keywords陣列(最多50個獨立關鍵字)先啱做廣撒網嗰步;篩選完剩返一兩個真係要長期監控嘅品牌,先轉用呢個做增量追蹤。

實際要花多少

LIHKG-scraper 三個模式對應三個計費事件——呢篇用嘅搜尋模式只會撞到search-listing,但《蘇民峰、Ming仔》嗰篇用到嘅mode: "thread"(完整貼文模式)會撞埋另外兩個,一次過寫齊先算係完整定價表:

事件單價適用actor/模式
search-listing(帖子列表每筆)$0.002LIHKG-scraper搜尋模式/分台列表模式
product-detail(帖子內容每篇)$0.008LIHKG-scraper完整貼文模式(mode: "thread")嘅主帖
review-item(回覆每則)$0.003LIHKG-scraper完整貼文模式(mode: "thread")嘅留言
mention-aggregated(去重後品牌提及每筆)$0.05asia-social-listening

以LIHKG-scraper搜尋模式為例,監控20個關鍵字,maxItems設10(每個關鍵字最多10筆),一次run上限200筆search-listing事件,成本上限$0.002×200=$0.40;實際計費以真正抓到嘅筆數為準,通常少過呢個上限。排程每4小時一次、一日6次,成本上限大約$2.4/日,一個月上限約$72——比起漏咗一單投訴帖一路靜靜燒到變公關風暴先知,呢筆廣撒網成本相對划算。如果改用mode: "thread"攞主帖連留言做蒐證(例如《蘇民峰、Ming仔》嗰篇嘅方法),成本係product-detail($0.008/篇)加review-item($0.003/則)——攞1篇主帖連50則留言大約$0.008+$0.003×50=$0.158。如果之後改用asia-social-listening嘅增量模式做長期單一品牌監控,因為單價貴 25 倍($0.05 vs $0.002),適合已經篩選出嚟、真係要長期釘實嘅少數幾個品牌,唔適合用嚟做初期嘅廣撒網——想再睇DIY社群聆聽同買現成SaaS嘅成本對比,可以睇自己用Apify建社群聆聽一個月多少錢嗰篇

三條路,挑一條開始

FAQ

標題講「跨分類」,係咪要喺 LIHKG-scraper 設定 catIds? 唔使。catIds 淨係分台列表模式(thread-list)先用得到,用嚟揀邊幾個分台。搜尋模式(mode設search)本身已經係全站搜尋標題,唔使揀分類就會撞晒所有分台,包括你根本冇諗到會有相關討論嘅版——呢個先係「跨分類」真正嘅來源。

keyword 命中咗,係咪代表件事真係會燒大? 唔係。關鍵字命中淨係話呢個詞喺標題度出現咗,唔代表講緊件事真係嚴重,亦都唔代表官方講法屬實——投訴帖好多時得一面之詞,官方未回應之前唔應該當佢係事實。命中之後要人手覆核內容,如果想再深一層判斷呢啲帖係真心投訴定係安排好嘅口碑操作,可以參考另一篇談用 LLM 分辨口碑文同真心負評嘅文章。

呢篇同《壽司郎當日道歉、陳曉東隔日回應》嗰篇有咩分別? 嗰篇係已知單一話題嘅時間軸退燒判斷——鎖定一個關鍵字,order揀desc_reply_time配合dateFrom,持續追蹤同一個thread_id嘅reply_count同last_reply_at點變化。呢篇係仲未知邊單會爆嘅廣撒網階段——鋪多個唔相關嘅keywords,order揀desc_create_time揸實新開嘅帖,先揪出候選訊號。兩個係監控漏斗嘅唔同階段,可以先用呢篇嘅方法揪到候選,再轉用嗰篇嘅方法長期釘實。

一定要自己手動比對 thread_id 先知邊個係新訊號? 唔一定。想連跨平台一齊監控、內建增量模式(deltaMode)同去重(deduplication),可以改用 asia-social-listening——用命名嘅key-value store記低已經見過嘅mention_id,跨run自動比對,唔使自己維護一份清單。代價係計費方式唔同、單價貴過原始搜尋,攞捨要睇你有幾多工程時間可以自己維護。

呢個方法點計費? LIHKG-scraper分三個事件計費:搜尋模式/分台列表模式用search-listing,每筆帖子列表0.002美元;完整貼文模式(mode設thread)攞主帖用product-detail,每篇0.008美元;攞留言用review-item,每則0.003美元,都係PPE按實際抓到嘅筆數計,冇月費。asia-social-listening用mention-aggregated事件,每一筆去重後嘅品牌提及計費0.05美元,重複提及唔計費。

抓連登資料合法嗎? 我哋只抓連登公開頁面嘅內容,唔登入帳號、唔抓需要登入先睇得到嘅資料,並遵守平台服務條款與當地法規。

延伸閱讀


作者 Chad 實際經營 40+ 隻上架 Apify actor(含本文用到嘅LIHKG-scraperasia-social-listening),文中每個數字與金額都直接對照原帖連結或新聞報道,查不到獨立來源嘅細節(例如未有第三方確認嘅單方投訴)呢篇會清楚標明係未經證實嘅指控,唔會當成事實寫。