1. 為什么我要給 WorkBuddy 設(shè)一個(gè)“十點(diǎn)半鬧鐘”每天早上到工位第一件事不是泡茶而是打開(kāi)各種信息源翻一遍項(xiàng)目群里有沒(méi)有新需求、昨天提交的代碼有沒(méi)有異常、行業(yè)里又出了什么新工具。這套動(dòng)作重復(fù)了幾個(gè)月之后我意識(shí)到它本質(zhì)上就是一次“信息聚合”完全沒(méi)必要靠人肉完成。于是就有了這個(gè)項(xiàng)目——給 WorkBuddy 設(shè)一個(gè)定時(shí)任務(wù)每天上午十點(diǎn)半把一份整理好的 AI 日?qǐng)?bào)自動(dòng)推送到微信。先說(shuō)清楚這個(gè)項(xiàng)目是什么。WorkBuddy 在這里扮演的是“執(zhí)行大腦”的角色它負(fù)責(zé)在指定時(shí)間被喚醒調(diào)用模型能力去抓取、篩選、總結(jié)信息最后把結(jié)果通過(guò)微信的通道送到我手上。整條鏈路的核心關(guān)鍵詞有三個(gè)WorkBuddy、AI 日?qǐng)?bào)、自動(dòng)化。它解決的問(wèn)題很具體——把“每天手動(dòng)刷信息”這件事從我的日程里徹底刪掉同時(shí)保證我拿到的不是一堆原始鏈接而是一份已經(jīng)消化過(guò)的、可以直接讀的簡(jiǎn)報(bào)。適合誰(shuí)來(lái)參考三類人。第一類是像我這樣每天需要跟蹤大量信息、但又不愿意把時(shí)間耗在“刷”上的開(kāi)發(fā)者或產(chǎn)品同學(xué)第二類是想入門自動(dòng)化工作流、但不知道從哪個(gè)場(chǎng)景切入的新手這個(gè)項(xiàng)目的門檻其實(shí)很低核心邏輯就是“定時(shí)觸發(fā) 內(nèi)容生成 消息推送”第三類是對(duì) WorkBuddy 這類工具感興趣、想看看它到底能干什么的人我會(huì)把配置思路和踩過(guò)的坑都攤開(kāi)講。需要提前說(shuō)明的是下面涉及的具體配置、參數(shù)和步驟有一部分是基于我自己的實(shí)踐記錄有一部分是基于同類自動(dòng)化方案的常見(jiàn)做法做的合理補(bǔ)全。因?yàn)椴煌姹镜?WorkBuddy 在界面和指令細(xì)節(jié)上可能有差異你在復(fù)現(xiàn)的時(shí)候以自己環(huán)境里的實(shí)際選項(xiàng)為準(zhǔn)思路是通用的。2. 整體方案設(shè)計(jì)與核心思路拆解2.1 為什么選“定時(shí)觸發(fā) 模型生成 微信推送”這條鏈路做自動(dòng)化最怕的就是把簡(jiǎn)單事情復(fù)雜化。我見(jiàn)過(guò)不少人一上來(lái)就搭一套完整的消息隊(duì)列加調(diào)度中心結(jié)果維護(hù)成本比手動(dòng)操作還高。這個(gè)項(xiàng)目的設(shè)計(jì)原則只有一條用最少的組件跑通最完整的閉環(huán)。整條鏈路拆開(kāi)看就三段。第一段是觸發(fā)每天上午十點(diǎn)半準(zhǔn)時(shí)啟動(dòng)這個(gè)時(shí)間點(diǎn)是我反復(fù)調(diào)過(guò)的——太早了信息源還沒(méi)更新完太晚了上午的工作節(jié)奏已經(jīng)起來(lái)了十點(diǎn)半剛好是第一個(gè)工作段落結(jié)束、需要補(bǔ)充信息的時(shí)間窗口。第二段是生成WorkBuddy 接到觸發(fā)信號(hào)后按照預(yù)設(shè)的指令去收集和整理內(nèi)容這里會(huì)用到模型能力熱搜詞里提到的 deepseek-v4-flash 就是這類場(chǎng)景下常見(jiàn)的一個(gè)模型選項(xiàng)特點(diǎn)是響應(yīng)快、成本低適合做這種每天都要跑的例行任務(wù)。第三段是推送把生成好的日?qǐng)?bào)通過(guò)微信送到手機(jī)上。為什么是微信而不是郵件或者別的渠道因?yàn)槲⑿攀俏颐刻齑蜷_(kāi)頻率最高的應(yīng)用消息觸達(dá)的確定性最高。郵件容易被淹沒(méi)其他工具需要額外打開(kāi)只有微信是“不用刻意去看也會(huì)看到”的。這個(gè)選擇看起來(lái)不起眼但它決定了這個(gè)自動(dòng)化任務(wù)能不能真正融入日常而不是變成一個(gè)需要我主動(dòng)去檢查的“另一個(gè)待辦”。2.2 WorkBuddy 在這個(gè)方案里到底承擔(dān)什么角色很多人第一次接觸 WorkBuddy 會(huì)把它理解成一個(gè)“聊天工具”這就把它的能力看窄了。在我的用法里它更像是一個(gè)可以接受自然語(yǔ)言指令的任務(wù)執(zhí)行器。你告訴它“每天十點(diǎn)半做一份 AI 日?qǐng)?bào)并發(fā)到微信”它負(fù)責(zé)把這句話拆解成可執(zhí)行的步驟。這里有個(gè)關(guān)鍵認(rèn)知WorkBuddy 的價(jià)值不在于它自己會(huì)不會(huì)寫代碼而在于它能把“意圖”翻譯成“動(dòng)作”。我不需要去寫一個(gè)爬蟲(chóng)腳本也不需要去配置復(fù)雜的定時(shí)任務(wù)表達(dá)式我只需要把需求描述清楚剩下的編排由它來(lái)完成。這也是為什么這個(gè)項(xiàng)目對(duì)新手友好——你不需要是后端工程師你只需要能把自己的需求說(shuō)明白。熱搜詞里出現(xiàn)了 workbuddy skill、workbuddy 自定義指令推薦這些詞說(shuō)明大家最關(guān)心的就是“怎么讓 WorkBuddy 聽(tīng)懂我要干什么”。我的經(jīng)驗(yàn)是指令要寫得像給同事交代任務(wù)一樣具體說(shuō)清楚時(shí)間、說(shuō)清楚內(nèi)容范圍、說(shuō)清楚輸出格式、說(shuō)清楚送到哪里。模糊的指令會(huì)得到模糊的結(jié)果這一點(diǎn)在后面講實(shí)操的時(shí)候我會(huì)展開(kāi)。2.3 方案選型時(shí)我放棄的幾個(gè)思路在定下最終方案之前我試過(guò)另外兩條路都放棄了說(shuō)一下原因可能幫你少走彎路。第一條是純腳本方案。用 Python 寫一個(gè)腳本定時(shí)抓取 RSS調(diào)模型接口總結(jié)再調(diào)微信的接口推送。這條路技術(shù)上完全可行但維護(hù)成本高——信息源一變就要改代碼模型接口一升級(jí)就要調(diào)參數(shù)微信側(cè)的推送通道還有各種限制。我跑了大概兩周就放棄了因?yàn)槊刻旎ㄔ诰S護(hù)腳本上的時(shí)間已經(jīng)超過(guò)了手動(dòng)刷信息的時(shí)間。第二條是純手動(dòng)方案加提醒。就是設(shè)個(gè)鬧鐘提醒自己“該看日?qǐng)?bào)了”然后手動(dòng)去各個(gè)平臺(tái)翻。這個(gè)方案的問(wèn)題在于提醒響了之后我還是要花十幾分鐘去收集和整理鬧鐘只解決了“記得看”沒(méi)解決“不用做”。自動(dòng)化的核心價(jià)值是替代動(dòng)作不是替代記憶。最終選擇 WorkBuddy 這條路線是因?yàn)樗凇办`活”和“省心”之間找到了平衡點(diǎn)。指令可以隨時(shí)改不用動(dòng)代碼執(zhí)行由平臺(tái)負(fù)責(zé)不用管服務(wù)器。對(duì)于這種每天都要跑、但邏輯不算特別復(fù)雜的任務(wù)來(lái)說(shuō)這是性價(jià)比最高的選擇。3. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)3.1 定時(shí)觸發(fā)怎么設(shè)才靠譜定時(shí)觸發(fā)看起來(lái)是最簡(jiǎn)單的一環(huán)但恰恰是坑最多的地方。我踩過(guò)的第一個(gè)坑就是時(shí)區(qū)問(wèn)題。WorkBuddy 如果跑在云端默認(rèn)時(shí)區(qū)可能不是北京時(shí)間你設(shè)了十點(diǎn)半實(shí)際執(zhí)行可能是下午六點(diǎn)半。所以第一件事是確認(rèn)執(zhí)行環(huán)境的時(shí)區(qū)設(shè)置確保它和你所在地的時(shí)間一致。第二個(gè)坑是觸發(fā)頻率和執(zhí)行時(shí)長(zhǎng)的關(guān)系。如果你把任務(wù)設(shè)成每五分鐘跑一次但單次執(zhí)行需要八分鐘就會(huì)出現(xiàn)任務(wù)堆積。對(duì)于日?qǐng)?bào)這種場(chǎng)景一天一次就夠了不需要高頻觸發(fā)。我的設(shè)置是每天十點(diǎn)半觸發(fā)一次如果執(zhí)行失敗隔半小時(shí)重試一次最多重試兩次。這樣既保證了可靠性又不會(huì)造成資源浪費(fèi)。第三個(gè)細(xì)節(jié)是觸發(fā)時(shí)間的容錯(cuò)。我一開(kāi)始設(shè)的是十點(diǎn)整結(jié)果發(fā)現(xiàn)有些信息源在十點(diǎn)的時(shí)候還沒(méi)更新完當(dāng)天的內(nèi)容生成出來(lái)的日?qǐng)?bào)缺斤少兩。后來(lái)改到十點(diǎn)半信息完整度明顯提升。這個(gè)時(shí)間點(diǎn)不是拍腦袋定的是我連續(xù)觀察了一周各個(gè)信息源的更新時(shí)間之后選的。如果你用的信息源更新更晚可以再往后調(diào)。提示定時(shí)任務(wù)設(shè)好之后不要只看第一天的執(zhí)行結(jié)果。連續(xù)觀察三到五天確認(rèn)每天都能在預(yù)期時(shí)間拿到完整內(nèi)容再把它當(dāng)成穩(wěn)定流程來(lái)依賴。3.2 日?qǐng)?bào)內(nèi)容怎么組織才不是“鏈接堆砌”一份好的 AI 日?qǐng)?bào)和一份差的 AI 日?qǐng)?bào)差別不在信息量而在信息密度。我見(jiàn)過(guò)很多自動(dòng)生成的日?qǐng)?bào)本質(zhì)上就是把抓到的標(biāo)題列一遍讀起來(lái)跟刷信息流沒(méi)區(qū)別那自動(dòng)化就失去意義了。我的做法是給 WorkBuddy 的指令里明確要求三個(gè)層次。第一層是今日要點(diǎn)用三到五句話概括今天最值得關(guān)注的幾件事這是給“沒(méi)時(shí)間細(xì)看”的場(chǎng)景準(zhǔn)備的。第二層是分類摘要把信息按主題分組每組給出一段簡(jiǎn)短的說(shuō)明這是給“想快速了解某個(gè)方向”的場(chǎng)景準(zhǔn)備的。第三層是原文索引把關(guān)鍵鏈接附在最后這是給“想深入看某一條”的場(chǎng)景準(zhǔn)備的。這個(gè)三層結(jié)構(gòu)的好處是你可以在三十秒內(nèi)看完第一層在三分鐘內(nèi)看完前兩層需要的時(shí)候再去看第三層。它把“讀日?qǐng)?bào)”這件事變成了可伸縮的而不是一個(gè)必須從頭讀到尾的固定動(dòng)作。指令里還要明確排除規(guī)則。比如我要求過(guò)濾掉純廣告性質(zhì)的內(nèi)容、過(guò)濾掉重復(fù)報(bào)道同一事件的條目、過(guò)濾掉超過(guò)三天的舊聞。這些規(guī)則不寫清楚生成出來(lái)的日?qǐng)?bào)就會(huì)很水。我的經(jīng)驗(yàn)是排除規(guī)則比包含規(guī)則更重要因?yàn)樾畔⑦^(guò)載的時(shí)代少即是多。3.3 微信推送通道的選擇與配置把內(nèi)容送到微信有幾條路可以走。一條是微信小程序如果你有自己的小程序可以通過(guò)訂閱消息的方式推送但需要用戶主動(dòng)訂閱而且有模板限制。另一條是企業(yè)微信機(jī)器人配置簡(jiǎn)單直接在群里加一個(gè)機(jī)器人通過(guò) Webhook 推送這是我最推薦的方式因?yàn)椴恍枰獙徍?、不需要用戶訂閱、格式也靈活。熱搜詞里出現(xiàn)了微信小程序、微信小程序請(qǐng)求封裝這些詞說(shuō)明很多人會(huì)考慮用小程序來(lái)做接收端。這條路不是不行但你要想清楚小程序適合做“交互”不適合做“通知”。如果你只是想讓日?qǐng)?bào)出現(xiàn)在手機(jī)上企業(yè)微信機(jī)器人或者服務(wù)號(hào)模板消息是更直接的選擇。小程序更適合你需要在日?qǐng)?bào)基礎(chǔ)上做進(jìn)一步操作比如標(biāo)記已讀、收藏、轉(zhuǎn)發(fā)的場(chǎng)景。配置 Webhook 的時(shí)候注意兩點(diǎn)。一是消息格式企業(yè)微信機(jī)器人支持 Markdown 格式你可以用標(biāo)題、列表、加粗來(lái)組織內(nèi)容可讀性比純文本好很多。二是頻率限制每個(gè)機(jī)器人每分鐘有發(fā)送條數(shù)限制日?qǐng)?bào)這種一天一條的場(chǎng)景完全不用擔(dān)心但如果你后續(xù)想擴(kuò)展成多條推送就要注意合并內(nèi)容。3.4 模型選型的考量為什么是 deepseek-v4-flash熱搜詞里出現(xiàn)了 deepseek-v4-flash我猜很多人關(guān)心模型怎么選。對(duì)于日?qǐng)?bào)生成這種場(chǎng)景選型的關(guān)鍵指標(biāo)不是“誰(shuí)最聰明”而是響應(yīng)速度、成本、穩(wěn)定性這三者的平衡。日?qǐng)?bào)生成的任務(wù)特點(diǎn)是每天都要跑、輸入內(nèi)容量大、輸出格式相對(duì)固定、對(duì)創(chuàng)造性要求不高。這種任務(wù)用頂級(jí)模型是浪費(fèi)用太小的模型又容易總結(jié)得不到位。deepseek-v4-flash 這類模型的定位剛好卡在中間——速度夠快成本夠低處理總結(jié)類任務(wù)的能力也夠用。我的實(shí)測(cè)感受是同樣的輸入內(nèi)容用大模型生成一份日?qǐng)?bào)大概需要十幾秒用 flash 級(jí)別的模型只需要幾秒而輸出質(zhì)量的差距在日?qǐng)?bào)這個(gè)場(chǎng)景下幾乎看不出來(lái)。因?yàn)槿請(qǐng)?bào)的核心是“準(zhǔn)確提煉”而不是“深度創(chuàng)作”模型不需要發(fā)揮想象力只需要把已有信息整理清楚。當(dāng)然如果你對(duì)日?qǐng)?bào)的質(zhì)量有更高要求比如希望它做一些趨勢(shì)分析或者跨條目的關(guān)聯(lián)解讀那可以考慮在關(guān)鍵部分調(diào)用更強(qiáng)的模型。我的做法是分級(jí)處理摘要部分用 flash 模型如果發(fā)現(xiàn)某天的內(nèi)容特別重要再手動(dòng)用更強(qiáng)的模型重新生成一遍。這樣既控制了日常成本又保留了深度處理的能力。4. 實(shí)操過(guò)程與核心環(huán)節(jié)實(shí)現(xiàn)4.1 從零開(kāi)始WorkBuddy 的初始化配置假設(shè)你是一個(gè)完全的新手手里只有一個(gè) WorkBuddy 賬號(hào)下面是我建議的起步路徑。第一步是確認(rèn)你的 WorkBuddy 版本和運(yùn)行環(huán)境。熱搜詞里有 workbuddy 國(guó)際版、workbuddy linux、workbuddy ubuntu 這些詞說(shuō)明不同環(huán)境的配置方式有差異。如果你用的是云端版本大部分配置在網(wǎng)頁(yè)界面里完成如果你用的是本地版本可能需要先確認(rèn)運(yùn)行環(huán)境的基礎(chǔ)依賴是否齊全。我的建議是先用云端版本跑通流程再考慮遷移到本地。第二步是創(chuàng)建一個(gè)專門的工作區(qū)。不要在你的主工作區(qū)里做實(shí)驗(yàn)新建一個(gè)干凈的空間這樣即使配置出錯(cuò)也不會(huì)影響其他任務(wù)。工作區(qū)建好之后先跑一個(gè)最簡(jiǎn)單的測(cè)試指令比如“輸出一句你好”確認(rèn)基礎(chǔ)鏈路是通的。第三步是配置模型接入。如果你用的是平臺(tái)自帶的模型這一步可以跳過(guò)如果你要接入 deepseek-v4-flash 這類外部模型需要準(zhǔn)備好 API Key 和接入地址。這里注意API Key 要保存在環(huán)境變量或者平臺(tái)的密鑰管理里不要直接寫在指令文本中。第四步是測(cè)試定時(shí)觸發(fā)。先設(shè)一個(gè)五分鐘后的觸發(fā)時(shí)間確認(rèn)任務(wù)能按時(shí)啟動(dòng)。這一步很多人會(huì)跳過(guò)直接設(shè)成明天十點(diǎn)半結(jié)果第二天發(fā)現(xiàn)沒(méi)執(zhí)行又要等一天才能排查。先用短周期測(cè)試確認(rèn)沒(méi)問(wèn)題再改成正式時(shí)間。4.2 編寫日?qǐng)?bào)生成指令的完整思路指令是整個(gè)項(xiàng)目的心臟。我把我用的指令結(jié)構(gòu)拆開(kāi)講你可以根據(jù)自己的需求調(diào)整。指令的開(kāi)頭要明確角色和任務(wù)。比如“你是一個(gè) AI 行業(yè)日?qǐng)?bào)編輯每天負(fù)責(zé)整理過(guò)去 24 小時(shí)內(nèi) AI 領(lǐng)域的重要?jiǎng)討B(tài)。”這句話看起來(lái)簡(jiǎn)單但它給模型定了一個(gè)明確的身份后續(xù)的輸出會(huì)圍繞這個(gè)身份展開(kāi)。接下來(lái)是信息源的定義。你要告訴 WorkBuddy 去哪里找信息?？梢允蔷唧w的網(wǎng)站、RSS 源、或者平臺(tái)內(nèi)置的信息渠道。我的做法是列三到五個(gè)高質(zhì)量的信息源而不是廣撒網(wǎng)。信息源太多會(huì)導(dǎo)致內(nèi)容重復(fù)和噪音增加三到五個(gè)足夠覆蓋主要?jiǎng)討B(tài)。然后是篩選和排序規(guī)則。我要求按重要性排序重要性判斷標(biāo)準(zhǔn)包括是否涉及重大產(chǎn)品發(fā)布、是否有實(shí)質(zhì)性的技術(shù)突破、是否來(lái)自權(quán)威信源。這些標(biāo)準(zhǔn)要寫清楚否則模型會(huì)按自己的理解來(lái)排結(jié)果可能不符合你的預(yù)期。再然后是輸出格式的定義。我前面提到的三層結(jié)構(gòu)就是在這里定義的。格式定義得越具體輸出越穩(wěn)定。比如我會(huì)明確要求“今日要點(diǎn)不超過(guò)五句話”、“每個(gè)分類摘要不超過(guò)三句話”、“原文索引最多列十條”。最后是異常處理規(guī)則。比如“如果某個(gè)信息源無(wú)法訪問(wèn)跳過(guò)并在日?qǐng)?bào)末尾注明”、“如果當(dāng)天沒(méi)有重要?jiǎng)討B(tài)輸出‘今日無(wú)重大更新’而不是強(qiáng)行湊內(nèi)容”。這些規(guī)則能避免日?qǐng)?bào)在異常情況下變成一堆廢話。4.3 微信推送的配置與聯(lián)調(diào)推送環(huán)節(jié)的配置分兩步。第一步是獲取推送通道的憑證。如果你用的是企業(yè)微信機(jī)器人在群設(shè)置里添加機(jī)器人拿到 Webhook 地址。這個(gè)地址就是你的推送入口任何能發(fā)送 HTTP 請(qǐng)求的工具都可以往這里推消息。第二步是在 WorkBuddy 里配置推送動(dòng)作。你需要告訴它生成完日?qǐng)?bào)之后把內(nèi)容發(fā)送到指定的 Webhook 地址。這里注意內(nèi)容格式的轉(zhuǎn)換——WorkBuddy 生成的是文本企業(yè)微信機(jī)器人接受的是 JSON 格式的 Markdown 消息中間需要一個(gè)簡(jiǎn)單的格式轉(zhuǎn)換。如果你的 WorkBuddy 版本支持直接配置 Webhook 推送這一步可以在界面里完成如果不支持可能需要寫一小段轉(zhuǎn)換邏輯。聯(lián)調(diào)的時(shí)候先用一條測(cè)試消息確認(rèn)通道是通的。我的習(xí)慣是先推一條“測(cè)試消息”確認(rèn)手機(jī)能收到再去調(diào)日?qǐng)?bào)的格式。這樣如果出問(wèn)題你能快速判斷是通道問(wèn)題還是內(nèi)容問(wèn)題。注意Webhook 地址相當(dāng)于一個(gè)密碼拿到的人就能往你的群里發(fā)消息。不要把它寫在公開(kāi)的代碼倉(cāng)庫(kù)或者分享出去。如果懷疑泄露了在企業(yè)微信里重新生成一個(gè)即可。4.4 完整鏈路的串聯(lián)與首次運(yùn)行把上面幾步串起來(lái)完整的執(zhí)行流程是這樣的十點(diǎn)半觸發(fā) → WorkBuddy 啟動(dòng) → 按指令收集信息 → 調(diào)用模型生成日?qǐng)?bào) → 格式轉(zhuǎn)換 → 推送到微信 → 你在手機(jī)上收到消息。首次運(yùn)行的時(shí)候我建議你全程盯著。從觸發(fā)開(kāi)始看每一步的執(zhí)行日志確認(rèn)信息收集是否完整、模型輸出是否符合預(yù)期、推送是否成功。第一次跑通之后再改成無(wú)人值守的模式。首次運(yùn)行還有一個(gè)作用就是校準(zhǔn)輸出質(zhì)量。你可能會(huì)發(fā)現(xiàn)模型總結(jié)得太籠統(tǒng)或者分類不合理或者格式不是你想要的。這時(shí)候直接改指令重新跑一次直到輸出讓你滿意為止。我的經(jīng)驗(yàn)是指令大概要改三到五輪才能達(dá)到穩(wěn)定可用的狀態(tài)不要指望一次就完美。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄5.1 定時(shí)任務(wù)沒(méi)有按時(shí)觸發(fā)怎么辦這是最高頻的問(wèn)題。排查順序是這樣的先確認(rèn)時(shí)區(qū)設(shè)置這是最常見(jiàn)的原因再確認(rèn)任務(wù)狀態(tài)是不是被意外暫停了然后看執(zhí)行日志里有沒(méi)有報(bào)錯(cuò)信息最后確認(rèn)觸發(fā)時(shí)間有沒(méi)有和其他任務(wù)沖突。如果日志顯示任務(wù)啟動(dòng)了但沒(méi)執(zhí)行完那可能是執(zhí)行超時(shí)。日?qǐng)?bào)生成涉及信息抓取和模型調(diào)用如果信息源響應(yīng)慢整個(gè)任務(wù)可能超時(shí)。解決辦法是設(shè)置合理的超時(shí)時(shí)間并且在指令里加上“單個(gè)信息源超時(shí)時(shí)間不超過(guò)十秒”這樣的約束。還有一種情況是任務(wù)執(zhí)行了但你沒(méi)收到推送。這時(shí)候去檢查推送通道的日志看消息有沒(méi)有發(fā)出去。如果發(fā)出去了但沒(méi)收到檢查一下是不是被折疊到某個(gè)不常看的會(huì)話里了。5.2 日?qǐng)?bào)內(nèi)容質(zhì)量不穩(wěn)定的排查思路內(nèi)容質(zhì)量波動(dòng)通常有三個(gè)原因。一是信息源本身波動(dòng)某天信息源更新少日?qǐng)?bào)自然就薄。這種情況在指令里加一條“如果內(nèi)容不足注明今日信息量較少”就能解決不要強(qiáng)行湊。二是模型輸出的隨機(jī)性。同樣的輸入不同次生成的結(jié)果可能有差異。如果你對(duì)穩(wěn)定性要求高可以在指令里加更多的格式約束約束越具體輸出越穩(wěn)定。三是指令本身有歧義。比如你寫“整理重要內(nèi)容”模型對(duì)“重要”的理解可能和你不一致。解決辦法是把判斷標(biāo)準(zhǔn)寫具體比如“重要指的是涉及頭部公司的產(chǎn)品發(fā)布或技術(shù)突破”。5.3 推送失敗或格式錯(cuò)亂的常見(jiàn)原因推送失敗最常見(jiàn)的原因是Webhook 地址失效或者消息格式不符合要求。企業(yè)微信機(jī)器人對(duì) JSON 格式有嚴(yán)格要求字段名寫錯(cuò)、消息類型不對(duì)都會(huì)導(dǎo)致推送失敗。排查的時(shí)候先用最簡(jiǎn)單的文本消息測(cè)試確認(rèn)通道通了再試 Markdown 格式。格式錯(cuò)亂通常是轉(zhuǎn)義問(wèn)題。Markdown 里的特殊字符在 JSON 里需要轉(zhuǎn)義如果轉(zhuǎn)換邏輯沒(méi)處理好消息就會(huì)顯示異常。我的做法是在推送之前先做一次格式校驗(yàn)確認(rèn) JSON 是合法的再發(fā)送。還有一個(gè)容易被忽略的問(wèn)題是消息長(zhǎng)度限制。企業(yè)微信機(jī)器人對(duì)單條消息有長(zhǎng)度限制如果日?qǐng)?bào)內(nèi)容太長(zhǎng)需要截?cái)嗷蛘叻謼l發(fā)送。我的日?qǐng)?bào)一般控制在兩千字以內(nèi)沒(méi)有遇到這個(gè)問(wèn)題但如果你信息源特別多就要注意這一點(diǎn)。5.4 常見(jiàn)問(wèn)題速查表問(wèn)題現(xiàn)象可能原因排查動(dòng)作解決方式定時(shí)任務(wù)未觸發(fā)時(shí)區(qū)不一致檢查執(zhí)行環(huán)境時(shí)區(qū)調(diào)整為北京時(shí)間任務(wù)啟動(dòng)但無(wú)輸出執(zhí)行超時(shí)查看執(zhí)行日志耗時(shí)增加超時(shí)時(shí)間或減少信息源日?qǐng)?bào)內(nèi)容過(guò)少信息源更新延遲檢查各信息源更新時(shí)間調(diào)整觸發(fā)時(shí)間或增加信息源推送未到達(dá)Webhook 失效用測(cè)試消息驗(yàn)證通道重新生成 Webhook 地址消息格式錯(cuò)亂JSON 轉(zhuǎn)義問(wèn)題檢查消息體格式增加格式校驗(yàn)步驟輸出質(zhì)量波動(dòng)指令歧義回顧指令表述細(xì)化判斷標(biāo)準(zhǔn)和格式約束5.5 我踩過(guò)的幾個(gè)印象深刻的坑第一個(gè)坑是信息源重復(fù)。我一開(kāi)始列了八個(gè)信息源結(jié)果發(fā)現(xiàn)其中三個(gè)經(jīng)常報(bào)道同一件事日?qǐng)?bào)里出現(xiàn)了大量重復(fù)內(nèi)容。后來(lái)砍到四個(gè)并且加了去重規(guī)則質(zhì)量立刻上來(lái)了。信息源不是越多越好覆蓋面和獨(dú)特性比數(shù)量重要。第二個(gè)坑是模型把舊聞當(dāng)新聞。有些信息源的內(nèi)容沒(méi)有明確的時(shí)間標(biāo)記模型會(huì)把幾天前的內(nèi)容當(dāng)成當(dāng)天的動(dòng)態(tài)。解決辦法是在指令里明確要求“只收錄過(guò)去 24 小時(shí)內(nèi)發(fā)布的內(nèi)容”并且在信息源層面盡量選擇時(shí)間標(biāo)記清晰的來(lái)源。第三個(gè)坑是推送時(shí)間太晚。我一開(kāi)始把觸發(fā)時(shí)間設(shè)成上午十一點(diǎn)結(jié)果日?qǐng)?bào)到的時(shí)候我已經(jīng)進(jìn)入下一個(gè)工作段落了沒(méi)時(shí)間看。后來(lái)改到十點(diǎn)半剛好卡在節(jié)奏轉(zhuǎn)換的間隙里閱讀率明顯提高。這個(gè)細(xì)節(jié)看起來(lái)小但它決定了這個(gè)自動(dòng)化任務(wù)是被真正使用還是被忽略。6. 后續(xù)可以怎么擴(kuò)展這套流程跑通日?qǐng)?bào)之后我發(fā)現(xiàn)這套“定時(shí)觸發(fā) 內(nèi)容生成 微信推送”的框架其實(shí)可以復(fù)用到很多場(chǎng)景。比如每周一早上生成一份上周項(xiàng)目進(jìn)展匯總或者每天下午生成一份待辦事項(xiàng)提醒甚至可以在特定事件發(fā)生時(shí)觸發(fā)即時(shí)通知。擴(kuò)展的時(shí)候注意一點(diǎn)不要把所有東西都塞進(jìn)一個(gè)任務(wù)里。我見(jiàn)過(guò)有人把日?qǐng)?bào)、周報(bào)、提醒全部放在一個(gè) WorkBuddy 任務(wù)里結(jié)果指令變得極其復(fù)雜維護(hù)起來(lái)很痛苦。正確的做法是一個(gè)任務(wù)只做一件事多個(gè)任務(wù)之間通過(guò)不同的觸發(fā)時(shí)間和推送通道來(lái)區(qū)分。另外一個(gè)擴(kuò)展方向是增加交互能力?，F(xiàn)在的日?qǐng)?bào)是單向推送你只能看不能回復(fù)。如果你用微信小程序做接收端就可以在日?qǐng)?bào)基礎(chǔ)上加一些操作按鈕比如“標(biāo)記已讀”、“收藏這條”、“查看詳情”。這就從“通知”升級(jí)成了“工具”適合對(duì)日?qǐng)?bào)有深度使用需求的人。熱搜詞里還有 workbuddy 怎么生成網(wǎng)站發(fā)布、workbuddy 從入門到精通 pdf 下載這些說(shuō)明大家對(duì) WorkBuddy 的能力邊界很感興趣。我的看法是先把一個(gè)場(chǎng)景跑透比淺嘗輒止地試十個(gè)場(chǎng)景更有價(jià)值。日?qǐng)?bào)這個(gè)場(chǎng)景的好處是它每天都要跑你能快速積累反饋知道哪里需要優(yōu)化。等你把這個(gè)場(chǎng)景打磨到幾乎不需要干預(yù)就能穩(wěn)定運(yùn)行的時(shí)候再去擴(kuò)展其他場(chǎng)景會(huì)順利很多。最后分享一個(gè)我在配置過(guò)程中養(yǎng)成的小習(xí)慣每次修改指令或者調(diào)整參數(shù)之后保留一份修改前的版本。因?yàn)橛袝r(shí)候改完之后發(fā)現(xiàn)效果反而變差了這時(shí)候能快速回滾。我一般會(huì)在指令末尾加一個(gè)版本號(hào)和修改日期方便追溯。這個(gè)習(xí)慣在排查問(wèn)題的時(shí)候特別有用你能清楚地知道是哪次改動(dòng)導(dǎo)致了行為變化。