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