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