?bào)自動(dòng)化推送)
1. 從一條消息推送說起為什么我要給 WorkBuddy 設(shè)個(gè)“鬧鐘”每天早上到工位第一件事是打開電腦、翻聊天記錄、看郵件、刷幾個(gè)技術(shù)社區(qū)把夜里發(fā)生的事過一遍。這個(gè)過程大概要花二十分鐘而且經(jīng)常漏掉關(guān)鍵信息——某個(gè)依賴庫發(fā)了新版本、某個(gè)接口悄悄改了字段、某個(gè)自動(dòng)化任務(wù)昨晚跑失敗了。信息不是沒有是散落在太多地方人肉聚合的效率太低。后來我換了個(gè)思路與其我追著信息跑不如讓信息在固定時(shí)間來找我。具體做法是用 WorkBuddy 作為任務(wù)調(diào)度和執(zhí)行的載體接上 DeepSeek 的模型能力做內(nèi)容生成最后通過微信小程序的訂閱消息通道把一份整理好的 AI 日?qǐng)?bào)在每天上午十點(diǎn)半準(zhǔn)時(shí)推到我微信里。整套流程跑通之后我早上到工位只需要花兩分鐘掃一眼日?qǐng)?bào)剩下的時(shí)間可以干正事。這個(gè)項(xiàng)目的核心關(guān)鍵詞是WorkBuddy、AI日?qǐng)?bào)、微信小程序、自動(dòng)化、DeepSeek。它解決的不是什么高深的技術(shù)難題而是一個(gè)很實(shí)際的效率問題把分散的信息聚合、摘要、定時(shí)送達(dá)。適合誰參考如果你手頭有重復(fù)性的信息整理工作或者想找一個(gè)輕量的自動(dòng)化項(xiàng)目練手把 WorkBuddy 的任務(wù)編排、DeepSeek 的 API 調(diào)用、微信小程序的訂閱消息這三塊串起來是一個(gè)性價(jià)比很高的切入點(diǎn)。下面我把整個(gè)搭建過程拆開講包括選型理由、參數(shù)配置、踩過的坑以及一些文檔里不會(huì)寫的實(shí)操細(xì)節(jié)。2. 整體方案設(shè)計(jì)與選型思路拆解2.1 為什么是 WorkBuddy 而不是純腳本一開始我確實(shí)想過寫個(gè) Python 腳本掛個(gè) cron 定時(shí)跑就完事了。但實(shí)際用下來純腳本有幾個(gè)繞不開的問題。第一是任務(wù)狀態(tài)不可見腳本跑沒跑、跑到哪一步、失敗了沒有全靠看日志文件時(shí)間一長(zhǎng)日志堆成山排查起來很煩。第二是多步驟編排麻煩抓取、清洗、調(diào)模型、推送每一步都要自己處理異常和重試代碼量不小。第三是跨設(shè)備同步困難我在公司電腦上配好的任務(wù)回家想改一下還得遠(yuǎn)程連回去。WorkBuddy 這類工作臺(tái)工具的價(jià)值就在于它把任務(wù)調(diào)度、步驟編排、執(zhí)行記錄這幾件事做成了可視化的。我可以把整個(gè)日?qǐng)?bào)流程拆成幾個(gè)節(jié)點(diǎn)每個(gè)節(jié)點(diǎn)單獨(dú)配置哪個(gè)節(jié)點(diǎn)失敗了在面板上一眼就能看到重跑也只需要點(diǎn)一下。這不是說腳本不好而是當(dāng)任務(wù)需要長(zhǎng)期穩(wěn)定運(yùn)行、且我希望能隨時(shí)調(diào)整的時(shí)候可視化編排的維護(hù)成本明顯更低。提示選工具的時(shí)候不要只看功能列表要看“出問題的時(shí)候我能不能快速定位”。長(zhǎng)期運(yùn)行的任務(wù)可觀測(cè)性比功能多寡更重要。2.2 DeepSeek 在流程里扮演什么角色日?qǐng)?bào)的內(nèi)容不是簡(jiǎn)單地把原始信息拼起來那樣讀起來跟沒整理一樣。我需要模型做三件事摘要壓縮、分類歸并、重點(diǎn)標(biāo)注。比如夜里抓到的二十條技術(shù)動(dòng)態(tài)模型要能判斷哪些是同一類事件、哪些值得單獨(dú)拎出來、哪些可以一句話帶過。選 DeepSeek 的理由很直接它的 API 調(diào)用成本低中文理解能力夠用而且支持較長(zhǎng)的上下文。日?qǐng)?bào)場(chǎng)景下我一次要喂進(jìn)去的原始素材可能有幾千字模型需要在一次調(diào)用里處理完上下文長(zhǎng)度和推理質(zhì)量都得跟得上。實(shí)測(cè)下來用 DeepSeek 做摘要和分類輸出質(zhì)量穩(wěn)定延遲也在可接受范圍內(nèi)。這里有個(gè)細(xì)節(jié)值得說不要把模型當(dāng)成萬能的黑盒。我在 prompt 里明確規(guī)定了輸出格式比如“每條動(dòng)態(tài)不超過兩句話”“按技術(shù)領(lǐng)域分三組”“每組用一句話總結(jié)”。格式約束越清晰模型輸出越穩(wěn)定后續(xù)解析也越省事。2.3 微信小程序作為推送通道的考量推送通道的選擇其實(shí)不少郵件、釘釘、飛書、企業(yè)微信都能做。我最終選微信小程序原因有三個(gè)。第一是觸達(dá)率高微信是我每天打開頻率最高的應(yīng)用訂閱消息直接出現(xiàn)在聊天列表里不會(huì)像郵件那樣被淹沒。第二是開發(fā)成本可控微信小程序的訂閱消息接口文檔清晰用 uniapp 開發(fā)的話一套代碼還能兼顧多端。第三是用戶體驗(yàn)好日?qǐng)?bào)以卡片形式呈現(xiàn)點(diǎn)開就能看不需要額外裝應(yīng)用。需要說明的是微信小程序的訂閱消息是一次性訂閱機(jī)制用戶授權(quán)一次只能推一條。對(duì)于每天推一條日?qǐng)?bào)的場(chǎng)景我采用的是“用戶每次查看日?qǐng)?bào)后引導(dǎo)其再次授權(quán)下一條”的方式形成一個(gè)授權(quán)循環(huán)。這個(gè)機(jī)制在微信小程序開發(fā)里是標(biāo)準(zhǔn)做法具體實(shí)現(xiàn)后面會(huì)講。2.4 整體數(shù)據(jù)流梳理把上面三塊串起來整個(gè)流程是這樣的觸發(fā)WorkBuddy 在每天上午十點(diǎn)觸發(fā)任務(wù)。采集任務(wù)第一步從預(yù)設(shè)的信息源抓取原始內(nèi)容存成結(jié)構(gòu)化數(shù)據(jù)。處理調(diào)用 DeepSeek API把原始內(nèi)容做摘要、分類、格式化。組裝把模型輸出組裝成微信小程序訂閱消息要求的 JSON 結(jié)構(gòu)。推送調(diào)用微信小程序的訂閱消息接口把日?qǐng)?bào)推送到用戶微信。記錄WorkBuddy 記錄本次執(zhí)行結(jié)果失敗則觸發(fā)告警。這個(gè)流程里采集和處理是耗時(shí)大頭推送是最后一步。所以我在 WorkBuddy 里把超時(shí)時(shí)間設(shè)得比較寬松避免因?yàn)槟Ｐ晚憫?yīng)慢導(dǎo)致任務(wù)被誤判為失敗。3. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)3.1 WorkBuddy 任務(wù)編排的關(guān)鍵配置在 WorkBuddy 里建任務(wù)核心是配好三樣?xùn)|西觸發(fā)時(shí)間、執(zhí)行步驟、失敗處理。觸發(fā)時(shí)間我設(shè)的是每天上午十點(diǎn)半。為什么不是更早因?yàn)樘绲脑捰行┬畔⒃催€沒更新完抓到的內(nèi)容不完整。十點(diǎn)半這個(gè)時(shí)間點(diǎn)大部分技術(shù)社區(qū)和更新源都已經(jīng)完成了當(dāng)天的首次更新同時(shí)離我上午的工作節(jié)奏也匹配看完日?qǐng)?bào)正好開始處理當(dāng)天任務(wù)。執(zhí)行步驟我拆成了四個(gè)節(jié)點(diǎn)每個(gè)節(jié)點(diǎn)獨(dú)立配置節(jié)點(diǎn)功能超時(shí)設(shè)置重試策略節(jié)點(diǎn)一信息采集120秒失敗重試2次節(jié)點(diǎn)二數(shù)據(jù)清洗60秒失敗重試1次節(jié)點(diǎn)三模型調(diào)用180秒失敗重試2次節(jié)點(diǎn)四消息推送30秒失敗重試3次超時(shí)和重試的設(shè)置邏輯是這樣的采集和模型調(diào)用是外部依賴網(wǎng)絡(luò)波動(dòng)或服務(wù)響應(yīng)慢的概率較高所以超時(shí)給得寬、重試次數(shù)多推送是最后一步失敗成本高所以重試次數(shù)最多確保消息能發(fā)出去。注意重試不是越多越好。如果某個(gè)節(jié)點(diǎn)連續(xù)失敗說明可能是配置錯(cuò)誤或服務(wù)不可用這時(shí)候應(yīng)該觸發(fā)告警而不是無限重試。我在 WorkBuddy 里設(shè)了“連續(xù)失敗3次則暫停任務(wù)并通知”的規(guī)則。3.2 DeepSeek API 調(diào)用的參數(shù)調(diào)優(yōu)調(diào)用 DeepSeek API 做日?qǐng)?bào)生成有幾個(gè)參數(shù)直接影響輸出質(zhì)量。temperature我設(shè)的是 0.3。這個(gè)值越低輸出越穩(wěn)定、越保守越高越有創(chuàng)造性。日?qǐng)?bào)場(chǎng)景不需要?jiǎng)?chuàng)造性需要的是準(zhǔn)確和一致所以調(diào)低。實(shí)測(cè) 0.3 的時(shí)候模型基本能按照我要求的格式輸出不會(huì)突然自由發(fā)揮。max_tokens根據(jù)日?qǐng)?bào)長(zhǎng)度來定。我一般控制在 1500 到 2000 之間。設(shè)太小會(huì)導(dǎo)致輸出被截?cái)嘣O(shè)太大又浪費(fèi)。我的做法是先跑幾次看實(shí)際輸出的 token 數(shù)然后留 20% 的余量。top_p保持默認(rèn)的 1.0 就行配合低 temperature 使用不需要額外調(diào)整。prompt 的結(jié)構(gòu)我固定成三段角色設(shè)定 任務(wù)說明 輸出格式。舉個(gè)例子你是一個(gè)技術(shù)日?qǐng)?bào)編輯。請(qǐng)把下面的原始信息整理成一份日?qǐng)?bào)。 要求 1. 按“開發(fā)工具”“AI動(dòng)態(tài)”“社區(qū)熱點(diǎn)”三個(gè)類別分組 2. 每條不超過兩句話 3. 每組末尾用一句話總結(jié) 4. 輸出用 JSON 格式字段為 category、items、summary 原始信息 {raw_content}這個(gè) prompt 模板我用了很久輸出格式基本沒跑偏過。關(guān)鍵點(diǎn)是把格式要求寫死在 prompt 里而不是靠后處理去猜。3.3 微信小程序訂閱消息的接入細(xì)節(jié)微信小程序的訂閱消息接入分三步申請(qǐng)模板、獲取 access_token、發(fā)送消息。申請(qǐng)模板在微信公眾平臺(tái)的“訂閱消息”里操作。我申請(qǐng)的是一個(gè)“日?qǐng)?bào)通知”類模板字段包括標(biāo)題、摘要、時(shí)間。模板申請(qǐng)通過后會(huì)拿到一個(gè) template_id后面發(fā)送消息要用。獲取 access_token 是調(diào)用微信接口的前置步驟。access_token 有效期是 7200 秒需要緩存起來不能每次發(fā)送都重新獲取。我的做法是在 WorkBuddy 里用一個(gè)節(jié)點(diǎn)專門管理 token緩存到本地文件過期前自動(dòng)刷新。發(fā)送消息的接口是subscribeMessage.send請(qǐng)求體里需要填 touser用戶 openid、template_id、page點(diǎn)擊跳轉(zhuǎn)的小程序頁面、data模板內(nèi)容。data 的字段名要和模板里定義的字段一一對(duì)應(yīng)否則會(huì)報(bào)錯(cuò)。提示微信小程序的訂閱消息有嚴(yán)格的字段長(zhǎng)度限制比如 thing 類型字段不超過 20 個(gè)字符。日?qǐng)?bào)摘要如果太長(zhǎng)需要先截?cái)嘣偬畛浞駝t接口會(huì)直接拒絕。3.4 數(shù)據(jù)采集環(huán)節(jié)的注意事項(xiàng)采集環(huán)節(jié)看起來簡(jiǎn)單實(shí)際上最容易出問題。我踩過的坑包括編碼不一致導(dǎo)致亂碼、請(qǐng)求頻率過高被限流、頁面結(jié)構(gòu)變化導(dǎo)致解析失敗。編碼問題好解決統(tǒng)一用 UTF-8 處理遇到非 UTF-8 的源先轉(zhuǎn)碼再解析。限流問題需要在采集節(jié)點(diǎn)里加延時(shí)我設(shè)的是每個(gè)源之間間隔 2 秒一天抓十幾個(gè)源總耗時(shí)控制在 30 秒以內(nèi)。頁面結(jié)構(gòu)變化是最麻煩的因?yàn)樵凑靖陌娌粫?huì)通知你。我的應(yīng)對(duì)策略是加一層校驗(yàn)如果某個(gè)源抓到的內(nèi)容為空或格式異常就在日?qǐng)?bào)里標(biāo)注“該源今日無有效內(nèi)容”而不是讓整個(gè)任務(wù)失敗。這個(gè)設(shè)計(jì)思路很重要單個(gè)源失敗不應(yīng)該拖垮整個(gè)日?qǐng)?bào)。日?qǐng)?bào)的價(jià)值在于整體信息覆蓋缺一兩個(gè)源可以接受但整個(gè)任務(wù)掛掉就什么都收不到了。4. 實(shí)操過程與核心環(huán)節(jié)實(shí)現(xiàn)4.1 環(huán)境準(zhǔn)備與依賴安裝先說環(huán)境。WorkBuddy 我裝在公司電腦上系統(tǒng)是 Windows。DeepSeek 的 API 調(diào)用用 Python 寫版本是 3.10。微信小程序的開發(fā)用 uniapp配合 HBuilderX。Python 這邊需要裝的庫不多pip install requests pip install schedulerequests 用來調(diào) DeepSeek API 和微信接口schedule 用來做本地測(cè)試時(shí)的定時(shí)模擬。實(shí)際跑在 WorkBuddy 里的時(shí)候定時(shí)由 WorkBuddy 負(fù)責(zé)schedule 只在本地調(diào)試用。微信小程序這邊需要在微信公眾平臺(tái)注冊(cè)一個(gè)小程序賬號(hào)拿到 AppID 和 AppSecret。然后在小程序后臺(tái)配置服務(wù)器域名把 WorkBuddy 所在服務(wù)器的 IP 或域名加進(jìn)去否則接口調(diào)用會(huì)被攔截。注意微信小程序的服務(wù)器域名配置有數(shù)量限制而且必須是 HTTPS。如果 WorkBuddy 跑在本地需要做內(nèi)網(wǎng)穿透或者部署到有公網(wǎng) IP 的服務(wù)器上。這一步是很多新手卡住的地方。4.2 DeepSeek API 調(diào)用的完整代碼實(shí)現(xiàn)先看調(diào)用 DeepSeek 的核心代碼。我把它封裝成了一個(gè)函數(shù)輸入原始文本輸出結(jié)構(gòu)化日?qǐng)?bào)。import requests import json def generate_daily_report(raw_content, api_key): url https://api.deepseek.com/v1/chat/completions headers { Authorization: fBearer {api_key}, Content-Type: application/json } prompt f你是一個(gè)技術(shù)日?qǐng)?bào)編輯。請(qǐng)把下面的原始信息整理成一份日?qǐng)?bào)。 要求 1. 按“開發(fā)工具”“AI動(dòng)態(tài)”“社區(qū)熱點(diǎn)”三個(gè)類別分組 2. 每條不超過兩句話 3. 每組末尾用一句話總結(jié) 4. 輸出用 JSON 格式字段為 category、items、summary 原始信息 {raw_content} payload { model: deepseek-chat, messages: [ {role: user, content: prompt} ], temperature: 0.3, max_tokens: 2000 } response requests.post(url, headersheaders, jsonpayload, timeout180) result response.json() content result[choices][0][message][content] # 清理可能的 markdown 代碼塊標(biāo)記 content content.replace(json, ).replace(, ).strip() return json.loads(content)這段代碼有幾個(gè)細(xì)節(jié)值得說。第一timeout 設(shè)了 180 秒因?yàn)槟Ｐ吞幚黹L(zhǎng)文本可能需要時(shí)間設(shè)太短會(huì)頻繁超時(shí)。第二輸出做了 markdown 清理模型有時(shí)候會(huì)把 JSON 包在代碼塊里返回直接 json.loads 會(huì)報(bào)錯(cuò)。第三temperature 和 max_tokens 寫死在代碼里方便統(tǒng)一管理。4.3 微信訂閱消息推送的實(shí)現(xiàn)推送這塊先獲取 access_token再發(fā)送消息。import requests import json import time import os def get_access_token(appid, secret): cache_file access_token_cache.json # 檢查緩存 if os.path.exists(cache_file): with open(cache_file, r) as f: cache json.load(f) if cache[expires_at] time.time(): return cache[access_token] # 重新獲取 url fhttps://api.weixin.qq.com/cgi-bin/token?grant_typeclient_credentialappid{appid}secret{secret} response requests.get(url, timeout30) result response.json() access_token result[access_token] expires_at time.time() result[expires_in] - 300 # 提前5分鐘過期 with open(cache_file, w) as f: json.dump({access_token: access_token, expires_at: expires_at}, f) return access_token def send_subscribe_message(access_token, openid, template_id, report_data): url fhttps://api.weixin.qq.com/cgi-bin/message/subscribe/send?access_token{access_token} payload { touser: openid, template_id: template_id, page: pages/index/index, data: { thing1: {value: report_data[title][:20]}, thing2: {value: report_data[summary][:20]}, time3: {value: report_data[date]} } } response requests.post(url, jsonpayload, timeout30) return response.json()這里的關(guān)鍵點(diǎn)是access_token 的緩存機(jī)制。微信的 access_token 每天有獲取次數(shù)限制如果每次發(fā)送都重新獲取很快就會(huì)用完配額。我用文件緩存的方式把 token 和過期時(shí)間存下來過期前 5 分鐘自動(dòng)刷新。另一個(gè)細(xì)節(jié)是字段截?cái)?。微信訂閱消息?thing 類型字段限制 20 個(gè)字符所以我在填充 data 的時(shí)候做了[:20]的截?cái)?。如果不截?cái)嘟涌跁?huì)返回錯(cuò)誤碼 47003。4.4 WorkBuddy 里的任務(wù)串聯(lián)把上面兩塊代碼串起來在 WorkBuddy 里配置成一個(gè)完整任務(wù)。我的做法是寫一個(gè)主入口腳本W(wǎng)orkBuddy 調(diào)用這個(gè)腳本腳本內(nèi)部按順序執(zhí)行采集、處理、推送。def main(): # 1. 采集 raw_content collect_sources() # 2. 生成日?qǐng)?bào) report generate_daily_report(raw_content, DEEPSEEK_API_KEY) # 3. 推送 access_token get_access_token(WECHAT_APPID, WECHAT_SECRET) result send_subscribe_message(access_token, USER_OPENID, TEMPLATE_ID, report) # 4. 記錄結(jié)果 log_result(result) return result if __name__ __main__: main()WorkBuddy 這邊我配置的是“執(zhí)行外部腳本”類型的任務(wù)指定 Python 解釋器路徑和腳本路徑觸發(fā)時(shí)間設(shè)為每天上午十點(diǎn)半。執(zhí)行記錄里能看到每次運(yùn)行的輸出和耗時(shí)方便排查。4.5 本地調(diào)試與線上運(yùn)行的差異處理本地調(diào)試的時(shí)候我直接用 schedule 庫模擬定時(shí)每五分鐘跑一次快速驗(yàn)證流程。但線上運(yùn)行有幾個(gè)差異需要注意。第一是網(wǎng)絡(luò)環(huán)境。本地調(diào)試時(shí)網(wǎng)絡(luò)穩(wěn)定線上服務(wù)器可能遇到網(wǎng)絡(luò)抖動(dòng)所以超時(shí)和重試策略要按線上環(huán)境來配。第二是文件路徑。本地用相對(duì)路徑?jīng)]問題線上要用絕對(duì)路徑否則 WorkBuddy 調(diào)用腳本時(shí)可能找不到文件。第三是日志輸出。本地調(diào)試看控制臺(tái)就行線上要把日志寫到文件里方便事后排查。我的做法是在腳本里加一個(gè)環(huán)境變量判斷本地調(diào)試和線上運(yùn)行走不同的配置分支。這樣一套代碼兩邊都能用不用維護(hù)兩份。5. 常見問題與排查技巧實(shí)錄5.1 模型輸出格式不對(duì)怎么辦這是最常見的問題。模型有時(shí)候會(huì)自由發(fā)揮不按 JSON 格式輸出或者在 JSON 外面加一堆解釋文字。我的排查思路是分三步走。第一步檢查 prompt 是否足夠明確。如果 prompt 里只寫了“輸出 JSON”模型可能理解成“在回答里包含 JSON”。要寫成“只輸出 JSON不要有任何其他文字”。第二步加后處理兜底。即使 prompt 寫得很清楚模型偶爾還是會(huì)跑偏。我在代碼里加了一層正則提取從輸出里找第一個(gè){到最后一個(gè)}之間的內(nèi)容再嘗試解析。這樣即使模型多說了幾句話也能把 JSON 摳出來。第三步設(shè)置失敗降級(jí)。如果 JSON 解析實(shí)在失敗就把模型的原始輸出直接作為純文本日?qǐng)?bào)推送至少保證信息能送達(dá)而不是整個(gè)任務(wù)失敗。5.2 微信推送報(bào)錯(cuò) 47003 怎么解決47003 是訂閱消息的字段校驗(yàn)錯(cuò)誤通常是因?yàn)樽侄蝺?nèi)容不符合模板要求。排查的時(shí)候重點(diǎn)看三個(gè)地方。一是字段類型是否匹配。模板里定義的是 thing 類型你傳了數(shù)字或者超長(zhǎng)文本就會(huì)報(bào)錯(cuò)。二是字段長(zhǎng)度是否超限。thing 類型限制 20 個(gè)字符超出就截?cái)?。三是字段名是否?duì)應(yīng)。模板里的字段名是 thing1、thing2你傳的時(shí)候?qū)懗闪?thing_1也會(huì)報(bào)錯(cuò)。我的經(jīng)驗(yàn)是在代碼里加一層校驗(yàn)發(fā)送前先檢查每個(gè)字段的長(zhǎng)度和類型不符合就先處理再發(fā)送。這樣比等接口報(bào)錯(cuò)再回頭改要高效得多。5.3 任務(wù)執(zhí)行超時(shí)怎么排查WorkBuddy 里任務(wù)超時(shí)原因通常有三個(gè)采集源響應(yīng)慢、模型調(diào)用耗時(shí)長(zhǎng)、網(wǎng)絡(luò)抖動(dòng)。排查方法是看執(zhí)行記錄里每個(gè)節(jié)點(diǎn)的耗時(shí)。如果采集節(jié)點(diǎn)耗時(shí)超過 100 秒說明某個(gè)源響應(yīng)慢需要單獨(dú)檢查。如果模型調(diào)用節(jié)點(diǎn)耗時(shí)超過 150 秒可能是輸入文本太長(zhǎng)需要做截?cái)嗷蚍峙幚怼Ｈ绻蔷W(wǎng)絡(luò)抖動(dòng)重試通常能解決。我設(shè)了一個(gè)規(guī)則如果某個(gè)節(jié)點(diǎn)連續(xù)三次超時(shí)就把它暫時(shí)禁用避免拖累整個(gè)任務(wù)。等排查清楚再重新啟用。5.4 常見問題速查表問題現(xiàn)象可能原因排查方法解決方案模型輸出非 JSONprompt 不明確檢查 prompt 格式要求加“只輸出 JSON”約束 正則兜底推送報(bào)錯(cuò) 47003字段超長(zhǎng)或類型錯(cuò)檢查 data 字段截?cái)? 類型轉(zhuǎn)換access_token 失效緩存過期未刷新檢查緩存文件提前 5 分鐘刷新采集內(nèi)容為空源站改版或限流單獨(dú)測(cè)試該源加校驗(yàn) 標(biāo)注無內(nèi)容任務(wù)超時(shí)某節(jié)點(diǎn)耗時(shí)過長(zhǎng)看執(zhí)行記錄耗時(shí)禁用問題節(jié)點(diǎn) 重試5.5 幾個(gè)文檔里不會(huì)寫的實(shí)操心得第一個(gè)心得日?qǐng)?bào)的“摘要”比“全文”更重要。我一開始把抓到的所有內(nèi)容都塞進(jìn)日?qǐng)?bào)結(jié)果讀起來跟沒整理一樣。后來改成每條只保留兩句話摘要閱讀效率明顯提升。模型做摘要的時(shí)候要明確告訴它“提煉核心信息去掉細(xì)節(jié)”。第二個(gè)心得推送時(shí)間要留緩沖。我設(shè)的是十點(diǎn)半推送但實(shí)際執(zhí)行時(shí)采集和模型處理可能花掉幾分鐘。所以我在 WorkBuddy 里把觸發(fā)時(shí)間設(shè)成十點(diǎn)二十五留五分鐘緩沖確保十點(diǎn)半之前能送達(dá)。第三個(gè)心得失敗告警要分級(jí)。不是所有失敗都需要立刻處理。采集失敗可以容忍推送失敗必須立刻知道。我在 WorkBuddy 里配了不同的告警級(jí)別推送失敗直接發(fā)通知采集失敗只記錄日志。第四個(gè)心得定期回顧日?qǐng)?bào)質(zhì)量。我每周會(huì)翻一下過去七天的日?qǐng)?bào)看看有沒有重復(fù)信息、有沒有漏掉重要?jiǎng)討B(tài)。根據(jù)回顧結(jié)果調(diào)整采集源和 prompt讓日?qǐng)?bào)越來越貼合自己的需求。6. 后續(xù)可以怎么擴(kuò)展這套流程跑通之后擴(kuò)展空間其實(shí)挺大的。我目前想到幾個(gè)方向也陸續(xù)在試。一個(gè)是多用戶支持?，F(xiàn)在日?qǐng)?bào)只推給我自己如果團(tuán)隊(duì)里其他人也想看可以把 openid 存成一個(gè)列表推送的時(shí)候循環(huán)發(fā)送。微信訂閱消息支持批量發(fā)送但每個(gè)用戶需要單獨(dú)授權(quán)。另一個(gè)是日?qǐng)?bào)內(nèi)容個(gè)性化。不同人關(guān)注的技術(shù)領(lǐng)域不一樣可以在 prompt 里加一個(gè)“關(guān)注領(lǐng)域”參數(shù)讓模型根據(jù)用戶偏好調(diào)整內(nèi)容權(quán)重。這個(gè)改動(dòng)不大但效果挺明顯。還有一個(gè)是歷史日?qǐng)?bào)歸檔。把每天的日?qǐng)?bào)存到數(shù)據(jù)庫里需要的時(shí)候可以回溯查詢。這個(gè)對(duì)于跟蹤某個(gè)技術(shù)趨勢(shì)的變化很有用。最后再分享一個(gè)小技巧WorkBuddy 的任務(wù)執(zhí)行記錄可以導(dǎo)出我每周會(huì)把記錄導(dǎo)出來用腳本統(tǒng)計(jì)一下各節(jié)點(diǎn)的平均耗時(shí)和失敗率。這樣能提前發(fā)現(xiàn)潛在問題而不是等任務(wù)掛了才去排查。這個(gè)習(xí)慣堅(jiān)持了幾個(gè)月任務(wù)的穩(wěn)定性確實(shí)提升了不少。 WorkBuddy+DeepSeek+微信小程序：打造每日AI日?qǐng)?bào)自動(dòng)化推送
1. 從一條消息推送說起為什么我要給 WorkBuddy 設(shè)個(gè)“鬧鐘”每天早上到工位第一件事是打開電腦、翻聊天記錄、看郵件、刷幾個(gè)技術(shù)社區(qū)把夜里發(fā)生的事過一遍。這個(gè)過程大概要花二十分鐘而且經(jīng)常漏掉關(guān)鍵信息——某個(gè)依賴庫發(fā)了新版本、某個(gè)接口悄悄改了字段、某個(gè)自動(dòng)化任務(wù)昨晚跑失敗了。信息不是沒有是散落在太多地方人肉聚合的效率太低。后來我換了個(gè)思路與其我追著信息跑不如讓信息在固定時(shí)間來找我。具體做法是用 WorkBuddy 作為任務(wù)調(diào)度和執(zhí)行的載體接上 DeepSeek 的模型能力做內(nèi)容生成最后通過微信小程序的訂閱消息通道把一份整理好的 AI 日?qǐng)?bào)在每天上午十點(diǎn)半準(zhǔn)時(shí)推到我微信里。整套流程跑通之后我早上到工位只需要花兩分鐘掃一眼日?qǐng)?bào)剩下的時(shí)間可以干正事。這個(gè)項(xiàng)目的核心關(guān)鍵詞是WorkBuddy、AI日?qǐng)?bào)、微信小程序、自動(dòng)化、DeepSeek。它解決的不是什么高深的技術(shù)難題而是一個(gè)很實(shí)際的效率問題把分散的信息聚合、摘要、定時(shí)送達(dá)。適合誰參考如果你手頭有重復(fù)性的信息整理工作或者想找一個(gè)輕量的自動(dòng)化項(xiàng)目練手把 WorkBuddy 的任務(wù)編排、DeepSeek 的 API 調(diào)用、微信小程序的訂閱消息這三塊串起來是一個(gè)性價(jià)比很高的切入點(diǎn)。下面我把整個(gè)搭建過程拆開講包括選型理由、參數(shù)配置、踩過的坑以及一些文檔里不會(huì)寫的實(shí)操細(xì)節(jié)。2. 整體方案設(shè)計(jì)與選型思路拆解2.1 為什么是 WorkBuddy 而不是純腳本一開始我確實(shí)想過寫個(gè) Python 腳本掛個(gè) cron 定時(shí)跑就完事了。但實(shí)際用下來純腳本有幾個(gè)繞不開的問題。第一是任務(wù)狀態(tài)不可見腳本跑沒跑、跑到哪一步、失敗了沒有全靠看日志文件時(shí)間一長(zhǎng)日志堆成山排查起來很煩。第二是多步驟編排麻煩抓取、清洗、調(diào)模型、推送每一步都要自己處理異常和重試代碼量不小。第三是跨設(shè)備同步困難我在公司電腦上配好的任務(wù)回家想改一下還得遠(yuǎn)程連回去。WorkBuddy 這類工作臺(tái)工具的價(jià)值就在于它把任務(wù)調(diào)度、步驟編排、執(zhí)行記錄這幾件事做成了可視化的。我可以把整個(gè)日?qǐng)?bào)流程拆成幾個(gè)節(jié)點(diǎn)每個(gè)節(jié)點(diǎn)單獨(dú)配置哪個(gè)節(jié)點(diǎn)失敗了在面板上一眼就能看到重跑也只需要點(diǎn)一下。這不是說腳本不好而是當(dāng)任務(wù)需要長(zhǎng)期穩(wěn)定運(yùn)行、且我希望能隨時(shí)調(diào)整的時(shí)候可視化編排的維護(hù)成本明顯更低。提示選工具的時(shí)候不要只看功能列表要看“出問題的時(shí)候我能不能快速定位”。長(zhǎng)期運(yùn)行的任務(wù)可觀測(cè)性比功能多寡更重要。2.2 DeepSeek 在流程里扮演什么角色日?qǐng)?bào)的內(nèi)容不是簡(jiǎn)單地把原始信息拼起來那樣讀起來跟沒整理一樣。我需要模型做三件事摘要壓縮、分類歸并、重點(diǎn)標(biāo)注。比如夜里抓到的二十條技術(shù)動(dòng)態(tài)模型要能判斷哪些是同一類事件、哪些值得單獨(dú)拎出來、哪些可以一句話帶過。選 DeepSeek 的理由很直接它的 API 調(diào)用成本低中文理解能力夠用而且支持較長(zhǎng)的上下文。日?qǐng)?bào)場(chǎng)景下我一次要喂進(jìn)去的原始素材可能有幾千字模型需要在一次調(diào)用里處理完上下文長(zhǎng)度和推理質(zhì)量都得跟得上。實(shí)測(cè)下來用 DeepSeek 做摘要和分類輸出質(zhì)量穩(wěn)定延遲也在可接受范圍內(nèi)。這里有個(gè)細(xì)節(jié)值得說不要把模型當(dāng)成萬能的黑盒。我在 prompt 里明確規(guī)定了輸出格式比如“每條動(dòng)態(tài)不超過兩句話”“按技術(shù)領(lǐng)域分三組”“每組用一句話總結(jié)”。格式約束越清晰模型輸出越穩(wěn)定后續(xù)解析也越省事。2.3 微信小程序作為推送通道的考量推送通道的選擇其實(shí)不少郵件、釘釘、飛書、企業(yè)微信都能做。我最終選微信小程序原因有三個(gè)。第一是觸達(dá)率高微信是我每天打開頻率最高的應(yīng)用訂閱消息直接出現(xiàn)在聊天列表里不會(huì)像郵件那樣被淹沒。第二是開發(fā)成本可控微信小程序的訂閱消息接口文檔清晰用 uniapp 開發(fā)的話一套代碼還能兼顧多端。第三是用戶體驗(yàn)好日?qǐng)?bào)以卡片形式呈現(xiàn)點(diǎn)開就能看不需要額外裝應(yīng)用。需要說明的是微信小程序的訂閱消息是一次性訂閱機(jī)制用戶授權(quán)一次只能推一條。對(duì)于每天推一條日?qǐng)?bào)的場(chǎng)景我采用的是“用戶每次查看日?qǐng)?bào)后引導(dǎo)其再次授權(quán)下一條”的方式形成一個(gè)授權(quán)循環(huán)。這個(gè)機(jī)制在微信小程序開發(fā)里是標(biāo)準(zhǔn)做法具體實(shí)現(xiàn)后面會(huì)講。2.4 整體數(shù)據(jù)流梳理把上面三塊串起來整個(gè)流程是這樣的觸發(fā)WorkBuddy 在每天上午十點(diǎn)觸發(fā)任務(wù)。采集任務(wù)第一步從預(yù)設(shè)的信息源抓取原始內(nèi)容存成結(jié)構(gòu)化數(shù)據(jù)。處理調(diào)用 DeepSeek API把原始內(nèi)容做摘要、分類、格式化。組裝把模型輸出組裝成微信小程序訂閱消息要求的 JSON 結(jié)構(gòu)。推送調(diào)用微信小程序的訂閱消息接口把日?qǐng)?bào)推送到用戶微信。記錄WorkBuddy 記錄本次執(zhí)行結(jié)果失敗則觸發(fā)告警。這個(gè)流程里采集和處理是耗時(shí)大頭推送是最后一步。所以我在 WorkBuddy 里把超時(shí)時(shí)間設(shè)得比較寬松避免因?yàn)槟Ｐ晚憫?yīng)慢導(dǎo)致任務(wù)被誤判為失敗。3. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)3.1 WorkBuddy 任務(wù)編排的關(guān)鍵配置在 WorkBuddy 里建任務(wù)核心是配好三樣?xùn)|西觸發(fā)時(shí)間、執(zhí)行步驟、失敗處理。觸發(fā)時(shí)間我設(shè)的是每天上午十點(diǎn)半。為什么不是更早因?yàn)樘绲脑捰行┬畔⒃催€沒更新完抓到的內(nèi)容不完整。十點(diǎn)半這個(gè)時(shí)間點(diǎn)大部分技術(shù)社區(qū)和更新源都已經(jīng)完成了當(dāng)天的首次更新同時(shí)離我上午的工作節(jié)奏也匹配看完日?qǐng)?bào)正好開始處理當(dāng)天任務(wù)。執(zhí)行步驟我拆成了四個(gè)節(jié)點(diǎn)每個(gè)節(jié)點(diǎn)獨(dú)立配置節(jié)點(diǎn)功能超時(shí)設(shè)置重試策略節(jié)點(diǎn)一信息采集120秒失敗重試2次節(jié)點(diǎn)二數(shù)據(jù)清洗60秒失敗重試1次節(jié)點(diǎn)三模型調(diào)用180秒失敗重試2次節(jié)點(diǎn)四消息推送30秒失敗重試3次超時(shí)和重試的設(shè)置邏輯是這樣的采集和模型調(diào)用是外部依賴網(wǎng)絡(luò)波動(dòng)或服務(wù)響應(yīng)慢的概率較高所以超時(shí)給得寬、重試次數(shù)多推送是最后一步失敗成本高所以重試次數(shù)最多確保消息能發(fā)出去。注意重試不是越多越好。如果某個(gè)節(jié)點(diǎn)連續(xù)失敗說明可能是配置錯(cuò)誤或服務(wù)不可用這時(shí)候應(yīng)該觸發(fā)告警而不是無限重試。我在 WorkBuddy 里設(shè)了“連續(xù)失敗3次則暫停任務(wù)并通知”的規(guī)則。3.2 DeepSeek API 調(diào)用的參數(shù)調(diào)優(yōu)調(diào)用 DeepSeek API 做日?qǐng)?bào)生成有幾個(gè)參數(shù)直接影響輸出質(zhì)量。temperature我設(shè)的是 0.3。這個(gè)值越低輸出越穩(wěn)定、越保守越高越有創(chuàng)造性。日?qǐng)?bào)場(chǎng)景不需要?jiǎng)?chuàng)造性需要的是準(zhǔn)確和一致所以調(diào)低。實(shí)測(cè) 0.3 的時(shí)候模型基本能按照我要求的格式輸出不會(huì)突然自由發(fā)揮。max_tokens根據(jù)日?qǐng)?bào)長(zhǎng)度來定。我一般控制在 1500 到 2000 之間。設(shè)太小會(huì)導(dǎo)致輸出被截?cái)嘣O(shè)太大又浪費(fèi)。我的做法是先跑幾次看實(shí)際輸出的 token 數(shù)然后留 20% 的余量。top_p保持默認(rèn)的 1.0 就行配合低 temperature 使用不需要額外調(diào)整。prompt 的結(jié)構(gòu)我固定成三段角色設(shè)定 任務(wù)說明 輸出格式。舉個(gè)例子你是一個(gè)技術(shù)日?qǐng)?bào)編輯。請(qǐng)把下面的原始信息整理成一份日?qǐng)?bào)。 要求 1. 按“開發(fā)工具”“AI動(dòng)態(tài)”“社區(qū)熱點(diǎn)”三個(gè)類別分組 2. 每條不超過兩句話 3. 每組末尾用一句話總結(jié) 4. 輸出用 JSON 格式字段為 category、items、summary 原始信息 {raw_content}這個(gè) prompt 模板我用了很久輸出格式基本沒跑偏過。關(guān)鍵點(diǎn)是把格式要求寫死在 prompt 里而不是靠后處理去猜。3.3 微信小程序訂閱消息的接入細(xì)節(jié)微信小程序的訂閱消息接入分三步申請(qǐng)模板、獲取 access_token、發(fā)送消息。申請(qǐng)模板在微信公眾平臺(tái)的“訂閱消息”里操作。我申請(qǐng)的是一個(gè)“日?qǐng)?bào)通知”類模板字段包括標(biāo)題、摘要、時(shí)間。模板申請(qǐng)通過后會(huì)拿到一個(gè) template_id后面發(fā)送消息要用。獲取 access_token 是調(diào)用微信接口的前置步驟。access_token 有效期是 7200 秒需要緩存起來不能每次發(fā)送都重新獲取。我的做法是在 WorkBuddy 里用一個(gè)節(jié)點(diǎn)專門管理 token緩存到本地文件過期前自動(dòng)刷新。發(fā)送消息的接口是subscribeMessage.send請(qǐng)求體里需要填 touser用戶 openid、template_id、page點(diǎn)擊跳轉(zhuǎn)的小程序頁面、data模板內(nèi)容。data 的字段名要和模板里定義的字段一一對(duì)應(yīng)否則會(huì)報(bào)錯(cuò)。提示微信小程序的訂閱消息有嚴(yán)格的字段長(zhǎng)度限制比如 thing 類型字段不超過 20 個(gè)字符。日?qǐng)?bào)摘要如果太長(zhǎng)需要先截?cái)嘣偬畛浞駝t接口會(huì)直接拒絕。3.4 數(shù)據(jù)采集環(huán)節(jié)的注意事項(xiàng)采集環(huán)節(jié)看起來簡(jiǎn)單實(shí)際上最容易出問題。我踩過的坑包括編碼不一致導(dǎo)致亂碼、請(qǐng)求頻率過高被限流、頁面結(jié)構(gòu)變化導(dǎo)致解析失敗。編碼問題好解決統(tǒng)一用 UTF-8 處理遇到非 UTF-8 的源先轉(zhuǎn)碼再解析。限流問題需要在采集節(jié)點(diǎn)里加延時(shí)我設(shè)的是每個(gè)源之間間隔 2 秒一天抓十幾個(gè)源總耗時(shí)控制在 30 秒以內(nèi)。頁面結(jié)構(gòu)變化是最麻煩的因?yàn)樵凑靖陌娌粫?huì)通知你。我的應(yīng)對(duì)策略是加一層校驗(yàn)如果某個(gè)源抓到的內(nèi)容為空或格式異常就在日?qǐng)?bào)里標(biāo)注“該源今日無有效內(nèi)容”而不是讓整個(gè)任務(wù)失敗。這個(gè)設(shè)計(jì)思路很重要單個(gè)源失敗不應(yīng)該拖垮整個(gè)日?qǐng)?bào)。日?qǐng)?bào)的價(jià)值在于整體信息覆蓋缺一兩個(gè)源可以接受但整個(gè)任務(wù)掛掉就什么都收不到了。4. 實(shí)操過程與核心環(huán)節(jié)實(shí)現(xiàn)4.1 環(huán)境準(zhǔn)備與依賴安裝先說環(huán)境。WorkBuddy 我裝在公司電腦上系統(tǒng)是 Windows。DeepSeek 的 API 調(diào)用用 Python 寫版本是 3.10。微信小程序的開發(fā)用 uniapp配合 HBuilderX。Python 這邊需要裝的庫不多pip install requests pip install schedulerequests 用來調(diào) DeepSeek API 和微信接口schedule 用來做本地測(cè)試時(shí)的定時(shí)模擬。實(shí)際跑在 WorkBuddy 里的時(shí)候定時(shí)由 WorkBuddy 負(fù)責(zé)schedule 只在本地調(diào)試用。微信小程序這邊需要在微信公眾平臺(tái)注冊(cè)一個(gè)小程序賬號(hào)拿到 AppID 和 AppSecret。然后在小程序后臺(tái)配置服務(wù)器域名把 WorkBuddy 所在服務(wù)器的 IP 或域名加進(jìn)去否則接口調(diào)用會(huì)被攔截。注意微信小程序的服務(wù)器域名配置有數(shù)量限制而且必須是 HTTPS。如果 WorkBuddy 跑在本地需要做內(nèi)網(wǎng)穿透或者部署到有公網(wǎng) IP 的服務(wù)器上。這一步是很多新手卡住的地方。4.2 DeepSeek API 調(diào)用的完整代碼實(shí)現(xiàn)先看調(diào)用 DeepSeek 的核心代碼。我把它封裝成了一個(gè)函數(shù)輸入原始文本輸出結(jié)構(gòu)化日?qǐng)?bào)。import requests import json def generate_daily_report(raw_content, api_key): url https://api.deepseek.com/v1/chat/completions headers { Authorization: fBearer {api_key}, Content-Type: application/json } prompt f你是一個(gè)技術(shù)日?qǐng)?bào)編輯。請(qǐng)把下面的原始信息整理成一份日?qǐng)?bào)。 要求 1. 按“開發(fā)工具”“AI動(dòng)態(tài)”“社區(qū)熱點(diǎn)”三個(gè)類別分組 2. 每條不超過兩句話 3. 每組末尾用一句話總結(jié) 4. 輸出用 JSON 格式字段為 category、items、summary 原始信息 {raw_content} payload { model: deepseek-chat, messages: [ {role: user, content: prompt} ], temperature: 0.3, max_tokens: 2000 } response requests.post(url, headersheaders, jsonpayload, timeout180) result response.json() content result[choices][0][message][content] # 清理可能的 markdown 代碼塊標(biāo)記 content content.replace(json, ).replace(, ).strip() return json.loads(content)這段代碼有幾個(gè)細(xì)節(jié)值得說。第一timeout 設(shè)了 180 秒因?yàn)槟Ｐ吞幚黹L(zhǎng)文本可能需要時(shí)間設(shè)太短會(huì)頻繁超時(shí)。第二輸出做了 markdown 清理模型有時(shí)候會(huì)把 JSON 包在代碼塊里返回直接 json.loads 會(huì)報(bào)錯(cuò)。第三temperature 和 max_tokens 寫死在代碼里方便統(tǒng)一管理。4.3 微信訂閱消息推送的實(shí)現(xiàn)推送這塊先獲取 access_token再發(fā)送消息。import requests import json import time import os def get_access_token(appid, secret): cache_file access_token_cache.json # 檢查緩存 if os.path.exists(cache_file): with open(cache_file, r) as f: cache json.load(f) if cache[expires_at] time.time(): return cache[access_token] # 重新獲取 url fhttps://api.weixin.qq.com/cgi-bin/token?grant_typeclient_credentialappid{appid}secret{secret} response requests.get(url, timeout30) result response.json() access_token result[access_token] expires_at time.time() result[expires_in] - 300 # 提前5分鐘過期 with open(cache_file, w) as f: json.dump({access_token: access_token, expires_at: expires_at}, f) return access_token def send_subscribe_message(access_token, openid, template_id, report_data): url fhttps://api.weixin.qq.com/cgi-bin/message/subscribe/send?access_token{access_token} payload { touser: openid, template_id: template_id, page: pages/index/index, data: { thing1: {value: report_data[title][:20]}, thing2: {value: report_data[summary][:20]}, time3: {value: report_data[date]} } } response requests.post(url, jsonpayload, timeout30) return response.json()這里的關(guān)鍵點(diǎn)是access_token 的緩存機(jī)制。微信的 access_token 每天有獲取次數(shù)限制如果每次發(fā)送都重新獲取很快就會(huì)用完配額。我用文件緩存的方式把 token 和過期時(shí)間存下來過期前 5 分鐘自動(dòng)刷新。另一個(gè)細(xì)節(jié)是字段截?cái)?。微信訂閱消息?thing 類型字段限制 20 個(gè)字符所以我在填充 data 的時(shí)候做了[:20]的截?cái)?。如果不截?cái)嘟涌跁?huì)返回錯(cuò)誤碼 47003。4.4 WorkBuddy 里的任務(wù)串聯(lián)把上面兩塊代碼串起來在 WorkBuddy 里配置成一個(gè)完整任務(wù)。我的做法是寫一個(gè)主入口腳本W(wǎng)orkBuddy 調(diào)用這個(gè)腳本腳本內(nèi)部按順序執(zhí)行采集、處理、推送。def main(): # 1. 采集 raw_content collect_sources() # 2. 生成日?qǐng)?bào) report generate_daily_report(raw_content, DEEPSEEK_API_KEY) # 3. 推送 access_token get_access_token(WECHAT_APPID, WECHAT_SECRET) result send_subscribe_message(access_token, USER_OPENID, TEMPLATE_ID, report) # 4. 記錄結(jié)果 log_result(result) return result if __name__ __main__: main()WorkBuddy 這邊我配置的是“執(zhí)行外部腳本”類型的任務(wù)指定 Python 解釋器路徑和腳本路徑觸發(fā)時(shí)間設(shè)為每天上午十點(diǎn)半。執(zhí)行記錄里能看到每次運(yùn)行的輸出和耗時(shí)方便排查。4.5 本地調(diào)試與線上運(yùn)行的差異處理本地調(diào)試的時(shí)候我直接用 schedule 庫模擬定時(shí)每五分鐘跑一次快速驗(yàn)證流程。但線上運(yùn)行有幾個(gè)差異需要注意。第一是網(wǎng)絡(luò)環(huán)境。本地調(diào)試時(shí)網(wǎng)絡(luò)穩(wěn)定線上服務(wù)器可能遇到網(wǎng)絡(luò)抖動(dòng)所以超時(shí)和重試策略要按線上環(huán)境來配。第二是文件路徑。本地用相對(duì)路徑?jīng)]問題線上要用絕對(duì)路徑否則 WorkBuddy 調(diào)用腳本時(shí)可能找不到文件。第三是日志輸出。本地調(diào)試看控制臺(tái)就行線上要把日志寫到文件里方便事后排查。我的做法是在腳本里加一個(gè)環(huán)境變量判斷本地調(diào)試和線上運(yùn)行走不同的配置分支。這樣一套代碼兩邊都能用不用維護(hù)兩份。5. 常見問題與排查技巧實(shí)錄5.1 模型輸出格式不對(duì)怎么辦這是最常見的問題。模型有時(shí)候會(huì)自由發(fā)揮不按 JSON 格式輸出或者在 JSON 外面加一堆解釋文字。我的排查思路是分三步走。第一步檢查 prompt 是否足夠明確。如果 prompt 里只寫了“輸出 JSON”模型可能理解成“在回答里包含 JSON”。要寫成“只輸出 JSON不要有任何其他文字”。第二步加后處理兜底。即使 prompt 寫得很清楚模型偶爾還是會(huì)跑偏。我在代碼里加了一層正則提取從輸出里找第一個(gè){到最后一個(gè)}之間的內(nèi)容再嘗試解析。這樣即使模型多說了幾句話也能把 JSON 摳出來。第三步設(shè)置失敗降級(jí)。如果 JSON 解析實(shí)在失敗就把模型的原始輸出直接作為純文本日?qǐng)?bào)推送至少保證信息能送達(dá)而不是整個(gè)任務(wù)失敗。5.2 微信推送報(bào)錯(cuò) 47003 怎么解決47003 是訂閱消息的字段校驗(yàn)錯(cuò)誤通常是因?yàn)樽侄蝺?nèi)容不符合模板要求。排查的時(shí)候重點(diǎn)看三個(gè)地方。一是字段類型是否匹配。模板里定義的是 thing 類型你傳了數(shù)字或者超長(zhǎng)文本就會(huì)報(bào)錯(cuò)。二是字段長(zhǎng)度是否超限。thing 類型限制 20 個(gè)字符超出就截?cái)?。三是字段名是否?duì)應(yīng)。模板里的字段名是 thing1、thing2你傳的時(shí)候?qū)懗闪?thing_1也會(huì)報(bào)錯(cuò)。我的經(jīng)驗(yàn)是在代碼里加一層校驗(yàn)發(fā)送前先檢查每個(gè)字段的長(zhǎng)度和類型不符合就先處理再發(fā)送。這樣比等接口報(bào)錯(cuò)再回頭改要高效得多。5.3 任務(wù)執(zhí)行超時(shí)怎么排查WorkBuddy 里任務(wù)超時(shí)原因通常有三個(gè)采集源響應(yīng)慢、模型調(diào)用耗時(shí)長(zhǎng)、網(wǎng)絡(luò)抖動(dòng)。排查方法是看執(zhí)行記錄里每個(gè)節(jié)點(diǎn)的耗時(shí)。如果采集節(jié)點(diǎn)耗時(shí)超過 100 秒說明某個(gè)源響應(yīng)慢需要單獨(dú)檢查。如果模型調(diào)用節(jié)點(diǎn)耗時(shí)超過 150 秒可能是輸入文本太長(zhǎng)需要做截?cái)嗷蚍峙幚怼Ｈ绻蔷W(wǎng)絡(luò)抖動(dòng)重試通常能解決。我設(shè)了一個(gè)規(guī)則如果某個(gè)節(jié)點(diǎn)連續(xù)三次超時(shí)就把它暫時(shí)禁用避免拖累整個(gè)任務(wù)。等排查清楚再重新啟用。5.4 常見問題速查表問題現(xiàn)象可能原因排查方法解決方案模型輸出非 JSONprompt 不明確檢查 prompt 格式要求加“只輸出 JSON”約束 正則兜底推送報(bào)錯(cuò) 47003字段超長(zhǎng)或類型錯(cuò)檢查 data 字段截?cái)? 類型轉(zhuǎn)換access_token 失效緩存過期未刷新檢查緩存文件提前 5 分鐘刷新采集內(nèi)容為空源站改版或限流單獨(dú)測(cè)試該源加校驗(yàn) 標(biāo)注無內(nèi)容任務(wù)超時(shí)某節(jié)點(diǎn)耗時(shí)過長(zhǎng)看執(zhí)行記錄耗時(shí)禁用問題節(jié)點(diǎn) 重試5.5 幾個(gè)文檔里不會(huì)寫的實(shí)操心得第一個(gè)心得日?qǐng)?bào)的“摘要”比“全文”更重要。我一開始把抓到的所有內(nèi)容都塞進(jìn)日?qǐng)?bào)結(jié)果讀起來跟沒整理一樣。后來改成每條只保留兩句話摘要閱讀效率明顯提升。模型做摘要的時(shí)候要明確告訴它“提煉核心信息去掉細(xì)節(jié)”。第二個(gè)心得推送時(shí)間要留緩沖。我設(shè)的是十點(diǎn)半推送但實(shí)際執(zhí)行時(shí)采集和模型處理可能花掉幾分鐘。所以我在 WorkBuddy 里把觸發(fā)時(shí)間設(shè)成十點(diǎn)二十五留五分鐘緩沖確保十點(diǎn)半之前能送達(dá)。第三個(gè)心得失敗告警要分級(jí)。不是所有失敗都需要立刻處理。采集失敗可以容忍推送失敗必須立刻知道。我在 WorkBuddy 里配了不同的告警級(jí)別推送失敗直接發(fā)通知采集失敗只記錄日志。第四個(gè)心得定期回顧日?qǐng)?bào)質(zhì)量。我每周會(huì)翻一下過去七天的日?qǐng)?bào)看看有沒有重復(fù)信息、有沒有漏掉重要?jiǎng)討B(tài)。根據(jù)回顧結(jié)果調(diào)整采集源和 prompt讓日?qǐng)?bào)越來越貼合自己的需求。6. 后續(xù)可以怎么擴(kuò)展這套流程跑通之后擴(kuò)展空間其實(shí)挺大的。我目前想到幾個(gè)方向也陸續(xù)在試。一個(gè)是多用戶支持?，F(xiàn)在日?qǐng)?bào)只推給我自己如果團(tuán)隊(duì)里其他人也想看可以把 openid 存成一個(gè)列表推送的時(shí)候循環(huán)發(fā)送。微信訂閱消息支持批量發(fā)送但每個(gè)用戶需要單獨(dú)授權(quán)。另一個(gè)是日?qǐng)?bào)內(nèi)容個(gè)性化。不同人關(guān)注的技術(shù)領(lǐng)域不一樣可以在 prompt 里加一個(gè)“關(guān)注領(lǐng)域”參數(shù)讓模型根據(jù)用戶偏好調(diào)整內(nèi)容權(quán)重。這個(gè)改動(dòng)不大但效果挺明顯。還有一個(gè)是歷史日?qǐng)?bào)歸檔。把每天的日?qǐng)?bào)存到數(shù)據(jù)庫里需要的時(shí)候可以回溯查詢。這個(gè)對(duì)于跟蹤某個(gè)技術(shù)趨勢(shì)的變化很有用。最后再分享一個(gè)小技巧WorkBuddy 的任務(wù)執(zhí)行記錄可以導(dǎo)出我每周會(huì)把記錄導(dǎo)出來用腳本統(tǒng)計(jì)一下各節(jié)點(diǎn)的平均耗時(shí)和失敗率。這樣能提前發(fā)現(xiàn)潛在問題而不是等任務(wù)掛了才去排查。這個(gè)習(xí)慣堅(jiān)持了幾個(gè)月任務(wù)的穩(wěn)定性確實(shí)提升了不少。