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