把「不可自动化」的内容平台
做成自动化：一次 13 信源实战复盘

需求长什么样：每天 6 条内容的全自动产线

需求本身并不复杂：运营三个内容账号（AI 科技、足球、茶文化），每个账号每天更新 2 条短视频，从选题到发布全自动。听上去像是一个脚本能解决的事——真正做起来，我们花了相当长的时间在摸通道上，而不是写代码上。

原因是这类需求和常规的数据采集有本质区别。常规采集面向的是「有 API 的系统」，而内容平台的现实是：

• 公众号没有开放「获取某账号最新文章」的接口，外部也没有稳定同步源；
• 视频号没有官方发布 API，后台只能人工操作；
• 大量垂类资讯站是 SPA（前端渲染），直接抓 HTML 拿不到列表。

所以第一步不是设计架构，而是把「哪些路走得通、哪些路走不通」一次性问清楚。这一步的产出直接决定后面所有工作的形态。

第一步不是写代码，是摸通道路

我们按「有鲜度、免登录、可自动化」三条标准，把 13 个点名信源逐个实测，形成一张通道能力矩阵。结论差异极大：

一个反直觉的发现：做得越「像给人看的页面」，反而越好抓。老牌资讯站的列表页结构二十年不变，一次抓 2590 条；而那些做了现代化前端的站点，反而因为前端渲染把数据藏进了接口里。

另一个重要判断是覆盖率可以互相补位。某个信源本身没有可用通道，但它的内容会被另一个平台的当日同步覆盖到——实测中，一个纸媒专栏的全部稿件都在某资讯站当日同步，等于用镜像平台绕过了这个缺口。先做矩阵、再找补位，比逐个硬啃效率高得多。

12 条实测证伪的路线（负结论清单）

下面这份清单，是我们认为这个项目里最值钱的产出。每一条都花了真实时间去验证，每一条都写明了「为什么不行」——它的价值在于，下一个做同类需求的人不用再走一遍。

这份清单带来的最大认知变化是：「抓不到」往往是平台事实，不是技术问题。公众号内容不对外开放索引，属于平台层面的策略，不是写更聪明的爬虫能解决的。承认边界之后，我们才转向了第 4 节的方案。

微信 PC 通道：从「不可读」到全自动

剩下 9 个号只在微信生态内发布，外部无稳定同步源，唯一可行的入口就是本机的微信 PC 客户端。这条路一开始被判为「不可行」，最后却成了整套方案里技术含量最高的一环。

关键发现：主窗口不可读，但内嵌浏览器可读

微信 PC 客户端的主窗口是自绘界面，标准无障碍接口只能读到 17 个节点（基本都是标题栏按钮），无法程序化导航。但我们发现：公众号主页与文章窗口使用的是内嵌浏览器内核，其无障碍树完整可读——能读到公众号名、简介、每篇文章的标题/日期/阅读点赞，以及正文全文。

踩过的坑：内嵌浏览器的无障碍树是异步补全的。首次探测只有骨架（69 个节点），反复读才会增长到 300+ 节点。我们早期一次「主界面不可读」的结论，其实只是探测时把节点数上限设得太小导致的——探测时务必给足节点数与深度。

实现原则：只读 + 默认动作，零注入

整条链路只使用操作系统标准的无障碍接口，不注入进程、不 hook、不修改客户端文件。每个环节的手段和实测结果：

这个方案的关键优势是全程不抢前台、不移动鼠标、不注入进程、不改客户端文件，客户端窗口可以在后台运行——这正是它能无人值守的原因。

几条容易踩空的实现细节

• DPI 感知必须显式声明：开发机缩放 150%，不声明时窗口坐标返回逻辑值，与无障碍接口的物理坐标差 1.5 倍，会导致点击与命中判断全部错位；
• 部分输入必须用真实按键：程序化写入搜索框「能写入也能回读」，但应用层不认（回车无效、界面仍为空），必须走物理按键；
• 搜索结果卡片只有真实鼠标单击有效：程序化触发方式实测三种全部无效；
• 「文章」与「贴图」标签页要兜底：部分账号内嵌页面会停在贴图标签，导致列表读不到图文，需要识别页面类型并切标签（多种方式依次尝试，点不动就静默放弃）。

图文帖与贴图帖的门禁

公众号主页同时存在纯图片帖与图文文章，而只读列表里图片完全不可见，两者在列表层没有差异。我们找到的判定依据是：规范图文帖的正文头部一定有「元信息头」（标题之后依次是原创标记、账号名、发布时间、地区、阅读人数），贴图帖没有。实测命中稳定。命中失败的条目单独归档并带原因标记，便于人工复核，不污染正式结果。

另一个类似的边界处理：「今日无图文」不等于失败。有些账号主页全是赛事海报，有些账号今日确实没更新。如果把这些都当失败，流水线会频繁误报。现在汇总时分三档输出——成功 / 今日无图文 / 失败，退出码只看真失败。

发布层：没有 API 的平台怎么自动发布

采集解决的是「输入」，发布解决的是「输出」。视频号没有官方发布接口，只能走浏览器自动化操作创作者后台。这条路上我们沉淀了十几条必须遵守的规则，挑几条最有代表性的：

• 关键按钮必须用真实鼠标事件：框架的事件处理不认程序化派发的事件，必须走底层输入协议模拟真实按下与释放；
• 发布器页面绝不能刷新：刷新后内嵌页面会挂死白屏，只能从列表页重新进入；
• 文件上传要用「主文档桥接」：跨进程连接方式下，内嵌页面的文件选择调用全部失效，需要在主文档构造输入框、拦截选择事件、用数据传输对象把文件转交给内嵌页面；
• 内嵌页面只有主执行环境可读：隔离环境读不到内嵌文档，表单操作统一走主环境；
• 描述框是富文本而非文本域：赋值要用内容 + 事件触发，才能被框架正确接收；
• 内嵌页面地址会变：上传后地址会切走，定位一律用名称属性，不要按地址匹配。

这些规则单看都很琐碎，但每一条都是实测踩出来的——违反任何一条都会导致静默失败（不报错、但事情没做成），这是自动化项目最耗时间的部分。

内容质量的三道门禁

通道打通只解决了「能采到、能发出」，内容质量还需要门禁来兜。我们设了三道：

一个值得记住的教训：我们曾在「同事件判定」上试图用字面相似度做嫁接，投入大量调参后彻底证伪——正样本（同一事件）与负样本（不同事件）的相似度完全重合，换实体词交集后正样本反而掉到 0。结论是：语义判断是模型的活，不该用启发式硬凑。

这套方法能复用到哪些场景

这套做法的内核不是「视频号自动化」，而是一套面对封闭平台时的通用打法：

• 先摸通道、后写代码：把可用通道与已证伪路线都固化成矩阵文档，避免团队重复试错；
• 把负结论当资产沉淀：失败路线的价值不低于成功路线，尤其是在平台策略会变的环境里；
• 优先走系统标准接口：能用无障碍接口就不注入进程，能用只读就不改文件——稳定性和合规性都更好；
• 给异步的东西留足余量：无障碍树异步补全、页面异步加载，探测时给足节点数与等待时间；
• 边界情况要分档而非二分：「无内容」和「失败」必须区分，否则流水线会被误报淹没。

可迁移的场景包括：竞品内容监控、行业情报订阅、多平台内容分发、企业内部系统的批量操作（很多老系统同样没有 API）、以及任何「人在界面上点，但量太大」的重复性工作。