Z-Blog自动化发布：用WorkBuddy将发布流程压缩到两分钟

如果你平时写博客肯定有过这种体验文章憋了两个小时结果在后台发出来又折腾了十几分钟。特别是我这种用 Z-Blog 自建站的老用户每篇文章要处理的环节比想象中多得多——标题要起、摘要要写、标签要选、分类要挑还要配图、设摘要、调 SEO 描述最后点发布还得检查格式对不对。这个痛点我忍了很久直到我用 WorkBuddy 自己搭了一个「Z-Blog 文章发布」技能才真正体会到什么叫自动化。现在我把一篇写入本地文档的内容交给它从内容清洗、格式转换、元信息生成到最终调用接口发布全程两分钟左右。今天这篇文章就把我搭建这个技能的全过程、设计思路和踩过的坑完整记录下来给同样在用自建博客的朋友一个可以直接复现的参考方案。1. 先说清楚手动发布一篇博文到底要花多少时间1.1 那些看不见的重复动作当我还在手动发布的时候通常流程是这样的先在编辑器里把文章从笔记软件复制到 Z-Blog 后台然后开始做一大堆整理工作。Markdown 里的代码块有时会丢缩进图片链接要重新核对标题里的特殊符号要处理分段要检查。然后是元信息环节摘要得单独写一遍还不能超过后台设定的字数标签要想三五个分类要在下拉框里翻找。再往下还有 SEO 描述、关键词、发布时间这些字段全都得人工填一遍。等到全部填完点预览发现某个地方格式乱了又得回到编辑器重新排。这么一套下来我掐过表快的时候十二分钟遇到图片多或者格式杂的内容二十分钟很正常。但问题在于这二十分钟里没有任何一步是需要创作力的全是重复劳动。写分类、写摘要、填标签本质上就是「把已经写好的内容换个形式再说一遍」偏偏每一篇都必须做躲不掉。更要命的是这些动作看起来简单实际做起来却极度消耗耐心。摘要写短了显得单薄写长了被后台截断标签选得太泛文章没有辨识度分类选错整个栏目结构都会乱。每篇文章内容不同这些决策就得重新做一次二十篇文章就是二十次重复思考边际成本从来没有降下来过。1.2 二十分钟都耗在哪儿了我把手动发布的耗时拆开看过真正的机械操作大概只占四分之一剩下四分之三都花在「切换」上从文章编辑器切到后台页面、从后台页面切到分类管理、从内容思考切到填空决策。每切一次注意力就要重新收回来一次特别是写到一半忘了摘要要写什么免不了又回头翻文章。这种上下文切换的代价很难用秒来量化但它真实存在而且会让人产生一种「发文章好麻烦」的厌烦感。还有一个隐含成本因为发布太麻烦我会不自觉地把本可以单独成篇的小内容攒着攒到足够「值得走一次发布流程」才发。结果很多时效性内容过期了才上线。这也是我下决心做自动化的直接原因——不是嫌打字累而是发布环节已经反过来影响我的内容节奏了。今天这篇教程里我会把整个技能从设计到落地的细节都摊开讲看完你也能照着自己搭一套。2. 为什么我选择 WorkBuddy 来做这件事2.1 WorkBuddy 技能把「流程」变成「可对话的助手」WorkBuddy 这套工具的核心思路是让用户用自然语言加可视化流程的方式构建一个能自主执行多步骤任务的「技能」。一个技能可以理解为一条工作流它接收输入按顺序调用不同的处理节点中间还能嵌入 AI 判断。比如我这个发布技能接收一篇草案内容先清洗格式再生成元信息然后转换 HTML最后调用接口发布。每个节点可以是一个大模型提示词步骤也可以是一个 HTTP 请求步骤节点与节点之间的数据可以自动传递。这和我之前试过的写死脚本有本质区别。脚本最大的问题是没有判断力文章里出现一句引用它不知道这句话该不该放进摘要标题里有个冒号它不知道要不要按平台规则替换。而 WorkBuddy 里的大模型步骤能理解上下文我只需要把规则写进提示词剩下它自己判断。当然代价是每次执行要花一点推理时间但两分钟的耗时完全在可接受范围内。我用过一个类比来理解这件事脚本像一台自动售货机你投什么币它就出什么货换个新币种就失灵技能更像一个熟悉你业务的助理你把稿件推给它它知道哪些环节要动脑、哪些环节要照做做完还会回来跟你确认。这种灵活性正是做内容发布最需要的。2.2 路线选择接口对接而不是浏览器模拟我当时其实考虑过两条技术路线。第一条是类似浏览器 RPA 的方案让程序控制浏览器打开 Z-Blog 后台模拟人一步步点按钮。这条路线听起来万能实际上非常脆后台改一次界面结构流程就要重新录一遍页面加载慢一点等待节点就报错偶尔弹个验证码整个流程直接卡死。第二条是接口路线利用 Z-Blog 提供的 MetaWeblog 协议一种通用的博客发布接口标准很多博客系统都支持来创建文章、上传附件、设置分类标签。接口路线稳定得多只要字段格式对一秒钟就能完成发布。最终我选了接口路线。WorkBuddy 里的 HTTP 请求节点可以直接支持这套协议配合它内置的 XML 构造能力基本就是填写参数、发送请求、解析返回结果这三步。后面我会把每个请求的具体写法都贴出来。再说一个现实原因浏览器模拟方式需要一台一直开着的电脑跑客户端而接口方式可以放在云端执行。我有时在外面用手机写好初稿回家以后把文件拖进技能里任务就在云端跑完了完全不依赖我这台设备是否开机。这种使用方式上的自由度也是我坚持选接口路线的加分项。2.3 触发方式的取舍WorkBuddy 的技能支持多种触发方式手动触发、定时触发、事件触发。我在实际使用中最常用的是手动触发——把写好的 Markdown 文档直接拖进技能面板它就开始跑。定时触发我留给了每日早报类内容每天早上固定时间去抓取信息源生成一篇聚合文章再发布。事件触发用得少因为我的发布节奏还是以「我写完才发」为主完全放给自动化不太放心。这个取舍背后其实是一个原则自动化的边界要划在「我能把控风险」的位置。手动触发适合成品内容定时触发适合模式固定、容错率高的内容而事件触发则更适合把某个人工动作当成开关的场景。你如果不确定什么内容用哪种触发先从手动触发开始跑顺了再逐步放开这个节奏通常比较稳。3. 搭建过程WorkBuddy 技能配置全拆解3.1 第一步拿到 Z-Blog 的接口凭证要在 WorkBuddy 里调用 Z-Blog 的接口首先得有一组可用的发布凭证。Z-Blog 后台默认支持 MetaWeblog 接口一般在「应用中心」里启用相应的接口插件然后进入用户设置页面生成一个用于外部访问的专用密码或者接口 Token。我这里不推荐具体插件名字因为不同版本的差异挺大但关键点在于你需要确认接口地址形如https://你的域名/zb_users/plugin/.../xmlrpc.php具体路径取决于你的安装方式并且确认你的账号对这个地址有发布权限。拿到接口地址和凭证后我把它们存进 WorkBuddy 的安全变量里不在流程中明文出现。这里有个小建议如果用专用密码建议定期更换如果接口支持只读令牌和读写令牌分离尽量用权限最小的那个。发布用的读写令牌只在技能执行时被调用不要拿一个超级管理员账号的密码到处用否则一旦流程文件泄露风险会被放大。3.2 第二步设计输入输出和总体流程技能定义的第一步是明确输入和输出。我的输入设计得很简单就三个字段文章标题可选缺省时让 AI 根据正文起标题、正文内容Markdown 格式、分类名称可选缺省时用默认分类。输出则是发布成功后返回的文章编号和前台访问链接。总体流程我设计成五步串联。第一步内容清洗去掉多余空行、统一换行符、修正代码块的缩进第二步 AI 生成元信息产出摘要、标签、SEO 描述第三步把 Markdown 转成 Z-Blog 能正确渲染的 HTML第四步调用 MetaWeblog 接口创建文章第五步回读校验确认文章已发布且关键字段正确。每一步的输出都会作为下一步的输入WorkBuddy 的可视化画布上能直接看到数据的流向调试的时候很方便。有一个容易被忽略的设计点技能失败的时候要能定位到具体环节。我在每步之间都加了日志输出内容对应原文的哪个段落、哪些信息是 AI 生成的、哪些是接口返回的都记录在案。否则一旦发布出问题你根本不知道是提示词写得不好还是接口字段传错了排查成本会很高。3.3 第三步几个关键节点的配置细节内容清洗节点。这里我用的是「提示词加正则配合」的方式。提示词负责处理语义层的东西比如「删除全文开头的导航说明文字」「把每段之间多余的空行压缩为一行」正则负责处理格式层比如把 Windows 换行符\r\n统一替换成\n。为什么混用因为单靠正则很难识别「哪段是导航说明」而单靠大模型又容易在改格式时把代码内容改坏。两层配合清洗效果稳定很多。元信息生成节点。这是整个技能里最依赖大模型的一步。我在提示词里明确了三条硬规则摘要控制在 120 字以内必须能独立成文标签取 4 到 6 个优先使用文章中出现过的实体词SEO 描述在摘要基础上提炼加入 1 到 2 个长尾关键词。我用的提示词模板大致是这样的你是一位中文博客编辑。请根据给定的文章正文生成以下三项内容 1. 摘要120字以内独立成文直接提炼干货结论禁止空泛套话。 2. 标签4到6个优先使用正文中出现的实体词用逗号分隔。 3. SEO描述一句话60到100字自然融入1到2个核心关键词。 输出格式摘要...\n标签...\nSEO描述...为了避免模型越写越长我在节点后面加了一个字符截断的校验步骤超长直接切断。这里有个心得大模型对字数其实很不可靠宁可提示词给一个更小的目标值比如 100 字留出冗余也不要卡着上限写。120 字的上限实际让它按 100 字左右生成返回结果既不会超限读起来也更紧凑。Markdown 转 HTML 节点。Z-Blog 后台对纯文本和 HTML 的处理逻辑不同直接塞 Markdown 过去会渲染成一堆源码。我让大模型节点负责这个转换同时在提示词里强调「代码块保留原有缩进不要重新排版」「图片标签保持原样不要加外链属性」。实测下来转换后的 HTML 在后台预览里基本不需要手工调整比如列表的嵌套层级、表格的边框属性Z-Blog 自带的编辑器都能正确识别。3.4 第四步编排 HTTP 请求节点MetaWeblog 的调用本质上是一个 XML-RPC 请求。WorkBuddy 的 HTTP 节点可以直接构造 POST 请求我只需要把请求体按协议格式填好。最核心的方法是metaWeblog.newPost参数包括博客编号、用户名、密码、文章结构体、是否直接发布。文章结构体里要传title、description正文 HTML、categories分类名数组、mt_keywords标签多个用逗号分隔这些字段。请求体大概长这样?xml version1.0? methodCall methodNamemetaWeblog.newPost/methodName params paramvaluestring博客编号/string/value/param paramvaluestring用户名/string/value/param paramvaluestring专用密码或Token/string/value/param paramvaluestruct membernametitle/namevaluestring文章标题/string/value/member membernamedescription/namevaluestring转义后的正文HTML/string/value/member membernamecategories/namevaluearraydatavaluestring技术笔记/string/value/data/array/value/member membernamemt_keywords/namevaluestringPython,定时任务,调度框架/string/value/member /struct/value/param paramvalueboolean1/boolean/value/param /params /methodCall这里有个容易漏的细节description里的 HTML 内容包含大量特殊字符直接放进去会被 XML 解析器误判必须做转义处理。WorkBuddy 的流程节点里提供编码工具我加了一个步骤把正文中的、、、引号全部转成实体这才保证接口稳定返回成功。标签字段同理如果标签里带空格或者逗号也要先确认 Z-Blog 侧的解析规则否则会出现标签被拆开的情况。3.5 第五步发布结果的回读校验接口返回成功不代表万事大吉。我遇到过接口返回true、但文章实际没有出现在前台的情况所以我在流程末尾加了一个回读步骤再调用一次metaWeblog.getPost检查文章是否存在同时比对标题、摘要、分类是否符合预期。如果校验不通过整个技能会标记失败并输出当时的接口返回内容方便我针对性检查。这个回读步骤多花不到两秒但省了我好多次「发布完了才发现不对」的返工。另外我在校验步骤里还会做一次「前台可达性判断」。方式是请求刚发布文章的前台页面检查响应码和页面里是否包含文章标题的关键字。这一步能把「接口认为成功但前台实际 404」的情况也兜住。对于自建站来说这类问题往往出在伪静态规则没刷新或者缓存插件作祟靠接口回读不一定能发现加上这层判断才踏实。4. 完整实操从拖入文档到发布成功4.1 准备一篇测试内容为了验证流程我拿了一篇写好的技术笔记做测试。文章内容是一篇关于 Python 定时任务框架对比的笔记大概两千字包含两个代码块、三个小节标题、一组对比表格。我在本地用文本编辑器保存为 Markdown 文件文件名就叫「定时任务框架对比.md」分类名称填「技术笔记」然后把它拖进 WorkBuddy 技能窗口点击执行。这里说一个使用上的细节输入文件我建议用纯 Markdown不要从笔记软件直接导出带模板的富文本因为富文本里会混入大量应用自定义标签清洗节点处理起来容易误伤。如果你习惯在笔记软件里写导出前先复制成纯文本再调整一下标题层级流程跑起来会顺利很多。4.2 分步执行记录技能开始执行后我在日志面板里看到每一步的耗时。内容清洗大约用了不到十秒日志显示它移除了文件头部的几行笔记软件自动生成的导出信息把表格前后的多余空行清掉了。接下来元信息生成用了大约二十秒大模型给这篇文章生成了一句 112 字的摘要、五个标签Python、定时任务、调度框架、APScheduler、Cron以及一段包含「Python 定时任务对比」的 SEO 描述。格式转换和接口发布几乎是一瞬间的事。日志里可以看到 HTTP 请求的返回码是 200返回的 XML 里包含新文章的文章编号。最后的回读校验显示标题和摘要都正确整条流程跑完不到一分钟。我又看了眼时间距离我拖入文件才过了不到两分钟——这中间还包括我犹豫了一下要不要修改摘要的时间。整个过程里我唯一做的「人工工作」是检查了一下生成的标签有没有多余的空格然后点了确认。对比以前手动操作时要反复切换页面的状态这次的体验可以说是「无感」的。4.3 发布后的核对我打开 Z-Blog 前台页面文章已经出现在列表顶端。点进去看标题、摘要、标签、分类、代码块高亮全部正常表格也渲染成了预期的样式。唯一需要手工补的是一张封面图因为我的流程里暂时没做图片自动上传这是后面要扩展的点。整体上这一篇的发布体验和之前手动操作最大的区别是我不再需要反复确认「是不是忘了填什么」因为校验步骤已经替我确认过了。人工只需要做两件事一件事是在生成完元信息后扫一眼摘要和标签有没有硬伤另一件事是发布完成后去前台看整体排版是否舒服。这两件事都属于「判断」而不是「执行」正好是人和自动化各司其职的边界。5. 踩坑记录五个高频问题及排查思路5.1 正文发布后变成空白这是我最开始遇到的头号问题接口明明返回成功前台文章却是空的。排查下来原因出在 XML 转义上正文里有符号比如代码里的没有转义导致 XML-RPC 解析时把后续内容截断了。解决的思路很明确在上文提到过的转义步骤里把所有 XML 特殊字符都处理掉同时在转义后做个简单的自检看原始长度和转义后长度是否匹配。这个方法我一直沿用至今。排查这类问题的时候我建议你先看接口返回的原始报文而不是直接看前台页面。因为接口返回里通常会带部分解析错误信息直接定位到具体哪一段数据出了状况。前台页面只能告诉你「坏了」接口报文才能告诉你「哪一步坏了」。5.2 摘要被后台截断有一段时间我生成的摘要总是被 Z-Blog 截断显示排查发现是摘要字段超过了后台设置的字数上限。Z-Blog 的摘要字数限制可以在后台参数里调但更好的做法是在技能里就控制长度。我在提示词模板里明确写了「120 字以内」还加了一个硬截断校验双保险。这里要特别提醒不要把字数控制完全丢给提示词。大模型对字节数的感知非常不稳定中文内容一个字算几个字符在不同编码下还不一样。我的做法是让模型生成完后用流程节点里的字符串处理步骤按字符数硬截断到安全范围再把完整摘要存一份到日志里备查。该交给 AI 的判断交给 AI该用代码保证的事情用代码保证两边不混淆。5.3 分类匹配错误技能早期版本靠 AI 从「技术笔记」「生活随笔」「产品思考」三个分类里选一个正确率大约七成偶尔会把一篇明显是经验总结的文章归到产品思考里去。这个问题的根源是分类名太抽象AI 缺少判断依据。后来我在提示词里给每个分类补了一个说明比如「技术笔记包含技术教程、工具对比、踩坑记录」匹配正确率立刻上来了。如果你有大量的历史文章还可以在技能里加一步「参考历史分类比例」的约束让模型优先选择以往用得多的分类也能提高稳定度。更进阶的做法是维护一张「关键词到分类」的映射表在技能里先用规则命中命中不了再交给 AI 判断这样确定性最高。5.4 封面图一直传不上去图片上传是我目前唯一还没完全自动化的环节。Z-Blog 的接口支持上传附件并返回图片地址但我的使用场景里图片来源很杂有的在本地、有的在远端、有的需要先下载再上传情况各不相同。现阶段我的折中方案是技能先完成正文发布输出一个待办项提醒我手工补封面。后续我准备做一个独立的图片处理技能把「下载原图、压缩、上传、返回 URL」做成一整条链路再合并回发布流程里。如果你只需要处理单一来源的图片其实可以直接在发布技能里加一个上传节点用metaWeblog.newMediaObject方法把 base64 编码的图片数据传上去拿到返回的 URL 再替换正文里的占位符。这个功能的难点不在接口本身而在图片的预处理策略比如压缩到什么分辨率、需不需要生成缩略图这些规则需要花时间沉淀。5.5 定时发布的时间差问题用定时触发做早报内容的时候我发现文章的实际发布时间和我设定的时间差了八个小时。排查下来是时区设置问题WorkBuddy 执行环境默认用的是协调世界时而我的服务器在别的时区。后来我在 HTTP 请求节点里显式传入了本地时区偏移量并把发布时间设置统一换算成协调世界时再提交问题就解决了。顺带提醒一下如果你用同一个技能服务不同时区的站点最好把时区参数做成输入项而不是写死在流程里。做定时发布前也建议先用「保存草稿但不发布」的方式测试几次等确认时间显示正确了再放开真正的定时发布否则很容易在凌晨发现文章发错了时间。6. 效率对比和我的使用建议6.1 前后数据对比我把两个月的发布记录做了个粗略统计。手动发布阶段平均每篇从复制文章到点下发布按钮大约需要十六分钟遇到复杂格式能拖到二十五分钟使用技能之后从拖入文档到发布成功平均一分半加上我人工审核摘要和确认发布的半分钟总时长约两分钟。也就是说发布环节压缩到了原来的十分之一左右。更重要的是我现在可以放心地写短文、发速记了不用再为「发一篇还要折腾半天」而囤稿。以前我会把三四个想法攒成一篇长文来摊薄发布成本现在每篇各自成文单独发网站的更新频率自然上去了。读者能感受到的不只是发布变快了而是内容的新鲜度和连贯性都明显改善。6.2 哪些内容适合技能发布哪些不建议以我自己的实践经验结构清晰的文章非常适合走这条流程技术教程、工具对比、读书笔记、日报汇总元信息好生成、格式差异不大技能跑起来几乎不需要人工干预。而一些强排版、重设计的文章比如带大量自定义样式的专题页面、需要插入复杂组件的活动页不建议用技能发布这类内容更适合保留手工编辑的灵活性。另外凡是涉及重要的声明或者需要反复斟酌措辞的内容我也建议走人工审核通道。自动化只负责帮你生成草稿真正点发布之前人一定得从头到尾读一遍。这不是流程设计上的保守而是内容发布的底线效率再高也不能让机器的判断覆盖掉人的责任。6.3 后续还能扩展的方向这个技能做好之后我陆续想到几个可以继续扩展的方向。一是多平台分发现在每次发布只针对 Z-Blog其实可以把「生成元信息」这一步的结果复用到其他平台的接口上一次处理、多处发布。二是发布报告让技能在发布成功后生成一张包含文章链接、标签列表、预计阅读时间的简短报告推送到聊天工具里存个档方便月底复盘。三是接入图片处理子技能把封面图自动化的缺口补上。四是加入「发布前人工确认」的审批节点在真正提交接口之前停下来让我过一眼摘要和标签。这几个方向里我最推荐先做审批节点它能用最低的成本留住人的判断同时不破坏自动化带来的效率。实际上我现在已经把审批节点用起来了技能执行完所有前置步骤后会先挂起把生成的摘要、分类、标签推给我我在消息里回复「确认」它才执行最后的发布请求。这个改动让整个流程同时拥有了速度和可控性。如果你打算照着搭一套我个人最想强调的就一点自动化不是让你完全撒手而是把从「想发到发出来」之间的脏活累活接过去决策权保留在自己手里。真遇到复杂内容我还是会手动打开后台慢慢调但那种场景一个月也碰不上几次了。大部分文章走这个技能两分钟落地剩下的时间拿去做真正值得做的事。