公众号更新这件事在我这儿曾经是比写稿更耗时的环节。稿子写完只是第一步复制进编辑器、上传封面、调整代码块样式、填摘要起标题一套下来二十分钟起步遇上图片要压缩、排版要微调半小时也打不住。后来我决定用 WorkBuddy 把这套流程做成一条自动化流水线从内容生成到进入公众号草稿箱一键完成定时发布基本不用碰浏览器。这篇文章就是把从零到一的完整步骤、踩过的坑和排查思路整理出来给准备搭建公众号工作台的人做个参照。1. 在动手搭建之前先盘清公众号发布的真实成本很多人一听到全自动发布都会先兴奋但真正卡住进度的是没搞清楚公众号发布这件事哪些环节值得自动化哪些环节受平台限制无法全自动。先把成本盘清楚搭建时才不会做无用功。1.1 一次手动发布拆开到底有多碎我把一次完整的手工发布拆过步骤大概是这么个流程把 Markdown 或 Word 内容复制到公众号编辑器标题摘要重新填一遍。处理文内的图片截图保存、压缩体积、逐张上传再替换到正文对应位置。调整排版两端缩进、行距、字距、引用块样式、代码块背景色。手动挑选封面图截成公众号要求的 2.35:1 比例再上传。检查错别字、全角半角标点、分段逻辑这些小细节。设置定时发布或到点手动点击群发按钮。这其中的大头不是打字而是重复性的搬运和格式化。文章越写越长图片越多手动操作的时间成本就越不可控。我自己统计过一篇含 10 张图左右的教程型文章从编辑器粘贴到最终发布平均要 18 到 25 分钟。这还没算临时发现某张图上传失败、某些样式在手机上劈叉后重新调试的时间。1.2 自动化边界哪些能自动哪些必须留给人盘完手动成本接下来最重要的一件事是认清边界。公众号平台的接口权限对不同主体类型的账号有差异这个差异直接决定你的流水线能做到全自动还是半自动。内容生成可以自动化。选题方向、素材库、风格设定都可以交给工作流处理。图片素材可以自动化处理但版权和下载限制必须先规避掉。平台里有些图片做了防盗链直接下载会失败这点后面踩坑章节细说。排版转换可以自动化。Markdown 转微信 HTML 的模板可以固定下来样式稳定可复用。草稿提交可以自动化。通过官方接口可以创建草稿箱文章。最终发布取决于账号主体。个人主体订阅号没有发布接口只能到草稿箱人工点一下企业主体或服务号权限不同可以通过接口直接发布或定时发布。我自己用的是个人主体订阅号所以流水线的定位是自动完成到草稿箱、人工一键确认发布。这是合规又稳定的做法从账号安全角度也更稳妥。如果你的主体类型支持接口直接发布流水线可以往后多走一步。2. 为什么我选 WorkBuddy 而不是脚本、RPA 或传统工作流工具做自动化方案一般有几种路线写 Python 脚本配合定时任务、用 RPA 工具模拟点击、用现成的自动化平台或者像我一样用一个带 AI 理解和执行能力的智能工作台。我最后选的是 WorkBuddy核心原因在于公众号发布不是纯粹的调接口中间还有内容生成、语气调整、格式校验这些需要 AI 判断的环节。2.1 WorkBuddy 到底是什么WorkBuddy 你可以理解成一个能动手干活的 AI 工作台。它跟你平时用的对话式 AI 工具不一样的地方在于它除了能理解指令还能组合调用外部工具、读写知识库、执行代码和 HTTP 请求并且把这些动作编排成可复用的流程。也就是说它不是一个只会聊天的助手而更像一个装了手脚的调度器。对应到公众号场景它承担的是总编排的角色把写稿这个 AI 任务和调接口上传草稿这个工程任务塞进同一条流水线里。以前你要么用脚本只能干工程部分要么用 AI 只能生成文本再人工搬运WorkBuddy 的价值是把这两段串起来。2.2 项目、Skill、知识库三件套的使用逻辑我在 WorkBuddy 里搭流水线时主要依赖三个概念理解它们基本上就理解了工具的使用框架项目Project一个项目对应一类任务或一个账号承载上下文、配置参数、历史记录。我把公众号发布作为独立项目账号的 appid、封面图目录、常用风格描述都放在项目里。Skill技能Skill 是封装好的可复用动作单元类似给 AI 定义的一套标准操作流程。我为公众号发布单独写了 Skill里面定义了从读取素材到生成文章再到提交草稿的每个环节包括每一步调什么接口、失败时怎么重试。知识库Knowledge Base知识库存放素材和参考资料。我把过往的高质量文章、常用行业术语、标题写法、避坑清单都丢了进去生成内容时 AI 会优先参考这些资料。这套结构最大的好处是换一个公众号不用重写逻辑复制项目 改配置即可发布逻辑作为 Skill 沉淀后其他任务也可以复用同一套能力。2.3 对比一下更传统的方案为什么不留个 Python 脚本自己调接口就完事我试过也跑通了一部分但很快发现脚本方案有短板脚本可以调接口完成草稿提交但生成内容还是得靠人工先写好AI 生成部分和自动化发布是断开的。图片处理逻辑一旦变化改脚本的成本不低Skills 里可以把规则用自然语言描述调整成本低很多。RPA 模拟点击虽然能覆盖发布按钮但只要公众号后台页面结构调整一次RPA 流程就失效维护成本很高。接口返回的异常信息脚本只能打印日志WorkBuddy 的编排里可以加入 AI 判断遇到错误时智能重试或走备用方案。所以我倾向把 WorkBuddy 看作是AI 判断 工程执行的混合编排平台而不是单纯的接口调度工具。文章生成、自检、上传、进草稿这条链路里每一环都需要不同能力WorkBuddy 恰好能把它们捏到一起。3. 搭建全自动发布流水线从零到一的实操记录下面进入正题。我会按实际搭建顺序写包括架构设计、公众号侧准备、WorkBuddy 侧的配置、Skill 编写逻辑和通知机制。每一步都尽量写清楚为什么这么做方便你按场景调整。3.1 目标架构先把整条链路画出来不画图了用文字描述一下这条链路的走向你心里有个全局图再动手会顺很多内容源知识库/素材池 → WorkBuddy 读取素材并生成文章 → 内置自检清单校验 → 图片下载与处理 → 组装微信 HTML → 获取 access_token → 上传封面/图片素材 → 创建草稿draft/add → 通知结果 → 人工点发布从这个结构能看出真正的发布动作放在最后且允许人工介入。这样的架构既保留自动化效率又给内容审核留了空间。文章推出去之前至少要过一遍人眼这是我对账号安全的底线要求。3.2 公众号平台的准备工作在 WorkBuddy 侧写任何代码之前先要确保公众号后台具备接入能力登录微信公众平台在设置与开发 → 基本配置里拿到 appid 和 appsecret。这两串字符串相当于你账号的钥匙务必放好别泄露到公共仓库。在IP 白名单里配置服务器出口 IP。WorkBuddy 调用接口时用的是自己服务器的出口地址不把这个 IP 加进白名单接口会直接报 invalid ip 错误。所以要先确认请求从哪个 IP 出去把它加白。确认账号类型对应的接口权限。个人主体订阅号没有 freepublish 之类的发布接口企业服务号才有完整的发布能力。我在本节的定位是个人主体订阅号自动提交草稿 人工确认发布如果你是企业服务号可以在同一思路下把最后一步换成 true publish 请求。这几项准备工作不做后面所有流程都是空转。尤其是 IP 白名单是最容易被忽略的前置条件。3.3 在 WorkBuddy 里搭建知识库我建了两个库一个是公众号素材库一个是公众号风格库。素材库存两块内容一是从各处保存来的参考文章和资料二是自己维护的选题池。我日常工作流里看到好的文章题目或结尾会顺手存进知识库这样 Skill 在生成新内容时可以检索引用避免 AI 凭空编造。风格库存固定表达和规则比如开头禁止用随着科技的发展这类万能套话。段落平均长度控制在三到五句多用具体案例少用抽象概念。标题的数字尽量用阿拉伯数字正文里的英文术语保留原文。收录哪些高频词汇和句式可以作为标志性表达。知识库的加载顺序和关键词规则可以自定义。我的做法是每一次生成任务都强制参考风格库素材库则按需检索命中才引用。这个设计能保证内容既符合平台调性又不至于每次生成都变成对同几篇素材的洗稿。3.4 编写公众号发布Skill 的完整逻辑Skill 是流水线的核心装配单元。我给这个 Skill 起的名字是公众号文章发布流水线它的执行流程分为五个阶段。阶段一生成文章。Skill 读取项目配置里的标题方向、风格库规则和素材库的内容生成 Markdown 格式的初稿。这一步里我会在提示词里加一句硬约束内容必须基于知识库资料禁止无根据的编造数据和案例。阶段二自检。按照内置检查清单走一遍包括错别字、敏感词、标点符号、事实性表述。自检不是浮于表面而是把文章逐段丢回模型里做两轮检查第一轮查规范性第二轮查是否像真人写的。如果出现值得注意的是综上所述这类模板化表达会触发重写逻辑。阶段三图片处理。解析正文里的图片引用逐个检查来源域名和下载限制。不能直接下载的图片会在知识库里寻找替代图或者自动占位提醒。图片统一压缩到合适尺寸后上传到公众号素材库拿到 media_id 后回填到正文。阶段四组装微信 HTML。公众号编辑器有自己的一套 HTML 子集Markdown 不能直接扔进去。我会用一个固定模板把正文、代码块、引用块、图片 URL 拼成所需的 JSON 结构再通过 draft/add 接口创建草稿。阶段五结果通知。接口返回成功后把草稿链接、标题、摘要通过通知通道发出来失败则收集错误码、触发重试或人工介入提示。用 JSON 定义配置的好处是方便复用。我把配置拆成了这样{ 公众号: { appid: 你的appid, 账号类型: 个人主体订阅号, 发布方式: 提交草稿人工确认, 默认封面图: asset/cover_default.png, 缩略图素材ID: permanent_material_id }, 生成规则: { 默认长度: 2000字左右, 风格库: 公众号风格库, 禁止开头: [随着, 在...背景下, 众所周知] }, 自检规则: { 敏感词: true, AI味检测: true, 事实核验: true } }Skill 不一定写得越复杂越好恰恰相反我建议从最简单的一条链开始生成 → 提交草稿 → 通知。跑通之后再逐步加图片处理、自检、AI 味检测这些环节。一上来就把 Skill 写得很庞大出了问题很难定位。3.5 发布与定时逻辑的取舍拿到草稿后接下来分两种情况如果你的账号主体支持发布接口调用发布接口后可以传入定时发布参数完成真正的定时群发。这种方式适合企业服务号或者有每天自定义发文需求的场景。如果像我一样是个人主体订阅号就只能在草稿箱里手动点击发布按钮。我的应对办法是WorkBuddy 在生成草稿时把标题、摘要、封面全部整理妥当并把发布按钮的确认路径发到手机上。从打开后台到点发布整个过程不到 30 秒依然是可接受的效率。3.6 通知与告警让流水线开口说话自动化跑起来以后最怕的是它在角落里默默失败。我也经历过某天草稿没进后台静悄悄的直到我主动登上去才发现接口报错。所以通知机制一定要有。我的做法是每次草稿创建成功后给通知通道发一条消息内容包括标题、草稿链接、生成耗时失败时发错误码和触发环节。通知可以用你习惯的任何通道比如企业微信群机器人、邮件或者简单 HTTP 回调。原则只有一个——不要让自己等到打开后台那一刻才知道出了问题。4. 踩坑记录五个高频问题与完整排查链路搭建和运行这两个多月遇到的坑不少。挑几个有代表性的写出来完整的排查思路比直接给答案更有用。4.1 图片上传失败从 40007 错误码开始顺藤摸瓜第一次跑通草稿接口后我发现上传正文里的图片时频繁报错错误码是 40007提示消息是 invalid media_id但我的 media_id 明明是刚上传成功的这让我一度怀疑是不是账号权限除了问题。排查链路是这样的先确认是不是 media_id 失效。我让流程把上传后返回的 media_id 原样打印出来然后手工调用一次查询素材接口发现素材存在排除 media_id 过期问题。再怀疑是不是图片格式不符合要求。公众号素材接口对图片格式有限制默认接受 JPG、PNG对某些浏览器导出的 WebP 或带透明通道的图会有兼容问题。我把原图换成 PNG 后重新上传问题依然存在。最后定位到真正的坑——那张图片来源有问题。文章里的某张配图是从其他站点复制过来的我本地的下载脚本先下载到了临时文件再上传。但源站的图片带了防盗链签名下载后的文件在 HTTP 传输过程中变成了不完整的损坏文件导致上传后图片内容不合法。解决方案很朴素下载图片时校验文件头和大小非空且魔数匹配才允许进入上传流程。这也解答了很多人问的为什么公众号文章里的有些图片下载不了——很大一部分是来源域名设置了防盗链你的下载请求没有带正确的来源标记服务器拒绝返回完整数据。我后来统一在下载请求里携带合适的请求头并把图片转存到自己的图片存储问题彻底消失。下载、压缩、上传这几个环节必须在流水线里分开并留下日志否则一旦图片出了问题你很难判断坏在哪个环节。4.2 access_token 过期与调用频率限制并发场景下的隐形炸弹公众号接口调用离不开 access_token它有两个天然限制有效期只有 7200 秒且刷新严格受频率限制。我的流水线第一次部署时在 token 管理上偷了懒每个环节都单独获取一次 token。结果流程一跑复杂多次获取导致前面的 token 被强制失效后面的请求全部报 40001 凭证无效。这个坑的排查过程并不难难在意识到问题根源。日志里全是 40001而我一开始还以为是自己 token 取错字段了。后来把每次获取 token 的时间和过期时间打印出来才发现同一时间窗口里有多个 token 在互相顶替。解决办法是全局单例缓存。流水线启动时先检查本地缓存的 token未过期就直接复用过期前预留 5 分钟缓冲刷新一次。刷新动作加了互斥锁保证同一时间只有一个请求在刷新 token。这样既避免频繁刷新撞上接口频率限制也保证全部环节共享同一个有效凭证。关于频率限制再多说一句公众号接口除了总量限制还有分钟级调用限制。自检流程如果设计得不好把文章段落逐段发回模型做检测接口调用量会非常可观容易把每日配额打爆。我的做法是优化 prompt让模型一次处理整篇文章而不是逐段处理。4.3 草稿箱排版与移动端显示不一致HTML子集的特殊性用 draft/add 接口提交草稿后PC 端后台看排版一切正常一旦切到手机端代码块边框消失、部分段落字号错乱、图片之间出现奇怪的间距。这是 Markdown 转公众号 HTML 最典型的坑。公众号编辑器的富文本渲染有自己的 HTML 子集很多标准 CSS 类名和样式前缀在移动端渲染时会被过滤。我最初直接套用通用 Markdown CSS 样式比如给 pre 元素加背景色结果移动端根本不认。这里的规则是你需要专门维护一套面向公众号的样式模板而不是通用样式。我的做法是代码块统一用内联样式写死不依赖外部 class。正文段落、引用块、标题字号分别用内联 font-size 和 margin 定义。图片一律压缩到 1080px 宽度以内并在 HTML 里显式设置 max-width: 100%。缩进用 section 标签包裹两段式缩进设置的写法在移动端相对稳定。每加一种新样式都要在用真实手机预览一遍再沉淀进模板。不要只看模拟器模拟器和真机渲染差异很明显。4.4 发布接口不可用账号类型决定自动化深度这是无数人搭建流水线时卡得最久的问题我也一样。在 WorkBuddy 里写好了自动发布逻辑调接口才发现个人主体订阅号根本不具备 freepublish 的权限。登录后台再看接口文档赫然写着此接口能力仅面向认证服务号。这个坑的正确排查顺序是先检查账号主体的认证状态和类型。个人订阅号、未认证订阅号、认证服务号的接口权限集合差异很大。再去公众平台后台的开发 → 接口权限页面确认有没有发布能力这一项。没有权限就不要强行折腾把流水线终点调整为草稿箱或者申请一个满足条件的账号。这件事给我的提醒是任何自动化方案在动手前都应该先确认能力边界别等代码写完才发现地基不行。4.5 内容被标记疑似 AI 生成的应对方式AI 生成的文字多了之后平台对内容的识别也在变严。我在前几篇自动生成的草稿里发现有些文章会收到提示或者阅读量明显偏低。排查后发现不是被限流而是内容本身的AI 味太重。问题集中在三处开头喜欢用在当今时代随着互联网的发展这类万能起手。每个段落结尾都要总结陈词像在写议论文。用词过于正确缺乏个人经历和瑕疵读起来没有真人感。我针对性地改了生成策略。一是在风格库里强制加入禁止使用的开头句式清单二是要求文章必须包含至少两处个人化经验描述例如我试过踩过坑之后这类表达三是在发布前增加一轮降 AI 味自检专门挑出那些教科书式表述换成更随意的说法。这套规则配合人工抽查内容质量明显回升。这事没有一劳永逸的解法核心原则是AI 负责初稿和流程人负责经验和判断关键内容在发布前必须过一遍人的眼睛。5. 让流水线产出的内容真正像人写的很多搭建自动化发布的人只关注接口是否调用成功忽略了内容本身的接受度。流水线不是只跑通接口就完了还要让产出内容经得起读者和平台的双重检验。5.1 减少 AI 味的三层设计我的降 AI 味方案是分三层的由浅入深第一层提示词约束。明确禁止模板化表达禁用总而言之综上所述值得注意的是这类明显书面腔要求多用短句、口语词和具体案例。第二层生成后处理。自检环节专门扫描一遍高频 AI 句式发现即触发局部重写。我对局部重写的要求是不改变原文信息只改表达方式。第三层人机协作。即使自动化全部跑通发布前人工快速通读一遍重点看开头和结尾有没有AI 腔。人工把关的意义不只是挑错更是给内容注入真实的个人判断。5.2 设置内容自检清单做多层次校验自检清单在自动化过程里起的作用类似“质检员”。我沉淀了一份固定清单错别字和标点全角半角是否混用标点是否规范。敏感词用词是否可能引发歧义尽量避免不严谨的绝对化表达。事实核验涉及数据、案例的内容必须来自知识库不凭空编造。结构检查每段是否超过六行有无大段文字堆砌。AI 味检查是否存在万能句式、空洞排比、过度书面化表达。这五个纬度每次生成时都会自动跑一遍。别小看最后的 AI 味检查前几次流水线产出的文章问题基本都出在这条。5.3 积累专属风格库让内容形成可识别的气味做公众号的人慢慢都会形成自己的文风这种文风很难用一两条规则描述。我的做法是不断往知识库里的风格库添加样本和反样本。样本是那些读起来很有自己人感觉的句子和段落反样本是那些典型的 AI 腔表达。Skill 生成时会对照样本调整语气遇到反样本里的句式就主动改写。积累越久风格库越厚流水线生产的内容就越稳定。这套思路本质上是把写作风格变成可维护的规则集而不是每次靠运气。6. 流水线的后续扩展与常见取舍跑通公众号之后这条流水线还可以继续生长。不少人会问下一步能做什么我这里说说几个常见方向和我自己的取舍。6.1 多平台分发的扩展空间公众号草稿创建成功后正文已经是结构化的 HTML理论上可以转换适配其他内容平台知乎、博客、头条都支持类似的富文本导入。WorkBuddy 里可以把公众号发布的 Skill 复制一份修改平台特定的排版模板和接口参数变成多平台分发Skill。但我要提醒一句不同平台的审核规则和读者口味差异很大同一篇文章直接一字不改分发效果多半一般。我目前的做法是公众号保持深度内容其他平台以摘要和跳转引导为主避免内容重复度过高。6.2 素材回流与选题循环流水线跑起来后每天都会有大量过程数据哪些选题打开了草稿、哪些段落被人工修改、哪些标题被最终保留。这些数据如果能回流到知识库的选题池会逐步优化后续内容的方向。我在实践中简化版的做法是人工发布时顺手标注这篇可继续深入的话题点WorkBuddy 在下次生成时可以优先参考这些标注。6.3 要不要全自动化的判断标准搭建到后面我经常会问自己一个问题这一步真的需要全自动吗我的判断标准是纯重复、规则明确、出错影响小的环节优先自动化需要判断力、创造力和对账号安全影响大的环节保留人工。所以我的流水线落点是自动到草稿、人工点发布而不是彻底无人化。公众号不是流量工厂内容质量与账号信任度绑定全自动的受众和场景其实很有限。拿我自己举例每月选题会还是会人工过一次重大节点的文章发布仍然走人工复核只有日常的常规更新才完全交给流水线。这套比例跑下来效率与质量相对平衡。自动化程度不是越高越好而是越适合自己的节奏越好。最后分享一个我从这套流水线里学到的小经验搭建顺序不要太理想化接口越早跑通越好。我一开始总想把知识库、风格库、图片处理全部做完美再上线结果拖延了很久。后来先跑通了最短链路——内容生成到草稿提交然后再逐步加图片、自检、通知。每次只加一个环节出问题能立刻定位这种渐进式搭建才是让流水线真正稳定运行的稳妥路线。