每天早上一睜眼就刷新聞刷完一圈發(fā)現(xiàn)要么是標題黨要么是三天前的舊聞?wù)嬲杏玫男袠I(yè)動態(tài)早就被鋪天蓋地的內(nèi)容淹沒了。我項目里有個AI方向的調(diào)研需求老板丟給我一句話幫我盯著AI創(chuàng)業(yè)這塊的動態(tài)每天給我整理一份簡報。人肉盯新聞根本不現(xiàn)實我只能順手寫了個腳本調(diào)用新聞類API扔進去AI創(chuàng)業(yè)這個關(guān)鍵詞讓它每天自動抓取、自動去重、自動生成一份Markdown格式的當日簡報。這項目做完之后已經(jīng)穩(wěn)定跑了好幾個月過程踩了不少坑我把它完整拆開講講。這套東西本質(zhì)上做的事其實不復(fù)雜關(guān)鍵詞輸入、API請求、數(shù)據(jù)清洗、按固定模板輸出。難的點在于穩(wěn)定和好用——API不返回數(shù)據(jù)了怎么辦、關(guān)鍵詞命中了一堆無關(guān)內(nèi)容怎么辦、免費額度用完了怎么辦這些才是真正磨人的地方。我把整個過程、代碼思路、參數(shù)選擇邏輯和踩坑實錄全部記錄下來新手照著搭能少走很多彎路。1. 項目拆解與整體思路1.1 這個項目到底解決了什么問題先別急著寫代碼想清楚一件事你需要的不是調(diào)一個API而是一條完整的信息流水線。拿AI創(chuàng)業(yè)這個關(guān)鍵詞舉例如果你只是簡單調(diào)一次新聞API拿到的一定是大量噪聲——平臺隨手發(fā)的一條融資快訊會進來標題里帶AI的無關(guān)科技八卦也會進來甚至半個月前的舊聞都會被翻出來。我最早第一版腳本就是這樣跑出來的簡報慘不忍睹七條里有三條跟創(chuàng)業(yè)沒關(guān)系。所以整個項目的核心難點并不在API調(diào)用本身而在數(shù)據(jù)過濾的規(guī)則設(shè)計、時效性控制、以及輸出格式的可讀性。另一個容易被忽視的需求是每天自動。抓一次、兩次沒有意義定時任務(wù)才是這個項目的靈魂。搭配上調(diào)度機制之后它才算真正替代了人肉盯新聞的動作。這個項目的整體鏈路分四段關(guān)鍵詞配置 → API請求 → 數(shù)據(jù)清洗 → 簡報生成。每一段都有獨立的坑后面我一個一個講。1.2 為什么選API而不是直接去網(wǎng)頁抓取拿到需求之后我其實猶豫過兩個技術(shù)路線直接寫爬蟲去各大科技媒體抓頁面的方式還是用新聞API的方式。直接抓網(wǎng)頁的誘惑是新聞源可控、內(nèi)容全、不依賴第三方接口。但實踐過一次就知道有多惡心。目標網(wǎng)站的HTML結(jié)構(gòu)經(jīng)常變一個class類名改了你的解析器就廢了反爬機制越來越強請求頻率稍高就被封IP為了應(yīng)付不同的站點你得寫不同的解析代碼維護成本直線上升。某個站今天改版了整個鏈路斷掉這種不確定性對日報系統(tǒng)來說是致命的。API方式的優(yōu)勢是穩(wěn)定和標準化。新聞聚合服務(wù)把采集、去重、分類這些臟活累活都做完了你只需要處理好關(guān)鍵詞和參數(shù)就行。輸出結(jié)構(gòu)統(tǒng)一出錯概率低維護起來也很輕松。代價是——免費的API在請求配額、歷史數(shù)據(jù)時長、返回字段上都有限制。但在抓取最新的行業(yè)新聞這個場景里免費額度基本夠用是性價比很高的選擇因此我會選API方案。2. 新聞API選型與參數(shù)解析2.1 主流新聞API怎么選市面上的新聞聚合接口分成幾類一類是大而全的通用新聞API覆蓋面廣但中文內(nèi)容質(zhì)量和行業(yè)垂直度一般一類是垂直領(lǐng)域的數(shù)據(jù)服務(wù)比如專門做創(chuàng)投、科技資訊的數(shù)據(jù)好但接入門檻和價格都高還有一類是各門戶自帶的開放接口穩(wěn)定性看平臺心情不推薦作為主力源。我實際的篩選標準就三條第一是否支持中文關(guān)鍵詞檢索返回結(jié)果里中文新聞的比例要說得過去第二免費檔位的每日請求次數(shù)夠不夠你跑多個關(guān)鍵詞——如果一天要跑好幾個關(guān)鍵詞很快就超了第三返回字段是否包含發(fā)布時間、來源、摘要、鏈接這幾項基本配置少了任何一個都會讓簡報制作變得非常別扭。我的選擇落地之后是這樣的用一個通用新聞API作為主數(shù)據(jù)源把請求頻率控制在每分鐘幾次、每天累計請求數(shù)控制在免費額度內(nèi)。同時留了一個備用源配置主源出問題時自動切換。多源策略會在后面常見問題里詳細介紹這里先記住一個結(jié)論別把雞蛋放在一個數(shù)據(jù)源里新聞API掛掉是常態(tài)不是意外。2.2 核心參數(shù)設(shè)置與返回結(jié)構(gòu)解析新聞API的調(diào)用方式大同小異本質(zhì)都是構(gòu)造一個HTTP GET請求帶上認證信息和查詢參數(shù)。我需要重點解析幾個核心參數(shù)。q關(guān)鍵詞這是最需要花心思的參數(shù)。直接填A(yù)I創(chuàng)業(yè)會匹配到大量帶AI、帶創(chuàng)業(yè)但跟主題關(guān)系不大的內(nèi)容。實際使用中要配合布爾操作符比如寫成AI AND 創(chuàng)業(yè)的形式或者用精確短語限定。不同API支持的查詢語法不完全一樣但思路是一致的通過詞組和邏輯符把范圍收緊。from / to時間范圍這個參數(shù)決定了你拿回來的是不是昨天的新聞。日報的場景下我一般把 from 設(shè)置為今天零點to 設(shè)置為當前時間這樣天然過濾掉舊聞。有些免費API支持的歷史時間窗口很短比如只能查最近7天所以一個準確的 from 參數(shù)能幫你省不少事。sortBy排序規(guī)則大多數(shù)API支持按相關(guān)性、發(fā)布時間、熱度排序。我的經(jīng)驗是抓新聞簡報用publishedAt倒序保證看到的是最新內(nèi)容如果你做的是主題研究報告想看到的是權(quán)威大稿那就用relevancy。別默認使用API自己的默認值你永遠猜不到它的默認邏輯是什么。language語言明確指定中文避免混入大量英文內(nèi)容。有些API只在特定參數(shù)里支持語言過濾不設(shè)置的話它會返回全語種的結(jié)果這對簡報是災(zāi)難。pageSize / page分頁控制每次返回條數(shù)。簡報場景每頁取50條足夠了不要貪多。條數(shù)越多后續(xù)清洗的負擔越大而且免費API單次請求上限通常就100條。API的返回結(jié)構(gòu)一般是JSON核心字段各家大同小異都會有一個articles數(shù)組每條包含title、description、url、publishedAt、source等信息。你拿到的publishedAt通常是UTC時間不轉(zhuǎn)換就直接寫進簡報會出現(xiàn)下午三點顯示早上八點的錯亂。這個細節(jié)放在后面問題排查部分單獨講。3. 自動化抓取與簡報生成實現(xiàn)3.1 從零搭建抓取腳本環(huán)境方面我會用Python因為它處理JSON、做文本清洗、寫定時任務(wù)都方便。依賴只有兩個核心庫requests負責發(fā)HTTP請求schedule負責定時任務(wù)。日志這塊用自帶的logging就行不用額外引入復(fù)雜框架。在寫具體實現(xiàn)之前先把目錄結(jié)構(gòu)規(guī)劃好避免所有代碼堆在一個單個文件里后期難以維護。news_daily/ ├── config.py # 關(guān)鍵詞、API地址、請求參數(shù)配置 ├── fetcher.py # 新聞API調(diào)用與數(shù)據(jù)獲取 ├── cleaner.py # 數(shù)據(jù)清洗與去重過濾 ├── reporter.py # 簡報生成與格式化輸出 ├── scheduler.py # 調(diào)度入口 ├── logs/ # 運行日志存放目錄 └── output/ # 生成的日報文件目錄配置模塊先跑起來# config.py API_ENDPOINT https://api.news-demo.example.com/v1/everything API_KEY your-api-key-placeholder KEYWORDS [AI創(chuàng)業(yè), AI 融資, 大模型 創(chuàng)業(yè)] REQUEST_PARAMS { language: zh, sortBy: publishedAt, pageSize: 50, page: 1, } TIME_RANGE_HOURS 24 # 只取最近24小時的新聞然后是數(shù)據(jù)獲取模塊核心就是一個帶參數(shù)校驗的GET請求。這里有幾個必須處理的細節(jié)請求要設(shè)置超時時間避免某個API卡死導(dǎo)致整個腳本掛起返回狀態(tài)碼非200時要做異常處理把錯誤信息寫進日志而不是直接拋錯中斷。# fetcher.py import requests import datetime import logging from config import API_ENDPOINT, API_KEY, KEYWORDS, REQUEST_PARAMS logger logging.getLogger(__name__) def fetch_news(keyword: str, time_from: str) - list: params { q: keyword, from: time_from, to: datetime.datetime.now().isoformat(), language: REQUEST_PARAMS[language], sortBy: REQUEST_PARAMS[sortBy], pageSize: REQUEST_PARAMS[pageSize], page: REQUEST_PARAMS[page], apiKey: API_KEY, } try: resp requests.get(API_ENDPOINT, paramsparams, timeout10) resp.raise_for_status() data resp.json() if data.get(status) ! ok or not data.get(articles): logger.warning(f關(guān)鍵詞 [{keyword}] 無有效返回) return [] return data[articles] except requests.exceptions.Timeout: logger.error(f請求超時: {keyword}) return [] except requests.exceptions.HTTPError as e: logger.error(fHTTP錯誤: {e}) return [] except Exception as e: logger.error(f未知異常: {e}) return []函數(shù)返回的是清洗前的原始數(shù)據(jù)列表。注意time_from參數(shù)不是寫死的我讓它在調(diào)度入口統(tǒng)一生成保證每天的請求窗口都準確對齊最近24小時。3.2 數(shù)據(jù)清洗與簡報生成的邏輯數(shù)據(jù)清洗這一步是整個項目里性價比最高的環(huán)節(jié)它決定了簡報的閱讀體驗。直接拿API的原始返回出簡報的做法我也試過結(jié)果就是閱讀者要從一堆重復(fù)內(nèi)容里挑重點體驗很差。我遇到的第一個問題是平臺轉(zhuǎn)載重復(fù)。同一家媒體的稿件會被各個門戶互相轉(zhuǎn)載標題或正文高度相似。對 title 做規(guī)范化處理之后用MD5值去重一個簡單方案是只保留第一篇。這樣每天能擠掉兩到三成水分。第二個問題是關(guān)鍵詞命中但內(nèi)容跑偏。這需要做一層基于正文片段的過濾我維護了一個簡單的排除詞列表比如標題里只出現(xiàn)AI但正文完全沒有創(chuàng)業(yè)、融資、產(chǎn)品、落地這些業(yè)務(wù)語義的條目統(tǒng)一標記為低相關(guān)度。這個規(guī)則的邊界需要根據(jù)自己的場景去調(diào)不用過度設(shè)計能過濾明顯噪聲就夠了。第三個問題是內(nèi)容完整度檢測。description字段為空、url字段為空的條目直接丟棄它們不值得占簡報的位置。清洗完之后是格式化輸出。我選擇了Markdown格式的日報原因是它既能方便閱讀也能隨時轉(zhuǎn)換成HTML。日常實際使用中被Copy到各種文檔工具里不會亂版。# reporter.py def build_report(articles: list, keyword: str) - str: lines [f# 每日行業(yè)簡報{keyword}, ] lines.append(f生成時間{datetime.datetime.now():%Y-%m-%d %H:%M}) lines.append(f今日收錄{len(articles)} 條) lines.append() for idx, item in enumerate(articles, start1): title item.get(title, ).strip() source item.get(source, {}).get(name, 未知來源) pub_time item.get(publishedAt, )[:16].replace(T, ) url item.get(url, ) summary item.get(description, ).strip() lines.append(f### {idx}. {title}) lines.append(f 來源{source} 時間{pub_time}) lines.append() if summary: lines.append(f摘要{summary}) lines.append(f鏈接{url}) lines.append() return \n.join(lines)3.3 定時運行與部署細節(jié)腳本能跑通是一回事每天準點跑是另一回事。我先后試過幾種定時方案最終用的是schedule庫配合后臺常駐進程的方式因為它跨平臺、配置直觀而且出錯時日志排查方便。# scheduler.py import logging import schedule import time from fetcher import fetch_news from cleaner import clean_articles from reporter import build_report logging.basicConfig(levellogging.INFO, format%(asctime)s | %(levelname)s | %(message)s) def job(): keywords [AI創(chuàng)業(yè), AI 融資, 大模型 創(chuàng)業(yè)] all_articles [] for kw in keywords: time_from (datetime.datetime.now() - datetime.timedelta(hours24)).isoformat() raw fetch_news(kw, time_from) cleaned clean_articles(raw) report build_report(cleaned, kw) output_path foutput/{datetime.datetime.now():%Y-%m-%d}_{kw}.md with open(output_path, w, encodingutf-8) as f: f.write(report) logging.info(f關(guān)鍵詞 {kw} 簡報已生成: {len(cleaned)} 條) schedule.every().day.at(08:00).do(job) while True: schedule.run_pending() time.sleep(60)注意兩個細節(jié)第一文件寫入的編碼必須是utf-8否則Windows環(huán)境下打開中文內(nèi)容會亂碼第二每日生成一個獨立文件比把內(nèi)容追加進同一個文件更好用這樣做久了之后你能回顧某天的信息后續(xù)要做趨勢分析時也有素材。部署層面我選擇放在一臺低配服務(wù)器上讓它常駐運行。因為沒有圖形界面資源需求整體的占用相對有限。服務(wù)器上掛nohup或?qū)懞唵螁幽_本即可。如果只是個人使用Windows任務(wù)計劃程序配合python scheduler.py也能達到同樣效果。我的建議是能掛著跑就別手動觸發(fā)定時任務(wù)是這個項目價值的一半。4. 常見問題與排查技巧實錄4.1 免費接口的請求限制與超額處理免費新聞API最頭疼的問題就是請求次數(shù)限制。我遇到過不止一次腳本跑到中午就開始返回429狀態(tài)碼一看控制臺原來免費檔位每天只能請求500次。我代碼里為了抓四個關(guān)鍵詞每個關(guān)鍵詞做了翻頁遍歷早早就把限額耗光了。排查后發(fā)現(xiàn)原因有三個一是翻頁邏輯寫得太貪每次把最大分頁數(shù)都輪一遍二是沒有做時間窗口內(nèi)的請求潤滑短時間密集請求特別容易被限流三是多個關(guān)鍵詞共用一個API Key沒有錯峰調(diào)度。解決方案很簡單。第一嚴格控制每個關(guān)鍵詞只取前1到2頁數(shù)據(jù)日報不需要幾十年前的舊聞第一頁已經(jīng)是該時間窗口下最新的一批了。第二在關(guān)鍵詞之間加time.sleep()比如3到5秒把瞬時請求頻率降下來。第三在代碼里對429響應(yīng)做特殊處理捕獲到之后自動暫停60秒重試一次而不是直接拉崩。4.2 發(fā)布時間字段的時區(qū)錯亂問題這屬于不看不知道、一看嚇一跳的坑。API返回的publishedAt字段絕大多數(shù)情況下是UTC時間我最初直接在簡報里原樣使用。有一天我早上八點打開簡報發(fā)現(xiàn)頭條新聞的發(fā)布時間寫著凌晨兩點我還以為是API數(shù)據(jù)有問題仔細一推才知道是UTC沒做本地化。正確的處理方式是在清洗階段就把時間統(tǒng)一轉(zhuǎn)換成東八區(qū)時間轉(zhuǎn)換邏輯不超過三行代碼但必須放在數(shù)據(jù)寫入簡報之前。我建議在cleaner.py里對所有時間字段做標準化轉(zhuǎn)換后續(xù)不管換哪家API都不用再改這塊。4.3 關(guān)鍵詞命中不準的內(nèi)容過濾策略大部分通用新聞API的文本匹配是比較寬松的你搜AI創(chuàng)業(yè)它可能把AI在醫(yī)療行業(yè)的創(chuàng)業(yè)故事創(chuàng)業(yè)公司用AI做電商這類近似主題都帶進來。這看起來是好事但實際簡報里會夾雜大量不相關(guān)內(nèi)容反而會影響閱讀效率。我的做法分三層。第一層在API請求層面通過加引號和AND邏輯符收縮匹配只保留同時包含核心詞的文本。第二層在清洗層面對標題做包含性檢測標題完全不出現(xiàn)業(yè)務(wù)核心詞的直接丟棄。第三層在排序階段把純資訊類的泛AI新聞排到最后把標題同時命中融資、發(fā)布、合作、增長等事件詞的排前面。這套策略做下來簡報的有效信息占比從最開始的六成左右提升到了八成五以上。4.4 鏈接跳轉(zhuǎn)失敗與摘要截斷的處理新聞API返回的鏈接大多是經(jīng)過跳轉(zhuǎn)的短鏈或追蹤鏈直接放進簡報里閱讀體驗尚可但偶爾會出現(xiàn)鏈接時效性問題——上午生成的簡報下午點擊就提示內(nèi)容不存在。我測試后發(fā)現(xiàn)這類問題多出在源站做了內(nèi)容下線或反爬攔截。建議做一層鏈接健康度抽查隨機抽三條URL做HEAD請求檢查返回狀態(tài)碼狀態(tài)碼異常的直接從簡報里替換掉。當然不用每條都查那樣太耗配額。摘要截斷的問題則簡單得多凡是超過80個字符的description字段統(tǒng)一截斷到圓滿的句子結(jié)束位置保證簡報排版不會因為長短不一變得凌亂。前面提到的內(nèi)容整理成速查表方便你排查時對照癥狀可能原因處理方式大量429返回請求頻率過高增加請求間隔限制翻頁次數(shù)文章時間全都早于預(yù)期UTC時間未轉(zhuǎn)本地統(tǒng)一做時區(qū)轉(zhuǎn)換簡報混入大量無關(guān)內(nèi)容關(guān)鍵詞匹配過寬加AND邏輯符、過濾層某幾條鏈接打不開源站下線或反爬抽查鏈接狀態(tài)異常即刪除中文標題亂碼文件寫入編碼錯誤指定utf-8編碼寫入同一篇文章反復(fù)出現(xiàn)各平臺互相轉(zhuǎn)載對title歸一化后MD5去重5. 從日報延伸到更多關(guān)鍵詞與場景5.1 多關(guān)鍵詞并行與自定義輸出模板這個項目跑通AI創(chuàng)業(yè)之后我很快加了AI 融資和大模型 創(chuàng)業(yè)兩個關(guān)鍵詞因為它們之間存在交叉但沒有完全被AI創(chuàng)業(yè)覆蓋。配置層面把關(guān)鍵詞列表外置到配置文件里新增一個關(guān)鍵詞不需要改代碼。輸出模板目前是Markdown如果你的使用場景是發(fā)到IM群里可以考慮把輸出格式切換成HTML或純文本只需要改reporter.py里的字符串拼接邏輯。5.2 結(jié)合摘要和趨勢數(shù)據(jù)的進一步拉寬日報做順手之后可以做的事就多起來了。比如把每篇文章的標題和摘要拼接后調(diào)用文本摘要接口做一個一兩句話的核心提煉放在簡報標題下面這樣打開簡報第一屏就能掌握今天大概發(fā)生了什么。再比如每天的數(shù)據(jù)都落地到SQLite積累兩三個月后能統(tǒng)計出AI創(chuàng)業(yè)相關(guān)資訊在周幾最密集、哪些媒體發(fā)布量最大甚至做一個簡單的熱度趨勢圖。這些都不是難點真正的底座是穩(wěn)定運行的抓取鏈路。5.3 推送渠道的替換與擴展如果你想把簡報從文件變成通知可以去接郵件或者群機器人。郵件的好處是可以沉淀、可以歸檔聊天機器人的好處是打開率極高適合日常快掃。我個人推薦郵件作為主力推送渠道因為它的格式兼容性最好排版不會亂。機器人作為補充發(fā)送摘要即可。6. 最后的幾個實操建議這個項目做完之后我有幾個體會。第一日報類工具的核心不是功能炫技而是穩(wěn)定。穩(wěn)定跑三個月的簡單腳本比功能花哨但每周掛兩次的工程更有價值。第二控制單次請求的量夠用就好不要試圖一次性把API的可用數(shù)據(jù)全拉回來少即是多。第三配置和代碼要分離關(guān)鍵詞、API地址、請求頻率都放進配置文件改動時不用碰代碼邏輯。還有一個小技巧我一直留著在被要求再次做個類似項目的時候使用給每個API請求打上自定義業(yè)務(wù)標識方便后續(xù)在日志和監(jiān)控里審計是哪類請求出了問題這在多個關(guān)鍵詞并行跑的場景下排查效率尤其高。這個項目我目前一直在用每天早上的第一件事就是打開郵箱看簡報三五分鐘就能知道AI創(chuàng)業(yè)領(lǐng)域昨天有哪些值得關(guān)注的消息。其實做一個好的自動化工具最大的成就感不在于技術(shù)多復(fù)雜而在于你把它設(shè)好后的一整年它都在替你干活。