做内容的人应该都有同一个痛点稿子在本地写完了、改完了觉得总算能松口气结果打开 Z-Blog 后台新建文章、把稿子粘进去、调标题层级、传图插位置、填摘要和 SEO 信息、拖分类、敲标签、再预览一遍防格式翻车最后才敢点发布。这一套流程走下来二十分钟算是快的。我自己博客一直搭在 Z-Blog 上被这套重复劳动折磨了很久后来用 WorkBuddy 自建了一个「Z-Blog 文章发布」技能把发布环节彻底变成流水线稿子一丢两分钟之内一篇带好分类、标签、SEO 信息和完整格式的文章就已经躺在网站上了。这篇不是广告纯粹是我自己踩完坑之后的实操记录。我会把整个技能的思路、接口选型、每一步的搭建细节、以及我遇到的典型问题都拆开讲给同样用 Z-Blog、又不想每天重复这套手工活的朋友做参考。不管你是刚开始接触自动化的小白还是已经玩过一阵子工作流的老手照着这个骨架搭基本上都能跑通。1. 为什么要把发布流程做成技能1.1 二十分钟到底被谁吃掉了我说二十分钟真不是夸张。你可以打开后台看一眼自己的操作路径拆开算算账新建文章、粘贴正文大概 1 到 2 分钟。粘贴完还得面对一个格式半残的编辑器标题全没了、列表挤成一团。手工修复格式这是最耗时的部分。重新给一级二级标题加样式、给代码块套标签、把表格理清楚运气好 5 分钟运气差 10 分钟起。图片处理又是 3 到 5 分钟。本地图片要一张张传、一张张插到对应位置还要顺带调整尺寸。后台表单填写标题、摘要、关键词、分类、标签、别名一项项核对2 到 3 分钟。预览、再修正、点发布又是 2 到 3 分钟。这些操作里没有一项是创作全是体力活。更烦的是Z-Blog 后台的表单字段你每次都要重新回忆一遍分类一多还容易选错。我曾经连着三天发三篇文章每一篇都在同样的格式修复上浪费十来分钟那会儿就在想如果有个东西能替我把粘贴-排版-传图-填表-发布这条链路跑完该多好。1.2 WorkBuddy 技能的解题思路WorkBuddy 这个工具你可以把它理解成一个个人自动化工作台。它的核心玩法是技能把一系列操作编排成一条可复用的流程输入一个东西跑完输出另一个东西。技能里可以接大模型做内容加工也可以接 HTTP 请求调用外部系统还能做变量处理、条件分支、结果校验。我的思路很简单就是把发布这篇文章要做的事拆成四段标准流程接收输入内容解析出标题、正文、图片、分类倾向这些信息。内容加工把稿子从 Markdown 规整成 Z-Blog 能直接用的 HTML同时生成摘要和 SEO 标题。调用 Z-Blog 的接口把文章、图片、分类、标签、状态这些参数一次性交过去。校验结果确认文章真的发出去了再返回后台编辑地址给我存档。这里最关键的一个选型决策是不用模拟浏览器去后台点按钮而是走 Z-Blog 自带的标准发布接口。理由很简单网页自动化太脆了后台改个按钮名、换个模板脚本就废了而且还得处理登录态、验证码这些麻烦事。Z-Blog 本身支持 MetaWeblog 标准的 XML-RPC 接口这是很多年前桌面写作客户端就在用的老协议稳定、轻量、文档明确直接用 HTTP POST 就能发文章这才是正路。2. 动手前先定边界接口与技能设计2.1 Z-Blog 侧的接口准备开发前先把 Z-Blog 这边的地基建好。打开你博客的 XML-RPC 接口一般在你站点地址的 zb_system 目录下路径形如 /zb_system/xml-rpc/index.php。不同版本路径可能有差异以你后台实际配置为准。然后确认用户名密码有调用权限建议专门建一个自动化发布用的后台账号别拿主管理员账号到处跑。这套接口是标准的 MetaWeblog API最常用的几个方法方法名作用metaWeblog.newPost新建文章metaWeblog.editPost修改文章metaWeblog.getPost读取单篇文章metaWeblog.getCategories获取分类列表metaWeblog.newMediaObject上传图片等媒体文件我建议第一步别急着写技能先拿一个通用客户端连一下接口手动发一篇测试文章。这一步能帮你同时确认三件事接口路径对不对、账号权限够不够、Z-Blog 版本对标准字段的支持程度。我见过很多人一上来就写全自动流程结果卡在最基础的登录上排错排到怀疑人生。先用最小实验跑通后面会省心很多。2.2 技能输入输出定义技能设计的第一原则先定义清楚输入和输出再想中间流程。否则很容易做着做着就变成一个大杂烩。我的输入设计是这样的一篇写在本地或者网盘里的 Markdown 文件文件名就是习惯性的文章编号加日期。WorkBuddy 技能读取这个文件拿到原始文本。输出则明确为三样东西文章 ID、前台访问链接、后台编辑地址。这三样东西会写回到一个记录文件里方便我复查和管理。还有一个很关键的配置文件我管它叫技能说明书本质上是一段规则文本告诉技能处理内容时的各种约束。比如标题长度控制、摘要字数、分类匹配规则、标签数量上限、正文段落间距规范。这个说明书越详细技能输出的稳定性越高。你也不想让技能自由发挥最后发出来一篇标题超长、标签塞了几十个的文章吧。3. 分步搭建「Z-Blog 文章发布」技能3.1 搭骨架把四段流程串起来在 WorkBuddy 里新建一个技能我习惯先把流程骨架搭出来再往里面填细节。整体节点是这样排的读取输入文件提取正文文本。大模型节点处理标题如果文件里没写标题就根据正文第一段生成写了标题就做长度校验和敏感词过滤。内容格式转换节点把 Markdown 转成干净 HTML。图片处理子流程遍历正文里的图片标记分成远程图片和本地图片两路处理。分类映射节点从配置表里选出最合适的分类。组装发布参数生成 XML-RPC 请求体。调用 Z-Blog 接口发起 HTTP POST。校验节点读回文章信息确认发布成功拼接后台编辑地址。这个顺序是经过几次调整后定下来的。最开始我把图片处理和格式转换放在一起做结果一旦图片上传失败整个发布就直接挂了。后来拆成独立子流程图片失败时技能会跳过图片继续把文章发出去并在最终报告里高亮提示有图片未处理我再单独补传。这个降级策略在实战中帮了我很多次。3.2 内容加工Markdown 到 HTML 的转换细节Z-Blog 的编辑器虽然支持直接粘 HTML但它对格式的处理没有想象的那么宽容。我的经验是不要直接拿大模型去写整篇 HTML而是先用标准的 Markdown 转 HTML 工具把正文转成结构化 HTML再让大模型只做局部修正。原因很简单大模型裸写 HTML 容易发挥不稳定经常漏掉闭合标签或者把代码块里的特殊字符当成格式标签吃掉。转换时有几个固定动作标题层级。Markdown 里的 # ## ### 对应 h2 h3 h4但文章里一般不应该出现 h1h1 是留给网站标题的。技能里我写了规则一级标题自动降为二级正文内从 h2 开始。代码块。转换后必须是 pre 加 code 的结构代码语言要保留 class这样 Z-Blog 的前端代码高亮插件才能正常识别。表格。Z-Blog 后台对表格的默认样式一般不太好看我会在转换后给 table 套一层带 class 的 div方便前台 CSS 统一处理。段落间距。Markdown 的换行规则和 HTML 不一样转换器容易把不该断的句子拆成两个 p。这个没法完全避免我的处理是发布前用一段规则检查正文里有没有过短的 p 标签比如少于五个字的段落标记出来让人工确认。最后整篇正文用一个 div 包裹起来再提交这样能防止 Z-Blog 的编辑器对内容做奇怪的重新排列。3.3 图片上传用好 newMediaObject图片是发布流程里最容易翻车的一环值得单独讲。我的技能把图片分成两种情况处理。第一种是远程图片也就是 Markdown 里直接写了完整 URL 的图。这种最简单技能只需要检查 URL 可访问性确认图片还在然后直接保留原链接。第二种是本地图片这就是真正的工作量所在。技能会先读取图片文件把它压缩到目标宽度以内再转成字节内容通过 metaWeblog.newMediaObject 方法上传。这个方法接收文件名、类型和二进制数据返回图片在服务器上的 URL然后把正文里的相对路径替换成这个真实地址。你可能会问为什么不在 WorkBuddy 里先把图片传到某个图床再拿图床链接填进正文我试过确实能跑但有一个致命问题图床和博客分离哪天图床域名过期或者防盗链一开整站图片全部挂掉。传到博客自己的服务器目录由 Z-Blog 自己托管数据是闭环的反而更省心。上传时的请求结构大概是这样的你可以直接用 HTTP 节点提交?xml version1.0 encodingutf-8? methodCall methodNamemetaWeblog.newMediaObject/methodName params paramvaluestring博客ID/string/value/param paramvaluestring发布账号/string/value/param paramvaluestring密码/string/value/param paramvaluestruct membernamename/namevaluestringarticle-2025-001.jpg/string/value/member membernametype/namevaluestringimage/jpeg/string/value/member membernamebits/namevaluebase64图片二进制内容的Base64编码/base64/value/member /struct/value/param /params /methodCall需要注意的是图片压缩这一步别省。我最早图省事直接传原图结果手机拍的一张照片三 MB接口超时不说还把服务器存储撑得很难看。现在技能里固定规则图片宽度超过 1200 像素就等比缩放整体质量压缩到 80 左右视觉上没什么影响体积能小好几倍接口也稳了。3.4 分类与标签的自动化映射分类和标签是纯体力活但做自动化的时候反而最需要细心因为它涉及语义理解。分类那边我用 getCategories 接口先把博客全部分类拉一遍存进配置文件。然后给每个分类写上一段特征描述比如工具教程软件操作、配置方法、工作流搭建相关。技能拿到文章正文后由大模型根据特征描述做匹配选出最合适的分类。这个特征描述写得越具体匹配准确率越高。初期我是纯靠大模型猜分类准确率大概七成写完特征描述之后能到九成以上。标签那边就简单一些规则是从正文提取三到五个核心关键词作为标签全部转成小写英文或保留中文原文逗号分隔。数量一定要限制我有一次测试时技能抽风生成了二十多个标签后台看起来就像标签垃圾场。后来在技能说明书里加死规则标签不超过五个每个不超过十个字。还要强调一点分类映射结果和标签结果都要写进发布前的预检报告我要能看得到技能打算把文章发到哪个分类、带哪些标签。自动化的前提是可控不是失控。3.5 组装发布参数标题、摘要、SEO 与状态接口调用前的最后一步是把所有参数装进一个结构体。核心字段就这些字段说明我的规则title文章标题最多 60 字超出则截断并确保语义完整description正文 HTML用 div 包裹图片链接已替换categories分类名称数组取映射结果mt_keywords标签文本逗号分隔最多 5 个postStatus发布状态draft 或 publishpostStatus 这个字段值得专门说一下。我的技能默认全部走 draft 模式文章发出去是草稿状态我在后台点一下发布才算真正上线。这样做的原因是即便技能已经校验过标题、分类和正文我依然想在内容真正面对读者之前过一眼。自动化要省的是时间不是判断力。等跑了一个月、确认技能足够稳定之后再在配置里把默认状态切成 publish。至于 SEO 标题和摘要描述这个要看 Z-Blog 版本对接口字段的支持情况。标准 MetaWeblog 协议里这两个字段不一定有对应项我的做法是先走标准字段把文章发出去再通过后台接口补齐 SEO 信息。你第一次配置时建议发一篇测试草稿然后去后台看文章详情页确认你用的版本支持哪些扩展字段再决定要不要在技能里把它们写进请求。发布请求的 XML 结构长这样?xml version1.0 encodingutf-8? methodCall methodNamemetaWeblog.newPost/methodName params paramvaluestring博客ID/string/value/param paramvaluestring发布账号/string/value/param paramvaluestring密码/string/value/param paramvaluestruct membernametitle/namevaluestring文章标题/string/value/member membernamedescription/namevaluestring正文HTML字符串/string/value/member membernamecategories/namevaluearraydata valuestring工具教程/string/value /data/array/value/member membernamemt_keywords/namevaluestring博客自动化,WorkBuddy,效率/string/value/member membernamepostStatus/namevaluestringdraft/string/value/member /struct/value/param paramvalueboolean1/boolean/value/param /params /methodCall这里有个低级但常见的坑XML-RPC 本质上是一个 XML 报文如果你的正文里有 这类特殊字符手搓 XML 很容易坏掉。所以我强烈建议技能里用现成的客户端组件发请求而不是拼字符串。如果实在要手拼务必把正文内容里的这几个字符做转义否则你会看到各种莫名其妙的解析错误。3.6 发布后的校验与结果回执发完不等于发成功了。我设计技能的时候特意加了一道回读校验接口返回文章 ID 之后技能再调用一次 getPost把刚发布的文章读回来核对标题、分类、正文开头几行。只要有一项对不上整个技能就报错退出并且不会覆盖之前的发布记录。这样做的好处是很多问题能在第一时间被发现。比如分类映射错了、正文被截断了、标签没写进去回读都能看出来。校验通过之后技能把结果写进一个发布记录文件内容包括文章 ID前台链接后台编辑地址发布时间本次发布使用的技能版本号这个记录文件非常有用。后来我写了一个小脚本定期扫这个文件把超过两周还是草稿状态的文章统计出来提醒我处理。等于发布流程不仅自动化了连后续的跟进也顺带管理起来了。4. 踩坑实录与排查清单4.1 常见问题速查表我把自己在实际搭建和使用中遇到的高频问题整理成了一张表基本都是能直接照着排查的症状常见原因处理方法接口返回 404XML-RPC 路径不对或服务器禁了 POST 请求后台确认接口开启核对完整路径用客户端先测一次登录失败/无权访问账号密码错误或该账号没有接口调用权限单独建发布账号确认后台接口权限勾选文章发出去了但图片全裂图片未上传或正文里的相对路径没替换检查图片子流程日志确认 newMediaObject 返回的 URL 被正确替换标签没进去后台空荡荡版本不支持 mt_keywords 字段发测试草稿看后台换用其他等效字段传入SEO 标题/摘要没生效标准接口不含该字段发布后调用后台接口或手动补齐 SEO 信息文章重复发布了好几篇技能没有做幂等处理重复触发了发布前按标题和内容指纹查重已存在则改为更新代码块里的特殊字符跑飞了内容里的 等字符被 XML 解析破坏用标准客户端组件提交避免手拼 XML图片上传超时图片太大接口处理不过来上传前压缩缩放限制单张体积4.2 几条实用避坑经验除了上面那张表还有几条经验是文档里不会写的我单独拿出来说。第一条永远保留草稿先行这道闸门。哪怕技能已经稳定跑了几个月我也不会把默认状态改成直接发布。有一次技能的分类特征描述被我不小心改坏了连续三篇文章全部分到了杂谈分类下。因为默认是草稿模式我只是后台改一下分类再发布没有任何一篇文章以错误分类的形式上线。如果当时是自动发布三个错误分类的文章就被读者看到了。第二条幂等设计一定要做。我最初版本的技能没有查重功能有一次文件重复触发同一篇文章发了三遍。后来加了双重保护发布前按标题在后台搜索找到同名草稿就改为更新同时在发布记录文件里记录内容指纹下次进来先比对指纹重复就直接跳过。第三条别让技能在有点问题但能发和报错之间做模糊判断。技能处理内容时一旦发现关键信息缺失比如正文为空、标题为空、分类匹配置信度低于阈值应该直接报错而不是凭感觉硬发。宁可这次不发也不要发一篇错的出去。每次报错都会促使你去完善规则这正是技能进化的方式。第四条密钥和账号信息一定要放在 WorkBuddy 的加密存储里不要直接写死在流程里更不要把密码塞进正文或记录文件。自动化工具经常要调试、分享、备份密钥一旦泄露等于把整个博客的写入权限送了出去。5. 实际效果与使用建议5.1 从 20 分钟到 2 分钟流程对比技能跑顺之后我的发布流程变成了这样环节之前手工操作现在自动化操作内容准备无差别反正都要写无差别反正都要写格式整理粘贴后手工修格式5-10 分钟自动化转换技能内完成图片处理逐张上传、定位插入3-5 分钟自动压缩上传替换约 30 秒分类标签后台点选容易漏2-3 分钟自动映射预检报告可审查SEO 信息手工填表和摘要2-3 分钟自动生成发布后补齐结果确认预览、再发布2-3 分钟回读校验、自动返回链接整体算下来单篇内容从打开后台开始算到草稿出现在后台基本在两分钟以内。如果算上我后台点一下发布的时间也就多花十几秒。关键是这个过程不耗神我可以利用碎片时间把稿子丢进技能回头统一处理草稿写作和发布的节奏完全分开了。这条流水线跑起来之后我最大的感受不是快而是心理负担消失了。以前一想到发文章还要过一遍后台表单就有一种微妙的抗拒感现在完全没有。稿子写完丢出去剩下的事情交给技能我只保留最后的确认权。5.2 把技能用出更多花样「Z-Blog 文章发布」技能一旦稳定你会发现它的价值远不止省时间。顺着这条思路我后来又做了一些扩展都是基于同一个骨架批量导入旧文章。以前在其他平台写的内容整理成 Markdown 丢进技能自动补全分类和标签批量搬到 Z-Blog。定时发布草稿。技能发布到草稿箱后再配合一个定时任务到点自动把草稿改成发布状态实现预约发文。多博客同步。同一篇内容配置多个目标博客的分支流程一键同步到不同站点但我会刻意让各站的摘要和标题做差异化处理避免完全重复。发布前内容自检。在交到接口之前先让技能跑一遍错别字、敏感词、敏感链接的检查不合格就打回。不过扩展之前要记住一个原则每一个新功能都是在原有稳定骨架之上加的一个检查点或分支不要为了一次加太多功能把主流程弄复杂。我见过有人把技能扩展到一个流程里塞了十几种判断最后连自己都看不懂哪里出了问题。自动化追求的是可靠不是炫技。最后再分享一个我私心觉得最值得养成的习惯给技能加版本号。我每修改一次技能规则就在发布记录里记录本次使用的版本号。出问题的时候能快速定位是哪个版本的改动导致的回滚也有依据。一个小小的版本号让这个自动化系统真正进入了可持续维护的状态。