微信公众号的更新频率我相信做过的人都懂选题、写稿、配图、排版、预览、改错别字、再预览、定时群发。一套流程走下来哪怕文章本身已经写好从编辑后台到正式发布之间至少还要耗掉半小时。如果内容源多、账号不止一个这个工作量还要成倍往上翻。我大概在半年前开始用 WorkBuddy 把整条链路串成自动化流水线现在两个账号的日常更新基本稳定在每天半小时以内。这篇就把整套搭建过程、配置细节和踩过的坑完整记录下来给同样被公众号更新频率折磨的人一个可以抄的作业。先说结论WorkBuddy 适合做的不是完全无人值守而是把采集、加工、排版、检查这些重复环节交给自动化把最需要判断力的审核环节留给人来做。整套流水线跑通之后我从写文章 2 小时 发布操作 30 分钟变成了写文章 2 小时 点一次确认发布。下面从选型逻辑开始讲。1. 公众号发布这件事到底哪些环节值得自动化1.1 被忽略的隐性成本很多人只算写一篇公众号文章的时间不算发布环节的时间。实际上一次常规发布要经过以下几步登录后台、新建图文、粘贴正文、逐张上传图片、调整格式、设置封面、填写摘要、预览到手机、反复修改、最后定时群发。就算完全不卡壳15 到 20 分钟是跑不掉的。如果账号的内容有固定来源比如你每天要转载团队内部的几篇技术周报或者你要把某个知识库里的内容整理后分发这个成本就要乘以账号数和文章数。我当时的痛点是一个技术号每天要发一篇原创一个行业资讯号每周要发三次转载加评论。转载类内容的排版和发布流程高度重复但每篇的标题、摘要、正文微调又需要人工过目。这种场景天然适合自动化——重复的部分交给工具判断的部分留给人。1.2 为什么选 WorkBuddy 而不是自研脚本可能有人会说这不就是一个爬虫加 API 调用的活吗自己写 Python 脚本也能做。我之前确实写过一版用 requests 调公众号接口配合 APScheduler 定时跑。能跑但维护成本很高token 过期要处理图片要单独传素材库排版规则稍微一变脚本就要改而且换个人接手基本看不懂。WorkBuddy 这类 AI 工作台工具的思路不一样。它对使用者的要求不是写代码而是编排流程你定义采集哪个源、送到哪里加工、加工完由谁确认、确认后调用哪个动作WorkBuddy 负责把节点串起来并执行。概念上类似于把 Zapier、n8n 和 AI Agent 的能力集中到一块但它对中文内容、本地文件、公众号生态的适配比通用型工具好很多比如内置了公众号图文接口的 skill可以直接操作草稿箱。另外选中它还有一个现实原因公众号的接口权限和调用方式比较特殊自己从零实现一遍要踩不少隐蔽的坑。WorkBuddy 把公众号相关能力做成了封装好的 skill我只需要填 AppID、AppSecret 和必要的参数不用关心签名算法和消息加解密这些底层细节。对于以内容运营为主业、不想投入太多时间维护代码的场景这是更划算的方案。1.3 一个关键判断全自动还是半自动刚开始我设想的流水线是全自动的文章生成、审核、发布都由系统完成。真跑起来才发现至少在内容型公众号这个场景全自动是个伪需求。原因有三第一公众号的违规风险是实打实的内容一旦涉及敏感词、违规广告或抄袭判定轻则删文重则限流封号这个风险不值得为省几分钟人工时间去冒第二AI 生成内容目前还不能做到完全符合每个号的语气和立场尤其是标题和摘要这种直接影响打开率的部分机器的判断经常和人的预期有偏差第三微信官方对接口发文是有风控的频繁用 API 群发而不经过后台人工确认账号权重容易受影响。所以我的方案是自动化处理 人工确认的混合流水线所有采集、清洗、排版、图片处理、草稿生成都由 WorkBuddy 完成最后一步推送前在手机或电脑上人工确认。这一改动让整个系统的实用度大幅提升也避免了很多潜在风险。2. 流水线总体架构从信息源到公众号草稿箱2.1 链路拆解我搭的这套流水线处理的是两个场景原创文章由我写好初稿后进入排版发布流程和转载文章从 RSS 源、合作站点抓取后做洗稿式整理。统一抽象成以下数据流信息采集定时检查各内容源RSS、网页、指定的公众号文章链接提取正文、标题、作者、发布时间、封面图。内容加工把抓取到的正文交给 WorkBuddy 的大模型节点按目标账号的风格要求重写或摘要生成标题候选和摘要文案。排版与素材处理将 Markdown 正文转成公众号排版图片批量上传至公众号素材库替换正文中的外链图片地址。人工审核WorkBuddy 把成稿写入公众号草稿箱并通过 IM 通知我我在手机上预览确认或直接在后台修改。发布调度确认后的草稿按预定时段发布。WorkBuddy 可以配置每日几点检查草稿箱待发布项并执行群发。这里面第 2 步和第 3 步是 WorkBuddy 最有价值的环节。如果没有 AI 加工自动化就只是机械搬运如果没有排版图片自动化人工仍然要花大量时间在美化上。两者结合后人要做的只剩第 4 步的判断。2.2 节点模型把流程画成有向图WorkBuddy 的编排方式和我之前用过的自动化工具不太一样。它不是简单的if this then that而是一个节点式的流程引擎每个节点可以是一个 skill、一个 prompt 模板、一个 HTTP 请求或一个条件判断。我的流水线在 WorkBuddy 里对应如下节点链触发器节点时间触发器每日 09:00 和 14:00 各触发一次。采集节点调用我自定义的 RSS 采集 skill将抓取结果输出为结构化 JSON。加工节点读取 JSON逐个送入大模型节点处理prompt 模板里写清楚目标账号的调性、禁用词、字数范围。图片处理节点调公众号素材库上传接口返回永久 URL。排版节点把 Markdown 渲染为公众号正文格式并替换图片 URL。草稿节点调用公众号新建草稿接口把排版结果写入草稿箱。通知节点通过微信或邮件通知我草稿已就绪请确认。发布节点定时检查草稿箱对标记为已确认的草稿执行群发。这个模型的好处是你可以只跑其中任意一段。比如某天选题不满意直接把采集和加工节点禁用只保留手写文章后的排版发布链路。不同节点的异常也不会互相影响哪个环节挂了重跑哪个就行。2.3 素材库方案的取舍做公众号自动化绕不开图片问题。很多人踩的第一个坑就是从网页直接抓来的图片地址无法在公众号正文中显示。公众号后台的图文编辑器只信任两类图片一类是上传到公众号素材库的图片另一类是通过 https 外链且域名在微信白名单内的图片。WorkBuddy 的图片处理节点内置了下载到本地-转存素材库-替换 URL的完整动作。实测下来这一步是跑通流水线的关键前提。如果你在编排时跳过了素材库转存直接把外站图片 URL 塞进正文最终预览时大概率会遇到图片无法显示或非微信域名限制的问题。3. 搭建前的准备工作账号权限与关键词门槛3.1 公众号侧需要什么先明确一点不是所有公众号都能走 API 发布。个人订阅号里只有已认证的账号才开放图文发布相关接口未认证的订阅号只能通过公众平台网页端手动操作。我用来跑流水线的两个号都是已认证的订阅号如果你手头是未认证的个人号建议先去完成认证流程否则下面的步骤都无从谈起。另外在设置与开发-基本配置里需要记录以下信息AppID接口调用的应用标识。AppSecret生成 access_token 用的密钥仅展示一次务必保存好。IP 白名单调用接口时服务器出口 IP 必须在此白名单内。我改过一次服务器 IP忘记更新白名单导致接口一直报错排查半天才发现是这个原因。服务器出口 IP 这个问题值得单独说。很多人拿本地开发环境去调接口本地 IP 随时变化今天能调通明天就报 40163 之类的错误。我的做法是把流水线部署在固定出口 IP 的云服务器上第一次配置时就把 IP 加进白名单。3.2 WorkBuddy 侧需要什么我用的是 WorkBuddy 的桌面版加远程执行模式流程在本地编辑跑定时任务时由服务器上的执行器接管。安装和账号体系这里不展开网上有大量教程关键是以下几个配置项公众号接入 skill在 WorkBuddy 的技能市场安装公众号相关 skill填好 AppID 和 AppSecret。官方 skill 默认支持草稿箱、素材库、群发接口基本覆盖流水线所需。大模型节点配置可以选 WorkBuddy 内置的模型也可以用自定义模型。我用的内置模型因为流程里涉及到大量中文排版处理内置模型对中文标点和段落转换的处理更省心。缓存目录设置这个默认值在系统盘跑了几周后缓存文件把磁盘占满了。建议一开始就改到数据盘或独立目录后面踩坑记录里会细说。3.3 关于自定义关键词过滤公众号分发机制里标题和摘要直接影响推荐量。WorkBuddy 的内容加工节点里可以配置关键词策略我维护了一个自定义词表分成两类一类是内容正向词命中后标题权重可以提高一类是风险词命中后整篇自动转人工不进入自动发布链路。这个过滤不是可选项。公众号对内容合规要求非常高哪怕你的账号本身没问题转载内容的原始出处里可能出现违规表述。机器不会自动识别哪些是引用、哪些是立场表达所以我的策略是宁严勿松凡是词表命中的内容一律人工再审一遍。4. 完整搭建步骤五个核心节点的配置实录4.1 采集节点适配 RSS 与公众号链接我的内容源有两类配置方式不同。RSS 源最简单在采集节点填上 feed 地址设置轮询周期和抓取条数即可。WorkBuddy 会解析出标题、正文、作者、发布时间和封面图。需要注意 RSS 返回的正文经常带有大量标签和无关模块比如相关文章推荐、版权声明需要在采集节点后接一个内容清洗步骤。公众号链接的采集稍微麻烦一点。直接抓链接往往只能拿到标题和部分摘要正文需要携带 Cookie 才能完整抓取。WorkBuddy 的浏览器自动化 skill 可以打开链接、滚动页面、提取正文并过滤广告模块。我这里补充一句只采集你自己有权限或已获授权的内容公众号文章版权归属复杂转载前务必确认授权链条别让自动化流水线变成侵权生产线。清洗规则我建议在 WorkBuddy 的可视化表达式里做删除所有script、style标签过滤与正文无关的固定段落比如点击上方蓝字关注图片标签统一转成 Markdown 格式识别正文中的首个标题作为候选标题。4.2 加工节点让 AI 按账号调性改写这一节点是整条流水线的灵魂。我配置了三种 prompt 模板分别对应原创文章校对、转载文章改写、短资讯摘要三种场景。核心模板大致如下你是【账号名称】的资深编辑。请完成以下任务 1. 将输入的新闻/文章改写为符合本账号调性的中文内容 2. 语气要求专业、克制、不夸张不使用震惊体 3. 禁止出现绝对化用语如最第一唯一、广告法违禁词 4. 标题要求给出 3 个候选每个不超过 30 字必须包含核心关键词 5. 摘要要求不超过 80 字概括核心信息点 6. 输出格式标题候选列表 正文 Markdown 摘要。这里我要特别提醒AI 味的问题。微信公众号的读者对AI 生成感非常敏感典型的 AI 味包括每段开头都用首先/其次/最后、过度使用值得注意的是、结尾喜欢说总而言之/相信通过本文等等。WorkBuddy 的大模型节点支持在 prompt 后追加负面提示词我把这些表达列入禁止出现清单效果立竿见影。如果你发现文章还是有点生硬可以再加一条规则强制使用短句每段不超过四行。4.3 排版与图片处理节点解决外链图片失效排版是公众号自动化最容易翻车的地方。真不是把 Markdown 转成 HTML 就完事微信公众号的编辑器对样式支持很有限外置 CSS 基本不支持只认内联样式。我的做法是让 WorkBuddy 生成带基础内联样式的 HTML正文段落 16px、行间距 1.75、段间距 12px、引用块用左侧灰线样式。这套样式普适性很强即使后台编辑器再渲染一次也不会乱。图片处理是流水线里最需要关注的一环。我的配置顺序是下载正文中的所有外部图片到本地临时目录逐张调用素材库上传接口获取永久图片 URL用永久 URL 替换正文中的临时地址选定封面图上传并记录 media_id。这里有个细节如果原文章的图片本身就是微信公众号素材库的地址理论上可以直接引用但我还是统一走一遍转存流程。原因有两个一是防止原账号删除或迁移导致图片挂掉二是通过自己的素材库还可以做后续的图片数据分析。4.4 人工审核节点自动化的边界我在流水线里专门留了一个人工审核节点它不是一个技术节点而是一个流程闸门。WorkBuddy 完成排版和草稿写入后会通过企业微信机器人给我推一条消息内容包含标题、摘要、草稿链接和确认发布按钮。我在手机上打开草稿链接预览排版确认正文图片正常、标题无敏感词后点一下确认。这个动作会回调一个确认接口WorkBuddy 收到确认后给草稿打上已确认标签。到了设定的发布窗口发布节点就会去草稿箱里找带此标签的草稿并执行群发。为什么不用 WorkBuddy 直接调群发接口除了前面说的内容风险外还有一个现实问题群发接口一旦调用不可撤回如果某天关键词策略漏掉了违规词、或者 AI 改写产生语义偏差发出后的成本极高。人工确认这个动作花费不到一分钟但给整条流水线增加了最关键的保险丝。4.5 发布节点定时与防抖发布节点解决的是什么时候发的问题。我配置了两个发布窗口早报类内容 08:30晚间内容 18:00。WorkBuddy 的定时触发器在发布窗口前 20 分钟检查一次草稿箱找到待发布草稿后先做一次发布前检查确认标题非空、正文长度大于 300 字、封面图已设置、无未替换的图片占位符。发布完成后还有一个收尾动作将发布结果回写进内容台账这样每月统计发文数量和阅读数据时不需要人工翻后台。WorkBuddy 的表格 skill 可以自动把发布记录同步到飞书多维表格我的月报就是这么自动生成的。5. 踩坑记录六个关键问题与完整排查链路这部分是全文最容易让后来者受益的内容。我在搭建和运行过程中遇到过不止一次深夜排障的情况下面按踩坑顺序记录。5.1 坑一图片全部裂开排查了两小时现象草稿生成后在手机预览时正文里的图片全部无法显示显示为灰色占位图。排查链路先看 WorkBuddy 的执行日志发现图片上传步骤全部成功返回的 URL 形如https://mmbiz.qpic.cn/mmbiz_jpg/xxx/640?wx_fmtjpeg。把 URL 直接贴到浏览器能打开说明素材库上传本身没问题。进一步检查发现WorkBuddy 在替换正文时把图片地址写成了 Markdown 格式的但公众号草稿箱接口要求正文 HTML 中的图片必须是img srcurl形式。我用的编辑器在保存时没有做 Markdown 渲染导致图片标签原样输出。修复方案在排版节点中先做 Markdown 到 HTML 的完整渲染再做图片 URL 替换。WorkBuddy 提供了内置的 Markdown 渲染 skill我把它接到图片处理节点之后问题解决。经验总结公众号接口接收的是安全的 HTML 子集不是 Markdown。任何未经转换的 Markdown 标记都会原样出现在正文里。排查这类问题时优先检查草稿箱接口返回的正文内容。5.2 坑二access_token 失效导致整条链路中断现象流水线运行两周后某天所有调用公众号接口的节点全部报 40001 错误invalid credential。排查链路查看日志发现 access_token 是在流程开始时获取一次之后所有节点共用这个 token。微信官方规定 access_token 有效期 7200 秒超过两小时必须重新获取。我的流程单次执行时间本身很短按理不会超时但问题出在定时任务上——WorkBuddy 的节点执行有缓存机制当流程触发间隔小于 token 有效期时它会复用缓存中的 token 值。但这次报错的原因不是过期而是 AppSecret 被重置过。我在某次调试时到公众平台重新生成了 AppSecret旧密钥立即失效WorkBuddy 缓存里的 token 却还是用旧密钥换来的。修复方案在获取 token 的节点里关闭缓存改为每次流程执行前强制刷新。同时养成一个习惯更换 AppSecret 后必须同步更新 WorkBuddy 的密钥配置并清空 flow 缓存。5.3 坑三AI 味太重文章被团队同事一眼识破现象第一篇由流水线完全生成的转载文章发给团队内部预览时同事回复这 AI 味太重了一眼假。排查链路逐段对比 AI 改写稿和原稿发现 AI 改写稿有几个特征段落结构过于整齐每段都是三到四句大量使用值得注意的是事实上不难看出等过渡语句子之间逻辑连接词过多缺乏原作者的节奏感。这些特征单独看都不算错但连在一起就很明显。修复方案三步走。第一在 prompt 中增加模仿人类作者写作节奏的指令要求段落长短错落、适当使用口语化表达第二维护一个禁用过渡词清单把常见的 AI 过渡表达全部列入负面提示第三在加工节点后增加一个AI 味检测节点用另一个模型对生成文本做检测如果检测到明显的机械化特征则自动退回重写。这个坑是 AI 辅助内容生产的共性问题运行流水线的时间越长越能感受到这类细节对读者体验的影响。5.4 坑四定时触发不稳定偶尔整个流程不跑现象某段时间内WorkBuddy 的定时任务不是每天准时触发而是偶尔跳过一次甚至连续两天没跑。排查链路先检查触发器配置确认时间表达式正确再查执行日志发现触发记录里显示任务已创建但节点未执行。进一步看系统资源发现是运行 WorkBuddy 执行器的服务器磁盘满了——日志文件、缓存文件、临时下载的图片把磁盘空间耗尽进程无响应。修复方案清理磁盘把缓存目录和日志目录迁移到独立数据盘并配置日志轮转策略。另外给服务器加了一个磁盘用量监控超过 80% 自动告警。这也是前面说一开始就把缓存目录改掉的原因。5.5 坑五草稿箱接口被限流现象某次批量导入 10 篇文章时前面 3 篇成功后面 7 篇全部报错错误码提示操作频繁。排查链路微信公众平台的接口调用频率是有限制的草稿箱接口虽然额度较高但短时间连续调用仍然可能触发限流。我的流程没有做请求间隔控制导致批量操作时触发频控。修复方案在 WorkBuddy 的 HTTP 请求节点中增加重试逻辑和请求间隔设置。我配置的是每次请求后等待 1 到 2 秒失败后指数退避重试最多重试 3 次。改动之后批量导入再也没有触发过限流。经验总结凡是调用外部 API 的节点默认都要做好请求间隔、重试退避、失败告警三件事。WorkBuddy 自带这些组件只是需要你在编排时主动加进链路别指望触发节点帮你自动容错。5.6 坑六换账号后旧记忆与配置丢失现象我在另一台机器上用新账号登录 WorkBuddy发现之前编排的所有流程都不见了只有默认模板。排查链路WorkBuddy 的流程配置默认保存在本地的用户数据目录里账号信息只负责云端同步一部分内容配置流程的本地执行缓存、密钥信息等并没有全量迁移。一开始我不知道这个机制差点以为要重新搭一遍。修复方案WorkBuddy 提供了项目导出功能把流程导出为 JSON 文件在新账号里导入即可。密钥信息导出后需要重新填写因为导出文件里的密钥做了脱敏处理。我的建议是每完成一次比较大的流程调整就导出一份配置文件保存到自己的代码仓库里这比任何云同步都可靠。6. 跑通后的真实效果与下一步打算流水线稳定运行约两个月后我的实际数据是这样每天纯人工干预时间从平均 40 分钟降到 8 分钟以内这 8 分钟主要花在审核确认和偶尔的标题替换上。转发内容的生产速度提升明显过去转载一篇需要 20 分钟找素材和排版现在来源确认后基本是分钟级成稿。原创内容的排版环节也完全自动化了我只需要在文档里写完初稿剩下的交给流水线。有一个意外的收获是因为每次发布后 WorkBuddy 都会回写发布记录我的内容台账数据变得非常完整。哪篇发了几点、阅读曲线怎么样、转载来源分布如何全都有迹可循。这些数据反过来指导选题和发布时段调整形成良性循环。我接下来的计划是再加一个素材选题节点每周自动汇总各内容源的高赞文章和热点话题结合账号历史数据给出本周选题建议。这一步的难点在于评估热点与账号调性的匹配度目前的方案是先把候选素材打好标签再从中筛选关联度高的进入加工链路。等这个节点跑顺了流水线就能覆盖从选题到发布的全链路。最后分享一个贯穿始终的心得自动化不是目的稳定才是。公众号运营里最怕的不是效率低而是某天流水线突然发出一条错误内容或者因为接口权限问题导致该发的没发。所以我的原则是——宁可用半自动的方式稳扎稳打也不追求百分之百无人值守。把 WorkBuddy 当成一个可靠的执行者而不是完全替代你的判断这套流水线才能真正长期跑下去。 
长河君 · 2026/10/27 9:01:36 · 阅读 1.2k 用WorkBuddy搭建公众号自动化发布流水线：从采集到审核的完整实践
微信公众号的更新频率我相信做过的人都懂选题、写稿、配图、排版、预览、改错别字、再预览、定时群发。一套流程走下来哪怕文章本身已经写好从编辑后台到正式发布之间至少还要耗掉半小时。如果内容源多、账号不止一个这个工作量还要成倍往上翻。我大概在半年前开始用 WorkBuddy 把整条链路串成自动化流水线现在两个账号的日常更新基本稳定在每天半小时以内。这篇就把整套搭建过程、配置细节和踩过的坑完整记录下来给同样被公众号更新频率折磨的人一个可以抄的作业。先说结论WorkBuddy 适合做的不是完全无人值守而是把采集、加工、排版、检查这些重复环节交给自动化把最需要判断力的审核环节留给人来做。整套流水线跑通之后我从写文章 2 小时 发布操作 30 分钟变成了写文章 2 小时 点一次确认发布。下面从选型逻辑开始讲。1. 公众号发布这件事到底哪些环节值得自动化1.1 被忽略的隐性成本很多人只算写一篇公众号文章的时间不算发布环节的时间。实际上一次常规发布要经过以下几步登录后台、新建图文、粘贴正文、逐张上传图片、调整格式、设置封面、填写摘要、预览到手机、反复修改、最后定时群发。就算完全不卡壳15 到 20 分钟是跑不掉的。如果账号的内容有固定来源比如你每天要转载团队内部的几篇技术周报或者你要把某个知识库里的内容整理后分发这个成本就要乘以账号数和文章数。我当时的痛点是一个技术号每天要发一篇原创一个行业资讯号每周要发三次转载加评论。转载类内容的排版和发布流程高度重复但每篇的标题、摘要、正文微调又需要人工过目。这种场景天然适合自动化——重复的部分交给工具判断的部分留给人。1.2 为什么选 WorkBuddy 而不是自研脚本可能有人会说这不就是一个爬虫加 API 调用的活吗自己写 Python 脚本也能做。我之前确实写过一版用 requests 调公众号接口配合 APScheduler 定时跑。能跑但维护成本很高token 过期要处理图片要单独传素材库排版规则稍微一变脚本就要改而且换个人接手基本看不懂。WorkBuddy 这类 AI 工作台工具的思路不一样。它对使用者的要求不是写代码而是编排流程你定义采集哪个源、送到哪里加工、加工完由谁确认、确认后调用哪个动作WorkBuddy 负责把节点串起来并执行。概念上类似于把 Zapier、n8n 和 AI Agent 的能力集中到一块但它对中文内容、本地文件、公众号生态的适配比通用型工具好很多比如内置了公众号图文接口的 skill可以直接操作草稿箱。另外选中它还有一个现实原因公众号的接口权限和调用方式比较特殊自己从零实现一遍要踩不少隐蔽的坑。WorkBuddy 把公众号相关能力做成了封装好的 skill我只需要填 AppID、AppSecret 和必要的参数不用关心签名算法和消息加解密这些底层细节。对于以内容运营为主业、不想投入太多时间维护代码的场景这是更划算的方案。1.3 一个关键判断全自动还是半自动刚开始我设想的流水线是全自动的文章生成、审核、发布都由系统完成。真跑起来才发现至少在内容型公众号这个场景全自动是个伪需求。原因有三第一公众号的违规风险是实打实的内容一旦涉及敏感词、违规广告或抄袭判定轻则删文重则限流封号这个风险不值得为省几分钟人工时间去冒第二AI 生成内容目前还不能做到完全符合每个号的语气和立场尤其是标题和摘要这种直接影响打开率的部分机器的判断经常和人的预期有偏差第三微信官方对接口发文是有风控的频繁用 API 群发而不经过后台人工确认账号权重容易受影响。所以我的方案是自动化处理 人工确认的混合流水线所有采集、清洗、排版、图片处理、草稿生成都由 WorkBuddy 完成最后一步推送前在手机或电脑上人工确认。这一改动让整个系统的实用度大幅提升也避免了很多潜在风险。2. 流水线总体架构从信息源到公众号草稿箱2.1 链路拆解我搭的这套流水线处理的是两个场景原创文章由我写好初稿后进入排版发布流程和转载文章从 RSS 源、合作站点抓取后做洗稿式整理。统一抽象成以下数据流信息采集定时检查各内容源RSS、网页、指定的公众号文章链接提取正文、标题、作者、发布时间、封面图。内容加工把抓取到的正文交给 WorkBuddy 的大模型节点按目标账号的风格要求重写或摘要生成标题候选和摘要文案。排版与素材处理将 Markdown 正文转成公众号排版图片批量上传至公众号素材库替换正文中的外链图片地址。人工审核WorkBuddy 把成稿写入公众号草稿箱并通过 IM 通知我我在手机上预览确认或直接在后台修改。发布调度确认后的草稿按预定时段发布。WorkBuddy 可以配置每日几点检查草稿箱待发布项并执行群发。这里面第 2 步和第 3 步是 WorkBuddy 最有价值的环节。如果没有 AI 加工自动化就只是机械搬运如果没有排版图片自动化人工仍然要花大量时间在美化上。两者结合后人要做的只剩第 4 步的判断。2.2 节点模型把流程画成有向图WorkBuddy 的编排方式和我之前用过的自动化工具不太一样。它不是简单的if this then that而是一个节点式的流程引擎每个节点可以是一个 skill、一个 prompt 模板、一个 HTTP 请求或一个条件判断。我的流水线在 WorkBuddy 里对应如下节点链触发器节点时间触发器每日 09:00 和 14:00 各触发一次。采集节点调用我自定义的 RSS 采集 skill将抓取结果输出为结构化 JSON。加工节点读取 JSON逐个送入大模型节点处理prompt 模板里写清楚目标账号的调性、禁用词、字数范围。图片处理节点调公众号素材库上传接口返回永久 URL。排版节点把 Markdown 渲染为公众号正文格式并替换图片 URL。草稿节点调用公众号新建草稿接口把排版结果写入草稿箱。通知节点通过微信或邮件通知我草稿已就绪请确认。发布节点定时检查草稿箱对标记为已确认的草稿执行群发。这个模型的好处是你可以只跑其中任意一段。比如某天选题不满意直接把采集和加工节点禁用只保留手写文章后的排版发布链路。不同节点的异常也不会互相影响哪个环节挂了重跑哪个就行。2.3 素材库方案的取舍做公众号自动化绕不开图片问题。很多人踩的第一个坑就是从网页直接抓来的图片地址无法在公众号正文中显示。公众号后台的图文编辑器只信任两类图片一类是上传到公众号素材库的图片另一类是通过 https 外链且域名在微信白名单内的图片。WorkBuddy 的图片处理节点内置了下载到本地-转存素材库-替换 URL的完整动作。实测下来这一步是跑通流水线的关键前提。如果你在编排时跳过了素材库转存直接把外站图片 URL 塞进正文最终预览时大概率会遇到图片无法显示或非微信域名限制的问题。3. 搭建前的准备工作账号权限与关键词门槛3.1 公众号侧需要什么先明确一点不是所有公众号都能走 API 发布。个人订阅号里只有已认证的账号才开放图文发布相关接口未认证的订阅号只能通过公众平台网页端手动操作。我用来跑流水线的两个号都是已认证的订阅号如果你手头是未认证的个人号建议先去完成认证流程否则下面的步骤都无从谈起。另外在设置与开发-基本配置里需要记录以下信息AppID接口调用的应用标识。AppSecret生成 access_token 用的密钥仅展示一次务必保存好。IP 白名单调用接口时服务器出口 IP 必须在此白名单内。我改过一次服务器 IP忘记更新白名单导致接口一直报错排查半天才发现是这个原因。服务器出口 IP 这个问题值得单独说。很多人拿本地开发环境去调接口本地 IP 随时变化今天能调通明天就报 40163 之类的错误。我的做法是把流水线部署在固定出口 IP 的云服务器上第一次配置时就把 IP 加进白名单。3.2 WorkBuddy 侧需要什么我用的是 WorkBuddy 的桌面版加远程执行模式流程在本地编辑跑定时任务时由服务器上的执行器接管。安装和账号体系这里不展开网上有大量教程关键是以下几个配置项公众号接入 skill在 WorkBuddy 的技能市场安装公众号相关 skill填好 AppID 和 AppSecret。官方 skill 默认支持草稿箱、素材库、群发接口基本覆盖流水线所需。大模型节点配置可以选 WorkBuddy 内置的模型也可以用自定义模型。我用的内置模型因为流程里涉及到大量中文排版处理内置模型对中文标点和段落转换的处理更省心。缓存目录设置这个默认值在系统盘跑了几周后缓存文件把磁盘占满了。建议一开始就改到数据盘或独立目录后面踩坑记录里会细说。3.3 关于自定义关键词过滤公众号分发机制里标题和摘要直接影响推荐量。WorkBuddy 的内容加工节点里可以配置关键词策略我维护了一个自定义词表分成两类一类是内容正向词命中后标题权重可以提高一类是风险词命中后整篇自动转人工不进入自动发布链路。这个过滤不是可选项。公众号对内容合规要求非常高哪怕你的账号本身没问题转载内容的原始出处里可能出现违规表述。机器不会自动识别哪些是引用、哪些是立场表达所以我的策略是宁严勿松凡是词表命中的内容一律人工再审一遍。4. 完整搭建步骤五个核心节点的配置实录4.1 采集节点适配 RSS 与公众号链接我的内容源有两类配置方式不同。RSS 源最简单在采集节点填上 feed 地址设置轮询周期和抓取条数即可。WorkBuddy 会解析出标题、正文、作者、发布时间和封面图。需要注意 RSS 返回的正文经常带有大量标签和无关模块比如相关文章推荐、版权声明需要在采集节点后接一个内容清洗步骤。公众号链接的采集稍微麻烦一点。直接抓链接往往只能拿到标题和部分摘要正文需要携带 Cookie 才能完整抓取。WorkBuddy 的浏览器自动化 skill 可以打开链接、滚动页面、提取正文并过滤广告模块。我这里补充一句只采集你自己有权限或已获授权的内容公众号文章版权归属复杂转载前务必确认授权链条别让自动化流水线变成侵权生产线。清洗规则我建议在 WorkBuddy 的可视化表达式里做删除所有script、style标签过滤与正文无关的固定段落比如点击上方蓝字关注图片标签统一转成 Markdown 格式识别正文中的首个标题作为候选标题。4.2 加工节点让 AI 按账号调性改写这一节点是整条流水线的灵魂。我配置了三种 prompt 模板分别对应原创文章校对、转载文章改写、短资讯摘要三种场景。核心模板大致如下你是【账号名称】的资深编辑。请完成以下任务 1. 将输入的新闻/文章改写为符合本账号调性的中文内容 2. 语气要求专业、克制、不夸张不使用震惊体 3. 禁止出现绝对化用语如最第一唯一、广告法违禁词 4. 标题要求给出 3 个候选每个不超过 30 字必须包含核心关键词 5. 摘要要求不超过 80 字概括核心信息点 6. 输出格式标题候选列表 正文 Markdown 摘要。这里我要特别提醒AI 味的问题。微信公众号的读者对AI 生成感非常敏感典型的 AI 味包括每段开头都用首先/其次/最后、过度使用值得注意的是、结尾喜欢说总而言之/相信通过本文等等。WorkBuddy 的大模型节点支持在 prompt 后追加负面提示词我把这些表达列入禁止出现清单效果立竿见影。如果你发现文章还是有点生硬可以再加一条规则强制使用短句每段不超过四行。4.3 排版与图片处理节点解决外链图片失效排版是公众号自动化最容易翻车的地方。真不是把 Markdown 转成 HTML 就完事微信公众号的编辑器对样式支持很有限外置 CSS 基本不支持只认内联样式。我的做法是让 WorkBuddy 生成带基础内联样式的 HTML正文段落 16px、行间距 1.75、段间距 12px、引用块用左侧灰线样式。这套样式普适性很强即使后台编辑器再渲染一次也不会乱。图片处理是流水线里最需要关注的一环。我的配置顺序是下载正文中的所有外部图片到本地临时目录逐张调用素材库上传接口获取永久图片 URL用永久 URL 替换正文中的临时地址选定封面图上传并记录 media_id。这里有个细节如果原文章的图片本身就是微信公众号素材库的地址理论上可以直接引用但我还是统一走一遍转存流程。原因有两个一是防止原账号删除或迁移导致图片挂掉二是通过自己的素材库还可以做后续的图片数据分析。4.4 人工审核节点自动化的边界我在流水线里专门留了一个人工审核节点它不是一个技术节点而是一个流程闸门。WorkBuddy 完成排版和草稿写入后会通过企业微信机器人给我推一条消息内容包含标题、摘要、草稿链接和确认发布按钮。我在手机上打开草稿链接预览排版确认正文图片正常、标题无敏感词后点一下确认。这个动作会回调一个确认接口WorkBuddy 收到确认后给草稿打上已确认标签。到了设定的发布窗口发布节点就会去草稿箱里找带此标签的草稿并执行群发。为什么不用 WorkBuddy 直接调群发接口除了前面说的内容风险外还有一个现实问题群发接口一旦调用不可撤回如果某天关键词策略漏掉了违规词、或者 AI 改写产生语义偏差发出后的成本极高。人工确认这个动作花费不到一分钟但给整条流水线增加了最关键的保险丝。4.5 发布节点定时与防抖发布节点解决的是什么时候发的问题。我配置了两个发布窗口早报类内容 08:30晚间内容 18:00。WorkBuddy 的定时触发器在发布窗口前 20 分钟检查一次草稿箱找到待发布草稿后先做一次发布前检查确认标题非空、正文长度大于 300 字、封面图已设置、无未替换的图片占位符。发布完成后还有一个收尾动作将发布结果回写进内容台账这样每月统计发文数量和阅读数据时不需要人工翻后台。WorkBuddy 的表格 skill 可以自动把发布记录同步到飞书多维表格我的月报就是这么自动生成的。5. 踩坑记录六个关键问题与完整排查链路这部分是全文最容易让后来者受益的内容。我在搭建和运行过程中遇到过不止一次深夜排障的情况下面按踩坑顺序记录。5.1 坑一图片全部裂开排查了两小时现象草稿生成后在手机预览时正文里的图片全部无法显示显示为灰色占位图。排查链路先看 WorkBuddy 的执行日志发现图片上传步骤全部成功返回的 URL 形如https://mmbiz.qpic.cn/mmbiz_jpg/xxx/640?wx_fmtjpeg。把 URL 直接贴到浏览器能打开说明素材库上传本身没问题。进一步检查发现WorkBuddy 在替换正文时把图片地址写成了 Markdown 格式的但公众号草稿箱接口要求正文 HTML 中的图片必须是img srcurl形式。我用的编辑器在保存时没有做 Markdown 渲染导致图片标签原样输出。修复方案在排版节点中先做 Markdown 到 HTML 的完整渲染再做图片 URL 替换。WorkBuddy 提供了内置的 Markdown 渲染 skill我把它接到图片处理节点之后问题解决。经验总结公众号接口接收的是安全的 HTML 子集不是 Markdown。任何未经转换的 Markdown 标记都会原样出现在正文里。排查这类问题时优先检查草稿箱接口返回的正文内容。5.2 坑二access_token 失效导致整条链路中断现象流水线运行两周后某天所有调用公众号接口的节点全部报 40001 错误invalid credential。排查链路查看日志发现 access_token 是在流程开始时获取一次之后所有节点共用这个 token。微信官方规定 access_token 有效期 7200 秒超过两小时必须重新获取。我的流程单次执行时间本身很短按理不会超时但问题出在定时任务上——WorkBuddy 的节点执行有缓存机制当流程触发间隔小于 token 有效期时它会复用缓存中的 token 值。但这次报错的原因不是过期而是 AppSecret 被重置过。我在某次调试时到公众平台重新生成了 AppSecret旧密钥立即失效WorkBuddy 缓存里的 token 却还是用旧密钥换来的。修复方案在获取 token 的节点里关闭缓存改为每次流程执行前强制刷新。同时养成一个习惯更换 AppSecret 后必须同步更新 WorkBuddy 的密钥配置并清空 flow 缓存。5.3 坑三AI 味太重文章被团队同事一眼识破现象第一篇由流水线完全生成的转载文章发给团队内部预览时同事回复这 AI 味太重了一眼假。排查链路逐段对比 AI 改写稿和原稿发现 AI 改写稿有几个特征段落结构过于整齐每段都是三到四句大量使用值得注意的是事实上不难看出等过渡语句子之间逻辑连接词过多缺乏原作者的节奏感。这些特征单独看都不算错但连在一起就很明显。修复方案三步走。第一在 prompt 中增加模仿人类作者写作节奏的指令要求段落长短错落、适当使用口语化表达第二维护一个禁用过渡词清单把常见的 AI 过渡表达全部列入负面提示第三在加工节点后增加一个AI 味检测节点用另一个模型对生成文本做检测如果检测到明显的机械化特征则自动退回重写。这个坑是 AI 辅助内容生产的共性问题运行流水线的时间越长越能感受到这类细节对读者体验的影响。5.4 坑四定时触发不稳定偶尔整个流程不跑现象某段时间内WorkBuddy 的定时任务不是每天准时触发而是偶尔跳过一次甚至连续两天没跑。排查链路先检查触发器配置确认时间表达式正确再查执行日志发现触发记录里显示任务已创建但节点未执行。进一步看系统资源发现是运行 WorkBuddy 执行器的服务器磁盘满了——日志文件、缓存文件、临时下载的图片把磁盘空间耗尽进程无响应。修复方案清理磁盘把缓存目录和日志目录迁移到独立数据盘并配置日志轮转策略。另外给服务器加了一个磁盘用量监控超过 80% 自动告警。这也是前面说一开始就把缓存目录改掉的原因。5.5 坑五草稿箱接口被限流现象某次批量导入 10 篇文章时前面 3 篇成功后面 7 篇全部报错错误码提示操作频繁。排查链路微信公众平台的接口调用频率是有限制的草稿箱接口虽然额度较高但短时间连续调用仍然可能触发限流。我的流程没有做请求间隔控制导致批量操作时触发频控。修复方案在 WorkBuddy 的 HTTP 请求节点中增加重试逻辑和请求间隔设置。我配置的是每次请求后等待 1 到 2 秒失败后指数退避重试最多重试 3 次。改动之后批量导入再也没有触发过限流。经验总结凡是调用外部 API 的节点默认都要做好请求间隔、重试退避、失败告警三件事。WorkBuddy 自带这些组件只是需要你在编排时主动加进链路别指望触发节点帮你自动容错。5.6 坑六换账号后旧记忆与配置丢失现象我在另一台机器上用新账号登录 WorkBuddy发现之前编排的所有流程都不见了只有默认模板。排查链路WorkBuddy 的流程配置默认保存在本地的用户数据目录里账号信息只负责云端同步一部分内容配置流程的本地执行缓存、密钥信息等并没有全量迁移。一开始我不知道这个机制差点以为要重新搭一遍。修复方案WorkBuddy 提供了项目导出功能把流程导出为 JSON 文件在新账号里导入即可。密钥信息导出后需要重新填写因为导出文件里的密钥做了脱敏处理。我的建议是每完成一次比较大的流程调整就导出一份配置文件保存到自己的代码仓库里这比任何云同步都可靠。6. 跑通后的真实效果与下一步打算流水线稳定运行约两个月后我的实际数据是这样每天纯人工干预时间从平均 40 分钟降到 8 分钟以内这 8 分钟主要花在审核确认和偶尔的标题替换上。转发内容的生产速度提升明显过去转载一篇需要 20 分钟找素材和排版现在来源确认后基本是分钟级成稿。原创内容的排版环节也完全自动化了我只需要在文档里写完初稿剩下的交给流水线。有一个意外的收获是因为每次发布后 WorkBuddy 都会回写发布记录我的内容台账数据变得非常完整。哪篇发了几点、阅读曲线怎么样、转载来源分布如何全都有迹可循。这些数据反过来指导选题和发布时段调整形成良性循环。我接下来的计划是再加一个素材选题节点每周自动汇总各内容源的高赞文章和热点话题结合账号历史数据给出本周选题建议。这一步的难点在于评估热点与账号调性的匹配度目前的方案是先把候选素材打好标签再从中筛选关联度高的进入加工链路。等这个节点跑顺了流水线就能覆盖从选题到发布的全链路。最后分享一个贯穿始终的心得自动化不是目的稳定才是。公众号运营里最怕的不是效率低而是某天流水线突然发出一条错误内容或者因为接口权限问题导致该发的没发。所以我的原则是——宁可用半自动的方式稳扎稳打也不追求百分之百无人值守。把 WorkBuddy 当成一个可靠的执行者而不是完全替代你的判断这套流水线才能真正长期跑下去。