1. 當日報變成一種產(chǎn)品我為什么要做AI日報自動化每天早上八點半我手機里會準時彈出一條消息不是新聞推送也不是社交軟件提醒而是一份我自己搭建的AI日報。它包含過去24小時內(nèi)我關(guān)注的幾個信息源里最重要的動態(tài)按主題分好類每條附一句話摘要和原文鏈接。整個過程沒有人工干預從抓取、篩選、摘要到排版推送全自動跑完。這件事的起點其實很樸素。2025年下半年開始AI領(lǐng)域的信息密度到了一個讓人窒息的程度——每天醒來打開信息流幾十條新模型發(fā)布、新論文、新工具、新融資刷完一圈半小時沒了真正有價值的信息可能就三五條。我試過用收藏夾、用稍后讀、用各種聚合工具最后發(fā)現(xiàn)都解決不了一個核心矛盾信息是無限的但我的注意力是有限的。所以AI日報這個項目本質(zhì)上不是做一個新聞產(chǎn)品而是做一套信息降噪系統(tǒng)。它的目標很明確把每天幾百條原始信息壓縮成一份十分鐘能讀完、且不會漏掉關(guān)鍵動態(tài)的簡報。適合誰來參考如果你也在被信息過載困擾或者你想學一套完整的抓取-處理-分發(fā)自動化鏈路那這套東西可以直接抄作業(yè)。它涉及的技術(shù)棧不復雜但每一個環(huán)節(jié)都有坑我會把踩過的都講清楚。需要先說明一點這篇內(nèi)容里的日期、數(shù)據(jù)、案例都是基于我自己的運行環(huán)境做的演示你實際跑的時候數(shù)字會不一樣但方法論是通用的。2. 信息源的選擇不是越多越好而是要可維護2.1 我為什么砍掉了三分之二的信息源一開始我貪心接了十幾個源各種技術(shù)博客、論文預印本平臺、行業(yè)媒體、社交平臺上的技術(shù)賬號、甚至幾個郵件列表。結(jié)果第一周就崩了——不是技術(shù)崩是內(nèi)容崩。同一個事件被五個源重復報道摘要出來五條幾乎一樣的內(nèi)容有些源更新頻率極低一周才一條但每次抓取都要花時間還有些源格式極其混亂解析出來的正文全是亂碼。后來我做了一次大清理標準就三條更新頻率穩(wěn)定至少每天有更新否則不值得占用抓取配額。內(nèi)容有獨特性如果它的內(nèi)容在別處也能看到且別處質(zhì)量更高就砍掉。結(jié)構(gòu)可解析RSS、公開API、或者結(jié)構(gòu)規(guī)整的頁面優(yōu)先純靠正則硬啃的源慎重。最后留下的源控制在8個以內(nèi)。這個數(shù)字不是拍腦袋定的而是根據(jù)我每天能消化的信息量倒推的——一份日報如果超過15條我就讀不完了而8個源平均每天產(chǎn)出20-30條原始信息經(jīng)過篩選后剛好落在10-15條這個區(qū)間。2.2 抓取方式的選擇邏輯不同源要用不同的抓取策略這里沒有萬能方案。我實際用的是三種方式的組合抓取方式適用場景優(yōu)點坑點RSS/Atom有標準訂閱源的博客、媒體結(jié)構(gòu)穩(wěn)定解析簡單部分源只給摘要不給全文公開API提供接口的平臺數(shù)據(jù)規(guī)整有速率控制需要處理鑒權(quán)和分頁頁面解析沒有訂閱源的站點能拿到最全內(nèi)容頁面改版就失效維護成本高我個人的優(yōu)先級是API RSS 頁面解析。頁面解析是最后手段因為它的維護成本太高了。我有個源用了三個月對方網(wǎng)站改了一次DOM結(jié)構(gòu)我的解析規(guī)則全廢那天日報直接空了。從那以后凡是能用RSS的我絕不寫頁面解析。提示抓取頻率不要設(shè)太高。我一開始設(shè)成每10分鐘一次結(jié)果被某個源限流了。后來改成每天固定兩個時間點抓取早上7點和晚上7點既夠用又不會給對方服務(wù)器造成壓力。2.3 去重的核心邏輯去重是日報質(zhì)量的生命線。我的去重分兩層第一層是URL去重這個簡單把URL規(guī)范化去掉追蹤參數(shù)、統(tǒng)一大小寫后做哈希比對就行。第二層是內(nèi)容去重這個復雜一些。同一個事件不同源的報道URL完全不同但內(nèi)容高度相似。我用的是文本相似度計算——把標題和正文前200字拼起來做分詞后計算余弦相似度超過閾值我設(shè)的是0.75就判定為重復只保留信息量最大的那條。這個閾值是調(diào)出來的。設(shè)0.9太松重復內(nèi)容還是會漏進來設(shè)0.6太嚴會把不同角度的報道誤殺。0.75是我實測下來比較平衡的值但你可以根據(jù)自己的源的特點微調(diào)。3. 從原始信息到一句話摘要處理鏈路拆解3.1 清洗把臟數(shù)據(jù)變成可處理數(shù)據(jù)抓下來的原始內(nèi)容十有八九是臟的。常見的問題包括HTML標簽殘留、多余的空格和換行、廣告段落混在正文里、編碼亂碼。這一步不做干凈后面的摘要質(zhì)量一定崩。我的清洗流程是這樣的去HTML標簽用解析庫把HTML轉(zhuǎn)成純文本保留段落結(jié)構(gòu)。去除噪聲段落比如點擊上方關(guān)注我們版權(quán)聲明相關(guān)閱讀這類固定模式用規(guī)則過濾掉。統(tǒng)一空白字符把連續(xù)的空格、換行、制表符統(tǒng)一成單個空格或標準換行。編碼歸一化統(tǒng)一轉(zhuǎn)成UTF-8處理掉特殊符號。這里有個經(jīng)驗不要試圖用一條正則解決所有清洗問題。我見過有人寫一個巨長的正則想一次性搞定結(jié)果維護起來是噩夢。正確做法是拆成多個小步驟每個步驟只干一件事出問題了好定位。3.2 摘要生成為什么我不直接用大模型一把梭很多人做摘要的第一反應(yīng)是把全文丟給大模型讓它輸出一句話總結(jié)。我一開始也這么干但很快發(fā)現(xiàn)三個問題成本每天幾十條內(nèi)容每條都調(diào)一次大模型一個月下來費用不低。不穩(wěn)定同樣的輸入模型每次輸出的風格和長度都不一樣日報看起來忽長忽短。幻覺偶爾會編造原文里沒有的信息這在日報場景里是致命的。所以我改成了兩段式摘要第一段是抽取式摘要用傳統(tǒng)方法比如TextRank或者基于詞頻的句子打分從原文里挑出最重要的1-2個句子。這一步不生成新內(nèi)容只做選擇所以不會有幻覺成本也幾乎為零。第二段是改寫式壓縮把抽出來的句子交給大模型讓它壓縮成一句話并且限定字數(shù)我設(shè)的是60字以內(nèi)。因為輸入已經(jīng)是精選過的句子模型的發(fā)揮空間被約束住了幻覺概率大幅降低成本也降下來了。這個組合實測下來摘要質(zhì)量比純大模型生成穩(wěn)定得多而且每條的成本降到了原來的五分之一左右。3.3 分類讓日報有目錄感一份好的日報讀者應(yīng)該能一眼看到今天有哪些類別的內(nèi)容。我的分類體系是固定的五類模型與算法新模型發(fā)布、算法改進、訓練技巧工具與產(chǎn)品新工具、新功能、實用產(chǎn)品行業(yè)動態(tài)融資、合作、政策相關(guān)注意這里只做客觀陳述不做評論論文速覽值得關(guān)注的新論文觀點與教程有深度的分析文章、實操教程分類用的是關(guān)鍵詞匹配加規(guī)則判斷沒有用模型。原因是分類類別固定且邊界清晰規(guī)則方法足夠用而且速度快、可解釋。比如標題里出現(xiàn)發(fā)布開源模型就歸到模型類出現(xiàn)教程指南如何就歸到觀點類。當然規(guī)則會有誤判我的處理方式是允許少量誤判但保證大類不錯。讀者對分類的容忍度其實很高只要不是把論文歸到融資里基本不會有人在意。4. 排版與推送日報的最后一公里4.1 排版不是美化是信息架構(gòu)我見過很多自動化日報內(nèi)容不錯但排版一塌糊涂——所有內(nèi)容堆在一起沒有層級沒有留白。讀者打開一看就關(guān)了。排版的核心不是好看而是降低閱讀成本。我的排版規(guī)則很簡單每個類別一個二級標題類別之間用分割線隔開。每條內(nèi)容一行標題加粗 一行摘要 一行來源鏈接。摘要控制在60字以內(nèi)超過就截斷。全文控制在手機屏幕滑動3-4屏以內(nèi)。這里有個細節(jié)鏈接不要用裸URL。裸URL又長又丑還占地方。我用的是Markdown的鏈接語法顯示成原文兩個字點進去才是真實鏈接。4.2 推送渠道的選擇推送渠道我試過三種郵件、即時通訊機器人、靜態(tài)網(wǎng)頁。郵件優(yōu)點是歸檔方便缺點是打開率低而且手機上看郵件體驗一般。即時通訊機器人優(yōu)點是觸達快打開率高缺點是消息太長會被折疊而且歷史消息不好檢索。靜態(tài)網(wǎng)頁優(yōu)點是可以做得很好看歷史歸檔也方便缺點是需要主動去打開。最后我的方案是組合拳即時通訊機器人推送一個精簡版只列標題和鏈接完整版生成靜態(tài)網(wǎng)頁鏈接放在精簡版末尾。這樣既保證了觸達又保證了完整體驗。4.3 定時任務(wù)的穩(wěn)定性整個鏈路是定時觸發(fā)的我用的是服務(wù)器上的定時任務(wù)。這里踩過一個坑任務(wù)執(zhí)行時間要留足余量。我一開始設(shè)的是早上7點執(zhí)行8點推送結(jié)果有幾次因為某個源響應(yīng)慢整個流程拖到了8點半才跑完推送就延遲了。后來我改成了兩個措施一是把執(zhí)行時間提前到早上6點留出兩小時緩沖二是給每個抓取步驟設(shè)了超時時間單個源最多等30秒超時就跳過不阻塞整體流程。這樣即使某個源掛了日報還是能按時出來只是少一條內(nèi)容而已。注意定時任務(wù)一定要加失敗告警。我有一次服務(wù)器磁盤滿了任務(wù)靜默失敗我三天后才發(fā)現(xiàn)日報沒推送?，F(xiàn)在只要任務(wù)失敗我就會收到一條提醒。5. 運行三個月后我總結(jié)出的幾條硬經(jīng)驗5.1 關(guān)于內(nèi)容質(zhì)量寧缺毋濫日報最怕的不是內(nèi)容少而是內(nèi)容水。我寧可某天只有5條也不要為了湊數(shù)塞進去10條垃圾。判斷標準很簡單這條信息如果我不推讀者會錯過什么重要的事嗎如果答案是不會那就砍掉。我設(shè)了一個硬性規(guī)則每條內(nèi)容必須能回答它新在哪里。新模型、新功能、新數(shù)據(jù)、新觀點總得占一個。純轉(zhuǎn)述、純評論、純舊聞重發(fā)的一律不要。5.2 關(guān)于自動化留一個人工兜底的口子全自動化聽起來很酷但實際運行中總會有意外。我的做法是自動化跑完后生成的內(nèi)容先存到一個待發(fā)布區(qū)我有10分鐘時間可以快速掃一眼如果發(fā)現(xiàn)明顯問題比如某條摘要完全跑偏可以手動刪掉或修改然后再觸發(fā)推送。這個人工兜底的口子救過我好幾次。有一次某個源的文章標題和正文完全不匹配對方網(wǎng)站自己出的bug自動摘要出來的內(nèi)容驢唇不對馬嘴我掃一眼就刪了。如果沒有這個環(huán)節(jié)這條內(nèi)容就推給讀者了。5.3 關(guān)于維護成本把配置和代碼分離這是工程上的經(jīng)驗但很重要。我一開始把信息源列表、分類關(guān)鍵詞、推送渠道這些都硬編碼在代碼里結(jié)果每次調(diào)整都要改代碼、重新部署。后來我把這些全部抽成配置文件YAML格式代碼只負責讀配置執(zhí)行。現(xiàn)在我想加一個源、改一個關(guān)鍵詞改配置文件就行不用碰代碼。這個改動看起來小但讓整個系統(tǒng)的可維護性上了一個臺階。自動化系統(tǒng)的壽命取決于你調(diào)整它有多容易。5.4 一個容易被忽略的細節(jié)時區(qū)如果你的信息源來自不同地區(qū)時區(qū)問題一定會找上你。我遇到過兩次一次是某條內(nèi)容明明是昨天的但因為時區(qū)換算錯誤被當成了今天的另一次是定時任務(wù)在夏令時切換那天執(zhí)行時間錯了一小時。解決方案很簡單但必須做所有時間統(tǒng)一存UTC只在展示的時候轉(zhuǎn)成本地時區(qū)。定時任務(wù)的時間也要明確指定時區(qū)不要依賴服務(wù)器默認設(shè)置。6. 如果你想自己搭一套從哪開始6.1 最小可行版本先跑通一條鏈路不要一上來就追求完整。我的建議是先做一個最小版本選一個源抓取清洗生成一條摘要推送到一個渠道。這條鏈路跑通了你再往上加源、加分類、加排版。最小版本大概需要這些東西一個能跑腳本的環(huán)境本地電腦就行、一個抓取庫、一個摘要方案哪怕先用最簡單的截取前100字、一個推送渠道即時通訊機器人的webhook最簡單。6.2 逐步迭代的路線圖跑通最小版本后我建議按這個順序迭代加去重這是提升質(zhì)量最快的一步。加分類讓日報有結(jié)構(gòu)。優(yōu)化摘要從截取改成抽取改寫。加排版讓閱讀體驗上一個臺階。加人工兜底保證內(nèi)容不出大錯。加監(jiān)控告警保證系統(tǒng)穩(wěn)定運行。每一步都獨立可驗證不要跳步。我見過有人一上來就想做全套結(jié)果每個環(huán)節(jié)都是半成品最后整個系統(tǒng)跑不起來。6.3 關(guān)于成本的一個參考如果你用大模型做摘要成本主要取決于調(diào)用量。以我的規(guī)模每天20-30條每條一次調(diào)用來算一個月的費用大概是一杯咖啡的錢。這個成本對于個人項目來說完全可以接受。如果你連這個都想省那抽取式摘要其實也夠用只是讀起來沒那么順。最后分享一個我自己的體會做日報這件事技術(shù)只占三成剩下七成是內(nèi)容判斷。你得知道什么信息值得推、什么不值得這個判斷力沒法自動化只能靠你自己每天讀、每天篩慢慢養(yǎng)出來。工具能幫你省時間但省不掉你的判斷。