TrendPublish 開源發文系統：AI 幫公眾號寫稿審稿，最後一步留給你

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

GitHub 上有 3,189 顆星的 TrendPublish，定位一句話講完：幫微信公眾號經營者完成「找材料、決定今天寫什麼、寫出來、檢查、送進草稿匣」的開源流水線。MIT 授權、TypeScript 寫成、自架在自己的機器上跑。我把整包原始碼 clone 下來讀完，並在本機用 Deno 2.9.5 實際跑過它的環境體檢、模板預覽和管理介面，想答三個讀者最可能問的問題：它到底是什麼、自己架要付出多少、標榜的自動發文實際能走到哪一步。三個答案裡最反直覺的一個先講：這條流水線的終點，只到微信的草稿匣。

一條會自己審稿的內容生產線

很多人把這類工具想像成「RSS 摘要機器人」，抓幾篇文章、拼一段摘要、排個版就發出去。原始碼裡的設計明顯不止於此。打開主要工作流程的定義檔，一次完整的產文會經過約二十個被逐一記錄的步驟：載入資料來源、抓取、去重，接著把同主題的文章聚成題目群、排序，然後進入編輯決策、補強證據、擬文章計畫，之後才寫內文、下標題、生封面、套模板渲染，收尾是審稿、視需要修訂、送發布。每一步都會留下對應的產物檔案，資料來源、題目報告、文章計畫、審稿分數到最終 HTML 全部存檔，跑完可以逐項調出來看「今天為什麼選這個題、審稿給了幾分、修了什麼」。

Pin

編輯決策和審稿這兩個環節值得單獨講。

編輯決策在動筆之前。系統會讓 AI 扮演主編，先決定今天的主線是什麼、哪些題目該跳過、和近期文章有沒有重複風險，連每個來源該當主證據還是只當參考都會分級。提示詞裡寫得明白：主編的任務不是寫正文，而是解釋今天為什麼寫這個、不寫那些，並把跳過理由一併記錄下來。

審稿在寫完之後。另一份提示詞讓 AI 以品質審稿人的身分打分，分七個維度：事實一致性、標題品質、結構、表達、微信 HTML 相容性、圖片相關性、風險處理。分數機制直接寫進提示詞：90 分以上可發布、60 到 79 分只建議預演或人工確認、未滿 40 分禁止正式發布，出現高風險事實問題時直接擋下。

v2.0.5 之後還有一層帳號級的學習設計。多個公眾號可以組成帳號矩陣，每個帳號維護自己的定位、目標讀者、語氣、標題偏好和來源分組，同一批素材丟進去，不同帳號會生成不同主線、不同形態的稿子。你在管理介面的選題工作台可以對每個候選題目標記鎖主線、採用或跳過，這些取捨連同每次運行的評價會按帳號記進編輯記憶，下一次選題時當成偏好與避坑訊號。作者的更新日誌自述過一次矩陣預演實測：兩個帳號各生成一篇文章，品質分 91 與 92，主線和文章形態確實拉開了差異。這段數字是作者單方宣稱，我沒有花模型金鑰重現，但機制本身在原始碼和資料庫遷移檔裡都對得上。

有個細節我讀到的時候多看了一眼。它的中文寫作指南提示詞裡，明文列了一份禁用句清單，禁止生成內容出現「總體來看」「這意味著」這類 AI 套話，還要求開頭第一段必須先答「這事為什麼現在值得看」，結尾不能寫空泛展望。一個 AI 內容工具，在自己內部先對抗 AI 味，這個自我約束起碼寫進了程式碼，不是行銷頁上的口號。更新日誌裡還留有一條修復紀錄：早期版本的內部編輯欄位（章節目標、待核對要點之類的工作標籤）會洩進最終 HTML，後來專門加了清理邏輯。這些痕跡說明作者真的在對「生成品質」打仗，而不只是把流程串起來。

十五個月斷代：網路上的介紹多數停在舊版本

中文圈流傳的 TrendPublish 介紹，絕大多數寫於 2025 年 3 月初。對照 git 提交歷史，那正是專案的 Node.js 時代：設定靠 .env、資料庫用 MySQL、排程跑 node-cron、摘要模型接訊飛和 DeepSeek。翻那個時期的檔案樹還能看到更有趣的出身：輸出目錄裡留著 aibench 開頭的日報成品，資料來源裡有抓取 LiveBench 榜單的程式碼。這個專案最早是作者為自己的公眾號產 AI 榜單日報的私人工具，範本寫死、來源寫死，後來才慢慢長成可配置的通用系統。讀者若照著舊介紹去找 package.json，現在會撲空。

時間線攤開看是這樣：專案 2025 年 1 月 13 日開張，3 月是開發高峰，單月 113 個提交；緊接著 3 月中旬就開始遷移到 Deno，MySQL 在同一時間退場。然後節奏慢下來，2025 年 6 到 7 月、9 到 11 月兩段長時間沒有提交，2025 年 12 月到 2026 年 4 月之間維持低頻修整。轉折出現在 2026 年 5 月 22 日，這一天加入了 React 管理介面並移除了 package.json，隔天一口氣發布 v2.0.0 平台大改版，之後三天內疊代到 v2.0.4，6 月初再加帳號矩陣與穩定性修復，最終版 v2.0.7 停在 2026 年 6 月 4 日，主分支最後一個提交是 2026 年 6 月 14 日。

現在的 v2 是什麼形態：單一 TypeScript 設定檔同時支撐三種部署（本機、Docker、Cloudflare Workers 加 D1 與 R2），管理介面掛在 /dashboard，可以在網頁上改資料來源、文章方案、帳號定位與排程規則，改完下一次運行就生效，金鑰仍然留在部署環境裡、不進資料庫。排程也不靠寫死的 cron 語法，登入管理介面就能調整觸發時間。有趣的是 GitHub 倉庫的簡介欄到今天還寫著 Node.js，和現實已經脫節。這也是讀舊介紹最容易踩的坑：v1 到 v2 之間隔著十五個月的斷層，功能與架構幾乎是兩個專案，星數卻在斷層期間一路漲到三千以上，說明慢維護不等於沒人用。

免費的只有程式碼：自架成本要分層算

MIT 授權、零使用費，這部分沒有爭議。我在本機實際跑過一輪環境體檢（deno task doctor），它對「你要付出什麼」答得很誠實，缺什麼金鑰會逐項點名，體檢結果就是一張自架成本清單。按功能拆成四層來看。

無金鑰層：clone 下來就能做的驗證。體檢指令會檢查 Deno 版本、專案檔案、部署檔案是否齊全；模板預覽指令（deno task preview）不需要任何金鑰，直接在本地渲染出九套微信排版模板，我在本機跑過這一步：極簡款大留白、只有字級與分隔線在引導視線，適合日更速讀；長文款走雜誌排版，標題字重對比明顯；另有深色研究筆記風、產品更新風等區隔，同一份示範內容換套模板就是完全不同的閱讀節奏。其中 dynamic 模板更激進，讓 AI 依每次文章內容即時生成版面，失敗時自動退用極簡模板。想先看看它的排版長什麼樣，這一層零成本。

Pin

生成層：要真正跑出文章，最少需要一組服務金鑰加一個 OpenAI 相容的大模型端點（baseUrl、apiKey、model 三項）。官方文件建議 DeepSeek 或阿里雲通義；issue 裡有使用者問 Gemini 支不支援，作者答得很清楚：設定結構走 OpenAI 相容格式，任何相容端點都能接，包括 Gemini 的相容模式。我的實測也印證了這層門檻：沒填模型金鑰時服務直接拒絕啟動，錯誤訊息明確列出缺哪三項，不會默默以降級模式跑起來。

配圖層：封面與正文插圖走圖像生成，預設接阿里雲（封面模型 qwen-image-2.0-pro，正文 qwen-image-2.0），也可以換 MiniMax 的 image-01。要圖就要再申請一把對應金鑰。這部分我只確認了配置與程式碼存在，生成品質沒有實測。

發布層：真正把稿子送進微信，需要一個有 API 權限的公眾號（appId 加 appSecret），而且微信官方要求把呼叫端 IP 加進白名單。本機或自有伺服器有固定 IP 就能直連；想用 Cloudflare 免伺服器方案跑的用戶，官方給出的解法是再多部署一台固定 IP 的 relay 轉發器，官方倉庫附了 systemd 安裝腳本。relay 的設計我讀了原始碼：它只做憑證透傳，每個請求臨時帶入該次發布帳號的金鑰、用完即丟，relay 本身不保存任何公眾號金鑰，這個切分對安全性是加分的。

部署形態按省事程度排：最熟悉 Docker 的用官方 GHCR 映像加 docker compose，設定檔和運行產物掛載進容器就好；要長期跑在自有伺服器上，倉庫附了 systemd 服務檔；偏好無伺服器的走 Cloudflare Workflows。不喜歡命令列的，服務起來之後有 JSON-RPC 介面可以手動觸發一次運行，也能接自己的排程系統。運行結束或出錯可以推 Bark、釘釘、飛書通知，掛了會知道，不必自己盯著 log。

隱私面順帶一提：整包原始碼我掃過，沒有任何 GA、Sentry、PostHog 之類的遙測，觀測功能是可選的日誌外送，日誌輸出前還會自動遮蔽金鑰字串，管理介面讀取設定摘要時也只給遮蔽後的版本。自架工具該有的分寸它有。要挑一個小毛病：封面生成失敗時的兜底素材 ID 直接寫死在原始碼裡，那是作者自己帳號的素材，換成你自己的帳號這個兜底是無效的，生圖服務掛掉時要有心理準備。

全自動的神話停在草稿匣前

標題寫「自動發布」，原始碼裡的發布邏輯卻很誠實：所謂發布，呼叫的是微信的草稿建立端點，把標題、摘要、封面和正文送進公眾號的草稿匣，送出後的狀態標記就是 draft。真正推送給訂閱者的群發動作，工具裡沒有對應的 API 呼叫，仍然要在公眾號後台手動完成。這不算缺陷，該說是產品邊界：把最後一步留給人，和它整體的防誤發設計是同一種哲學。

帳號權限的落差更早就能撞上。2026 年 8 月有人在 issue 提問：個人訂閱號呼叫發布類 API 會收到 48001 錯誤，等於 API 未授權。作者兩天後答得直白：支援，但個人號一般就是送到草稿。換句話說，沒有完成認證、沒有 API 權限的帳號，全自動這條路比你想的更早到底。

IP 白名單這關它也做了專門處理，做法有點巧妙：工作流程裡有一個白名單驗證步驟，原理是直接去要一個存取權杖，微信若拒絕會在錯誤訊息裡附上它看到的來源 IP，工具就把這個 IP 解析出來告訴你「該把哪個位址加進後台」，省掉自己查出口 IP 的功夫。這個驗證只在真發布模式執行，預演模式整段跳過。

防誤發的設計倒是做得很扎實，這點值得給分。出廠預設就是預演模式（dry-run），設定解析的原始碼裡寫死「未指定即 true」，預演狀態下會跳過 IP 白名單驗證、不生圖也不上傳，只把渲染好的 HTML 存在本地給你看。要真的送草稿，得明確把 dryRun 關掉；管理介面的觸發任務彈窗也預設勾預演，要真發布必須二次確認並送出 forcePublish 標記。品質閘同樣預設開啟：審稿分數要過 80 分、出現高風險事實問題直接擋；也允許自動修訂，但修訂輪數預設一輪，而且一旦修訂後分數變差或等級下降，系統會自動還原成修訂前的版本，不會越修越糟。這幾個預設值全部能在設定解析的原始碼裡逐行對上，不是文件說說。唯一要留意的取捨：品質閘可以配置成「低分也先進草稿」，追求產量的使用者把它打開後，前面說的防線就只剩你自己把關。

誰該裝來用、誰先繞路

我的判斷分三種人。

已經在經營認證公眾號、每天為選題和排版耗時間的人，這是目前唯一能吃到完整價值的群體。把固定資料來源配好（支援 RSS、Hacker News、arXiv、X，以及 FireCrawl、Jina、Brave、Tavily 等搜尋源，一般網頁 URL 直接貼上就能當來源），讓它每天早上把草稿備好，人工把關後在後台群發，日更的機械勞動確實能省掉大半。來源管理有個值得知道的設計：可以用「分組前綴加 URL」的寫法替不同來源指定抓取策略，例如同一個網址讓 FireCrawl 和 Jina 按順序互為備援，某個抓取服務掛了自動換下一個；Hacker News、arXiv、GDELT 這類來源連金鑰都不用。怕選題重複的，再開向量去重，用 embedding 相似度把寫過的主題壓下去。要同時經營多個號的，帳號矩陣讓每個帳號有自己的定位與語氣，同一批素材產不同主線的稿子，對矩陣化經營是實打實的功能。

想研究「AI 編輯台怎麼設計」的開發者，這個倉庫值得整包讀。它的提示詞目錄就是一套現成的編輯決策、審稿、修訂範本，品質閘、產物快照、步驟時間線的工程化程度，比多數同類開源專案完整；微信排版引擎和微信相容 HTML 清洗這類細活，單獨抽出來用也行。

沒有公眾號的台灣讀者，務實的期待是把它當研究案或實驗台。你可以零金鑰跑體檢和模板預覽，填一組模型金鑰就能用預演模式看它完整生成一篇文章，但要走到發布那一步，卡的是帳號權限而不是工具。若目的是幫內容網站做題目研究和素材調查，站上先前介紹過的本地部署深度研究工具在來源調查那段做得更專；若需求是微信文章的排版與編輯，開源微信 Markdown 編輯器是更輕的選擇；想在微信生態自架服務的人，也可以參考我們實測過的微信群活碼短網址系統。

想親手驗證的，最小路徑三行：clone 倉庫、複製範例設定檔、跑 deno task doctor 看它點名缺什麼。這一步不需要任何金鑰，十分鐘內能判斷自己的環境能不能駕馭它。

授權與現狀最後交代：MIT 授權可商用改作；穩定版 v2.0.7，主分支提交停在 2026 年 6 月 14 日，issue 仍有人提問、作者也還在答，但程式碼面的更新已靜了三個月。它是個能跑、設計誠實、門檻分明的自架系統，只是「全自動發文」這四個字，讀的時候請自動在心裡補上「到草稿匣為止」。