如果你也在做内容站应该能体会这种说不出的累文章写完了但离“发出去”还隔着一段又长又无聊的操作流程。打开后台、新建文章、复制标题、粘贴正文、摘要重写一遍、选分类、填标签、找图传封面、检查 SEO 信息、再点发布……我粗略算过一篇 3000 字左右的教程文章从编辑器里复制出来到前台真的可见至少要 18 到 20 分钟。中间真正有创造性的工作几乎为零全是重复劳动还特别容易出错——标签漏填、分类选错、摘要和正文对不上哪一步都能让你再折回去改一遍。后来我用 WorkBuddy 自建了一个「Z-Blog 文章发布」技能把大部分机械动作交给了技能去跑。现在一篇文章从编辑文档里落地到网站前台2 分钟左右就能完成中间还包括了 AI 自动生成摘要和标签的时间。这篇文章就把这套技能从需求拆解、接口对接、完整配置到踩坑记录全部放出来给用 Z-Blog 做独立博客、企业站、内容站的博主或者运营一个可以直接抄作业的参考。1. 先算一笔账一篇内容的落地时间到底花在哪很多人以为写文章最费时间其实“写完”到“发出去”这段路才是被忽略的时间黑洞。我手动发布一篇标准文章时实际操作是这样的操作步骤耗时估算说明登录后台约 1 分钟打开登录页、输入账号密码、等待跳转新建文章约 0.5 分钟点菜单、点新建有时候还会误入页面编辑粘贴正文约 1 分钟长文档滚动复制偶尔格式错乱要重排整理摘要约 4 分钟要概括全文既要准确又要吸引点击选择分类约 1 分钟分类多了之后找正确分类也要翻页填写标签约 4 分钟想关键词、查相关词、控制数量最费脑上传封面图约 3 分钟本地找图、裁图、上传、替换默认图检查 SEO 设置约 2 分钟自定义标题、关键词、描述逐项确认预览检查约 2 分钟点预览、看排版、看标签是否生效点击发布约 0.5 分钟回列表页确认状态合计约 19 分钟熟练后也基本在 15 分钟以上拆开看你会发现真正必须“人来做”的只有一小部分。摘要和标签需要语义理解这是人脑的优势分类选择需要知道网站结构封面图需要审美判断。至于登录、粘贴、发布、确认这些本质上都是机械动作完全可以用一个技能把流程串起来。我最早也想过直接用一段 Python 脚本解决问题后来发现走不通。脚本只能解决“调用接口发布文章”这一步但发布之前需要准备的标题润色、摘要生成、标签提取靠纯规则做不好必须让大模型参与。这时候就体现出 WorkBuddy 这类技能平台的价值——可以把 AI 处理节点和接口调用节点编排到同一个流程里一次运行从头跑到尾。2. WorkBuddy 技能机制拆解先搞清楚技能是怎么工作的自建技能之前先要理解这类工具的核心逻辑。你可以把 WorkBuddy 技能想象成一条私人定制的流水线货品从一头进来经过几个工作站处理从另一头出来就已经是成品了。你不需要控制每个传送带怎么转只需要把各个工作站按顺序摆好。2.1 技能的四段式结构一个完整的发布技能通常由四个部分组成输入端定义这个技能收什么参数。我设计的发布技能输入很简单强制参数就一个“文章正文”可选参数包括“分类名称”“封面图 URL”“是否发布”。正文是最核心的原料其他都可以由 AI 辅助判断或走默认值。处理节点AI 节点这是技能里最聪明的部分。把原文喂给大模型让它按照预设规则输出标准化的 JSON 数据里面包含润色后的标题、一段摘要、一组标签。大模型的语义理解能力在这里替代了人工思考也是整个技能能提效的核心。执行节点接口节点把 AI 输出的字段映射到 Z-Blog 发布接口的请求参数上调用 XML-RPC 接口完成文章创建。这个节点要保证确定性接口参数是什么就传什么不允许模型自由发挥。反馈节点发布完成后把返回的文章链接和 ID 作为技能输出方便你确认结果。如果失败则暴露错误信息方便排查。这个四段式结构看起来很基础但它把“智能决策”和“机械执行”分得很清楚。AI 只负责生成内容元数据决定发不发、发到哪个分类、要不要定时这些规则仍然由人来定死。确定了的行为不做任何“智能优化”这是一个非常关键的设计原则。2.2 AI 只做辅助不做决定有一点要特别注意不要把发布动作本身交给 AI 做决定。比如让模型自由判断“这篇文章要不要发布”或者“应该发到哪个分类”它可能今天觉得可以发明天觉得不行结果完全不可控。我的做法是分类和发布状态一律走用户输入或默认值AI 只负责生成标题、摘要、标签这三个文本字段。标题、摘要、标签恰恰是手动发布时耗时最长、最需要“想”的部分。标题要既准确又有吸引力摘要要在 120 字左右压缩全文核心标签要覆盖文章的不同检索角度。这三样正好是大模型擅长的任务交给 AI 处理既省时间质量也稳定。2.3 技能的可复用性另一个选择 WorkBuddy 而不是硬编码脚本的理由是复用性。建好一次技能之后每次使用只需要输入正文即可不用管接口细节。不同平台的发布技能可以在同一个工作空间里维护。你甚至可以在此基础上再叠一层把多个发布技能组合起来实现一篇文章同时分发到几个博客站点的效果。这个后文会单独说一下。3. 对接 Z-Blog发布接口选型与代码实现技能有了骨架接下来要解决最关键的问题怎么把文章真实地写进 Z-Blog这里接口选型非常重要选错了方案后面的环节都会跟着难受。3.1 三个可选方案对接 Z-Blog 的自动化发布方式主流上有三条路XML-RPC 接口Z-Blog 自带的远程发布接口可以在根目录的xmlrpc.php找到。支持标准的 MetaWeblog API 和 Blogger API任何编程语言都可以调用不需要额外装插件。第三方 REST API 插件应用中心有一些第三方插件提供更现代的 REST 接口返回 JSON语义更清晰。但依赖插件维护升级博客版本时可能不兼容。浏览器自动化用模拟点击的方式操作后台页面理论上可行但脚本脆弱后台改个按钮名就白写了而且登录态维护麻烦不建议。我选了方案一XML-RPC 接口。最大理由是这是 Z-Blog 自带的能力不需要依赖第三方插件升级也不容易坏。MetaWeblog API 是很多博客系统通用的老牌协议资料相对齐全用起来稳定。3.2 MetaWeblog API 的核心方法MetaWeblog API 里最常用的方法有三个metaWeblog.newPost发布新文章metaWeblog.editPost编辑已有文章metaWeblog.getCategories获取分类列表newPost的参数结构是这个样子参数位参数名含义第 1 个blogid博客 IDZ-Blog 默认填1第 2 个username后台登录用户名第 3 个password应用专用密码第 4 个struct文章内容结构体第 5 个publish布尔值True直接发布False存草稿其中struct结构体里最常用的字段是title文章标题description文章正文支持 HTML 格式categories分类名称数组mt_keywords标签用英文逗号分隔mt_excerpt文章摘要3.3 Python 调用示例我用 Python 写了一个最小可用的调用函数这里的关键点是不需要引入任何第三方库用 Python 自带的xmlrpc.client就够了。import xmlrpc.client def publish_post( xmlrpc_url: str, username: str, password: str, title: str, content_html: str, category: str, tags: str, excerpt: str, publish: bool True, ): server xmlrpc.client.ServerProxy(xmlrpc_url) post_struct { title: title, description: content_html, categories: [category], mt_keywords: tags, mt_excerpt: excerpt, } post_id server.metaWeblog.newPost( 1, username, password, post_struct, publish, ) return post_id # 使用示例 post_id publish_post( xmlrpc_urlhttps://你的域名/xmlrpc.php, username你的用户名, password你的应用密码, title示例文章标题, content_htmlp这里是文章正文支持b加粗/b等HTML标签。/p, category技术笔记, tags博客,自动化,ZBlog, excerpt这是一段摘要一句话说清文章核心内容。, publishTrue, ) print(文章ID:, post_id)函数返回的post_id就是新发布文章的文章 ID可以根据这个 ID 拼接出前台文章链接https://你的域名/post/{post_id}.html也可以把这个链接作为技能输出回显。3.4 一个关键细节应用专用密码调用接口时用的密码一定要重视。Z-Blog 后台的用户中心里可以单独生成一串“应用密码”专门给 API 调用使用。不要直接拿登录密码去调接口登录密码一旦在平台配置里泄露你的博客后台就等于裸奔了。我在 WorkBuddy 的技能参数里只存应用密码即使配置不小心被导出损失也有限随时可以去后台重置。3.5 获取分类列表如果你的博客分类比较多想先看看分类 ID 或者名称可以用getCategories方法categories server.metaWeblog.getCategories(1, username, password) for cat in categories: print(cat[categoryId], cat[categoryName])这一步通常在技能配置阶段做一次就够了把分类名称和 ID 记下来后续发布直接填名称即可。4. 全流程实操把发布技能一步步配置出来接口代码验证没问题之后就可以进入 WorkBuddy 里正式搭技能了。下面按实际配置顺序走一遍注意不同版本的工具界面可能有差异但整体思路通用。4.1 准备阶段在开始配置之前先把这些东西放在手边Z-Blog 前台域名包括xmlrpc.php所在的完整 URL后台用户名和应用专用密码一篇测试用的短文章HTML 格式一个分类名称比如“技术笔记”把密码填进技能配置的时候我建议使用工具提供的加密变量或者密钥管理功能而不是直接明文写在参数里。WorkBuddy 这类平台一般支持变量引用如果你找不到加密变量至少把技能设为私有可见别分享给别人。4.2 创建技能并定义输入参数新建技能命名成“Z-Blog 文章发布”。输入端我定义了这几个字段正文内容必填手动粘贴文章正文分类选填默认值填“未分类”或你最常用的分类封面图 URL选填如果没有封面则留空是否发布默认勾选“直接发布”取消勾选则存草稿有一个小技巧正文内容支持 HTML 粘贴这样从编辑器复制过来时加粗、链接、小标题这些样式基本能保留。如果你从 Word 复制最好先经过一遍“清除格式再重新粘贴”的过程或者让 AI 节点顺手把 HTML 清洗一遍。4.3 配置 AI 处理节点AI 节点是整个技能里的“内容加工站”。这个节点接收上一步输入的正文然后输出一段 JSON。提示词我写得比较明确直接贴出来供参考你是一名熟悉内容运营的编辑。下面是一篇已经写好的博客正文请完成三个任务 1. 提取一个适合作为博客标题的字段要求准确概括全文包含核心关键词不超过30个汉字。 2. 编写一段文章摘要要求120字以内说清文章解决的问题和结论不写成“本文介绍了”这类套话。 3. 提取3到8个标签每个标签不超过10个汉字覆盖主题、场景、技术关键词三个角度。 请只输出一个 JSON 对象不要输出解释文字格式如下 {title: ..., excerpt: ..., tags: [标签1, 标签2]}这里有两个值得讲的细节。第一提示词里明确写了“不写成‘本文介绍了’这类套话”这是因为我发现模型在生成摘要时特别容易落入这种模板给一句负面提示能明显改善结果。第二要求 AI 只输出 JSON、不输出解释文字是为了下游节点可以直接解析。如果模型多输出一句“好的这是你的标题”整个解析就会炸掉这种约束必须在提示词里提前写死。4.4 配置接口调用节点AI 节点准备好之后接着配接口节点。这里取决于 WorkBuddy 支持的能力如果它有“脚本节点”或者“函数节点”直接把上面那段 Python 函数放进去把 AI 节点的输出映射成函数参数即可。如果版本只支持通用 HTTP 请求节点有一个绕不开的麻烦XML-RPC 的请求体是 XML 格式不是常见的 JSON普通 HTTP 节点构建这种请求比较别扭。我的建议是写一个极简的本地转换层比如用某个云函数或者一直在跑的常驻服务暴露一个 JSON 接口内部再转成 XML-RPC 调用。外部请求{ title: ..., content_html: ..., category: 技术笔记, tags: ..., excerpt: ..., publish: true }然后由这个转换层组装 XML-RPC 请求发给 Z-Blog。这样 WorkBuddy 里只需要配置一个普通的 HTTP 调用返回 JSON 也更容易解析。接口节点的参数映射大致是正文内容→content_html分类→categoryAI 输出的title→titleAI 输出的excerpt→excerptAI 输出的tags数组 → 用逗号拼接成tags字符串是否发布→publish4.5 编排顺序与反馈输出在技能编排面板里把流程连成一条线输入端 → AI 节点 → 接口节点 → 输出端。输出端需要定义一个结果展示模板我用的是“发布成功文章ID 链接”的格式。接口节点返回post_id之后输出端模板会自动把链接拼出来发布成功 文章ID: {{post_id}} 文章地址: {{domain}}/post/{{post_id}}.html这样你运行一次技能最后看到的不是一堆原始返回数据而是一条可以直接点开的文章链接体验上完整得多。4.6 首次运行验证配置完成后用一篇测试文章跑一遍。第一轮运行我建议把“是否发布”设置成存草稿先到后台确认正文、标题、摘要、标签都正确再改成正式发布。这样即使接口逻辑有问题也不会把垃圾内容直接推到线上。确认草稿没问题后再发布一篇正式文章。发布完成回后台看文章列表确认分类正确、标签生效、摘要显示正常、前台页面可以打开。到这里整个技能就算是落地了。5. 踩坑记录发布过程中最常见的 7 个问题和排查实录这个技能我前前后后跑了上百次中间踩了不少坑。下面按出现频率从高到低整理一份问题速查表每个问题是真实遇到过的排查思路也是实际验证过的。5.1 问题速查表现象原因解决办法返回成功但前台没有文章把publish参数设成了False成了草稿确认参数传值True/False 别写成字符串AI 节点 JSON 解析失败模型多输出了解释文字或换行符提示词里明确“只输出 JSON”解析时做前后缀清理标签全挤在一起数组忘了用逗号拼接强制转成英文逗号分隔的字符串检查是否有中文逗号标题超过 60 字被截断没有在提示词里限制字数提示词加“不超过 30 个汉字”接口侧再加一道长度校验分类不存在导致 500 错误传入了后台不存在的分类名称先调getCategories梳理全部分类再配置默认值正文图片全部丢失正文里的图片 URL 是相对路径让 AI 节点清理 HTML相对路径替换为绝对域名前缀接口偶发超时长文正文体积大加上网络波动设置 30 秒以上超时并增加一次重试机制5.2 最容易被忽略的坑AI 节点生成的标签字符数有一个问题排查了很久才发现Z-Blog 对单个标签的字符数有上限一旦超过就会静默丢弃甚至导致整篇文章发布失败。我的经验是在提示词里强制“每个标签不超过 10 个汉字”同时在接口节点拼接标签前用代码再截断一次双保险。5.3 永久链接格式的坑Z-Blog 默认的永久链接格式可能不是/post/{id}.html老版本或者改过固定链接配置的站点可能不一样。拼接反馈链接时不建议写死格式最好从返回的post_id出发手动到前台确认一次链接结构再把模板改成实际格式。我见过有人技能里拼的链接和实际路径不一致每次都要手动改地址等于白自动化了。5.4 正文 HTML 清洗的坑从富文本编辑器复制过来的正文经常会带上一堆冗余的span、style属性、空段落。直接扔给 Z-Blog 也能用但前台排版会很乱。我的做法是在 AI 节点之后加一个 HTML 清洗提示词让模型保留下标题层级、段落、加粗、链接、图片这些核心标签去掉行内样式和空标签。这一步优化完之后前后台显示干净很多。5.5 密码中的特殊字符应用密码如果包含、、#这类特殊字符在某些 HTTP 请求封装里可能会被转义或截断。稳妥的做法是生成应用密码之后手动检查一遍是否包含特殊字符如果有重置一次密码只用大小写字母和数字。5.6 分类名称前导空格和大小写Z-Blog 的分类名称匹配是严格区分空格和大小写的。“技术笔记”和“技术笔记 ”是两个分类后者不存在发布就会报错。AI 节点如果负责输出分类名称务必在提示词里要求原样输出用户输入的分类名称不要润色、不要加空格。5.7 批量发布时的限流问题如果你不只是发布一篇而是要把旧平台的历史文章整体迁入一次性并发几十个请求很容易触发服务器的连接数限制。实测下来连续发布而不是并发发布间隔 2 到 3 秒成功率最高。WorkBuddy 技能可以加一个延时节点批量场景下非常有用。6. 从二十分钟到两分钟复盘效果和适用边界技能跑稳之后我做了一次相对正式的时间对比测试用同一篇文章分别走手动流程和技能流程记录从正文复制完成到前台可见的耗时环节手动耗时技能耗时登录后台约 1 分钟0新建文章约 0.5 分钟0粘贴正文约 1 分钟约 10 秒输入正文生成摘要约 4 分钟约 20 秒AI 节点填写标签约 4 分钟约 15 秒AI 节点选择分类约 1 分钟5 秒默认值上传封面约 3 分钟约 20 秒传图 URLSEO 设置约 2 分钟约 5 秒接口自动写入发布确认约 2 分钟约 5 秒返回链接合计约 18.5 分钟约 80 秒这个对比没有算上 AI 节点偶尔需要手动修正的情况但即使加上修正时间控制在 3 分钟以内也完全没问题。最直接的变化是人从“操作者”变成了“检查者”和“兜底者”不再需要盯着后台界面一步步点。这套方案适合什么人我做下来觉得最明显受益的是这几类场景每天更新多个站点的内容运营能省出大量重复操作时间需要高频同步教程类、资讯类内容的博主批量转载或分发时效率提升极其明显临时有多篇文章需要补发、补标签、补摘要的维护场景不用一篇篇后台改不太适合的场景也要说清楚。如果你的文章每篇都要手写大量定制化封面、配图说明或者需要频繁手动调整特殊字段那么技能只能帮你完成一部分瓶颈会转移到素材准备环节。另外如果博客后台本身配置复杂、有大量自定义字段接口层可能需要额外扩展这类需求不属于本文的通用方案范围。我在实际使用中体会最深的一件事情是自动化技能能不能真正省时间关键不在于把多少个按钮变成自动而在于敢不敢把那些“需要动脑但其实不复杂”的环节交给 AI。摘要和标签以前总觉得要自己想才放心跑了几十篇之后发现模型输出的质量并不比我手写差多少而速度是我的几十倍。放掉那点“不放心”时间才真的省下来了。最后再分享一个小经验这套技能后续可以扩展成一个“文章分发中心”。在 WorkBuddy 里把同一个正文同时接到多个站点的发布技能上跑一次就同步发到两三个博客站点标签和摘要按各站规则自动适配。我现在的新内容基本都走这条链路运营效率相比单站点时代又上了一个台阶。 用WorkBuddy编排Z-Blog自动化发布：从20分钟到2分钟
如果你也在做内容站应该能体会这种说不出的累文章写完了但离“发出去”还隔着一段又长又无聊的操作流程。打开后台、新建文章、复制标题、粘贴正文、摘要重写一遍、选分类、填标签、找图传封面、检查 SEO 信息、再点发布……我粗略算过一篇 3000 字左右的教程文章从编辑器里复制出来到前台真的可见至少要 18 到 20 分钟。中间真正有创造性的工作几乎为零全是重复劳动还特别容易出错——标签漏填、分类选错、摘要和正文对不上哪一步都能让你再折回去改一遍。后来我用 WorkBuddy 自建了一个「Z-Blog 文章发布」技能把大部分机械动作交给了技能去跑。现在一篇文章从编辑文档里落地到网站前台2 分钟左右就能完成中间还包括了 AI 自动生成摘要和标签的时间。这篇文章就把这套技能从需求拆解、接口对接、完整配置到踩坑记录全部放出来给用 Z-Blog 做独立博客、企业站、内容站的博主或者运营一个可以直接抄作业的参考。1. 先算一笔账一篇内容的落地时间到底花在哪很多人以为写文章最费时间其实“写完”到“发出去”这段路才是被忽略的时间黑洞。我手动发布一篇标准文章时实际操作是这样的操作步骤耗时估算说明登录后台约 1 分钟打开登录页、输入账号密码、等待跳转新建文章约 0.5 分钟点菜单、点新建有时候还会误入页面编辑粘贴正文约 1 分钟长文档滚动复制偶尔格式错乱要重排整理摘要约 4 分钟要概括全文既要准确又要吸引点击选择分类约 1 分钟分类多了之后找正确分类也要翻页填写标签约 4 分钟想关键词、查相关词、控制数量最费脑上传封面图约 3 分钟本地找图、裁图、上传、替换默认图检查 SEO 设置约 2 分钟自定义标题、关键词、描述逐项确认预览检查约 2 分钟点预览、看排版、看标签是否生效点击发布约 0.5 分钟回列表页确认状态合计约 19 分钟熟练后也基本在 15 分钟以上拆开看你会发现真正必须“人来做”的只有一小部分。摘要和标签需要语义理解这是人脑的优势分类选择需要知道网站结构封面图需要审美判断。至于登录、粘贴、发布、确认这些本质上都是机械动作完全可以用一个技能把流程串起来。我最早也想过直接用一段 Python 脚本解决问题后来发现走不通。脚本只能解决“调用接口发布文章”这一步但发布之前需要准备的标题润色、摘要生成、标签提取靠纯规则做不好必须让大模型参与。这时候就体现出 WorkBuddy 这类技能平台的价值——可以把 AI 处理节点和接口调用节点编排到同一个流程里一次运行从头跑到尾。2. WorkBuddy 技能机制拆解先搞清楚技能是怎么工作的自建技能之前先要理解这类工具的核心逻辑。你可以把 WorkBuddy 技能想象成一条私人定制的流水线货品从一头进来经过几个工作站处理从另一头出来就已经是成品了。你不需要控制每个传送带怎么转只需要把各个工作站按顺序摆好。2.1 技能的四段式结构一个完整的发布技能通常由四个部分组成输入端定义这个技能收什么参数。我设计的发布技能输入很简单强制参数就一个“文章正文”可选参数包括“分类名称”“封面图 URL”“是否发布”。正文是最核心的原料其他都可以由 AI 辅助判断或走默认值。处理节点AI 节点这是技能里最聪明的部分。把原文喂给大模型让它按照预设规则输出标准化的 JSON 数据里面包含润色后的标题、一段摘要、一组标签。大模型的语义理解能力在这里替代了人工思考也是整个技能能提效的核心。执行节点接口节点把 AI 输出的字段映射到 Z-Blog 发布接口的请求参数上调用 XML-RPC 接口完成文章创建。这个节点要保证确定性接口参数是什么就传什么不允许模型自由发挥。反馈节点发布完成后把返回的文章链接和 ID 作为技能输出方便你确认结果。如果失败则暴露错误信息方便排查。这个四段式结构看起来很基础但它把“智能决策”和“机械执行”分得很清楚。AI 只负责生成内容元数据决定发不发、发到哪个分类、要不要定时这些规则仍然由人来定死。确定了的行为不做任何“智能优化”这是一个非常关键的设计原则。2.2 AI 只做辅助不做决定有一点要特别注意不要把发布动作本身交给 AI 做决定。比如让模型自由判断“这篇文章要不要发布”或者“应该发到哪个分类”它可能今天觉得可以发明天觉得不行结果完全不可控。我的做法是分类和发布状态一律走用户输入或默认值AI 只负责生成标题、摘要、标签这三个文本字段。标题、摘要、标签恰恰是手动发布时耗时最长、最需要“想”的部分。标题要既准确又有吸引力摘要要在 120 字左右压缩全文核心标签要覆盖文章的不同检索角度。这三样正好是大模型擅长的任务交给 AI 处理既省时间质量也稳定。2.3 技能的可复用性另一个选择 WorkBuddy 而不是硬编码脚本的理由是复用性。建好一次技能之后每次使用只需要输入正文即可不用管接口细节。不同平台的发布技能可以在同一个工作空间里维护。你甚至可以在此基础上再叠一层把多个发布技能组合起来实现一篇文章同时分发到几个博客站点的效果。这个后文会单独说一下。3. 对接 Z-Blog发布接口选型与代码实现技能有了骨架接下来要解决最关键的问题怎么把文章真实地写进 Z-Blog这里接口选型非常重要选错了方案后面的环节都会跟着难受。3.1 三个可选方案对接 Z-Blog 的自动化发布方式主流上有三条路XML-RPC 接口Z-Blog 自带的远程发布接口可以在根目录的xmlrpc.php找到。支持标准的 MetaWeblog API 和 Blogger API任何编程语言都可以调用不需要额外装插件。第三方 REST API 插件应用中心有一些第三方插件提供更现代的 REST 接口返回 JSON语义更清晰。但依赖插件维护升级博客版本时可能不兼容。浏览器自动化用模拟点击的方式操作后台页面理论上可行但脚本脆弱后台改个按钮名就白写了而且登录态维护麻烦不建议。我选了方案一XML-RPC 接口。最大理由是这是 Z-Blog 自带的能力不需要依赖第三方插件升级也不容易坏。MetaWeblog API 是很多博客系统通用的老牌协议资料相对齐全用起来稳定。3.2 MetaWeblog API 的核心方法MetaWeblog API 里最常用的方法有三个metaWeblog.newPost发布新文章metaWeblog.editPost编辑已有文章metaWeblog.getCategories获取分类列表newPost的参数结构是这个样子参数位参数名含义第 1 个blogid博客 IDZ-Blog 默认填1第 2 个username后台登录用户名第 3 个password应用专用密码第 4 个struct文章内容结构体第 5 个publish布尔值True直接发布False存草稿其中struct结构体里最常用的字段是title文章标题description文章正文支持 HTML 格式categories分类名称数组mt_keywords标签用英文逗号分隔mt_excerpt文章摘要3.3 Python 调用示例我用 Python 写了一个最小可用的调用函数这里的关键点是不需要引入任何第三方库用 Python 自带的xmlrpc.client就够了。import xmlrpc.client def publish_post( xmlrpc_url: str, username: str, password: str, title: str, content_html: str, category: str, tags: str, excerpt: str, publish: bool True, ): server xmlrpc.client.ServerProxy(xmlrpc_url) post_struct { title: title, description: content_html, categories: [category], mt_keywords: tags, mt_excerpt: excerpt, } post_id server.metaWeblog.newPost( 1, username, password, post_struct, publish, ) return post_id # 使用示例 post_id publish_post( xmlrpc_urlhttps://你的域名/xmlrpc.php, username你的用户名, password你的应用密码, title示例文章标题, content_htmlp这里是文章正文支持b加粗/b等HTML标签。/p, category技术笔记, tags博客,自动化,ZBlog, excerpt这是一段摘要一句话说清文章核心内容。, publishTrue, ) print(文章ID:, post_id)函数返回的post_id就是新发布文章的文章 ID可以根据这个 ID 拼接出前台文章链接https://你的域名/post/{post_id}.html也可以把这个链接作为技能输出回显。3.4 一个关键细节应用专用密码调用接口时用的密码一定要重视。Z-Blog 后台的用户中心里可以单独生成一串“应用密码”专门给 API 调用使用。不要直接拿登录密码去调接口登录密码一旦在平台配置里泄露你的博客后台就等于裸奔了。我在 WorkBuddy 的技能参数里只存应用密码即使配置不小心被导出损失也有限随时可以去后台重置。3.5 获取分类列表如果你的博客分类比较多想先看看分类 ID 或者名称可以用getCategories方法categories server.metaWeblog.getCategories(1, username, password) for cat in categories: print(cat[categoryId], cat[categoryName])这一步通常在技能配置阶段做一次就够了把分类名称和 ID 记下来后续发布直接填名称即可。4. 全流程实操把发布技能一步步配置出来接口代码验证没问题之后就可以进入 WorkBuddy 里正式搭技能了。下面按实际配置顺序走一遍注意不同版本的工具界面可能有差异但整体思路通用。4.1 准备阶段在开始配置之前先把这些东西放在手边Z-Blog 前台域名包括xmlrpc.php所在的完整 URL后台用户名和应用专用密码一篇测试用的短文章HTML 格式一个分类名称比如“技术笔记”把密码填进技能配置的时候我建议使用工具提供的加密变量或者密钥管理功能而不是直接明文写在参数里。WorkBuddy 这类平台一般支持变量引用如果你找不到加密变量至少把技能设为私有可见别分享给别人。4.2 创建技能并定义输入参数新建技能命名成“Z-Blog 文章发布”。输入端我定义了这几个字段正文内容必填手动粘贴文章正文分类选填默认值填“未分类”或你最常用的分类封面图 URL选填如果没有封面则留空是否发布默认勾选“直接发布”取消勾选则存草稿有一个小技巧正文内容支持 HTML 粘贴这样从编辑器复制过来时加粗、链接、小标题这些样式基本能保留。如果你从 Word 复制最好先经过一遍“清除格式再重新粘贴”的过程或者让 AI 节点顺手把 HTML 清洗一遍。4.3 配置 AI 处理节点AI 节点是整个技能里的“内容加工站”。这个节点接收上一步输入的正文然后输出一段 JSON。提示词我写得比较明确直接贴出来供参考你是一名熟悉内容运营的编辑。下面是一篇已经写好的博客正文请完成三个任务 1. 提取一个适合作为博客标题的字段要求准确概括全文包含核心关键词不超过30个汉字。 2. 编写一段文章摘要要求120字以内说清文章解决的问题和结论不写成“本文介绍了”这类套话。 3. 提取3到8个标签每个标签不超过10个汉字覆盖主题、场景、技术关键词三个角度。 请只输出一个 JSON 对象不要输出解释文字格式如下 {title: ..., excerpt: ..., tags: [标签1, 标签2]}这里有两个值得讲的细节。第一提示词里明确写了“不写成‘本文介绍了’这类套话”这是因为我发现模型在生成摘要时特别容易落入这种模板给一句负面提示能明显改善结果。第二要求 AI 只输出 JSON、不输出解释文字是为了下游节点可以直接解析。如果模型多输出一句“好的这是你的标题”整个解析就会炸掉这种约束必须在提示词里提前写死。4.4 配置接口调用节点AI 节点准备好之后接着配接口节点。这里取决于 WorkBuddy 支持的能力如果它有“脚本节点”或者“函数节点”直接把上面那段 Python 函数放进去把 AI 节点的输出映射成函数参数即可。如果版本只支持通用 HTTP 请求节点有一个绕不开的麻烦XML-RPC 的请求体是 XML 格式不是常见的 JSON普通 HTTP 节点构建这种请求比较别扭。我的建议是写一个极简的本地转换层比如用某个云函数或者一直在跑的常驻服务暴露一个 JSON 接口内部再转成 XML-RPC 调用。外部请求{ title: ..., content_html: ..., category: 技术笔记, tags: ..., excerpt: ..., publish: true }然后由这个转换层组装 XML-RPC 请求发给 Z-Blog。这样 WorkBuddy 里只需要配置一个普通的 HTTP 调用返回 JSON 也更容易解析。接口节点的参数映射大致是正文内容→content_html分类→categoryAI 输出的title→titleAI 输出的excerpt→excerptAI 输出的tags数组 → 用逗号拼接成tags字符串是否发布→publish4.5 编排顺序与反馈输出在技能编排面板里把流程连成一条线输入端 → AI 节点 → 接口节点 → 输出端。输出端需要定义一个结果展示模板我用的是“发布成功文章ID 链接”的格式。接口节点返回post_id之后输出端模板会自动把链接拼出来发布成功 文章ID: {{post_id}} 文章地址: {{domain}}/post/{{post_id}}.html这样你运行一次技能最后看到的不是一堆原始返回数据而是一条可以直接点开的文章链接体验上完整得多。4.6 首次运行验证配置完成后用一篇测试文章跑一遍。第一轮运行我建议把“是否发布”设置成存草稿先到后台确认正文、标题、摘要、标签都正确再改成正式发布。这样即使接口逻辑有问题也不会把垃圾内容直接推到线上。确认草稿没问题后再发布一篇正式文章。发布完成回后台看文章列表确认分类正确、标签生效、摘要显示正常、前台页面可以打开。到这里整个技能就算是落地了。5. 踩坑记录发布过程中最常见的 7 个问题和排查实录这个技能我前前后后跑了上百次中间踩了不少坑。下面按出现频率从高到低整理一份问题速查表每个问题是真实遇到过的排查思路也是实际验证过的。5.1 问题速查表现象原因解决办法返回成功但前台没有文章把publish参数设成了False成了草稿确认参数传值True/False 别写成字符串AI 节点 JSON 解析失败模型多输出了解释文字或换行符提示词里明确“只输出 JSON”解析时做前后缀清理标签全挤在一起数组忘了用逗号拼接强制转成英文逗号分隔的字符串检查是否有中文逗号标题超过 60 字被截断没有在提示词里限制字数提示词加“不超过 30 个汉字”接口侧再加一道长度校验分类不存在导致 500 错误传入了后台不存在的分类名称先调getCategories梳理全部分类再配置默认值正文图片全部丢失正文里的图片 URL 是相对路径让 AI 节点清理 HTML相对路径替换为绝对域名前缀接口偶发超时长文正文体积大加上网络波动设置 30 秒以上超时并增加一次重试机制5.2 最容易被忽略的坑AI 节点生成的标签字符数有一个问题排查了很久才发现Z-Blog 对单个标签的字符数有上限一旦超过就会静默丢弃甚至导致整篇文章发布失败。我的经验是在提示词里强制“每个标签不超过 10 个汉字”同时在接口节点拼接标签前用代码再截断一次双保险。5.3 永久链接格式的坑Z-Blog 默认的永久链接格式可能不是/post/{id}.html老版本或者改过固定链接配置的站点可能不一样。拼接反馈链接时不建议写死格式最好从返回的post_id出发手动到前台确认一次链接结构再把模板改成实际格式。我见过有人技能里拼的链接和实际路径不一致每次都要手动改地址等于白自动化了。5.4 正文 HTML 清洗的坑从富文本编辑器复制过来的正文经常会带上一堆冗余的span、style属性、空段落。直接扔给 Z-Blog 也能用但前台排版会很乱。我的做法是在 AI 节点之后加一个 HTML 清洗提示词让模型保留下标题层级、段落、加粗、链接、图片这些核心标签去掉行内样式和空标签。这一步优化完之后前后台显示干净很多。5.5 密码中的特殊字符应用密码如果包含、、#这类特殊字符在某些 HTTP 请求封装里可能会被转义或截断。稳妥的做法是生成应用密码之后手动检查一遍是否包含特殊字符如果有重置一次密码只用大小写字母和数字。5.6 分类名称前导空格和大小写Z-Blog 的分类名称匹配是严格区分空格和大小写的。“技术笔记”和“技术笔记 ”是两个分类后者不存在发布就会报错。AI 节点如果负责输出分类名称务必在提示词里要求原样输出用户输入的分类名称不要润色、不要加空格。5.7 批量发布时的限流问题如果你不只是发布一篇而是要把旧平台的历史文章整体迁入一次性并发几十个请求很容易触发服务器的连接数限制。实测下来连续发布而不是并发发布间隔 2 到 3 秒成功率最高。WorkBuddy 技能可以加一个延时节点批量场景下非常有用。6. 从二十分钟到两分钟复盘效果和适用边界技能跑稳之后我做了一次相对正式的时间对比测试用同一篇文章分别走手动流程和技能流程记录从正文复制完成到前台可见的耗时环节手动耗时技能耗时登录后台约 1 分钟0新建文章约 0.5 分钟0粘贴正文约 1 分钟约 10 秒输入正文生成摘要约 4 分钟约 20 秒AI 节点填写标签约 4 分钟约 15 秒AI 节点选择分类约 1 分钟5 秒默认值上传封面约 3 分钟约 20 秒传图 URLSEO 设置约 2 分钟约 5 秒接口自动写入发布确认约 2 分钟约 5 秒返回链接合计约 18.5 分钟约 80 秒这个对比没有算上 AI 节点偶尔需要手动修正的情况但即使加上修正时间控制在 3 分钟以内也完全没问题。最直接的变化是人从“操作者”变成了“检查者”和“兜底者”不再需要盯着后台界面一步步点。这套方案适合什么人我做下来觉得最明显受益的是这几类场景每天更新多个站点的内容运营能省出大量重复操作时间需要高频同步教程类、资讯类内容的博主批量转载或分发时效率提升极其明显临时有多篇文章需要补发、补标签、补摘要的维护场景不用一篇篇后台改不太适合的场景也要说清楚。如果你的文章每篇都要手写大量定制化封面、配图说明或者需要频繁手动调整特殊字段那么技能只能帮你完成一部分瓶颈会转移到素材准备环节。另外如果博客后台本身配置复杂、有大量自定义字段接口层可能需要额外扩展这类需求不属于本文的通用方案范围。我在实际使用中体会最深的一件事情是自动化技能能不能真正省时间关键不在于把多少个按钮变成自动而在于敢不敢把那些“需要动脑但其实不复杂”的环节交给 AI。摘要和标签以前总觉得要自己想才放心跑了几十篇之后发现模型输出的质量并不比我手写差多少而速度是我的几十倍。放掉那点“不放心”时间才真的省下来了。最后再分享一个小经验这套技能后续可以扩展成一个“文章分发中心”。在 WorkBuddy 里把同一个正文同时接到多个站点的发布技能上跑一次就同步发到两三个博客站点标签和摘要按各站规则自动适配。我现在的新内容基本都走这条链路运营效率相比单站点时代又上了一个台阶。