過去兩周，又是在昏天暗地項目實施和咨詢中度過，計劃發的文章也略微耽擱了兩篇，后續補上。

接觸業務場景越多，愈發覺得應該埋頭苦干的同時，除了日常翻些公眾號和知乎的水文外，還是應該多瀏覽些國內外優質信息源的不同行業最佳實踐。說到這里也就要引出“AI 日報”（自動化信息/內容匯總推送）這個概念。

雖然市面上有不少“AI 日報”類的信息推送，但實測了些發現，大多還是偏向于泛化內容，比如新模型發布動態、新奇產品和工具推薦，當然還有些是什么大廠花邊新聞之類。

So，過去一周花了些時間持續優化個自動化 RAG 日報工作流，每天聚合和篩選國內外圍繞 RAG 在不同行業落地的最佳實踐、實用技巧和最新案例。后續完成進一步測試后，我會把日報每天更新在知識星球會員群中。

這篇試圖說清楚，我在開發這套“RAG 日報”工作流過程中的思考、工具選擇、踩過的坑，以及未來的優化計劃。

以下，enjoy:

1、技術實現：為啥選擇 n8n

首先，需要回答的問題是，用啥工具來實現這個信息的收集、處理和推送？

1.1工具橫評

市面上自動化工具不少：n8n、Make、Zapier、直接用 Python 腳本，甚至用 Airflow 這類調度工具，都各有優勢。

我一開始也并不確定哪一個最適合，于是做了幾輪嘗試后選擇了 n8n。整了個表格做了些橫向對比，感興趣的可以瞅一瞅。

看到這里，可能會有人好奇為啥不直接用 Dify 來搭這個流程。這是因為 Dify 本身定位是 “AI-native app builder”，雖然具備工作流編排、LLM 集成、RAG 配置這些功能，似乎也可以實現一套“AI 日報”的自動化流程。但 Dify 并不具備像 n8n 那樣豐富的 API 節點（沒有 RSS、爬蟲、Webhook 等模塊），數據源接入需要自建外部 API 或用代碼補齊。

換句話說，相比之下，n8n 原生是面向“集成+自動化+流程編排”場景，有成熟的節點庫支持各種 API、爬蟲、數據處理、消息推送，而 Dify 更偏向“AI 應用開發平臺”。

1.2如何使用

官方網站

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

本地化部署

n8n 如上所述是個開源框架，支持本地化部署。部署方式也支持兩種，在安裝 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 倉庫地址： https://github.com/n8n-io/n8n 

2、信息源的選擇與構建

一個高質量、專業性強的 RAG 日報肯定是要有對應的優質信源作為支撐，我梳理了以下幾種類型的部分信源供參考：

2.1Blog

Weaviate 博客

深入解析 RAG 架構、不同實現方式（如 HyDE、ReAct）、評估方法、與向量數據庫的結合。技術深度高，有很多關于向量搜索和 RAG 結合的實戰文章。??https://www.google.com/urlsa=E&q=https%3A%2F%2Fweaviate.io%2Fblog 

LlamaIndex 博客

作為領先的 RAG 框架，其博客會分享關于數據攝取、索引、查詢引擎、評估 RAG 應用等的最新進展和最佳實踐。

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

Kapa.ai博客

總結了來自 OpenAI、LangChain 等團隊的 RAG 實踐經驗，提供了數據源管理、評估方法等方面的最佳實踐，尤其關注 RAG 在文檔問答、代碼問答等場景的應用。實測有很多有價值的“避坑”指南。

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

Cohere 博客

Cohere 提供強大的嵌入模型和重排（Rerank）API，其博客常有關于提升檢索質量、語義表示、多語言 RAG 等方面的文章。關注提升 RAG 中“R”（Retrieval）環節質量的前沿技術和思考。

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

2.2社區與論壇

Reddit

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

r/LocalLLaMA: 大量關于在本地運行 LLM 和相關技術（包括 RAG）的討論。

r/LangChain & r/LlamaIndex: 針對這兩個框架的 RAG 實踐、問題和解決方案。

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

這里穿插介紹個 The Batch (DeepLearning.AI），Andrew Ng 團隊出品，每周精選 AI 領域的重要新聞和研究，RAG 相關進展常被覆蓋。

??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 團隊成員或行業專家討論 LLM 應用開發、數據框架、RAG 等話題??  https://www.google.com/url?sa=E&q=https%3A%2F%2Fwww.youtube.com%2F%40LlamaIndex )

Latent Space Podcast

由 swyx 和 Alessio 主持，采訪 AI 領域的構建者，經常深入探討 LLM、向量數據庫、RAG 等技術細節和實踐。?? https://www.google.com/url?sa=E&q=https%3A%2F%2Fwww.latent.space%2Fpodcast )

3、工作流介紹

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

Schedule Trigger (定時觸發器)：

作為工作流的起點，按照預設的時間（每天固定時間）自動觸發整個流程的執行。

GET_NewsAPI (獲取新聞 API)：

通過 HTTP 請求調用外部新聞 API（如 NewsAPI.org)，檢索關鍵詞“Retrieval-Augmented Generation”

（注意不要只使用RAG,實測會搜出一些和rag字面意思破布相關的內容）

獲取API key(每天100次免費請求）https://gnews.io/docs/v4#authentication 

news_api_article (數據處理/編輯字段 - 手動)：

對從 NewsAPI 獲取到的原始數據進行初步的篩選、格式化或字段提取。只保留新聞部分的文字內容。

AI Agent：

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

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

Code (代碼處理/數據轉換)：

在 AI Agent 輸出后，通過自定義 JavaScript 代碼對生成的內容進行進一步的格式化、轉換或數據結構調整。

HTTP Request (企業微信機器人推送)：

將 Code 節點處理好的日報內容，通過 HTTP POST 請求發送到企業微信機器人的 Webhook 地址 (https://qyapi.weixin.qq....)。 

Google Sheets (數據備份與中轉)：

將 Code 節點處理好的日報內容（或其核心部分及元數據）追加到指定的 Google Sheets 電子表格中。方便后續的數據分析、內容二次加工（如轉語音、深度解讀）、以及向個人網站等其他平臺發布。

4、推送機制的設計與優化

當把日報內容生成之后，如何自動推送到微信群，是個很重要的一步。以下介紹我探索過的三種方法。簡而言之，微信有點特別，自動化發送是種執念，我最后還是權衡下選擇了人機結合的方式。

4.1放棄魔法

首先需要聲明，根據《微信軟件許可及服務協議》的約束，微信官方對各種形式的外掛明確立場是不支持、不鼓勵、嚴厲打擊。我調研了多個基于開源項目的解決方案，這類方案的核心思路是模擬微信客戶端的行為，與微信服務器進行通信。從實現原理上說有三種：

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

低版本 Windows/Android 客戶端 Hook 類：通過逆向工程或 Hook 特定版本的微信客戶端（通常是較舊版本，因為新版本防護更嚴）來實現消息收發。這種方式可能需要特定的運行環境和客戶端版本。

網頁版微信 API (已失效)：早期很多機器人基于網頁版微信，但該接口已被官方關閉，不再可行。

有一說一，我折了個小號，不建議再嘗試了。所以，這也說明了當你去搜公開教程中介紹 AI 日報的，最后都是教你怎么發到 email、teleragm、飛書、notion 等等。或者教你上述前兩種的，封號風險了解下。

4.2官方路徑

官方提供的解決方案——企業微信群機器人。

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

但這里有個 Bug 是，企業微信機器人只能將消息發送到企業微信內部的群聊。如果最終目標是個人微信群，則無法一步到位。選擇這種方式就意味著，不得不采取“先自動推送到企業微信群，再手動復制粘貼到個人微信群”的折中方案。

4.3RPA 的強大與笨拙

RPA 提供了強大的界面自動化能力，為了克服直接對接個人微信的困難和企業微信的局限，我嘗試了另一種自動化思路——使用影刀 RPA 工具來模擬人工操作。

實現原理

RPA 通過識別桌面應用的 UI 元素（窗口、按鈕、輸入框等）并模擬鼠標點擊、鍵盤輸入等操作來完成任務。LLM 生成日報 -> 存入中轉站 -> RPA 讀取中轉站 -> RPA 打開微信 -> 定位群聊 -> 粘貼/輸入內容 -> 發送。

中轉站的選擇

為了讓 RPA 能穩定獲取日報內容，我把 LLM 的輸出分別保存到以下三個地方，實測都可以，具體用哪個看個人喜好：

Notion：優點是排版美觀，內容組織靈活。缺點是 API 獲取頁面內容（尤其是包含多種塊類型時）相對復雜，解析 JSON 提取純文本步驟較多。

Google Sheets/飛書多維表格：優點是結構化數據，API 相對簡單，易于讀寫特定單元格的純文本。

RPA 模擬輸入的風險

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

4.4最后選擇

經過以上三個階段的探索和試錯，綜合考慮穩定性、合規性、維護成本和實現效果，我最終選擇了以下方案作為當前 AI 日報發送的最佳實踐：

核心發送渠道：使用企業微信群機器人。

n8n 工作流將 AI 生成的日報內容格式化后，通過 Webhook 推送到指定的企業微信群。

手動轉發：從企業微信群手動復制內容，再粘貼到個人微信群。這是當前在合規和觸達個人微信之間的一個平衡點。

數據沉淀與二次利用：

在 n8n 工作流的末端，將 AI 日報的核心文本內容以及相關的元數據同步保存到 Google Sheets 中，為后續的深度利用提供基礎（內容轉語音、LLM 深度解讀、個人網站發布等）

5、寫在最后

構建一個自動化的 RAG 日報系統本身只是手段，充分實踐才是真理。但確實要要警惕“閉門造車”。我計劃下周開始，陸續把過去半年沉淀下來的一些項目案例進行梳理，制作成視頻內容，供不同實踐階段的盆友參考。也歡迎加入付費社群獲取更多優質內容。

最后，再說個“過度工程化”的問題，我年初到現在接觸過的 180 多家企業里，大部分都對 LLM 本地化部署有些執念，尤其是在沒有足夠多卡的情況下，選擇了一種低配的底座模型。這帶來的致命問題是，當 RAG 或者其他特定任務的理解和生成效果不佳時，會讓研發投入過多的精力去做復雜的工程化“雕花”和外圍系統優化，結果當前是事倍功半。畢竟，工程的價值在于放大模型的優勢，而非彌補其根本性的不足。