1. 这个技能到底解决了什么问题先把场景说清楚。我做内容这行有些年头了手上同时跑着好几个站点其中有一个是用 Z-Blog 搭的。Z-Blog 这东西老归老但胜在轻、稳、可控后台该有的都有插件生态也够用。可它有个让我一直很烦的点发一篇文章的流程太碎了。碎到什么程度我给你还原一下我以前的真实操作链路。写完一篇稿子先打开浏览器登录后台点“新建文章”把标题粘进去正文从本地 Markdown 编辑器里复制过来——注意Z-Blog 默认编辑器对 Markdown 支持一般我还得手动处理一下格式要么切到 HTML 模式贴源码要么用插件转。然后设分类、打标签、填摘要、选封面、调发布时间、设别名slug最后点发布。一套下来顺利的话十五到二十分钟不顺利——比如格式乱了、标签忘了、摘要没填——半小时都打不住。问题不在于每一步有多难而在于步骤多、重复、容易漏。人一旦重复做同一件事几十上百次注意力就会涣散漏填标签、忘设别名这种事几乎必然发生。而这类遗漏对 SEO 是有实际影响的别名没设好URL 就是一串数字 ID标签漏了站内聚合页就少一个入口。所以当我开始用 WorkBuddy 这类可以自定义技能的工具时第一个念头就是能不能把“发 Z-Blog 文章”这件事压缩成一个动作标题里说的“从二十分钟压到两分钟”不是夸张是我实测下来的稳定结果。这篇文章就把这个技能从设计思路到落地实现完整拆给你看。这个内容适合谁三类人一是自己维护 Z-Blog 站点的独立博主二是手上管着多个内容站、需要批量分发的运营三是想学 WorkBuddy 自定义技能怎么写、拿一个真实场景练手的开发者。哪怕你不用 Z-Blog这套“把重复流程封装成技能”的思路换个平台照样能用。提示本文讲的是一种“流程封装”的思路核心是把多步手动操作收敛成一次调用。平台和工具只是载体思路才是能迁移的东西。2. 整体设计思路与方案选型2.1 为什么选“技能封装”而不是“写个脚本”很多人第一反应是发文章嘛写个 Python 脚本调接口不就行了我一开始也这么想但实际做下来发现纯脚本有几个绕不开的坎。第一脚本是死的内容是活的。每篇文章的标题、分类、标签、摘要都不一样你得每次改脚本参数或者写一堆命令行参数解析用起来比手动还累。第二脚本没有“理解”能力。我给它一段 Markdown它不知道怎么从里面提取合适的摘要、怎么根据内容自动推荐标签。第三脚本的容错和交互很差。发失败了它要么报个错就退出要么你得自己去翻日志。WorkBuddy 的技能机制不一样它本质上是把一段可复用的能力包装成能被自然语言调用的东西。我可以对着一篇稿子说“帮我发到 Z-Blog”技能就去执行整套流程。中间涉及内容理解的部分比如生成摘要、推荐标签可以交给模型来处理涉及确定性操作的部分比如调接口、填表单用代码来保证稳定。这种“模型负责判断、代码负责执行”的分工是这套方案最核心的设计。2.2 两条技术路线接口派 vs 模拟派具体到“怎么把内容送进 Z-Blog”有两条路可走我两条都试过给你对比一下。对比维度接口调用路线浏览器模拟路线实现方式直接调 Z-Blog 的发布接口模拟人在后台点按钮、填表单稳定性高接口不变就一直能用中页面改版就可能失效速度快一次请求搞定慢要等页面加载和渲染前置条件需要拿到接口地址和鉴权方式需要维护登录态适用场景自己完全掌控的站点接口不开放或鉴权复杂的站点我最终选的是接口调用为主、模拟为辅的混合方案。原因很直接接口路线快且稳是主力但 Z-Blog 有些版本或者装了某些插件后接口行为会变这时候模拟路线作为兜底保证技能不会彻底瘫痪。这里要解释一下为什么接口路线更快。手动发布时浏览器要加载整个后台页面、编辑器、各种 JS 资源一次操作下来网络请求几十个。而接口调用只发一个 POST 请求把标题、正文、分类这些字段打包送过去服务端处理完返回结果。请求数量从几十个降到一两个时间自然从分钟级降到秒级。这就是“二十分钟到两分钟”里最大的一块时间节省来源。2.3 技能的能力边界怎么划设计技能时最容易犯的错是贪多。我一开始想让它什么都能干自动配图、自动内链、自动排版、自动分发到多个平台。结果就是每个功能都半吊子调试起来一团乱。后来我把边界收窄只做三件事内容预处理从原始 Markdown 里提取标题、正文、摘要推荐分类和标签。发布执行调接口把内容送进 Z-Blog处理返回结果。结果反馈告诉用户发布成功还是失败失败的话给出可操作的排查建议。配图、内链这些我单独拆成别的技能需要的时候串联调用。一个技能只解决一个清晰的问题这是我在踩了坑之后总结出的原则。边界清晰调试简单复用性也高。注意技能边界划得越清楚后面维护成本越低。宁可拆成三个小技能也不要做一个什么都塞的大技能。3. 核心细节解析与实操要点3.1 内容预处理怎么从一篇文章里“读懂”该填什么Z-Blog 发布时需要一堆元数据标题、摘要、分类、标签、别名。手动发布时这些是人来填的技能要自动化就得让模型来“读懂”文章。标题提取相对简单Markdown 的一级标题或者文件名通常就是。但要注意有些稿子的标题和正文里的第一个标题不一致我的处理逻辑是优先用用户显式指定的标题没有的话取文档第一个一级标题再没有就用文件名去掉扩展名。摘要生成是重点。Z-Blog 的摘要字段影响列表页展示和 SEO 描述不能随便截前 100 个字了事。我的做法是让模型读完整篇内容生成一段 80 到 120 字的概括要求包含核心关键词、语句通顺、不堆砌。实测下来模型生成的摘要比机械截断的质量高一大截列表页看起来专业很多。分类推荐这块我维护了一个分类列表让模型从里面选最合适的一个。这里有个坑不要让模型自由发挥创造新分类否则你的分类体系会越来越乱。我的做法是把现有分类作为候选集传给模型强制它从中选。标签推荐类似但可以稍微放开一点。我允许模型推荐 3 到 5 个标签同时给一个已有标签库做参考优先复用已有标签避免同义词泛滥比如“教程”和“教学”被当成两个标签。别名slug生成是个细节活。中文标题直接转 URL 会变成一串编码很难看。我的处理是如果标题是英文直接转小写加连字符如果是中文让模型给一个简短的英文别名或者用拼音。这个字段对 SEO 有实际价值值得多花点心思。3.2 接口鉴权怎么安全地把内容送进去调 Z-Blog 接口绕不开鉴权。不同版本、不同配置的 Z-Blog鉴权方式不太一样常见的有基于 Cookie 的会话、基于 Token 的接口密钥等。我这里讲通用的思路具体参数你按自己站点的实际情况来。核心原则是凭证不硬编码在技能里。我见过有人把账号密码直接写在脚本里这是大忌。我的做法是把凭证放在环境变量或者独立的配置文件里技能运行时读取。这样技能代码可以分享、可以版本管理凭证不会泄露。# 凭证放在环境变量里技能运行时读取 export ZBLOG_API_ENDPOINT你的站点接口地址 export ZBLOG_API_TOKEN你的接口凭证读取的时候做一层校验如果环境变量没设置直接给出清晰提示而不是让请求失败后报一个看不懂的错。import os def get_credentials(): endpoint os.environ.get(ZBLOG_API_ENDPOINT) token os.environ.get(ZBLOG_API_TOKEN) if not endpoint or not token: raise RuntimeError( 缺少 Z-Blog 接口配置请先设置 ZBLOG_API_ENDPOINT 和 ZBLOG_API_TOKEN 环境变量 ) return endpoint, token这段代码看着简单但那个清晰的报错信息能省你很多排查时间。我踩过的坑就是一开始没做校验请求失败后返回一个模糊的错误我花了半小时才反应过来是环境变量没设。3.3 正文格式处理Markdown 到 Z-Blog 的转换这是整个流程里最容易出问题的一环。Z-Blog 的编辑器对 Markdown 的支持取决于你装了什么插件、用的什么编辑器模式。我的经验是不要指望 Z-Blog 原生完美渲染 Markdown要么在发布前把 Markdown 转成 HTML要么确保站点装了可靠的 Markdown 插件。我选的是发布前转 HTML。用成熟的 Markdown 转 HTML 库把正文转好再送过去这样不管站点什么配置显示效果都一致。转换时要注意几个点代码块要保留语言标记方便前端高亮。图片链接要检查是不是有效地址本地图片得先上传拿到 URL。表格转换后要确保样式不崩有些主题对表格支持不好可能需要加内联样式。import markdown def convert_markdown_to_html(md_text): # 启用常用扩展覆盖代码块、表格、目录等场景 html markdown.markdown( md_text, extensions[fenced_code, tables, toc, codehilite] ) return html提示转换后建议先本地预览一下确认代码块、表格、图片都正常再送进接口。我吃过亏有一次表格没转好发出去列表页排版全乱了只能删了重发。3.4 发布参数组装一个都不能少接口发布时参数组装是最后一道关。我把必填字段和选填字段分开管理必填的缺一个就直接报错选填的给合理默认值。字段是否必填默认值策略标题是无缺失直接报错正文是无缺失直接报错分类是缺失时用“未分类”并提醒标签否缺失时留空不阻塞发布摘要否缺失时自动生成别名否缺失时自动生成发布状态否默认草稿确认后再发布这里有个设计决策值得说默认发草稿而不是直接发布。为什么因为自动化流程再稳也可能有意外。默认草稿你可以在后台扫一眼确认没问题再点发布多一道保险。等你对技能足够信任了再改成直接发布。4. 实操过程与核心环节实现4.1 环境准备与依赖安装动手之前先把环境理清楚。你需要的东西不多一个能跑 Python 的环境、几个必要的库、以及 Z-Blog 站点的接口信息。# 创建独立环境避免污染系统 Python python -m venv workbuddy-zbog source workbuddy-zbog/bin/activate # Windows 用 workbuddy-zbog\Scripts\activate # 安装依赖 pip install requests markdownrequests负责发 HTTP 请求markdown负责格式转换。就这两个核心依赖不搞复杂。环境变量按前面说的配好。然后写一个最小的连通性测试确认能连上你的 Z-Blog 接口。import os import requests def test_connection(): endpoint os.environ.get(ZBLOG_API_ENDPOINT) token os.environ.get(ZBLOG_API_TOKEN) # 用一个只读接口测试连通性不要用发布接口测 resp requests.get( f{endpoint}/check, headers{Authorization: fBearer {token}}, timeout10 ) print(状态码:, resp.status_code) print(返回:, resp.text[:200]) test_connection()这一步的目的是把网络和鉴权问题提前暴露。如果连不上先解决连通性别急着往下走。我见过有人跳过这步直接写发布逻辑结果发布失败后分不清是网络问题还是参数问题排查起来很痛苦。4.2 技能主流程的代码骨架主流程我拆成四个函数每个函数只干一件事这样调试的时候能精确定位问题出在哪一步。def parse_content(raw_text): 从原始文本中提取标题、正文、摘要等结构化信息 # 这里可以接入模型做摘要和标签推荐 ... def build_payload(parsed, category, tags, slug): 组装发布接口需要的参数字典 ... def publish(payload): 调用接口发布返回结果 ... def run(raw_text): 主流程解析 - 组装 - 发布 - 反馈 parsed parse_content(raw_text) payload build_payload(parsed, ...) result publish(payload) return result这种拆法的好处是每个函数可以单独测试。parse_content出问题就调它publish出问题就调它不用每次都跑完整流程。调试效率能提升好几倍。4.3 发布环节的完整实现发布函数是核心我把重试、超时、错误处理都放进去。import time def publish(payload, max_retries3): endpoint os.environ.get(ZBLOG_API_ENDPOINT) token os.environ.get(ZBLOG_API_TOKEN) url f{endpoint}/post for attempt in range(1, max_retries 1): try: resp requests.post( url, jsonpayload, headers{Authorization: fBearer {token}}, timeout15 ) if resp.status_code 200: return {ok: True, data: resp.json()} # 4xx 是客户端错误重试没意义直接返回 if 400 resp.status_code 500: return {ok: False, reason: f请求被拒绝: {resp.text}} # 5xx 是服务端错误可以重试 print(f第 {attempt} 次失败状态码 {resp.status_code}准备重试) except requests.Timeout: print(f第 {attempt} 次超时准备重试) except requests.RequestException as e: print(f第 {attempt} 次请求异常: {e}) if attempt max_retries: time.sleep(2 ** attempt) # 指数退避2秒、4秒 return {ok: False, reason: 重试多次仍失败请检查网络和接口状态}这里有几个设计点值得展开。为什么区分 4xx 和 5xx因为 4xx 通常是你参数错了或者鉴权失败重试一百次也没用不如直接返回让用户改。5xx 是服务端临时抽风重试往往能成功。为什么用指数退避如果服务端压力大你疯狂重试只会雪上加霜退避等待给它喘息时间成功率更高。4.4 一次完整的发布实录我把一次真实发布的过程记录下来你能看到每一步的耗时和输出。[00:00] 读取稿件文件大小 12KB [00:01] 解析内容标题《XXX》正文 3800 字 [00:03] 模型生成摘要98 字 [00:05] 模型推荐分类技术教程 [00:06] 模型推荐标签自动化, 效率工具, 内容运营 [00:07] 生成别名auto-publish-zbog [00:08] Markdown 转 HTML 完成 [00:09] 组装发布参数完成 [00:10] 调用发布接口... [00:12] 接口返回成功文章 ID: 1234 [00:12] 发布完成总耗时 12 秒注意这里 12 秒是纯机器执行时间。标题里说的“两分钟”是包含了人工确认、偶尔调整分类标签的时间。即便算上人工介入从原来的二十分钟降到两分钟也是实打实的提升。省下来的时间主要来自三块不用手动登录后台、不用手动填一堆字段、不用手动处理格式。提示第一次跑通后建议连续发几篇测试稿观察不同内容类型长文、短文、多图、多代码下的表现把边界情况摸清楚。5. 常见问题与排查技巧实录5.1 发布失败类问题速查这类问题最影响体验我整理了一张速查表按现象找原因。现象可能原因排查方向返回 401凭证失效或格式错检查 Token 是否过期、请求头格式返回 403权限不足确认账号有发布权限返回 400参数缺失或格式错对照必填字段表逐个检查连接超时网络或接口地址错先用只读接口测连通性发布成功但内容乱格式转换问题检查 Markdown 转 HTML 结果标签丢失标签字段格式不对确认接口要求的标签格式这张表是我踩坑踩出来的。比如“发布成功但内容乱”这条我遇到过两次一次是代码块没转好一次是表格样式冲突。后来我养成了习惯发布前先在本地把 HTML 渲染出来看一眼确认没问题再送接口。5.2 内容理解类问题模型生成摘要和标签偶尔会跑偏。常见的有摘要太长或太短、标签推荐了不相关的、分类选错。我的应对策略是加约束。摘要明确要求 80 到 120 字超出范围就重新生成。标签强制从候选库里选不允许自由发挥。分类同样给候选集。加了约束之后跑偏的概率大幅下降。还有一个技巧把用户的历史选择作为参考。比如你过去发的文章大多归到“技术教程”分类模型看到这个倾向推荐时会更准。这个可以通过在提示里带上几条历史记录来实现。5.3 我踩过的三个坑第一个坑把凭证写死在代码里。早期图省事直接把 Token 写在脚本里。后来想把技能分享给朋友发现得先把 Token 删掉很麻烦。改成环境变量后代码可以随便分享凭证各人配各人的。第二个坑默认直接发布。有一次模型把分类选错了文章直接发出去列表页分类乱了我赶紧去后台改。从那以后默认发草稿多一道确认心里踏实。第三个坑忽略别名生成。一开始觉得别名无所谓反正能访问。后来做 SEO 分析时发现没有别名的文章 URL 是一串数字分享出去很难看也不利于记忆。加上别名生成后URL 变得可读分享体验好很多。注意这三个坑都不是技术难题而是流程设计上的疏忽。做自动化的时候安全和可回退比效率更重要。宁可多一步确认也不要让错误直接生效。5.4 性能优化的几个实操点如果你要批量发布性能就值得关注了。我实测下来几个优化点效果明显。复用 HTTP 连接。用requests.Session()代替每次新建连接批量发布时能省下不少握手时间。session requests.Session() session.headers.update({Authorization: fBearer {token}}) # 后续所有请求都用这个 session并发发布要谨慎。理论上可以并发发多篇但 Z-Blog 这类站点通常扛不住高并发容易触发限流甚至把服务打挂。我的做法是串行发布每篇之间间隔一两秒稳字当头。缓存模型调用结果。摘要和标签生成要调模型如果同一篇稿子反复调试每次都调模型很浪费。我在开发阶段加了个本地缓存相同内容直接读缓存调试速度快很多。6. 技能复用与扩展思路6.1 换平台怎么迁移这套技能的核心逻辑是“解析内容、组装参数、调接口发布”跟具体平台关系不大。换成别的博客系统改的主要是接口地址、鉴权方式、参数字段名这三块。内容预处理那部分几乎不用动因为“从文章里提取标题摘要标签”这件事跟发到哪个平台无关。我的建议是把平台相关的部分抽成配置比如用一个字典描述字段映射关系。这样迁移时只改配置不改主逻辑。PLATFORM_CONFIG { zbog: { endpoint_key: ZBLOG_API_ENDPOINT, token_key: ZBLOG_API_TOKEN, title_field: title, content_field: content, category_field: category, }, # 其他平台按同样结构加进来 }6.2 还能扩展出哪些能力技能跑通之后我陆续加了几个扩展都挺实用。发布前自动检查检查正文里有没有失效链接、有没有忘记替换的占位符、图片地址是不是本地路径。这些检查能在发布前拦住不少低级错误。发布后自动归档发布成功后把稿件从“待发布”目录移到“已发布”目录并记录发布时间和文章 ID。这样你的稿件目录始终是干净的找历史文章也方便。多站点分发同一篇内容稍作调整后发到多个站点。这个要注意内容差异化别原样复制搜索引擎不喜欢重复内容。我的做法是每个站点用不同的标题和摘要正文主体保持一致。6.3 关于“两分钟”这个数字最后聊聊标题里那个“两分钟”。有人可能觉得是营销话术我解释一下这个数字怎么来的。纯机器执行时间是十几秒这个前面实录里能看到。但实际使用中你总得看一眼生成的结果确认分类标签对不对偶尔微调一下。这个人工确认环节大概花一分钟左右。加起来就是两分钟上下。对比原来的二十分钟省下的十八分钟里大约十分钟是省在“不用手动填字段”上五分钟省在“不用处理格式”上三分钟省在“不用登录后台和等待页面加载”上。每一块单独看都不算惊天动地但加在一起就是实打实的效率提升。我在实际使用中的体会是这类技能的价值不在于技术多高深而在于把重复劳动固化下来让人的精力集中在真正需要判断的地方。分类选哪个、摘要怎么写更好这些值得人花心思而“把标题粘到输入框里”这种事交给机器就好。