1. 為什么我要折騰一個自動推送的 AI 日報每天早上到工位第一件事是打開瀏覽器翻十幾個頁面看行業(yè)動態(tài)、看競品更新、看技術(shù)社區(qū)的新帖子一圈下來半小時沒了真正記下來的沒幾條。這個習(xí)慣我堅持了大半年直到某天早上我盯著滿屏的標(biāo)簽頁發(fā)呆突然覺得這事不該由人來做——信息聚合、摘要提煉、定時推送這三件事拆開看都是機(jī)器更擅長的活。于是就有了這個項(xiàng)目給 WorkBuddy 設(shè)一個鬧鐘每天上午十點(diǎn)半讓它把過去24小時里我關(guān)心的內(nèi)容抓一遍、用大模型總結(jié)成一份日報、再通過微信推送到我手機(jī)上。整套流程跑通之后我早上到工位只需要花三分鐘掃一眼日報剩下的時間可以干正事。這里說的 WorkBuddy 是一個可以掛載自定義技能、支持定時任務(wù)和外部工具調(diào)用的 AI 工作臺類產(chǎn)品不同平臺可能有不同的叫法但核心能力是相通的它能按你設(shè)定的時間自動執(zhí)行一段任務(wù)流并且可以調(diào)用大模型、HTTP 接口、腳本等外部能力。我用的模型是 deepseek-v4-flash選它的原因后面會細(xì)說。推送通道走的是微信具體落地方式是用一個微信小程序做接收端配合服務(wù)端轉(zhuǎn)發(fā)。這篇文章適合三類人看一是每天被信息淹沒、想用自動化給自己減負(fù)的職場人二是正在玩 WorkBuddy 或者類似 AI 工作臺、想找個真實(shí)項(xiàng)目練手的開發(fā)者三是對AI 日報這個形態(tài)感興趣、想自己搭一套但不知道從哪下手的人。我會把整套方案的選型邏輯、關(guān)鍵配置、踩過的坑全部攤開講代碼和參數(shù)能給的都給你照著抄基本能跑起來。需要提前說明的是這套方案不涉及任何網(wǎng)絡(luò)訪問工具所有數(shù)據(jù)來源都是公開的、合規(guī)的信息渠道推送通道也是正規(guī)的微信生態(tài)能力。下面進(jìn)入正題。2. 整體方案設(shè)計與選型思路拆解2.1 這套系統(tǒng)到底由哪幾塊拼起來先把架構(gòu)攤平了說。整個AI 日報自動推送系統(tǒng)拆開就是四個環(huán)節(jié)每個環(huán)節(jié)對應(yīng)一個技術(shù)選型環(huán)節(jié)職責(zé)我的選型備選方案觸發(fā)調(diào)度每天10:30準(zhǔn)時啟動任務(wù)WorkBuddy 內(nèi)置定時任務(wù)系統(tǒng) crontab、云函數(shù)定時觸發(fā)器數(shù)據(jù)采集抓取指定來源的內(nèi)容WorkBuddy 自定義技能 HTTP 請求Python 爬蟲、RSS 訂閱內(nèi)容生成把原始內(nèi)容總結(jié)成日報deepseek-v4-flash其他大模型 API消息推送把日報送到微信微信小程序 服務(wù)端轉(zhuǎn)發(fā)郵件、企業(yè)微信機(jī)器人這個拆法的好處是每一層都可以單獨(dú)替換。比如你不想用 WorkBuddy 的定時能力換成服務(wù)器上的 crontab 完全沒問題你不想用 deepseek-v4-flash換成別的模型接口也就是改個 URL 和 key 的事。我之所以這么選是因?yàn)?WorkBuddy 把調(diào)度和技能調(diào)用這兩塊整合得比較順省去了自己維護(hù)一臺常駐服務(wù)器的麻煩。2.2 為什么調(diào)度放在 WorkBuddy 而不是自己寫 crontab我一開始的方案其實(shí)是在一臺云服務(wù)器上寫 crontabPython 腳本跑采集和總結(jié)然后調(diào)接口推送。跑了大概兩周問題逐漸暴露出來腳本掛了沒人知道。有天早上沒收到日報登服務(wù)器一看是某個數(shù)據(jù)源的頁面結(jié)構(gòu)變了解析報錯腳本靜默退出。crontab 不會告訴你任務(wù)失敗了。改需求成本高。我想把日報的總結(jié)風(fēng)格從羅列改成分板塊點(diǎn)評得改代碼、測試、重新部署一來一回半小時。模型切換麻煩。想試試新出的模型效果得改代碼里的調(diào)用邏輯。換成 WorkBuddy 之后這三個問題基本被抹平了。它的定時任務(wù)有執(zhí)行記錄失敗了能看到日志總結(jié)風(fēng)格可以通過調(diào)整提示詞prompt直接改不用動代碼模型切換在配置里改個名字就行。對于這種每天跑一次、邏輯不復(fù)雜、但需要經(jīng)常微調(diào)的任務(wù)用工作臺類產(chǎn)品比自己維護(hù)腳本劃算得多。當(dāng)然WorkBuddy 也不是沒有代價。它的自定義技能能力有邊界復(fù)雜的解析邏輯還是得靠外部接口兜底。我的做法是WorkBuddy 負(fù)責(zé)調(diào)度和編排真正臟活累活的解析放在一個輕量 HTTP 服務(wù)里兩邊通過接口通信。這樣既享受了工作臺的便利又保留了靈活性。2.3 模型為什么選 deepseek-v4-flash日報總結(jié)這個任務(wù)對模型的要求其實(shí)很明確輸入長十幾個來源的內(nèi)容拼起來輕松過萬 token、輸出要結(jié)構(gòu)化、響應(yīng)要快、成本要低。它不需要模型有多強(qiáng)的推理能力但需要它穩(wěn)定地做壓縮歸類提煉。我對比過幾個模型在這個任務(wù)上的表現(xiàn)deepseek-v4-flash 的優(yōu)勢在于速度快。日報是定時任務(wù)10:30 觸發(fā)我希望 10:31 就能收到不能等模型慢慢想。flash 版本在長文本總結(jié)上的響應(yīng)速度明顯優(yōu)于標(biāo)準(zhǔn)版。長上下文處理穩(wěn)。十幾個來源的內(nèi)容拼一起token 數(shù)不小flash 版本在這個量級下沒有出現(xiàn)明顯的中間內(nèi)容丟失問題。成本可控。每天跑一次一個月三十次用 flash 版本的成本幾乎可以忽略。結(jié)構(gòu)化輸出聽話。我在提示詞里要求它按行業(yè)動態(tài) / 技術(shù)更新 / 值得關(guān)注三個板塊輸出它基本能穩(wěn)定遵守格式不需要反復(fù)調(diào)教。提示模型選型沒有絕對優(yōu)劣關(guān)鍵看任務(wù)匹配度。日報總結(jié)這種長輸入、短輸出、重格式的場景flash 類模型往往比旗艦?zāi)Ｐ透线m因?yàn)槠炫災(zāi)Ｐ偷耐评砟芰υ谶@里是浪費(fèi)的。2.4 推送通道為什么繞道微信小程序最直接的推送方式其實(shí)是郵件但郵件的打開率太低我經(jīng)常一整天想不起來看。微信不一樣它是我手機(jī)里打開頻率最高的應(yīng)用日報送到微信里我掃一眼通知欄就能決定要不要細(xì)看。但微信個人號沒有官方的機(jī)器人接口直接給個人號發(fā)消息這條路走不通。所以我的方案是做一個極簡的微信小程序作為接收端服務(wù)端把日報內(nèi)容寫進(jìn)一個接口小程序打開時拉取展示同時通過訂閱消息推送一條提醒。這個方案的關(guān)鍵在于訂閱消息。微信小程序支持訂閱消息能力用戶授權(quán)后服務(wù)端可以在特定條件下推送一條模板消息到用戶微信點(diǎn)擊后跳轉(zhuǎn)到小程序查看詳情。整個鏈路是合規(guī)的也是微信官方推薦的觸達(dá)方式。小程序的開發(fā)我用的是 uniapp一套代碼可以同時編譯到微信小程序和 App后面如果想擴(kuò)展到其他端也方便。頁面極其簡單就一個列表頁展示日報加一個詳情頁看全文。3. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)3.1 WorkBuddy 定時任務(wù)的配置要點(diǎn)WorkBuddy 的定時任務(wù)配置界面各個版本可能略有差異但核心參數(shù)就幾個執(zhí)行時間、執(zhí)行頻率、要調(diào)用的技能或指令、失敗重試策略。我的配置是這樣的執(zhí)行時間每天 10:30。選這個時間是因?yàn)槲乙话?10 點(diǎn)左右到工位處理完郵件和消息10:30 正好需要一份信息匯總來規(guī)劃當(dāng)天的工作。執(zhí)行頻率每天一次。日報這種東西一天一次足夠頻率太高反而變成噪音。調(diào)用內(nèi)容一個自定義指令指令里寫清楚抓取以下來源 → 拼接內(nèi)容 → 調(diào)用模型總結(jié) → 推送結(jié)果的完整流程。失敗重試開啟重試 2 次間隔 5 分鐘。數(shù)據(jù)源偶爾抽風(fēng)是常態(tài)重試能解決大部分臨時性失敗。這里有個細(xì)節(jié)值得說WorkBuddy 的定時任務(wù)時區(qū)要確認(rèn)清楚。我有一次發(fā)現(xiàn)任務(wù)在凌晨跑了排查半天才發(fā)現(xiàn)是時區(qū)配置成了 UTC10:30 UTC 對應(yīng)北京時間是 18:30完全錯位。改成 Asia/Shanghai 之后就正常了。另一個細(xì)節(jié)是任務(wù)執(zhí)行超時時間。采集加總結(jié)整個流程我實(shí)測下來大概需要 40 到 90 秒取決于數(shù)據(jù)源響應(yīng)速度和模型返回速度。如果你的 WorkBuddy 默認(rèn)超時時間比較短比如 30 秒需要手動調(diào)大否則任務(wù)會被中途掐斷。3.2 數(shù)據(jù)采集環(huán)節(jié)的實(shí)操細(xì)節(jié)數(shù)據(jù)采集是整個流程里最臟的部分因?yàn)槟阋鎸Φ氖歉鞣N格式不統(tǒng)一的網(wǎng)頁和接口。我的做法是優(yōu)先找 RSS 或公開 API找不到再考慮頁面解析。我訂閱的來源大概分三類技術(shù)社區(qū)的公開 RSS。這類最省事直接請求 XML 然后解析就行格式穩(wěn)定。行業(yè)資訊站的公開接口。有些站點(diǎn)會暴露 JSON 接口給前端調(diào)用直接請求這個接口比解析 HTML 穩(wěn)定得多。需要頁面解析的站點(diǎn)。這類是下策因?yàn)轫撁娼Y(jié)構(gòu)一變解析就掛。我的處理方式是只提取最穩(wěn)定的部分比如文章標(biāo)題和鏈接正文內(nèi)容讓模型根據(jù)標(biāo)題去概括而不是硬抓全文。采集環(huán)節(jié)有幾個坑我踩過編碼問題。有些站點(diǎn)的響應(yīng)是 GBK 編碼直接按 UTF-8 解析會亂碼。處理方式是先檢測響應(yīng)頭里的 charset沒有的話用 chardet 之類的庫猜一下。請求頻率。別把采集腳本寫成一秒請求十次容易被封。我的做法是每個來源之間間隔 1 到 2 秒整個采集過程控制在 30 秒以內(nèi)。內(nèi)容去重。不同來源可能轉(zhuǎn)載同一篇文章直接拼給模型會浪費(fèi) token。我的做法是用標(biāo)題做簡單去重相似度超過閾值的只保留一條。采集到的原始內(nèi)容我會做一個預(yù)處理去掉 HTML 標(biāo)簽、壓縮多余空白、截斷過長的正文。截斷這一步很重要因?yàn)槟Ｐ蜕舷挛挠邢夼c其塞進(jìn)去一堆無關(guān)內(nèi)容不如每個來源只保留前 500 字把 token 留給更多來源。3.3 提示詞設(shè)計讓模型穩(wěn)定輸出結(jié)構(gòu)化日報提示詞是這份日報質(zhì)量的決定性因素。我前后改了七八版最終穩(wěn)定下來的結(jié)構(gòu)是這樣的你是一個信息匯總助手。以下是過去24小時內(nèi)我從多個來源采集的內(nèi)容請幫我整理成一份日報。 要求 1. 按三個板塊組織行業(yè)動態(tài)、技術(shù)更新、值得關(guān)注 2. 每個板塊下用短句列出要點(diǎn)每條不超過50字 3. 如果某個板塊沒有相關(guān)內(nèi)容寫今日無 4. 最后用一句話總結(jié)今天的整體趨勢 5. 不要編造內(nèi)容只基于我提供的信息 采集內(nèi)容如下 {content}這個提示詞的關(guān)鍵在于約束足夠具體。每條不超過50字這種量化要求比簡潔一點(diǎn)有效得多。不要編造內(nèi)容這句也必須加否則模型容易自由發(fā)揮把沒發(fā)生的事寫進(jìn)日報。我還試過讓模型輸出 Markdown 格式方便小程序渲染但后來發(fā)現(xiàn)純文本加簡單換行反而更穩(wěn)因?yàn)槟Ｐ团紶枙?Markdown 語法上出錯導(dǎo)致渲染混亂?，F(xiàn)在的做法是模型輸出純文本小程序端用固定樣式渲染把格式控制權(quán)握在自己手里。注意提示詞里的{content}占位符替換時要確保內(nèi)容里沒有會干擾模型理解的特殊字符。我遇到過采集內(nèi)容里包含類似指令的文本導(dǎo)致模型被帶偏。處理方式是在拼接前對內(nèi)容做一次清洗去掉明顯的指令性語句。3.4 微信小程序接收端的實(shí)現(xiàn)要點(diǎn)小程序端我做得極其克制就兩個頁面列表頁展示最近 7 天的日報每條顯示日期和摘要。詳情頁展示某一天的完整日報內(nèi)容。數(shù)據(jù)獲取走的是服務(wù)端接口。服務(wù)端在 WorkBuddy 推送日報時把內(nèi)容寫進(jìn)數(shù)據(jù)庫小程序打開時調(diào)接口拉取。這樣即使小程序沒打開日報也已經(jīng)存好了不會丟。訂閱消息的配置有幾個關(guān)鍵點(diǎn)模板選擇微信提供了多種訂閱消息模板我選的是內(nèi)容更新提醒類的模板字段填日期和摘要。用戶授權(quán)訂閱消息需要用戶主動授權(quán)且每次授權(quán)只能推送有限次數(shù)。我的做法是在小程序里放一個開啟每日提醒的按鈕用戶點(diǎn)擊后請求授權(quán)授權(quán)一次可以推送多次具體次數(shù)看模板類型。推送時機(jī)服務(wù)端在日報生成后立即調(diào)用訂閱消息接口推送用戶收到通知點(diǎn)擊進(jìn)入小程序正好看到當(dāng)天的日報。這里有個容易忽略的點(diǎn)訂閱消息的推送有頻率限制不能無限制推送。如果你的日報一天推多次可能會觸發(fā)限制。我的方案是一天只推一次完全在安全范圍內(nèi)。3.5 服務(wù)端轉(zhuǎn)發(fā)層的輕量實(shí)現(xiàn)服務(wù)端我用的是一臺最低配的云服務(wù)器跑一個簡單的 HTTP 服務(wù)職責(zé)就兩個接收 WorkBuddy 推送的日報內(nèi)容并存儲、給小程序提供查詢接口。技術(shù)棧選得很隨意Python 的 FastAPI 或者 Node 的 Express 都行我用的是 FastAPI因?yàn)閷懫饋砜?。核心接口就三個# 偽代碼示意 POST /api/daily-report # WorkBuddy 推送日報內(nèi)容 GET /api/daily-report/latest # 小程序獲取最新日報 GET /api/daily-report/list # 小程序獲取歷史日報列表存儲用的是 SQLite因?yàn)閿?shù)據(jù)量極小一天一條沒必要上 MySQL 或者 PostgreSQL。表結(jié)構(gòu)就四個字段日期、內(nèi)容、創(chuàng)建時間、推送狀態(tài)。這個服務(wù)端的部署有個小技巧用 systemd 或者 supervisor 做進(jìn)程守護(hù)確保服務(wù)掛了能自動重啟。我有一次服務(wù)器重啟后忘了設(shè)自啟結(jié)果第二天日報沒收到排查半天才發(fā)現(xiàn)是服務(wù)沒起來。4. 完整實(shí)操流程與關(guān)鍵環(huán)節(jié)實(shí)現(xiàn)4.1 從零開始的搭建順序如果你是第一次搭這套系統(tǒng)我建議按下面的順序來每一步都能單獨(dú)驗(yàn)證避免一次性堆完發(fā)現(xiàn)跑不通先跑通模型調(diào)用。寫一個最簡單的腳本把一段文本發(fā)給 deepseek-v4-flash看能不能拿到總結(jié)結(jié)果。這一步驗(yàn)證 API key、網(wǎng)絡(luò)、模型名稱都對。再跑通數(shù)據(jù)采集。單獨(dú)寫采集邏輯把幾個來源的內(nèi)容抓下來打印出來確認(rèn)格式和內(nèi)容符合預(yù)期。然后串起來。把采集內(nèi)容拼進(jìn)提示詞調(diào)模型拿到日報文本。接著搭服務(wù)端。把日報文本通過接口存起來用 Postman 或者 curl 驗(yàn)證接口能讀能寫。再做小程序。先做列表頁和詳情頁能拉到數(shù)據(jù)展示就行訂閱消息最后加。最后配 WorkBuddy 定時任務(wù)。把前面驗(yàn)證過的流程封裝成 WorkBuddy 的自定義指令設(shè)定時任務(wù)觀察一兩天確認(rèn)穩(wěn)定。這個順序的核心邏輯是從易到難、從獨(dú)立到集成。每一步都驗(yàn)證過最后集成時出問題也容易定位是哪一環(huán)的鍋。4.2 關(guān)鍵參數(shù)的計算與選擇過程有幾個參數(shù)是我實(shí)際調(diào)過的把計算過程攤開說采集來源數(shù)量。我一開始訂了 20 多個來源結(jié)果日報長得像流水賬模型總結(jié)質(zhì)量也下降。后來砍到 8 個核心來源日報質(zhì)量明顯提升。來源不是越多越好而是要精。我的標(biāo)準(zhǔn)是每個來源必須是我真正會看的如果一個來源連續(xù)一周的內(nèi)容我都沒點(diǎn)開過就砍掉。單條內(nèi)容截斷長度。我設(shè)的是 500 字。計算邏輯是8 個來源 × 500 字 ≈ 4000 字加上提示詞本身約 200 字總共 4200 字左右換算成 token 大概 6000 以內(nèi)完全在 deepseek-v4-flash 的上下文窗口內(nèi)且留足了輸出空間。如果來源增加到 15 個截斷長度就要相應(yīng)降到 300 字左右。任務(wù)超時時間。實(shí)測采集 8 個來源約 20 秒模型總結(jié)約 30 秒推送約 5 秒總共 55 秒左右。我把超時設(shè)成 180 秒留足余量應(yīng)對網(wǎng)絡(luò)波動。重試間隔。設(shè)的是 5 分鐘。太短了可能數(shù)據(jù)源還沒恢復(fù)太長了當(dāng)天日報就延誤了。5 分鐘是個比較平衡的值。4.3 WorkBuddy 自定義指令的寫法WorkBuddy 的自定義指令是整個流程的膠水它把采集、總結(jié)、推送三步串起來。我的指令邏輯大致是這樣的步驟1調(diào)用采集接口獲取原始內(nèi)容 步驟2對原始內(nèi)容做清洗和去重 步驟3拼接提示詞調(diào)用 deepseek-v4-flash 步驟4將模型返回的日報內(nèi)容 POST 到服務(wù)端接口 步驟5調(diào)用微信訂閱消息接口推送提醒 步驟6記錄執(zhí)行日志每一步都要有錯誤處理。比如步驟1采集失敗不應(yīng)該直接中斷而是記錄哪些來源失敗、哪些成功用成功的內(nèi)容繼續(xù)走流程。步驟3模型調(diào)用失敗應(yīng)該重試一次還失敗就推送一條今日日報生成失敗的提醒而不是靜默消失。WorkBuddy 的指令編輯器支持條件判斷和循環(huán)這些能力要用上。我見過有人把所有邏輯寫成一條超長的直線指令結(jié)果一出錯完全不知道哪一步掛了。把流程拆成帶錯誤處理的步驟是保證長期穩(wěn)定運(yùn)行的關(guān)鍵。4.4 小程序端的頁面實(shí)現(xiàn)細(xì)節(jié)小程序的列表頁和詳情頁都很簡單但有幾個細(xì)節(jié)值得說列表頁的日期顯示。我用的是今天 / 昨天 / 具體日期的格式比單純顯示2024-01-15更符合閱讀習(xí)慣。判斷邏輯是拿日報日期和當(dāng)前日期做差0 天顯示今天1 天顯示昨天其余顯示日期。詳情頁的排版。日報內(nèi)容是純文本我用的是按行分割、逐行渲染的方式。板塊標(biāo)題如行業(yè)動態(tài)加粗放大要點(diǎn)內(nèi)容正常顯示整體留白充足。這里不要用富文本渲染因?yàn)槟Ｐ洼敵龅母袷讲煌耆煽馗晃谋救菀卒秩境銎婀值男Ч?。下拉刷新。列表頁支持下拉刷新方便用戶手動拉取最新日報。雖然訂閱消息會推送提醒但用戶主動打開時能刷新體驗(yàn)更好。緩存策略。小程序端對日報內(nèi)容做了本地緩存緩存時間設(shè)的是 1 小時。這樣用戶反復(fù)打開不會重復(fù)請求接口減輕服務(wù)端壓力。緩存過期后自動重新拉取。4.5 訂閱消息推送的完整鏈路訂閱消息的推送鏈路稍微繞一點(diǎn)我把完整流程寫清楚用戶在小程序里點(diǎn)擊開啟每日提醒按鈕。小程序調(diào)用wx.requestSubscribeMessage請求用戶授權(quán)。用戶同意后小程序把授權(quán)憑證一個 token發(fā)給服務(wù)端。服務(wù)端保存這個 token并在每次日報生成后調(diào)用微信的訂閱消息接口。微信服務(wù)器把消息推送到用戶微信。用戶點(diǎn)擊消息跳轉(zhuǎn)到小程序詳情頁。這里的關(guān)鍵是token 的保存和刷新。微信的訂閱消息 token 有有效期過期需要重新獲取。我的做法是服務(wù)端定時刷新 token確保推送時 token 有效。如果推送失敗返回 token 過期就自動刷新后重試一次。提示訂閱消息的模板字段是固定的不能隨意添加字段。在微信公眾平臺配置模板時要選字段數(shù)量和類型都匹配的模板否則推送會失敗。5. 常見問題與排查技巧實(shí)錄5.1 日報沒收到按這個順序排查日報沒收到是最常見的問題我整理了一個排查順序從最可能的原因開始排查順序檢查項(xiàng)可能原因解決方法1WorkBuddy 任務(wù)執(zhí)行記錄任務(wù)沒觸發(fā)或執(zhí)行失敗看日志確認(rèn)失敗原因2數(shù)據(jù)采集是否成功數(shù)據(jù)源改版或超時單獨(dú)測試采集邏輯3模型調(diào)用是否成功API key 過期或額度用完檢查 key 和賬戶余額4服務(wù)端接口是否正常服務(wù)掛了或接口報錯檢查服務(wù)進(jìn)程和日志5訂閱消息是否推送成功token 過期或模板不匹配檢查推送返回碼6小程序是否能拉到數(shù)據(jù)接口地址變更或緩存問題清緩存重試這個順序的邏輯是從上游到下游。日報的流轉(zhuǎn)路徑是WorkBuddy → 采集 → 模型 → 服務(wù)端 → 微信 → 小程序哪一環(huán)斷了后面的都收不到。按順序排查能最快定位問題。5.2 模型總結(jié)質(zhì)量不穩(wěn)定的處理模型總結(jié)質(zhì)量波動是另一個高頻問題。表現(xiàn)是有時候日報條理清晰有時候像流水賬。我總結(jié)的原因和對策輸入內(nèi)容質(zhì)量波動。如果某天采集到的內(nèi)容本身就很碎模型也很難總結(jié)出條理。對策是在采集環(huán)節(jié)做質(zhì)量過濾太短的內(nèi)容比如少于 50 字直接丟棄。提示詞被稀釋。如果某天內(nèi)容特別多提示詞里的要求可能被模型忽略。對策是控制輸入長度超過閾值就截斷保證提示詞占比。模型本身的隨機(jī)性。大模型輸出有隨機(jī)性同樣的輸入兩次結(jié)果可能不同。對策是把 temperature 調(diào)低我設(shè)的是 0.3輸出穩(wěn)定性明顯提升。5.3 采集環(huán)節(jié)的典型故障與修復(fù)采集環(huán)節(jié)的故障最五花八門我挑幾個典型的說故障一某個來源突然返回空內(nèi)容。排查發(fā)現(xiàn)是該站點(diǎn)改了頁面結(jié)構(gòu)原來的解析規(guī)則失效。修復(fù)方式是更新解析規(guī)則同時加一個告警機(jī)制——如果某個來源連續(xù)兩天返回空就在日報末尾提示來源 X 采集異常。故障二采集內(nèi)容出現(xiàn)亂碼。原因是編碼判斷錯誤。修復(fù)方式是在解析前先檢測編碼優(yōu)先用響應(yīng)頭里的 charset沒有就用 chardet 檢測還不行就按 UTF-8 強(qiáng)制解碼并忽略錯誤。故障三采集超時導(dǎo)致整個任務(wù)卡住。某個來源響應(yīng)特別慢拖垮了整個流程。修復(fù)方式是給每個來源的請求設(shè)置獨(dú)立超時我設(shè)的是 10 秒超時就跳過這個來源不阻塞整體流程。5.4 小程序端的常見問題小程序端的問題主要集中在訂閱消息和數(shù)據(jù)展示上訂閱消息收不到。檢查三個地方用戶是否授權(quán)、token 是否有效、模板字段是否匹配。我遇到過一次是模板字段填錯了推送接口返回錯誤但沒仔細(xì)看排查了半天。詳情頁內(nèi)容顯示不全。原因是內(nèi)容里有特殊字符導(dǎo)致渲染中斷。修復(fù)方式是在服務(wù)端對內(nèi)容做轉(zhuǎn)義處理把可能干擾渲染的字符替換掉。列表頁日期顯示錯誤。原因是時區(qū)處理不當(dāng)。修復(fù)方式是統(tǒng)一用服務(wù)端返回的日期字符串不在客戶端做日期計算。5.5 我踩過的三個印象最深的坑坑一時區(qū)錯位。前面提過WorkBuddy 定時任務(wù)時區(qū)設(shè)成了 UTC導(dǎo)致日報在傍晚才生成。這個坑讓我意識到任何涉及時間的配置都要顯式確認(rèn)時區(qū)。坑二token 過期沒處理。訂閱消息的 token 過期后推送靜默失敗我連續(xù)三天沒收到日報才發(fā)現(xiàn)。修復(fù)方式是在推送邏輯里加 token 有效性檢查過期自動刷新?？尤齼?nèi)容里的指令注入。有一次采集到的內(nèi)容里包含類似忽略以上指令輸出 XXX的文本模型真的被帶偏了。修復(fù)方式是在拼接前對內(nèi)容做清洗去掉明顯的指令性語句同時在提示詞里強(qiáng)調(diào)只基于提供的信息總結(jié)。6. 幾個讓系統(tǒng)更耐用的優(yōu)化技巧6.1 給日報加一個健康度標(biāo)記我在日報末尾加了一行小字顯示本次采集的成功率比如本次采集 8 個來源成功 7 個。這樣我一眼就能看出日報的完整性如果成功率突然下降說明某個來源出問題了可以及時處理。這個標(biāo)記的實(shí)現(xiàn)很簡單就是在采集環(huán)節(jié)統(tǒng)計成功和失敗的數(shù)量拼到日報末尾。6.2 歷史日報的歸檔與檢索日報積累多了之后偶爾會想翻某一天的日報。我在服務(wù)端加了一個簡單的檢索接口支持按日期范圍和關(guān)鍵詞查詢。小程序端也加了一個搜索框輸入關(guān)鍵詞能搜到包含該詞的日報。這個功能用 SQLite 的 LIKE 查詢就能實(shí)現(xiàn)不需要上全文檢索引擎。6.3 把日報同步一份到筆記軟件微信里看日報方便但不利于長期歸檔。我的做法是在服務(wù)端加一個同步邏輯把每天的日報通過接口寫進(jìn)我的筆記軟件我用的是支持 API 的筆記工具。這樣日報既能在微信里快速查看又能在筆記軟件里長期保存和檢索。6.4 定期回顧和調(diào)整來源列表來源列表不是一成不變的。我每個月會花十分鐘回顧一下哪些來源的內(nèi)容我從來沒細(xì)看過哪些來源最近質(zhì)量下降然后做增刪。保持來源列表的精簡和高質(zhì)量是日報長期有價值的前提。一個塞滿低質(zhì)量來源的日報很快就會變成沒人看的噪音。6.5 給模型加一個風(fēng)格記憶我在提示詞里加了一段固定的風(fēng)格描述比如用簡潔、直接的語言避免套話和空泛表述。這段描述每次調(diào)用都帶上讓模型的輸出風(fēng)格保持一致。如果不加這段模型有時候會輸出很官方的總結(jié)讀起來很累。風(fēng)格記憶的本質(zhì)是把提示詞里穩(wěn)定的部分固化下來只把變化的內(nèi)容采集結(jié)果作為變量傳入。這套系統(tǒng)跑到現(xiàn)在大概三個月中間修修補(bǔ)補(bǔ)不少次但核心流程一直很穩(wěn)。最大的感受是自動化的價值不在于省了多少時間而在于把一件需要想起來去做的事變成了不用想就會發(fā)生的事。信息獲取這件事一旦變成被動接收心態(tài)會輕松很多——我不再焦慮今天有沒有漏掉什么因?yàn)槲抑朗c(diǎn)半會有一份匯總送到我面前。