寫一篇公眾號文章，真正耗時的往往不只有寫作。

整理資料、修改文字、想標題、製作封面、處理排版、請人審稿，再把內容搬進公眾號後台，每個環節都可能切換一次工具。文章還沒完成，注意力已經消耗在複製、貼上與來回確認。

@canghe 分享的 Codex、Obsidian 與 WeSight 工作流試著把這些環節收進同一個編輯環境。重點不是讓 AI 接管文章，而是讓作者留在熟悉的文字介面，把可重複的加工與發布工作交給 Agent。

本文根據原始分享及 WeSight 開源專案目前的說明，整理這套流程的角色分工、導入方式，以及「本地工作流」仍需注意的資料邊界。

三個工具，各自只做一件事

這套工作流可以拆成三層：

工具角色負責內容
Obsidian內容與狀態層保存 Markdown 文章、素材與長期知識庫
CodexAgent 執行層讀取上下文，協助研究、改稿、標題、摘要、封面方向與其他內容任務
WeSight整合與發布層在 Obsidian 內提供對話、行內修改、排版、分享與平台同步

Obsidian Vault 是整套流程的單一內容來源。文章與參考筆記都保存在本機檔案系統，Agent 不必依賴另一套 CMS 才能讀寫內容。

Codex 負責理解當前文章與相關筆記，再執行具體任務。WeSight 則把 Agent CLI 嵌入 Obsidian 側邊欄，並處理從預覽到發布的介面。官方專案目前支援 Codex、Claude Code 與 OpenCode，但不會代替使用者安裝或更新這些 CLI。

這樣的分工很重要：Obsidian 保存內容，Agent 執行轉換，外掛負責串接。任何一層更換時，Markdown 原稿仍然存在，不需要把核心內容鎖在外掛自己的格式裡。

從初稿到公眾號草稿箱

實際流程可以整理成七個階段：

Obsidian 撰寫初稿
→ Agent 協作修改
→ 產生標題、摘要與封面方向
→ 套用公眾號排版
→ 預覽並邀請審稿
→ 同步到公眾號草稿箱
→ 人工確認後發布

1. 在原稿旁邊與 Agent 協作

作者可以直接在 Obsidian 側邊欄與 Codex 對話，要求它讀取目前文章、引用 Vault 裡的相關筆記，或補強特定段落。

如果只要調整一小段文字，可以選取內容後執行行內修改。WeSight 會先顯示建議版本，使用者確認後才套用，避免一次重寫整篇文章。

2. 把內容加工集中在同一份 Markdown

原始分享把標題、摘要、封面與排版都納入 Agent 任務。Codex 可以根據文章上下文提供標題候選、整理摘要，或透過已設定的圖片能力產生封面方向。

這些輸出不是最終答案。標題會影響點擊，封面會建立讀者預期，內容是否準確仍需要作者決定。AI 的價值在於快速產生可以比較的候選方案，而不是保證「爆款」。

3. 預覽、分享與同步

完成內容後，WeSight 可以預覽公眾號版面，使用預設模板、內建 Skill 主題或自訂樣式。若需要他人審稿，也能將文章發布成保留常見 Markdown 格式的網頁快照，開啟評論後分享連結。

外掛也支援透過 Lark CLI 建立或更新飛書文件。若目標是微信公眾號，則可將當前筆記建立或更新成公眾號草稿；正式發布仍由人進入公眾號後台完成。

這個設計保留了一個必要的人工關卡：Agent 與外掛負責把內容送到草稿箱，人類負責最後確認與發布。

為什麼 Obsidian 不只是編輯器

這套流程真正有價值的地方，不是把聊天視窗搬進側邊欄，而是讓 Vault 成為跨任務存在的內容狀態。

單次聊天適合改寫一段文字，卻很難長期保存作者的歷史文章、常用案例、語氣偏好與領域名詞。當這些資料都以 Markdown 留在 Vault 裡，Agent 可以在需要時按檔案讀取，不必每次重新複製完整背景。

長期累積後，作者得到的不只是更多筆記，而是一套可重複利用的寫作上下文：

  • 過去文章提供語氣與結構參考；
  • 素材筆記保存尚未使用的案例；
  • 領域筆記避免每篇文章重新解釋背景；
  • Markdown 原稿可以用 Git 或其他備份方式保留差異與歷史。

Agent 的每次工作仍是暫時的，但它操作的內容狀態可以持續累積。

「本地優先」的資料邊界

Obsidian Vault 保存在本機，不代表所有處理都只發生在本機。

WeSight 官方文件說明，本地聊天與行內修改會把所選 Agent CLI 當作子程序執行；提示、檔案與模型請求如何傳輸，仍取決於 CLI 及其模型供應商的設定。

使用者主動發布或更新網頁分享、公眾號草稿時，文章文字及支援的本地圖片才會送往 WeSight Cloud。飛書功能則使用另行安裝的 Lark CLI 與飛書連線。

外掛也會在啟動時及每六小時讀取 GitHub Releases 的正式版本資訊，以檢查更新。官方文件表示，這項檢查不會傳送 Vault 內容、帳號資料或裝置識別資訊。換句話說，即使沒有主動發布內容，外掛仍可能產生不含文章內容的背景網路請求。

因此，導入前至少要確認四件事：

  1. Agent 被允許讀取 Vault 的哪些檔案；
  2. 使用哪個模型供應商及其資料政策；
  3. 哪些發布動作會把文章或圖片送到雲端；
  4. 是否有客戶資料、未公開商業資訊或其他不該離開本機的內容。

「本地優先」提供的是可檢查的檔案所有權，不是自動成立的資料隔離。

導入條件與付費邊界

截至 2026 年 8 月 31 日，官方專案要求使用桌面版 Obsidian 1.11.4 以上，並自行安裝至少一種支援的 Agent CLI。WeSight 會偵測既有執行檔，也可以手動指定路徑，但不會替使用者安裝 Agent Runtime。

若要同步微信公眾號，還需要：

  • WeSight 帳號；
  • 具備素材、文章圖片與草稿 API 權限的微信公眾號；
  • 將 WeSight 固定出口 IP 加入公眾號白名單；
  • 在 WeSight Cloud 中設定由服務端加密保存的 AppSecret。

同樣以 2026 年 8 月 31 日的官方文件為準，本地聊天與行內修改不要求 WeSight 帳號；網頁分享與公眾號發布則需要登入，公眾號草稿成功建立或更新後會扣除一點 WeSight 積分。價格、會員方案與贈送額度屬於時間敏感資訊，應以實際產品介面為準。

最小可行的導入順序

不必第一天就串完所有發布平台。比較穩妥的順序是：

  1. 先在測試 Vault 安裝 WeSight，只啟用本地聊天；
  2. 確認 Agent 能讀取正確檔案，並理解修改前的預覽流程；
  3. 用一篇非敏感文章測試排版與網頁分享；
  4. 最後才設定公眾號憑證、IP 白名單與草稿同步。

每一步都能獨立驗證。若本地聊天已經解決主要問題，就不需要為了「完整工作流」提前接上所有雲端服務。

結語：自動化的是搬運，不是作者責任

Codex、Obsidian 與 WeSight 的組合，解決的不是「按一下就生成好文章」，而是把散落在多個工具裡的內容加工與發布步驟串成一條可檢查的管線。

Obsidian 保存原稿與知識，Codex 負責理解和執行，WeSight 提供排版、分享與平台同步。人類則保留最重要的工作：決定文章要說什麼、判斷事實是否成立，以及在送出前完成最後確認。

當 Agent 能在原稿旁邊工作，又不取代人工發布關卡時，它才真正從另一個聊天工具，變成內容流程的一部分。

參考資料