公众号更新这件事，在我这儿曾经是比写稿更耗时的环节。稿子写完只是第一步，复制进编辑器、上传封面、调整代码块样式、填摘要起标题，一套下来二十分钟起步，遇上图片要压缩、排版要微调，半小时也打不住。后来我决定用 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 要不要全自动化的判断标准
搭建到后面，我经常会问自己一个问题：这一步真的需要全自动吗？
我的判断标准是：纯重复、规则明确、出错影响小的环节优先自动化；需要判断力、创造力和对账号安全影响大的环节保留人工。所以我的流水线落点是"自动到草稿、人工点发布"，而不是彻底无人化。公众号不是流量工厂，内容质量与账号信任度绑定，全自动的受众和场景其实很有限。
拿我自己举例，每月选题会还是会人工过一次；重大节点的文章发布仍然走人工复核；只有日常的常规更新才完全交给流水线。这套比例跑下来效率与质量相对平衡。自动化程度不是越高越好，而是越适合自己的节奏越好。
最后分享一个我从这套流水线里学到的小经验：搭建顺序不要太理想化，接口越早跑通越好。我一开始总想把知识库、风格库、图片处理全部做完美再上线，结果拖延了很久。后来先跑通了最短链路——内容生成到草稿提交，然后再逐步加图片、自检、通知。每次只加一个环节，出问题能立刻定位，这种渐进式搭建才是让流水线真正稳定运行的稳妥路线。
