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

相關(guān)新聞

從紙質(zhì)家政合同到電子簽,家政公司遠(yuǎn)程簽完服務(wù)協(xié)議

從紙質(zhì)家政合同到電子簽,家政公司遠(yuǎn)程簽完服務(wù)協(xié)議

家政合同為什么總簽得散 家政公司的簽約對(duì)象有兩個(gè):一邊是上門(mén)服務(wù)的阿姨,一邊是雇用服務(wù)的客戶,兩邊都分散在城市各處,簽約時(shí)間還常常湊不到一塊。紙質(zhì)服務(wù)協(xié)議要打印、要見(jiàn)面簽、要回收歸檔,遇上阿姨剛培訓(xùn)完就要上戶…

2026/7/29 21:18:46 閱讀更多
中小型加工廠管理系統(tǒng)軟件開(kāi)發(fā)

中小型加工廠管理系統(tǒng)軟件開(kāi)發(fā)

中小型加工廠管理系統(tǒng)軟件開(kāi)發(fā)的關(guān)鍵要點(diǎn)編輯:araolin(私域邦網(wǎng)絡(luò)土土哥)開(kāi)發(fā)中小型加工廠管理系統(tǒng)需要結(jié)合生產(chǎn)流程、庫(kù)存管理、訂單跟蹤等核心需求。以下為關(guān)鍵開(kāi)發(fā)方向:系統(tǒng)功能模塊設(shè)計(jì)生產(chǎn)管理模塊實(shí)現(xiàn)工單創(chuàng)建、任務(wù)分配、進(jìn)…

2026/7/29 22:29:46 閱讀更多
norns開(kāi)發(fā)者手冊(cè):貢獻(xiàn)代碼、修復(fù)bug與構(gòu)建自定義DSP模塊

norns開(kāi)發(fā)者手冊(cè):貢獻(xiàn)代碼、修復(fù)bug與構(gòu)建自定義DSP模塊

norns開(kāi)發(fā)者手冊(cè):貢獻(xiàn)代碼、修復(fù)bug與構(gòu)建自定義DSP模塊 【免費(fèi)下載鏈接】norns norns is many sound instruments. 項(xiàng)目地址: https://gitcode.com/gh_mirrors/no/norns norns是一個(gè)功能強(qiáng)大的開(kāi)源聲音合成平臺(tái),允許開(kāi)發(fā)者通過(guò)貢獻(xiàn)代碼、修復(fù)bug…

2026/7/29 22:29:46 閱讀更多
面試官大笑:“一個(gè)任務(wù)拆給 5 個(gè) Subagent 并行跑,不比 1 個(gè)快 5 倍?“我搖頭:“快不了,還可能更慢“

面試官大笑:“一個(gè)任務(wù)拆給 5 個(gè) Subagent 并行跑,不比 1 個(gè)快 5 倍?“我搖頭:“快不了,還可能更慢“

前兩個(gè)月,我在重構(gòu) AlgoMooc 網(wǎng)站過(guò)程中,發(fā)現(xiàn)一個(gè)問(wèn)題:在 Claude Code 里把一個(gè)任務(wù)拆給 5 個(gè) Subagent 并行跑,結(jié)果可能比 1 個(gè) agent 從頭干到尾還慢? 大多數(shù)人的第一反應(yīng)是反過(guò)來(lái)的:活是并行干的&#…

2026/7/29 0:15:24 閱讀更多
# 鴻蒙 HarmonyOS 應(yīng)用開(kāi)發(fā)實(shí)戰(zhàn)(第25期)|骰子(Dice Roller)— Unicode 符號(hào)與動(dòng)畫(huà)渲染精講

# 鴻蒙 HarmonyOS 應(yīng)用開(kāi)發(fā)實(shí)戰(zhàn)(第25期)|骰子(Dice Roller)— Unicode 符號(hào)與動(dòng)畫(huà)渲染精講

一、應(yīng)用概述 骰子(Dice Roller) 是一款經(jīng)典的休閑娛樂(lè)應(yīng)用,模擬了真實(shí)擲骰子的過(guò)程。應(yīng)用投擲兩個(gè)骰子(六面標(biāo)準(zhǔn)骰),使用 Unicode 骰面符號(hào)直觀展示每個(gè)骰子的點(diǎn)數(shù),并伴有快速滾動(dòng)的動(dòng)畫(huà)效果?!?/p>

2026/7/29 0:15:24 閱讀更多