Obsidian Claude Code 搭自動化發布客戶端Playwright × 掘金/知乎/CSDN 的全鏈路踩坑實錄AI工具人PM 的實戰筆記前幾篇講了掘金、知乎各自的自動化踩坑。這三篇合起來——我用 Obsidian Playwright Claude Code Electron從源碼文件到三個平臺一鍵發布搭了一整套系統。這不是教程是我的真實踩坑記錄。起因三個平臺的編輯器讓我瘋掉了掘金是 CKEditor直接往 DOM 里注入 HTML知乎是 Draft.js基于 React 的富文本編輯器數據存在 Immutable.js 結構里DOM 上看不到正文內容CSDN 又是另一套編輯模式。每次手動發一篇文章要開三個瀏覽器窗口切換七八次——標題復制一次內容復制三次格式還不完全一樣標簽一個個手選。如果一天發一篇一個月就是三十次這樣的循環。但真正要命的是手動發的時候你不知道失敗原因是什么。頁面卡了Cookie 過期了網絡超時了你只能盯著轉圈的那個按鈕不知道問題出在哪。自動化是出路。但問題在于怎么確保你的自動化真的跑通了架構Obsidian 寫 → Python 發 → Electron 看┌─────────────────────────────────────────────────┐ │ Obsidian (Markdown 源文件) │ │ └── 待發布/ ← frontmatter: title, url, status │ │ └── 已發布/ ← 各平臺歸檔 │ ├─────────────────────────────────────────────────┤ │ Python 后端 (vault-scripts/) │ │ ├── daily_publish.py ← 調度 CLI 入口 │ │ ├── juejin.py ← 掘金 Playwright 引擎 │ │ ├── zhihu.py ← 知乎 Playwright 引擎 │ │ └── csdn.py ← CSDN Playwright 引擎 │ ├─────────────────────────────────────────────────┤ │ Electron 客戶端 (pubhub) │ │ ├── main.js ← 主進程 IPC handler │ │ ├── preload.js ← 安全橋接 │ │ ├── renderer/ ← Vue.js 前端 │ │ │ ├── index.html ← 表格列表 詳情彈窗 │ │ │ ├── app.js ← 發布狀態管理 │ │ │ └── style.css ← 暗色側邊欄 進度面板 │ │ └── data/ ← article_cache.json │ └─────────────────────────────────────────────────┘核心設計原則 -Obsidian 是唯一的源。不用維護多份內容frontmatter 字段統一管理 URL 和狀態 -Python 負責重活。Playwright 控制 Chromium模擬人在瀏覽器里的每一步操作 -Electron 提供反饋。CLI 腳本跑完后你知道發了嗎——前端可視化看到每個平臺的具體狀態IPC主進程和渲染進程的對話Electron 的安全模型規定渲染進程不能直接調用 Node API。所以需要一個中間層// preload.js — 安全的橋接 contextBridge.exposeInMainWorld(electronAPI, { scanArticles: () ipcRenderer.invoke(scan-articles), publishArticle: (title, platform) ipcRenderer.invoke(publish-article, title, platform) }); // main.js — 實際執行 ipcMain.handle(publish-article, async (event, articleTitle, platform) { const pythonScript path.join(obsidianRoot, vault-scripts/daily_publish.py); execFile(python, [pythonScript, --once, --title, articleTitle, --platform, platform], ...); // stdout/stderr 解析為 JSON 返回給前端 });關鍵點 -nodeIntegration: falsecontextIsolation: true— 渲染進程沙箱化 ---title--platform— 精準路由到目標文章和目標平臺不走全量隊列 - 正則解析 stdout — Python 輸出終端日志 → 前端能解析每個平臺的狀態坑一logger is not definedCSDN 發布腳本的某一行用了logger.log(25, ...)打了一條 debug 日志但文件頭部沒 import logging。結果整篇文章的發布流程中斷stderr 被吞掉前端收到的錯誤信息是空白。修復方式就是在文件開頭加上import logging logger logging.getLogger(csdn_publisher)這個小 bug 卡了我一個小時——因為錯誤不在 daily_publish.py不在 main.js而在 csdn.py 內部。調試的時候需要一層層追 traceback?？佣laywright inner_text(timeoutN) 新版已廢棄舊代碼里寫了opt.inner_text(timeout100).strip()。在 Playwright 1.40 版本中inner_text()不再接受 timeout 參數——這個參數在更早的版本已經移除了只是之前的版本沒有報錯。去掉 timeout 參數后所有平臺的自動化才真正跑通。這提醒我們自動化腳本的生命周期比你想的長依賴庫更新時它也會跟著變老?？尤龜祿ブ睾喜⑼粋€文章可能同時出現在待發布/和已發布/比如剛發布還沒從待發布目錄移走。掃描時需要按標題 key 去重并合并平臺信息pending: [{zhihu: success}, {juejin: pending}] archive/csdn/: [{csdn: success}] 合并后: [{zhihu: success}, {juejin: pending}, {csdn: success}]如果不去重同一篇文章會在緩存里出現兩條記錄前端顯示的統計數據就會翻倍?？铀奈募h除順序最危險的一步發布成功后要刪除待發布目錄中的原文件。但如果刪除過早比如先刪源文件再歸檔一旦歸檔步驟失敗文章就永久丟失了。正確的順序 1. 更新 frontmatter寫入各平臺 URL 2. 拷貝到已發布目錄備份 3. 確認拷貝成功 4. 才刪除待發布目錄中的文件效果對比維度手動客戶端單篇文章發布~15 分鐘三平臺來回切換~10 秒自動完成狀態追蹤打開三個網站逐個確認一行表格一目了然失敗排查不確定哪個環節出問題逐平臺顯示具體錯誤原因重試操作從頭再來一遍失敗按鈕可直接點重試歷史記錄沒有每篇文章的前后狀態可追溯總結為什么一定要做這個客戶端手動自動化都好用但自動化的價值不在于快而在于可見。一個 Python 腳本就能搞定批量發布——我早就有了。但它的問題是腳本跑完后你不知道結果。stdout 是文本你需要 grep 才能看懂。加了一個 Electron 客戶端把每個平臺的發布狀態、URL、時間戳、錯誤信息全部可視化呈現出來。這才是完整的閉環寫 → 自動化發 → 看到結果 → 有問題可以重試 → 下次不再踩同樣的坑這個流程不是省了多少分鐘的問題而是讓整個發布過程變成了可觀測、可控制的系統。對產品經理來說這是一個把模糊過程變成清晰數據的典型案例——不是所有的東西都需要 GUI但當你能看到每個環節的真實狀態時決策的質量會顯著提升。