企业官网建设流程全解析

做内容的人应该都有同一个痛点：稿子在本地写完了、改完了，觉得总算能松口气，结果打开 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 请求调用外部系统，还能做变量处理、条件分支、结果校验。

我的思路很简单，就是把发布这篇文章要做的事，拆成四段标准流程：

1. 接收输入内容，解析出标题、正文、图片、分类倾向这些信息。
2. 内容加工，把稿子从 Markdown 规整成 Z-Blog 能直接用的 HTML，同时生成摘要和 SEO 标题。
3. 调用 Z-Blog 的接口，把文章、图片、分类、标签、状态这些参数一次性交过去。
4. 校验结果，确认文章真的发出去了，再返回后台编辑地址给我存档。

这里最关键的一个选型决策是：不用模拟浏览器去后台点按钮，而是走 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，最常用的几个方法：

我建议第一步别急着写技能，先拿一个通用客户端连一下接口，手动发一篇测试文章。这一步能帮你同时确认三件事：接口路径对不对、账号权限够不够、Z-Blog 版本对标准字段的支持程度。我见过很多人一上来就写全自动流程，结果卡在最基础的登录上，排错排到怀疑人生。先用最小实验跑通，后面会省心很多。

2.2 技能输入输出定义

技能设计的第一原则：先定义清楚输入和输出，再想中间流程。否则很容易做着做着就变成一个大杂烩。

我的输入设计是这样的：一篇写在本地或者网盘里的 Markdown 文件，文件名就是习惯性的文章编号加日期。WorkBuddy 技能读取这个文件，拿到原始文本。

输出则明确为三样东西：文章 ID、前台访问链接、后台编辑地址。这三样东西会写回到一个记录文件里，方便我复查和管理。

还有一个很关键的配置文件，我管它叫"技能说明书"，本质上是一段规则文本，告诉技能处理内容时的各种约束。比如标题长度控制、摘要字数、分类匹配规则、标签数量上限、正文段落间距规范。这个说明书越详细，技能输出的稳定性越高。你也不想让技能自由发挥，最后发出来一篇标题超长、标签塞了几十个的文章吧。

3. 分步搭建「Z-Blog 文章发布」技能

3.1 搭骨架：把四段流程串起来

在 WorkBuddy 里新建一个技能，我习惯先把流程骨架搭出来，再往里面填细节。整体节点是这样排的：

1. 读取输入文件，提取正文文本。
2. 大模型节点处理标题：如果文件里没写标题，就根据正文第一段生成；写了标题，就做长度校验和敏感词过滤。
3. 内容格式转换节点，把 Markdown 转成干净 HTML。
4. 图片处理子流程，遍历正文里的图片标记，分成"远程图片"和"本地图片"两路处理。
5. 分类映射节点，从配置表里选出最合适的分类。
6. 组装发布参数，生成 XML-RPC 请求体。
7. 调用 Z-Blog 接口，发起 HTTP POST。
8. 校验节点，读回文章信息确认发布成功，拼接后台编辑地址。

这个顺序是经过几次调整后定下来的。最开始我把图片处理和格式转换放在一起做，结果一旦图片上传失败，整个发布就直接挂了。后来拆成独立子流程，图片失败时技能会跳过图片继续把文章发出去，并在最终报告里高亮提示"有图片未处理"，我再单独补传。这个降级策略在实战中帮了我很多次。

3.2 内容加工：Markdown 到 HTML 的转换细节

Z-Blog 的编辑器虽然支持直接粘 HTML，但它对格式的处理没有想象的那么宽容。我的经验是：不要直接拿大模型去"写"整篇 HTML，而是先用标准的 Markdown 转 HTML 工具把正文转成结构化 HTML，再让大模型只做局部修正。原因很简单，大模型裸写 HTML 容易发挥不稳定，经常漏掉闭合标签，或者把代码块里的特殊字符当成格式标签吃掉。

转换时有几个固定动作：

• 标题层级。Markdown 里的 # ## ### 对应 h2 h3 h4，但文章里一般不应该出现 h1，h1 是留给网站标题的。技能里我写了规则：一级标题自动降为二级，正文内从 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 version="1.0" encoding="utf-8"?> <methodCall> <methodName>metaWeblog.newMediaObject</methodName> <params> <param><value><string>博客ID</string></value></param> <param><value><string>发布账号</string></value></param> <param><value><string>密码</string></value></param> <param><value><struct> <member><name>name</name><value><string>article-2025-001.jpg</string></value></member> <member><name>type</name><value><string>image/jpeg</string></value></member> <member><name>bits</name><value><base64>图片二进制内容的Base64编码</base64></value></member> </struct></value></param> </params> </methodCall>

需要注意的是，图片压缩这一步别省。我最早图省事直接传原图，结果手机拍的一张照片三 MB，接口超时不说，还把服务器存储撑得很难看。现在技能里固定规则：图片宽度超过 1200 像素就等比缩放，整体质量压缩到 80 左右，视觉上没什么影响，体积能小好几倍，接口也稳了。

3.4 分类与标签的自动化映射

分类和标签是纯体力活，但做自动化的时候反而最需要细心，因为它涉及"语义理解"。

分类那边，我用 getCategories 接口先把博客全部分类拉一遍，存进配置文件。然后给每个分类写上一段特征描述，比如"工具教程：软件操作、配置方法、工作流搭建相关"。技能拿到文章正文后，由大模型根据特征描述做匹配，选出最合适的分类。这个特征描述写得越具体，匹配准确率越高。初期我是纯靠大模型猜分类，准确率大概七成，写完特征描述之后能到九成以上。

标签那边就简单一些，规则是：从正文提取三到五个核心关键词作为标签，全部转成小写英文或保留中文原文，逗号分隔。数量一定要限制，我有一次测试时技能抽风，生成了二十多个标签，后台看起来就像标签垃圾场。后来在技能说明书里加死规则：标签不超过五个，每个不超过十个字。

还要强调一点：分类映射结果和标签结果都要写进发布前的"预检报告"，我要能看得到技能打算把文章发到哪个分类、带哪些标签。自动化的前提是可控，不是失控。

3.5 组装发布参数：标题、摘要、SEO 与状态

接口调用前的最后一步是把所有参数装进一个结构体。核心字段就这些：

postStatus 这个字段值得专门说一下。我的技能默认全部走 draft 模式，文章发出去是草稿状态，我在后台点一下"发布"才算真正上线。这样做的原因是，即便技能已经校验过标题、分类和正文，我依然想在内容真正面对读者之前过一眼。自动化要省的是时间，不是判断力。等跑了一个月、确认技能足够稳定之后，再在配置里把默认状态切成 publish。

至于 SEO 标题和摘要描述，这个要看 Z-Blog 版本对接口字段的支持情况。标准 MetaWeblog 协议里这两个字段不一定有对应项，我的做法是先走标准字段把文章发出去，再通过后台接口补齐 SEO 信息。你第一次配置时，建议发一篇测试草稿，然后去后台看文章详情页，确认你用的版本支持哪些扩展字段，再决定要不要在技能里把它们写进请求。

发布请求的 XML 结构长这样：

<?xml version="1.0" encoding="utf-8"?> <methodCall> <methodName>metaWeblog.newPost</methodName> <params> <param><value><string>博客ID</string></value></param> <param><value><string>发布账号</string></value></param> <param><value><string>密码</string></value></param> <param><value><struct> <member><name>title</name><value><string>文章标题</string></value></member> <member><name>description</name><value><string>正文HTML字符串</string></value></member> <member><name>categories</name><value><array><data> <value><string>工具教程</string></value> </data></array></value></member> <member><name>mt_keywords</name><value><string>博客自动化,WorkBuddy,效率</string></value></member> <member><name>postStatus</name><value><string>draft</string></value></member> </struct></value></param> <param><value><boolean>1</boolean></value></param> </params> </methodCall>

这里有个低级但常见的坑：XML-RPC 本质上是一个 XML 报文，如果你的正文里有 & < > 这类特殊字符，手搓 XML 很容易坏掉。所以我强烈建议技能里用现成的客户端组件发请求，而不是拼字符串。如果实在要手拼，务必把正文内容里的这几个字符做转义，否则你会看到各种莫名其妙的解析错误。

3.6 发布后的校验与结果回执

发完不等于发成功了。我设计技能的时候特意加了一道"回读校验"：接口返回文章 ID 之后，技能再调用一次 getPost，把刚发布的文章读回来，核对标题、分类、正文开头几行。只要有一项对不上，整个技能就报错退出，并且不会覆盖之前的发布记录。

这样做的好处是，很多问题能在第一时间被发现。比如分类映射错了、正文被截断了、标签没写进去，回读都能看出来。校验通过之后，技能把结果写进一个发布记录文件，内容包括：

• 文章 ID
• 前台链接
• 后台编辑地址
• 发布时间
• 本次发布使用的技能版本号

这个记录文件非常有用。后来我写了一个小脚本，定期扫这个文件，把超过两周还是草稿状态的文章统计出来，提醒我处理。等于发布流程不仅自动化了，连后续的跟进也顺带管理起来了。

4. 踩坑实录与排查清单

4.1 常见问题速查表

我把自己在实际搭建和使用中遇到的高频问题整理成了一张表，基本都是能直接照着排查的：

4.2 几条实用避坑经验

除了上面那张表，还有几条经验是文档里不会写的，我单独拿出来说。

第一条，永远保留"草稿先行"这道闸门。哪怕技能已经稳定跑了几个月，我也不会把默认状态改成直接发布。有一次技能的分类特征描述被我不小心改坏了，连续三篇文章全部分到了"杂谈"分类下。因为默认是草稿模式，我只是后台改一下分类再发布，没有任何一篇文章以错误分类的形式上线。如果当时是自动发布，三个错误分类的文章就被读者看到了。

第二条，幂等设计一定要做。我最初版本的技能没有查重功能，有一次文件重复触发，同一篇文章发了三遍。后来加了双重保护：发布前按标题在后台搜索，找到同名草稿就改为更新；同时在发布记录文件里记录内容指纹，下次进来先比对指纹，重复就直接跳过。

第三条，别让技能在"有点问题但能发"和"报错"之间做模糊判断。技能处理内容时，一旦发现关键信息缺失，比如正文为空、标题为空、分类匹配置信度低于阈值，应该直接报错，而不是凭感觉硬发。宁可这次不发，也不要发一篇错的出去。每次报错都会促使你去完善规则，这正是技能进化的方式。

第四条，密钥和账号信息一定要放在 WorkBuddy 的加密存储里，不要直接写死在流程里，更不要把密码塞进正文或记录文件。自动化工具经常要调试、分享、备份，密钥一旦泄露，等于把整个博客的写入权限送了出去。

5. 实际效果与使用建议

5.1 从 20 分钟到 2 分钟：流程对比

技能跑顺之后，我的发布流程变成了这样：

整体算下来，单篇内容从打开后台开始算，到草稿出现在后台，基本在两分钟以内。如果算上我后台点一下"发布"的时间，也就多花十几秒。关键是这个过程不耗神，我可以利用碎片时间把稿子丢进技能，回头统一处理草稿，写作和发布的节奏完全分开了。

这条流水线跑起来之后，我最大的感受不是"快"，而是"心理负担消失了"。以前一想到发文章还要过一遍后台表单就有一种微妙的抗拒感，现在完全没有。稿子写完丢出去，剩下的事情交给技能，我只保留最后的确认权。

5.2 把技能用出更多花样

「Z-Blog 文章发布」技能一旦稳定，你会发现它的价值远不止省时间。顺着这条思路，我后来又做了一些扩展，都是基于同一个骨架：

• 批量导入旧文章。以前在其他平台写的内容，整理成 Markdown 丢进技能，自动补全分类和标签，批量搬到 Z-Blog。
• 定时发布草稿。技能发布到草稿箱后，再配合一个定时任务，到点自动把草稿改成发布状态，实现预约发文。
• 多博客同步。同一篇内容，配置多个目标博客的分支流程，一键同步到不同站点，但我会刻意让各站的摘要和标题做差异化处理，避免完全重复。
• 发布前内容自检。在交到接口之前，先让技能跑一遍错别字、敏感词、敏感链接的检查，不合格就打回。

不过扩展之前要记住一个原则：每一个新功能都是在原有稳定骨架之上加的一个检查点或分支，不要为了一次加太多功能把主流程弄复杂。我见过有人把技能扩展到一个流程里塞了十几种判断，最后连自己都看不懂哪里出了问题。自动化追求的是可靠，不是炫技。

最后再分享一个我私心觉得最值得养成的习惯：给技能加"版本号"。我每修改一次技能规则，就在发布记录里记录本次使用的版本号。出问题的时候能快速定位是哪个版本的改动导致的，回滚也有依据。一个小小的版本号，让这个自动化系统真正进入了可持续维护的状态。