過(guò)去兩周，又是在昏天暗地項(xiàng)目實(shí)施和咨詢中度過(guò)，計(jì)劃發(fā)的文章也略微耽擱了兩篇，后續(xù)補(bǔ)上。

接觸業(yè)務(wù)場(chǎng)景越多，愈發(fā)覺(jué)得應(yīng)該埋頭苦干的同時(shí)，除了日常翻些公眾號(hào)和知乎的水文外，還是應(yīng)該多瀏覽些國(guó)內(nèi)外優(yōu)質(zhì)信息源的不同行業(yè)最佳實(shí)踐。說(shuō)到這里也就要引出“AI 日?qǐng)?bào)”（自動(dòng)化信息/內(nèi)容匯總推送）這個(gè)概念。

雖然市面上有不少“AI 日?qǐng)?bào)”類的信息推送，但實(shí)測(cè)了些發(fā)現(xiàn)，大多還是偏向于泛化內(nèi)容，比如新模型發(fā)布動(dòng)態(tài)、新奇產(chǎn)品和工具推薦，當(dāng)然還有些是什么大廠花邊新聞之類。

So，過(guò)去一周花了些時(shí)間持續(xù)優(yōu)化個(gè)自動(dòng)化 RAG 日?qǐng)?bào)工作流，每天聚合和篩選國(guó)內(nèi)外圍繞 RAG 在不同行業(yè)落地的最佳實(shí)踐、實(shí)用技巧和最新案例。后續(xù)完成進(jìn)一步測(cè)試后，我會(huì)把日?qǐng)?bào)每天更新在知識(shí)星球會(huì)員群中。

這篇試圖說(shuō)清楚，我在開發(fā)這套“RAG 日?qǐng)?bào)”工作流過(guò)程中的思考、工具選擇、踩過(guò)的坑，以及未來(lái)的優(yōu)化計(jì)劃。

以下，enjoy:

1、技術(shù)實(shí)現(xiàn)：為啥選擇 n8n

首先，需要回答的問(wèn)題是，用啥工具來(lái)實(shí)現(xiàn)這個(gè)信息的收集、處理和推送？

1.1工具橫評(píng)

市面上自動(dòng)化工具不少：n8n、Make、Zapier、直接用 Python 腳本，甚至用 Airflow 這類調(diào)度工具，都各有優(yōu)勢(shì)。

我一開始也并不確定哪一個(gè)最適合，于是做了幾輪嘗試后選擇了 n8n。整了個(gè)表格做了些橫向?qū)Ρ龋信d趣的可以瞅一瞅。

看到這里，可能會(huì)有人好奇為啥不直接用 Dify 來(lái)搭這個(gè)流程。這是因?yàn)?Dify 本身定位是 “AI-native app builder”，雖然具備工作流編排、LLM 集成、RAG 配置這些功能，似乎也可以實(shí)現(xiàn)一套“AI 日?qǐng)?bào)”的自動(dòng)化流程。但 Dify 并不具備像 n8n 那樣豐富的 API 節(jié)點(diǎn)（沒(méi)有 RSS、爬蟲、Webhook 等模塊），數(shù)據(jù)源接入需要自建外部 API 或用代碼補(bǔ)齊。

換句話說(shuō)，相比之下，n8n 原生是面向“集成+自動(dòng)化+流程編排”場(chǎng)景，有成熟的節(jié)點(diǎn)庫(kù)支持各種 API、爬蟲、數(shù)據(jù)處理、消息推送，而 Dify 更偏向“AI 應(yīng)用開發(fā)平臺(tái)”。

1.2如何使用

官方網(wǎng)站

官方支持 14 天試用，如果是新手盆友，建議先在官網(wǎng)跟著官方模板測(cè)試幾個(gè)工作流先上手再說(shuō)。這部分不做展開討論，具體看下文的搭建過(guò)程介紹。

本地化部署

n8n 如上所述是個(gè)開源框架，支持本地化部署。部署方式也支持兩種，在安裝 node.js 的前提下使用 npx n8n 命令即可一鍵部署。或者使用 Docker 部署，使用 http://localhost:5678 即可打開。

docker volume create n8n_data
docker run -it --rm --name n8n -p 5678:5678 -v n8n_data:/home/node/.n8n docker.n8n.io/n8nio/n8n

Github 倉(cāng)庫(kù)地址： https://github.com/n8n-io/n8n 

2、信息源的選擇與構(gòu)建

一個(gè)高質(zhì)量、專業(yè)性強(qiáng)的 RAG 日?qǐng)?bào)肯定是要有對(duì)應(yīng)的優(yōu)質(zhì)信源作為支撐，我梳理了以下幾種類型的部分信源供參考：

2.1Blog

Weaviate 博客

深入解析 RAG 架構(gòu)、不同實(shí)現(xiàn)方式（如 HyDE、ReAct）、評(píng)估方法、與向量數(shù)據(jù)庫(kù)的結(jié)合。技術(shù)深度高，有很多關(guān)于向量搜索和 RAG 結(jié)合的實(shí)戰(zhàn)文章。??https://www.google.com/urlsa=E&q=https%3A%2F%2Fweaviate.io%2Fblog 

LlamaIndex 博客

作為領(lǐng)先的 RAG 框架，其博客會(huì)分享關(guān)于數(shù)據(jù)攝取、索引、查詢引擎、評(píng)估 RAG 應(yīng)用等的最新進(jìn)展和最佳實(shí)踐。

??https://www.google.com/url?sa=E&q=https%3A%2F%2Fblog.llamaindex.ai%2F )

Kapa.ai博客

總結(jié)了來(lái)自 OpenAI、LangChain 等團(tuán)隊(duì)的 RAG 實(shí)踐經(jīng)驗(yàn)，提供了數(shù)據(jù)源管理、評(píng)估方法等方面的最佳實(shí)踐，尤其關(guān)注 RAG 在文檔問(wèn)答、代碼問(wèn)答等場(chǎng)景的應(yīng)用。實(shí)測(cè)有很多有價(jià)值的“避坑”指南。

??https://www.google.com/url?sa=E&q=https%3A%2F%2Fkapa.ai%2Fblog )

Cohere 博客

Cohere 提供強(qiáng)大的嵌入模型和重排（Rerank）API，其博客常有關(guān)于提升檢索質(zhì)量、語(yǔ)義表示、多語(yǔ)言 RAG 等方面的文章。關(guān)注提升 RAG 中“R”（Retrieval）環(huán)節(jié)質(zhì)量的前沿技術(shù)和思考。

?? https://www.google.com/url?sa=E&q=https%3A%2F%2Ftxt.cohere.com%2Fblog%2F )

2.2社區(qū)與論壇

Reddit

r/MachineLearning: 定期有關(guān)于 RAG 的討論和最新研究分享。

r/LocalLLaMA: 大量關(guān)于在本地運(yùn)行 LLM 和相關(guān)技術(shù)（包括 RAG）的討論。

r/LangChain & r/LlamaIndex: 針對(duì)這兩個(gè)框架的 RAG 實(shí)踐、問(wèn)題和解決方案。

Hugging Face、GitHub 這些就不多做贅述了。

這里穿插介紹個(gè) The Batch (DeepLearning.AI），Andrew Ng 團(tuán)隊(duì)出品，每周精選 AI 領(lǐng)域的重要新聞和研究，RAG 相關(guān)進(jìn)展常被覆蓋。

??https://www.google.com/url?sa=E&q=https%3A%2F%2Fwww.deeplearning.ai%2Fthe-batch%2F 

2.3播客與訪談

LlamaIndex 播客 (原 The Index by LlamaIndex)

LlamaIndex 團(tuán)隊(duì)成員或行業(yè)專家討論 LLM 應(yīng)用開發(fā)、數(shù)據(jù)框架、RAG 等話題??  https://www.google.com/url?sa=E&q=https%3A%2F%2Fwww.youtube.com%2F%40LlamaIndex )

Latent Space Podcast

由 swyx 和 Alessio 主持，采訪 AI 領(lǐng)域的構(gòu)建者，經(jīng)常深入探討 LLM、向量數(shù)據(jù)庫(kù)、RAG 等技術(shù)細(xì)節(jié)和實(shí)踐。?? https://www.google.com/url?sa=E&q=https%3A%2F%2Fwww.latent.space%2Fpodcast )

3、工作流介紹

注：為了演示方便，信源部分這里只演示通過(guò) NewsAPI.org 的 api 獲取的 RAG 相關(guān)資訊

Schedule Trigger (定時(shí)觸發(fā)器)：

作為工作流的起點(diǎn)，按照預(yù)設(shè)的時(shí)間（每天固定時(shí)間）自動(dòng)觸發(fā)整個(gè)流程的執(zhí)行。

GET_NewsAPI (獲取新聞 API)：

通過(guò) HTTP 請(qǐng)求調(diào)用外部新聞 API（如 NewsAPI.org)，檢索關(guān)鍵詞“Retrieval-Augmented Generation”

（注意不要只使用RAG,實(shí)測(cè)會(huì)搜出一些和rag字面意思破布相關(guān)的內(nèi)容）

獲取API key(每天100次免費(fèi)請(qǐng)求）https://gnews.io/docs/v4#authentication 

news_api_article (數(shù)據(jù)處理/編輯字段 - 手動(dòng))：

對(duì)從 NewsAPI 獲取到的原始數(shù)據(jù)進(jìn)行初步的篩選、格式化或字段提取。只保留新聞部分的文字內(nèi)容。

AI Agent：

核心的內(nèi)容生成與處理單元，接收上一步處理好的新聞數(shù)據(jù)，并利用連接的OpenRouter Chat Model（deepseek-chat-v3-0324:free ）進(jìn)行總結(jié)、提煉、改寫。

注：OpenRouter 中有很多免費(fèi)的 LLM 可供選擇，在測(cè)試階段可考慮使用這個(gè)。不過(guò)經(jīng)過(guò)測(cè)試，一般免費(fèi) LLM 的上下文窗口有限，建議內(nèi)容控制在 2000 字以下。https://openrouter.ai/settings/keys 

Code (代碼處理/數(shù)據(jù)轉(zhuǎn)換)：

在 AI Agent 輸出后，通過(guò)自定義 JavaScript 代碼對(duì)生成的內(nèi)容進(jìn)行進(jìn)一步的格式化、轉(zhuǎn)換或數(shù)據(jù)結(jié)構(gòu)調(diào)整。

HTTP Request (企業(yè)微信機(jī)器人推送)：

將 Code 節(jié)點(diǎn)處理好的日?qǐng)?bào)內(nèi)容，通過(guò) HTTP POST 請(qǐng)求發(fā)送到企業(yè)微信機(jī)器人的 Webhook 地址 (https://qyapi.weixin.qq....)。 

Google Sheets (數(shù)據(jù)備份與中轉(zhuǎn))：

將 Code 節(jié)點(diǎn)處理好的日?qǐng)?bào)內(nèi)容（或其核心部分及元數(shù)據(jù)）追加到指定的 Google Sheets 電子表格中。方便后續(xù)的數(shù)據(jù)分析、內(nèi)容二次加工（如轉(zhuǎn)語(yǔ)音、深度解讀）、以及向個(gè)人網(wǎng)站等其他平臺(tái)發(fā)布。

4、推送機(jī)制的設(shè)計(jì)與優(yōu)化

當(dāng)把日?qǐng)?bào)內(nèi)容生成之后，如何自動(dòng)推送到微信群，是個(gè)很重要的一步。以下介紹我探索過(guò)的三種方法。簡(jiǎn)而言之，微信有點(diǎn)特別，自動(dòng)化發(fā)送是種執(zhí)念，我最后還是權(quán)衡下選擇了人機(jī)結(jié)合的方式。

4.1放棄魔法

首先需要聲明，根據(jù)《微信軟件許可及服務(wù)協(xié)議》的約束，微信官方對(duì)各種形式的外掛明確立場(chǎng)是不支持、不鼓勵(lì)、嚴(yán)厲打擊。我調(diào)研了多個(gè)基于開源項(xiàng)目的解決方案，這類方案的核心思路是模擬微信客戶端的行為，與微信服務(wù)器進(jìn)行通信。從實(shí)現(xiàn)原理上說(shuō)有三種：

iPad/Mac 協(xié)議類 (如 Padlocal 等付費(fèi)方案)：通過(guò)模擬 iPad 或 Mac 微信客戶端的通信協(xié)議，被認(rèn)為是相對(duì)穩(wěn)定的一種方式（尤其在早期）。這類方案通常需要獲取特定的 token 或通過(guò)掃碼登錄。

低版本 Windows/Android 客戶端 Hook 類：通過(guò)逆向工程或 Hook 特定版本的微信客戶端（通常是較舊版本，因?yàn)樾掳姹痉雷o(hù)更嚴(yán)）來(lái)實(shí)現(xiàn)消息收發(fā)。這種方式可能需要特定的運(yùn)行環(huán)境和客戶端版本。

網(wǎng)頁(yè)版微信 API (已失效)：早期很多機(jī)器人基于網(wǎng)頁(yè)版微信，但該接口已被官方關(guān)閉，不再可行。

有一說(shuō)一，我折了個(gè)小號(hào)，不建議再嘗試了。所以，這也說(shuō)明了當(dāng)你去搜公開教程中介紹 AI 日?qǐng)?bào)的，最后都是教你怎么發(fā)到 email、teleragm、飛書、notion 等等。或者教你上述前兩種的，封號(hào)風(fēng)險(xiǎn)了解下。

4.2官方路徑

官方提供的解決方案——企業(yè)微信群機(jī)器人。

企業(yè)微信允許在群聊中添加機(jī)器人，并為每個(gè)機(jī)器人生成一個(gè)唯一的 Webhook 地址。外部應(yīng)用（如 n8n）只需要向這個(gè) Webhook 地址發(fā)送特定格式的 HTTP POST 請(qǐng)求（通常是 Markdown 或文本消息），機(jī)器人就會(huì)將消息內(nèi)容推送到群聊中。

但這里有個(gè) Bug 是，企業(yè)微信機(jī)器人只能將消息發(fā)送到企業(yè)微信內(nèi)部的群聊。如果最終目標(biāo)是個(gè)人微信群，則無(wú)法一步到位。選擇這種方式就意味著，不得不采取“先自動(dòng)推送到企業(yè)微信群，再手動(dòng)復(fù)制粘貼到個(gè)人微信群”的折中方案。

4.3RPA 的強(qiáng)大與笨拙

RPA 提供了強(qiáng)大的界面自動(dòng)化能力，為了克服直接對(duì)接個(gè)人微信的困難和企業(yè)微信的局限，我嘗試了另一種自動(dòng)化思路——使用影刀 RPA 工具來(lái)模擬人工操作。

實(shí)現(xiàn)原理

RPA 通過(guò)識(shí)別桌面應(yīng)用的 UI 元素（窗口、按鈕、輸入框等）并模擬鼠標(biāo)點(diǎn)擊、鍵盤輸入等操作來(lái)完成任務(wù)。LLM 生成日?qǐng)?bào) -> 存入中轉(zhuǎn)站 -> RPA 讀取中轉(zhuǎn)站 -> RPA 打開微信 -> 定位群聊 -> 粘貼/輸入內(nèi)容 -> 發(fā)送。

中轉(zhuǎn)站的選擇

為了讓 RPA 能穩(wěn)定獲取日?qǐng)?bào)內(nèi)容，我把 LLM 的輸出分別保存到以下三個(gè)地方，實(shí)測(cè)都可以，具體用哪個(gè)看個(gè)人喜好：

Notion：優(yōu)點(diǎn)是排版美觀，內(nèi)容組織靈活。缺點(diǎn)是 API 獲取頁(yè)面內(nèi)容（尤其是包含多種塊類型時(shí)）相對(duì)復(fù)雜，解析 JSON 提取純文本步驟較多。

Google Sheets/飛書多維表格：優(yōu)點(diǎn)是結(jié)構(gòu)化數(shù)據(jù)，API 相對(duì)簡(jiǎn)單，易于讀寫特定單元格的純文本。

RPA 模擬輸入的風(fēng)險(xiǎn)

我測(cè)試發(fā)現(xiàn) RPA 在處理長(zhǎng)文本時(shí)，不是直接將內(nèi)容“粘貼”到輸入框，而是像人一樣通過(guò)模擬鍵盤逐字輸入。這種操作不僅帶來(lái)了高耗時(shí)，重點(diǎn)是長(zhǎng)時(shí)間、高頻率的模擬輸入可能被微信客戶端識(shí)別為異常行為，甚至導(dǎo)致客戶端崩潰或退出（不要問(wèn)我是怎么知道的）。搜了下雖然某些 RPA 工具可能提供模擬 Ctrl+C/Ctrl+V 的指令，但猜測(cè)微信可能對(duì)此類操作也有防護(hù)。

4.4最后選擇

經(jīng)過(guò)以上三個(gè)階段的探索和試錯(cuò)，綜合考慮穩(wěn)定性、合規(guī)性、維護(hù)成本和實(shí)現(xiàn)效果，我最終選擇了以下方案作為當(dāng)前 AI 日?qǐng)?bào)發(fā)送的最佳實(shí)踐：

核心發(fā)送渠道：使用企業(yè)微信群機(jī)器人。

n8n 工作流將 AI 生成的日?qǐng)?bào)內(nèi)容格式化后，通過(guò) Webhook 推送到指定的企業(yè)微信群。

手動(dòng)轉(zhuǎn)發(fā)：從企業(yè)微信群手動(dòng)復(fù)制內(nèi)容，再粘貼到個(gè)人微信群。這是當(dāng)前在合規(guī)和觸達(dá)個(gè)人微信之間的一個(gè)平衡點(diǎn)。

數(shù)據(jù)沉淀與二次利用：

在 n8n 工作流的末端，將 AI 日?qǐng)?bào)的核心文本內(nèi)容以及相關(guān)的元數(shù)據(jù)同步保存到 Google Sheets 中，為后續(xù)的深度利用提供基礎(chǔ)（內(nèi)容轉(zhuǎn)語(yǔ)音、LLM 深度解讀、個(gè)人網(wǎng)站發(fā)布等）

5、寫在最后

構(gòu)建一個(gè)自動(dòng)化的 RAG 日?qǐng)?bào)系統(tǒng)本身只是手段，充分實(shí)踐才是真理。但確實(shí)要要警惕“閉門造車”。我計(jì)劃下周開始，陸續(xù)把過(guò)去半年沉淀下來(lái)的一些項(xiàng)目案例進(jìn)行梳理，制作成視頻內(nèi)容，供不同實(shí)踐階段的盆友參考。也歡迎加入付費(fèi)社群獲取更多優(yōu)質(zhì)內(nèi)容。

最后，再說(shuō)個(gè)“過(guò)度工程化”的問(wèn)題，我年初到現(xiàn)在接觸過(guò)的 180 多家企業(yè)里，大部分都對(duì) LLM 本地化部署有些執(zhí)念，尤其是在沒(méi)有足夠多卡的情況下，選擇了一種低配的底座模型。這帶來(lái)的致命問(wèn)題是，當(dāng) RAG 或者其他特定任務(wù)的理解和生成效果不佳時(shí)，會(huì)讓研發(fā)投入過(guò)多的精力去做復(fù)雜的工程化“雕花”和外圍系統(tǒng)優(yōu)化，結(jié)果當(dāng)前是事倍功半。畢竟，工程的價(jià)值在于放大模型的優(yōu)勢(shì)，而非彌補(bǔ)其根本性的不足。