1. 从手动搬运到一次编排多平台发布到底难在哪做内容的人大概都有过这种体验一篇稿子写完了真正的折磨才刚开始。公众号要排版、知乎要调格式、头条要重新传图、B站专栏还得再贴一遍每个平台的编辑器脾气都不一样图片上传逻辑不同代码块渲染规则不同甚至连换行符的处理都能让你抓狂。我最早做多平台分发的时候靠的就是复制—粘贴—微调三件套一篇三千字的文章发五个平台前后要花掉将近一个小时而且每次都会漏掉某个平台的某个细节。WorkBuddy 这个工具进入我视野的契机就是我想把发布这件事从手工劳动变成可编排的流程。它的核心思路并不复杂用一套统一的描述文件来定义内容要发到哪里、以什么形式发、发完之后做什么检查然后由程序去驱动浏览器完成实际的操作。这里的关键词是Chrome DevTools ProtocolCDP也就是通过程序直接和浏览器内核对话而不是靠模拟鼠标点击那种脆弱的方式。为什么这件事值得单独写一篇实战总结因为多平台发布看起来是个体力活但真正做起来你会发现它涉及好几个层面的技术决策怎么和浏览器建立稳定的控制通道、怎么处理不同平台千奇百怪的 DOM 结构、怎么在Shadow DOM这种封闭结构里定位元素、怎么用JSON把整个发布流程描述清楚。这些点单拎出来都不算难但凑在一起就是一堆坑。这篇内容适合两类人看一类是想把重复发布工作自动化的内容创作者另一类是想了解 CDP 实战用法的开发者。我会把整个链路的原理、选型理由、实操步骤和踩坑经验都摊开讲尽量让你看完能直接照着搭一套出来。2. 为什么我最终选了 CDP 而不是模拟点击2.1 模拟点击方案的天花板在哪里在讲 CDP 之前得先说清楚为什么传统的自动化方案不够用。早期我用过基于坐标点击的工具原理很简单记录鼠标位置然后按顺序点过去。这套东西在固定分辨率、固定页面布局下能跑但一旦平台改版、弹窗位置变了、或者页面加载慢了一拍整个流程就崩了。更麻烦的是很多平台的编辑器是动态渲染的你点下去的那一刻元素可能还没挂载到 DOM 上点击就落空了。还有一类方案是基于浏览器扩展注入脚本直接在页面上下文里操作 DOM。这个比坐标点击靠谱得多但它有个硬伤你得为每个平台单独写一套扩展而且扩展的运行环境受浏览器策略限制跨域、权限、更新维护都是问题。我试过用这种方式维护三个平台的发布脚本半年之后代码已经乱得不想看了。2.2 CDP 的本质把浏览器当成一个可编程的服务CDP 的思路完全不同。它把浏览器内核暴露成一套基于 WebSocket 的协议接口你可以发送指令让浏览器打开页面、执行 JavaScript、拦截网络请求、读取 DOM 节点、模拟输入事件。关键在于这些操作都是在协议层面完成的不依赖屏幕坐标也不依赖扩展的沙箱环境。用生活化的类比来说模拟点击像是隔着玻璃用手指戳屏幕你得猜准位置而 CDP 像是直接拿到了浏览器内部的遥控器你想让它干什么发个指令就行。这个差别在稳定性上是数量级的。具体到 WorkBuddy 的场景CDP 带来的好处有三个。第一是元素定位精准可以通过选择器直接拿到节点不用管它在屏幕的哪个位置。第二是能穿透 Shadow DOM这一点后面会详细讲很多现代编辑器的组件都封装在 Shadow DOM 里普通选择器根本够不着。第三是可以监听网络和事件比如等某个保存接口返回成功之后再进入下一步而不是傻等固定秒数。2.3 启动参数里那些容易被忽略的细节用 CDP 驱动浏览器第一步是让浏览器以调试模式启动。这里有个坑我踩过如果你直接用默认配置启动很多浏览器会复用已有的用户数据目录导致调试端口起不来。正确的做法是单独指定一个用户数据目录并且显式打开远程调试端口。# 以调试模式启动浏览器指定独立的数据目录和端口 chrome --remote-debugging-port9222 \ --user-data-dir/tmp/workbuddy-profile \ --no-first-run \ --no-default-browser-check这几个参数各有用途。--remote-debugging-port是核心指定 CDP 监听的端口。--user-data-dir保证每次启动都是干净的环境避免和日常使用的浏览器配置冲突。--no-first-run和--no-default-browser-check是省事的跳过首次运行的引导弹窗否则你的自动化流程第一步就会被一个欢迎使用的页面卡住。提示调试端口不要用默认的 9222 之外还随便暴露到公网本地开发环境用 127.0.0.1 绑定就够了。这一点在多平台发布这种涉及账号登录的场景里尤其重要。启动之后你可以访问http://127.0.0.1:9222/json/version来确认服务是否正常返回的 JSON 里会有webSocketDebuggerUrl这就是后续所有操作的入口。3. 用 JSON 描述发布流程把发文章变成可配置的数据3.1 为什么流程要用 JSON 而不是写死在代码里我见过很多人做自动化习惯把每一步操作硬编码在脚本里。这样写第一版很快但平台一改版你就得改代码、重新测试、重新部署。WorkBuddy 这类工具的价值恰恰在于把流程和执行分离流程用 JSON 描述执行引擎负责解释这份 JSON 并驱动浏览器。JSON 在这里扮演的角色本质上是一份发布配方。它告诉你目标平台是什么、登录状态怎么判断、标题填到哪个选择器、正文粘贴到哪里、图片上传按钮怎么触发、发布成功后用什么标志来确认。这份配方是数据不是代码所以改起来不需要动引擎改完直接跑就行。{ platform: example-blog, steps: [ { action: navigate, url: https://example.com/editor, waitUntil: networkIdle }, { action: input, selector: #title-input, value: {{article.title}} }, { action: pasteHTML, selector: .editor-body, value: {{article.html}} }, { action: click, selector: button.publish, waitFor: .publish-success-toast } ] }这份配置里{{article.title}}这种占位符是模板变量运行时会被真实内容替换。waitUntil和waitFor是等待策略决定了引擎在什么时候认为这一步完成了。这两个字段是稳定性的关键后面会专门讲。3.2 选择器怎么写才不容易失效选择器是 JSON 配置里最容易出问题的部分。我的经验是优先用语义化的属性其次用稳定的结构最后才考虑用文本内容。很多平台的按钮有>{ action: pasteHTML, selector: .editor-body, value: {{article.html}}, transform: [markdownToHTML, uploadImages, rewriteImageSrc] }这样写的好处是流程的每一步在做什么一目了然新人接手也能看懂。比起一坨几百行的脚本这种声明式的配置维护成本低太多了。4. Shadow DOM 这道墙定位不到元素时怎么办4.1 Shadow DOM 为什么会让选择器失灵如果你做多平台发布时遇到明明元素在页面上看得见但document.querySelector就是返回 null那大概率是撞上了 Shadow DOM。Shadow DOM 是 Web Components 的一部分它把组件的内部结构封装起来形成一个独立的 DOM 子树。外部的选择器默认是穿不进去的这是设计上的隔离不是 bug。很多现代编辑器、富文本组件、甚至一些平台的登录框都用 Web Components 实现。你打开开发者工具能看到元素但那是因为 DevTools 会自动展开 shadow root实际在页面上下文里普通选择器是够不着的。4.2 逐层穿透 shadow root 的定位方法要拿到 Shadow DOM 里的元素思路是逐层找到 shadow host然后访问它的shadowRoot再在里面查询。CDP 提供了DOM.getDocument和DOM.querySelector这类接口配合pierce参数可以穿透 shadow root。// 逐层穿透 shadow root 定位元素 function queryShadow(hostSelector, innerSelector) { const host document.querySelector(hostSelector); if (!host || !host.shadowRoot) return null; return host.shadowRoot.querySelector(innerSelector); } // 多层嵌套的情况递归往下找 function deepQuery(selectors) { let root document; for (const sel of selectors) { const el root.querySelector(sel); if (!el) return null; root el.shadowRoot || el; } return root; }在实际配置里我会把这种穿透路径也写进 JSON用数组表示层级。这样引擎就知道该一层层往下钻而不是在顶层瞎找。{ action: input, shadowPath: [rich-editor, toolbar, #title], value: {{article.title}} }4.3 穿透之后还要处理事件冒泡定位到元素只是第一步真正操作它还有坑。Shadow DOM 里的事件冒泡规则和普通 DOM 不一样有些组件监听的是composed事件你直接设置value可能不触发它的内部状态更新。我的经验是对于输入框先 focus再设置值然后手动派发一个input事件最后再派发change事件。这套组合拳能覆盖绝大多数组件。const input deepQuery([rich-editor, #title]); input.focus(); input.value 标题内容; input.dispatchEvent(new Event(input, { bubbles: true, composed: true })); input.dispatchEvent(new Event(change, { bubbles: true, composed: true }));注意composed: true这个参数它决定了事件能否穿过 shadow 边界。漏了这个组件可能收不到事件表现就是值填进去了但保存时是空的。注意不同框架对输入的处理方式不同。React 控制的输入框需要触发原生 setter 才能更新状态Vue 的响应式系统对直接赋值更宽容。遇到填了值不生效的情况优先怀疑是框架的受控组件机制在作怪。5. 等待策略让流程稳下来的真正秘诀5.1 固定 sleep 是万恶之源我早期写的自动化脚本里到处都是sleep(3000)这种代码。它的逻辑是等三秒应该够了吧但现实是网络快的时候浪费两秒网络慢的时候三秒不够直接失败。更糟的是这种脚本在本地跑得好好的换台机器或者换个时段就各种超时。固定等待的根本问题是它假设了一个不存在的确定性。网页加载、接口返回、动画完成这些时间都是波动的。正确的做法是等待一个可观测的条件而不是等待一个固定的时长。5.2 三类可靠的等待信号我在 WorkBuddy 的配置里主要用三类等待信号。第一类是网络空闲通过 CDP 监听网络请求当一段时间内没有新的请求发出时认为页面稳定了。第二类是元素出现或消失比如等发布成功的 toast 弹出来或者等 loading 遮罩消失。第三类是接口响应直接监听某个特定的 XHR 请求等它返回 200 再继续。{ action: click, selector: button.publish, waitFor: [ { type: networkIdle, timeout: 15000 }, { type: elementVisible, selector: .success-toast, timeout: 10000 } ] }多个等待条件可以组合引擎会等所有条件都满足才进入下一步。超时时间要设得合理太短容易误判失败太长会让整个流程变慢。我的经验值是页面导航类操作给 15 秒元素出现类给 10 秒接口响应类给 20 秒。5.3 失败重试与幂等性设计再稳的等待策略也架不住偶发的网络抖动。所以重试机制是必须的。但重试有个前提操作必须是幂等的。也就是说重试一次不会产生副作用。比如点击发布这个操作就不幂等重试可能导致发两篇。而填写标题是幂等的重试无非是再填一遍。我的做法是把流程拆成幂等步骤和非幂等步骤幂等步骤允许自动重试非幂等步骤失败后暂停并报警让人工介入。这样既保证了稳定性又避免了重复发布的尴尬。操作类型是否幂等重试策略导航到页面是自动重试 3 次填写表单字段是自动重试 3 次上传图片是自动重试 2 次点击发布否失败暂停人工确认删除草稿否失败暂停人工确认这张表是我踩过坑之后总结出来的尤其是点击发布那一条我曾经因为自动重试导致同一篇文章发了两遍被读者发现后相当尴尬。6. 多平台适配的实战拆解6.1 平台差异到底体现在哪些维度做多平台发布最耗时的不是写引擎而是摸清每个平台的脾气。我把差异归纳成几个维度登录态维持方式、编辑器类型、图片处理逻辑、发布确认信号、频率限制。登录态这块有的平台用 cookie有的用 localStorage 里的 token有的还有设备指纹校验。CDP 的好处是可以直接读取和注入这些状态但要注意别频繁切换账号容易触发风控。编辑器类型决定了你用什么方式填内容富文本、Markdown、纯 HTML 各有各的填法。图片处理是最烦的有的平台自动抓取外链图片有的必须手动上传。发布确认信号也不统一有的是 toast有的是跳转到文章列表页有的是接口返回特定字段。6.2 用配置继承减少重复如果每个平台都从零写一份 JSON维护起来会疯掉。我的做法是抽出一份基础配置包含所有平台通用的步骤然后每个平台只写差异部分通过继承机制合并。{ extends: base-publish.json, platform: platform-a, overrides: { steps: [ { action: input, selector: #title, value: {{article.title}} }, { action: pasteHTML, selector: .editor, value: {{article.html}} } ] } }这样基础配置里定义的登录检查、错误处理、日志记录都能复用平台配置只关注自己特有的部分。实测下来新增一个平台的配置时间从最初的两小时缩短到了二十分钟左右。6.3 一个真实的适配案例拿我最近适配的一个平台来说它的编辑器是 Web Components 实现的标题输入框藏在两层 shadow root 里正文区是一个 contenteditable 的 div图片上传走的是一个隐藏的 file input。整个适配过程是这样的先用 CDP 的DOM.getDocument配合pierce: true把整棵 DOM 树包括 shadow 部分dump 出来找到各个元素的路径然后写配置标题用 shadowPath 定位正文用pasteHTML直接注入 HTML图片通过 CDP 的DOM.setFileInputFiles接口直接设置文件绕过点击上传按钮那一步。// 通过 CDP 直接给 file input 设置文件跳过点击上传按钮 await client.send(DOM.setFileInputFiles, { files: [/path/to/image.png], nodeId: fileInputNodeId });这个接口特别好用因为它不依赖文件选择对话框直接就把文件塞进去了。很多平台的上传按钮点开是系统文件选择框自动化工具根本没法操作用这个接口就绕过去了。7. 那些文档里不会写的踩坑记录7.1 登录态过期导致的连锁失败最常见的坑是登录态过期。流程跑到一半发现跳到了登录页后面的步骤全部失败。我的解决方案是在流程开头加一个登录态检查步骤访问一个需要登录才能看到的页面检查是否被重定向。如果过期了就暂停流程并通知我手动登录而不是傻乎乎地继续跑。{ action: checkLogin, probeUrl: https://example.com/dashboard, loginIndicator: #user-avatar, onFailure: pauseAndNotify }这里的关键是onFailure的处理策略。我试过自动填充账号密码登录但很多平台有验证码或者二次验证自动登录反而容易触发风控。所以现在的策略是暂停加通知人工处理登录然后流程继续。7.2 内容里的特殊字符引发的解析错误JSON 配置里如果直接嵌入文章内容遇到引号、换行、反斜杠这些字符很容易解析失败。我一开始图省事直接把内容拼进 JSON 字符串结果一篇带代码块的文章直接把配置搞崩了。后来改成用模板变量内容单独存储运行时替换问题就解决了。还有一个隐蔽的坑是 Unicode 字符。有些平台的编辑器对 emoji 或者特殊符号处理有问题粘贴进去会变成乱码。我的做法是在内容预处理阶段做一次字符过滤把平台不支持的字符替换掉或者转义。7.3 并发发布时的资源竞争如果你同时给多个平台发布要注意浏览器实例的资源竞争。多个标签页同时操作CPU 和内存会飙升而且 CDP 的某些接口在并发调用时可能返回错乱的结果。我的做法是串行发布一个平台发完再发下一个虽然慢一点但稳定。如果非要并发至少给每个平台分配独立的浏览器实例别共用。7.4 平台风控的边界这一点必须说清楚自动化发布要控制在合理范围内。频繁、大批量的操作容易触发平台的风控机制轻则限流重则封号。我的原则是模拟正常用户的行为节奏发布间隔不要太短单日发布量控制在合理范围。工具是拿来提效的不是拿来刷量的这个边界心里要有数。8. 从能跑到好用几个提升体验的细节8.1 日志要记到能复现问题的程度自动化流程出问题时最怕的是不知道哪一步挂了。我的日志策略是每一步都记录步骤序号、操作类型、选择器、耗时、结果。失败时还要把当时的页面截图和 DOM 快照存下来。这样排查问题时直接看日志和快照就能定位不用重新跑一遍。{ step: 5, action: click, selector: button.publish, duration: 1230, result: timeout, screenshot: /logs/20260115-step5.png, domSnapshot: /logs/20260115-step5.html }DOM 快照这个特别有用因为页面是动态的等你回头去看的时候可能已经变了。存一份当时的快照相当于给问题现场拍了照。8.2 配置的热更新与版本管理JSON 配置改完之后最好能热更新不用重启整个引擎。我的做法是监听配置文件的变化检测到修改就重新加载。同时给配置加上版本号每次发布记录用了哪个版本出问题可以快速回滚。8.3 一个趁手的小工具选择器验证器写配置最烦的是选择器写错了要跑一遍流程才知道。我单独做了一个小工具输入选择器和 shadowPath它直接在浏览器里高亮对应的元素告诉你找没找到、找到几个。这个工具帮我省了大量的调试时间强烈建议自己也搭一个。// 选择器验证高亮匹配到的元素 async function highlightSelector(client, selector, shadowPath) { const { root } await client.send(DOM.getDocument, { pierce: true }); const { nodeId } await client.send(DOM.querySelector, { nodeId: root.nodeId, selector }); if (nodeId) { await client.send(Overlay.highlightNode, { nodeId }); return true; } return false; }9. 我在这套流程里踩过的三个认知误区第一个误区是越自动化越好。我一开始想把登录、发布、数据统计全部串起来结果流程太长任何一环出问题整个链路就断了。后来我把它拆成了几个独立的模块登录归登录发布归发布统计归统计每个模块可以单独跑也可以组合跑。模块化之后维护成本降了一大截。第二个误区是选择器越精确越好。我曾经用超长的 CSS 选择器链来定位元素精确是精确但平台一改版就全废了。后来我改用语义锚点 相对定位的策略找那些不太可能变的功能性属性容错率高多了。第三个误区是配置写一次就不用管了。平台是会变的今天能跑的配置下个月可能就失效了。所以我现在会定期跑一遍所有平台的配置发现失效的及时修。这个维护成本是必须接受的指望一劳永逸不现实。10. 关于 WorkBuddy 这类工具的一点个人看法用了这么久我最大的体会是这类工具的价值不在于全自动而在于把重复劳动标准化。你不需要追求百分之百无人值守只要能把原来一小时的手工操作压缩到十分钟的检查和确认收益就已经很可观了。另外CDP 这套东西的适用范围远不止发布。任何需要和网页交互的重复工作比如数据采集、表单填写、批量操作都可以用同样的思路来做。JSON 配置 CDP 驱动这个组合本质上是一套通用的网页自动化框架发布只是它的一个应用场景。最后分享一个我自己的习惯每适配一个新平台我都会把调试过程录屏存下来。因为过几个月回头看配置很多当时的决策理由已经忘了有录屏就能快速回忆起来。这个习惯帮我省了不少重新摸索的时间。工具是死的经验是活的把踩过的坑记下来下次就能绕过去。