实战案例内容平台自动化发布系统的构建复盘这篇文章想复盘一次啃硬骨头的实践——给一个没有开放接口的内容平台搭一套自动化发布系统。之所以选这个场景不是因为它炫酷而是因为它足够典型平台没给 API、登录态脆弱、风控敏感、前端结构三天两头变。把这些约束叠在一起正好能逼出一套可复用的无接口时代的执行层方法论。我用第一人称把整个过程捋一遍从动机到方案、从流水线到踩坑希望对同样在做内容运营或封闭后台自动化的同行有点参考价值。一、为什么做这件事内容运营的人力瓶颈故事起点很简单内容团队每天要往平台铺量。选题、写稿、配图、排版、发布、看数据——每一步单看都不难叠起来就是一座搬不完的山。尤其是发布这个动作本身机械、重复、且必须踩着平台规则小心翼翼地做标题多长、正文几段、配几张图、话题怎么挂全有讲究。一个运营同学手动发一篇笔记从打开后台到点发布顺利的话几分钟遇到登录态过期、图片传不上、话题框失焦半小时就搭进去了。更要命的是量。一旦你想把内容生产从几篇扩到几十篇人力就成了天花板。AI 已经能帮你把选题和文案生成出来——这部分是想清楚的活大模型干得很好但做完它——真正打开后台、把内容填进去、把图传上去、把话题挂好、最后发布——这一公里始终卡在人工手里。所以我定了一个目标让 Agent 接管做完这一段。输入是一份结构化的图文内容输出是平台上发布好的笔记中间的浏览器操作、登录态维护、风控规避全部由系统兜住。二、技术方案当界面就是最后的接口第一个要死磕的事实是这个平台没有给创作者开放 API。没有接口意味着你不能用调一个端点、传一个 JSON这种干净利落的方式完成任务。那怎么办界面就是接口。这里要厘清一个常被混淆的分层。模型层负责想清楚——生成文案、解释规则、判断边界但它不直接接管真实业务系统UI 执行层负责做完它——进入系统、完成动作、可接管闭环。一个聊天式 AI不管多聪明它只能停在建议层给你一段标题、一段正文然后你手动复制粘贴到后台。它打不开封闭后台、传不了本地图片、留不住登录态、发不出二维码。这些恰恰是分水岭。让 AI 能进入界面完成动作才真正跨过那道坎。这种让 Agent 使用计算机界面的能力业内叫 CUA拆开是三个能力环观察截图、读 DOM、看页面状态、决策识别下一步做什么、执行点击、输入、上传、切页。只会生成文字Agent 永远停在建议层能操作界面才进入执行层。我把执行层的技术栈搭成了一个四层能力栈按优先级从高到低用API 自动化有官方接口就直接调最稳、最快、可监控。可惜这个场景没有。浏览器 DOM 穿透没有 API 但网页结构可读用浏览器自动化框架操作页面元素。这是本次的主要路径。视觉锚点控制DOM 不稳定或不可读时退而靠截图、OCR、视觉锚点判断位置。兜底用。原生 UI 桥接浏览器之外的桌面软件需要系统权限和本地伴侣应用。这次不涉及。能力栈的设计原则是能用结构化能力就不要退回纯视觉。原因很实际DOM 操作稳定、可验证、能读控件属性视觉操作接近人类观察方式但分辨率、遮挡、主题色、缩放都会影响稳定性。所以这套系统主要走 DOM 加截图留痕不是纯视觉点击。DOM 穿透的底层靠的是 Chrome 开发者工具协议CDP它是一条从脚本到浏览器内核的完整控制通道——通过 WebSocket 连接发送 JSON-RPC 消息覆盖页面结构树、网络请求、控制台、运行时、文件上传控件、设备模拟等多个域。直接写 CDP 调用太繁琐所以我在上面包了一层 Playwright 作为开发者友好的控制层它把复杂的协议调用封装成稳定的、可维护的脚本 API。三、语义锚点让定位不随像素漂移搭完底座最容易被现实毒打的一环是元素定位。一开始我按坐标点击——click(1320, 860)结果分辨率一变、布局一滚、弹窗一弹、缩放一调坐标全废而且你根本解释不清点的到底是哪个元素。后来我换了个思路不记住今天页面长什么样而是描述我要找的业务对象有什么特征。坐标会变但业务对象的语义相对稳定。这个思路叫语义锚点。同样是定位标题输入框与其按坐标不如按业务语义找找 placeholder 是填写标题的那个控件。同一个业务对象我还准备了多个候选定位方式——前端一改版只要其中一个命中就够了。语义优先可读性高、维护成本低CSS 兜底确保至少一种方式能命中。我把定位方式的稳定性排了个序从高到低定位方式稳定性适用场景Placeholder 文本高表单输入框Role 加 Name高标准按钮业务文本中高菜单、标签、按钮CSS 特征中上传控件XPath 层级低临时调试坐标点击最低最后兜底核心观点一句话越接近业务语义稳定性越高越容易维护。把尝试多个候选变成通用能力我写了一个工具函数——按候选顺序逐个尝试第一个命中就返回只返回真正可见的元素避免定位到隐藏节点把所有候选的错误信息都留着哪个断了一眼看出。这一层做扎实了前端改版时维护成本才降得下来。定位之外登录和验证码是另一道现实约束。登录态会过期、二维码有时效、云服务器 IP 可能触发额外验证、偶尔还可能冒出滑块或人机校验。正确的姿势不是绕过——绕过验证码既违规又不稳定——而是把人工接管设计成流程节点检测到未登录就截图、生成交接数据、把二维码图片发到群里、等人扫码、扫完继续。业务自动化要可控不是盲目无人化。四、发布流水线从素材到发布到留痕把上面这些拼成一条完整的发布流水线大致是这么几段素材生成段。内容不是提示词是结构化数据。我把要发布的内容封装成一个可执行的任务对象——标题、正文、话题列表、图片路径、执行模式草稿或正式发布。标题交给运营规则约束二十字以内、核心关键词前置、避开标题党和极限词正文按三百到八百字、分三五个短段组织话题两到五个精准带井号配图一到九张、首图承担点击理由、推荐竖图三比四。这些规则先在校验阶段过一遍失败就拦在浏览器外面不浪费执行开销。部署段。云服务器上没有显示器有头浏览器一启动就报错。这个坑必须先用虚拟帧缓冲器填上——它给云服务器提供一个虚拟显示环境让浏览器以为自己有屏幕一行核心命令把发布脚本包在里面跑就行。部署脚本自动拉仓库、装系统依赖、初始化 Python 环境、装无头浏览器全程不用手动进终端。执行段。这是 Skill 内部真正干活的五道关卡。第一关是图文入口定位——用业务文本找到上传图文的入口避免系统停在视频模式。第二关是本地图片上传——用文件输入控件走浏览器原生的文件通道不模拟拖拽因为拖拽在无头环境下不稳。第三关是标题和正文定位——多候选 selector 加工具函数绑定业务对象而不是 DOM 层级。第四关是内容回读验证——填完不是结束要读回页面状态确认编辑器真正接受了内容因为有些富文本编辑器会把内容吞掉。第五关是提交按钮策略链——四级递进先试组件方法、再 DOM 打分、再可见过滤、最后坐标兜底。每一步都用到了语义锚点和多候选 selector。接管段。登录这一步是设计出来的流程节点不是失败。系统在云端启动浏览器检测到未登录就截出二维码生成一份标准的交接数据文件——这里面有个职责解耦的设计执行器只负责产出结果写交接文件不直接发消息外层的 Agent 负责读取交接文件、取出图片路径、把二维码图片直接发到群里是图片消息不是路径文字也不需要公网链接链路更短、更安全。人扫码之后系统自动继续执行发布流程浏览器 profile 还会把登录态缓存住下次运行可能连扫码都省了。留痕段。每一步操作的日志、最终状态、标准化后的内容 JSON、关键步骤截图、页面 DOM 快照全部落盘归档。让自动化结果可复盘、可审计、可复跑——这点对任何要上生产的系统都是底线要求。整条流水线的核心范式可以浓缩成一句话口述意图 → 生成结构化数据 → 自动执行。不需要手写代码操作页面全程靠对话驱动。五、翻车与修补风控、登录态、元素定位实践过程当然不是一帆风顺。几个印象深的坑和对应解法记录一下。风控检测是最敏感的一环。内容平台对自动化操作有检测一旦行为模式像机器人轻则限流、重则封号。我做了几件事降低风险先校验内容对象再进浏览器内容不合规就拦在外面先跑草稿模式不直接正式发布确认内容填对了再切发布模式图片走原生文件通道不模拟拖拽行为更接近正常用户正文和话题严格按平台规则——不堆话题、不写摘要式正文、不侵权搬运、不站外导流。还有一条课堂红线不拿重要账号做第一次测试先用小号把链路跑通。登录态维护是第二道坎。二维码有时效一分钟一刷新登录态有效期有限但可续期。我一开始把扫码当成失败处理后来想通了——扫码是设计出来的流程节点不是失败。系统检测到未登录就自动截图、生成交接文件、把图发到群里等扫扫完继续。浏览器 profile 把登录态缓存住下次能复用就复用。还有个细节云服务器 IP 有时会被平台当成异地登录触发额外验证这种情况只能靠人工接管消化别想着硬刚。元素定位失败是最高频的故障源。前端一改版selector 就失效。多候选 selector 加错误信息保留这套机制能让定位失败从页面报错一团乱变成哪个候选断了清清楚楚补一个新候选就行。我还遇到过富文本编辑器把正文内容吞掉的情况——填进去页面显示空所以加了内容回读验证这一关填完读回来确认避免发了一篇空文。环境依赖也有几个经典坑仓库拉不下来查服务器网络系统依赖装不上确认 root 权限和系统版本无头浏览器初始化失败多半是缺系统库重跑部署脚本补上没生成二维码先查虚拟显示环境有没有启动扫码后页面无反应多半是登录轮询超时把超时参数调大页面结构变了找不到输入框更新 selector 配置。把常见卡点整理成一张速查表故障来了对照排查比临时拍脑袋快得多现象多半原因处理思路仓库拉取失败服务器网络换源或检查连通性依赖安装失败非 root 或系统版本旧确认权限和版本浏览器初始化失败缺系统库重跑部署脚本补依赖没生成二维码虚拟显示未启动查运行脚本是否启动扫码后无反应登录轮询超时调大超时参数找不到输入框前端改版更新 selector 配置六、效果复盘与迁移思考跑通之后回看效果。从内容生成到草稿落地Agent 在云端自动完成打开后台、切换上传模式、传图、填标题、填正文、挂话题这一串动作停在发布前等人确认。这个链路一旦稳定内容运营的人力瓶颈就被撬开了一个口子——运营同学从搬砖工变成审核员只管选题和最后确认机械动作交给系统。更值钱的是这套架构的可迁移性。这个平台只是验证场景底层架构能平移到任何没有 API 的业务后台内容 JSON 换成报销单、客户资料、工单输入结构化图片上传换成发票、合同、附件文件路径校验与上传标题正文填写换成表单字段填写selector 配置化二维码登录换成 SSO、短信、MFA 的人工接管草稿模式换成提交前预览先填充后确认运行产物换成审批留痕可复盘可审计。这条迁移路径才是我真正想沉淀的东西。方法论可以浓缩成四句话界面是无接口时代的最后接口浏览器自动化是 AI 执行层不是简单脚本稳定穿透依赖语义锚点而不是像素记忆真实平台必须设计人机接管边界。最后说点教训。这套系统能跑但不是无人值守——登录扫码、发布前确认这些节点必须留人。盲目追求全自动在风控和合规面前会翻车。把人工接管设计成可控的流程节点比追求绝对无人化更现实、更安全。另外selector 会随前端改版失效这是无接口方案的宿命多候选加回读验证能把维护成本压到可接受但没法消灭。接受这一点把它写进运维流程比幻想一劳永逸更靠谱。还有一条成本视角的经验这套系统的想清楚部分文案生成、规则判断交给模型层做完部分浏览器操作交给执行层两层职责分清既不浪费模型算力去做它不擅长的 DOM 操作也不让执行层去承担它解释不了的规则判断。模型负责想执行层负责做中间用结构化数据衔接——这个分工原则比任何具体的技术选型都更值得记住。
