WorkBuddy+自建Skill，打造公众号日更自动化流水线

如果你和我一样，公众号后台的“定时群发”按钮按了四年，你应该早就发现一个事实：写字本身从来不费时间，真正吃掉你精力的是写字之外的那条流水线。我现在的做法是，把整条流水线交给WorkBuddy，再给它装上两个自建skill：一个负责把历史文章和碎片素材变成结构化的选题库，另一个负责把草稿变成能直接发布的公众号排版。做完这件事之后，日更对我来说不再是负担，而是每天早上二十分钟的固定动作。

这篇文章想把整个过程拆开讲清楚，包括两个 skill 的功能设计、任务拆解思路、中间产物怎么组织，以及我在实际运行中踩过的几个坑。如果你也在做公众号，或者你正在用 WorkBuddy 之类的智能体工具但不知道怎么真正落地，这篇文章应该能给你一套可以直接抄走的方案。

1. 被公众号日更拖垮之后，我决定让WorkBuddy接管

1.1 我的时间都去哪了：写作之外的五个重复环节

先说一个真实的场景。我有一次从下午两点坐到晚上九点，七个多小时里，真正用于“写”的时间不超过一个小时。剩下的时间全部耗在五个环节上：

• 找素材：翻自己的收藏夹、翻历史文章、翻各个群里转发的链接，就为了确认某个观点我之前有没有写过。
• 配图：找图、裁剪、压缩，还要改文件名，把图传到服务器上，拿到链接之后再插进文章。
• 排版：标题层级、加粗、引用块、代码块样式，每次都在编辑器里手动调一遍。
• 检查外链：点开每一个链接确认没有失效，确认图片没有被防盗链拦截。
• 发布前的最后核对：看一遍按钮、合集标签、摘要、封面，确认别出乌龙。

这些事情单看都不难，但凑在一起就是一座山。更崩溃的是，这套流程每周要重复五到六次，每次都要重来。说白了，公众号运营根本不缺写作能力，缺的是对重复劳动的容忍度。

1.2 为什么是WorkBuddy而不是ChatGPT加一堆插件

我也试过用对话式 AI 来加速这个流程，比如直接在对话框里让它“整理这篇文章”“生成排版 HTML”。结果发现一个问题：每次都要把上下文重新描述一遍，它给出的结果格式还不稳定，有时候给我 Markdown，有时候给我带样式的 HTML，有时候干脆漏掉图片。零零散散凑合能用，但离“解放自己”还差得远。

WorkBuddy 打动我的地方，是它的skill 机制。你可以把一个 skill 理解成一个高度定制化的岗位说明书加操作手册——它定义了输入是什么、输出是什么、中间按什么步骤执行、遇到什么情况怎么处理。装好之后，只要用自然语言发出触发指令，整个流程就会按预设逻辑跑，而不是每次现场“即兴发挥”。

我还特意对比过 skill 和 agent 的区别。Agent 是那个做决策的主体，skill 是技能包；一个 agent 可以挂载多个 skill，skill 也能被不同的 agent 复用。我这两个 skill 就是独立的技能包，谁用都行，挂在 WorkBuddy 上只是我个人的习惯。

1.3 两个skill的定位划分：一个管入口，一个管出口

动手之前，我把“公众号自由”拆成了两个方向：入口侧和出口侧。

入口侧解决的是“内容从哪来”的问题。历史文章、碎片笔记、网上的好文章，这些信息如果只是躺在收藏夹里，等于不存在。需要有人把它们抓出来、洗干净、贴上标签、放进一个可以随时检索的素材库。这是第一个 skill 的活。

出口侧解决的是“内容怎么发出去”的问题。草稿写完之后，图片要上传、链接要替换、排版要统一、还要过一遍平台规则。这些工作重复且规则明确，非常适合自动化。这是第二个 skill 的活。

中间那块“判断和表达”留给人类自己。我不指望 skill 帮我思考，我只指望它帮我把思考之前的准备和思考之后的交付全部包圆。

2. 自建skill前必须搞懂的三个概念：任务拆解、工具边界和状态流转

2.1 skill到底是什么：一个带输入输出契约的小型工作流

很多人第一次接触 skill 会把它理解成一个“超长提示词”，其实不对。提示词是写给 AI 看的愿望清单，skill 是写给 AI 看的岗位说明书，它必须包含四个东西：触发条件、处理步骤、输入格式、输出格式。

我自己写 skill 的时候，习惯用一套类似下面的 YAML 模板来定义：

name: article-collector version: 1.2.0 description: 采集指定公众号历史文章或单篇文章，提取正文与图片，按主题归档为素材卡 trigger: 用户提供公众号名称或文章URL inputs: - target: string outputs: - cards_dir: 素材库目录 steps: - 1. 解析入口，获取文章列表 - 2. 逐篇提取标题、作者、时间、正文 - 3. 过滤无关区块（推广、页脚、打赏引导） - 4. 下载正文图片到本地，按文章ID+序号重命名 - 5. 生成素材卡Markdown，写入素材库 constraints: - 只处理用户有权访问的内容 - 不绕过任何访问限制

这样做的好处是，每一步都有明确的验收标准，Agent 在执行的时候不会自由发挥偏离轨道。

2.2 任务拆解：把“公众号自由”拆成skill可执行的最小单元

接手任何一个自动化项目，最忌讳上来就写 prompt。你连自己要什么都不知道，AI 再聪明也帮不了你。我的做法是先画一条“内容处理流水线”，把公众号从选题到发布拆成六个环节：

拆完之后你会发现，真正需要“人”的部分其实很少。其他环节全都符合自动化的三个特征：重复、规则明确、有客观的验收标准。

2.3 工具边界：哪些事交给skill，哪些事必须人工兜底

我见过不少人踩的坑，是把 skill 当成万能工具箱，让它“帮我写一篇有深度的文章”。结果出来的东西看着通顺，实际上观点空泛，甚至数据都是编的。

这里必须划一条边界。Skill 适合做的是信息处理，比如抓取、归类、格式转换、图片上传、链接替换、生成固定结构的模板文本。Skill 不适合做的是价值判断，比如“这个观点是否成立”“这个案例是否真实”“这句话会不会冒犯到某类读者”。这些事一旦交给机器，风险极高。

我自己的原则是：skill 做流水线，人做质检员。任何一篇文章在点击发布之前，必须经过五分钟的人工审核。具体看哪些内容，我在第五部分会详细列一个清单。

2.4 状态流转：两个skill如何共享一份工作目录

两个 skill 不是孤立的，它们的协作方式需要提前设计好，否则就是两条各干各的流水线。我用的是“中间产物”的方式：Skill A 把处理好的素材写进一个固定的工作目录，Skill B 再去这个目录里读取。

目录结构大概是这样的：

post-packages/ ├── 2026-01-14-ai-writing-tools/ │ ├── source.json # 素材来源信息 │ ├── cards/ # 素材卡(Markdown) │ ├── images/ # 本地图片 │ └── draft.md # 我写的草稿

状态流转的关键在于，中间产物必须用稳定、可解析的格式，而不是一段对话里的零散回答。这样哪怕执行到一半崩溃了，重新跑一次也能从断点继续，不至于翻车。

3. Skill一号：历史文章采集与素材库自动归类

3.1 为什么先做素材采集而不是直接生成文章

最初有人建议我直接做一个“自动写文章”的 skill，我犹豫了一下，还是决定先做素材采集。原因是公众号内容的核心从来不是文字堆砌，而是素材密度。你写一个观点，如果背后有一两个鲜活案例、两三句准确引用、一组可靠数据，文章的可读性立刻就不一样。

我的收藏夹里存了上千篇“以后可能会用”的文章，但真正要用的时候根本找不到。因为它们的标题、来源、核心观点都散落在不同地方，没有统一的索引。做一个采集 skill，本质上是在给这些散落的信息建索引。这件事不做，后面所有自动化都是空中楼阁。

3.2 采集规则设计：入口、正文提取、图片落盘

Skill A 的触发方式很简单，支持两种输入：一个公众号的名字，或者一条具体的文章链接。给它一个名字时，它会去抓取该公众号最近一段时间的文章列表；给它一条链接时，它会把单篇内容完整扒下来。

正文提取的规则我调教了很久，因为公众号文章里总是混着一堆跟正文无关的东西，比如顶部引导关注、底部广告、往期推荐。我在 skill 的描述里明确要求过滤器：只保留标题、作者、发布时间、正文段落、配图、引用金句，其余一律丢弃。

图片落盘是一个容易被忽略的关键点。我在 skill 里规定，图片必须以“文章ID_序号”的格式命名，并且在下载完成后自动做一次 MD5 去重。这样同一张图出现在多篇文章里时，只保留一份原始文件，节省空间的同時也让后续素材查重变得简单。

3.3 素材库组织：主题聚类和标签体系

素材抓下来只是第一步，能不能用好取决于怎么组织。Skill A 每处理完一篇文章，会生成一张结构化的素材卡，类似这样：

--- title: 为什么说提示词工程正在变成一门手艺 source: https://mp.weixin.qq.com/s/xxx author: 某作者 date: 2025-12-03 topics: [AI, 提示词, 写作] desc: 提示词不是填空题，而是对需求的精确描述。 --- 核心观点： - 提示词的本质是约束信息空间 - 结构化输出优于自由发挥 - 好的提示词需要迭代而非一次成型 引用金句： > “你问不出好问题，就得不到好答案。” 相关素材： - [[20251203-提示词工程入门]] - [[20251210-结构化Prompt模板]]

素材卡会按主题自动归档，比如 AI、效率、产品、写作。这样我在写新文章的时候，只需要在素材库里按标签检索，就能快速找到可用的案例和引用。

3.4 合规边界：只处理你有权访问的内容

这里必须说清楚一个边界问题。Skill A 的设计初衷是整理你自己有权限访问的内容，包括你订阅的公开文章、你自己写的历史文章、你购买课程的配套资料。它不应该、也不能用来绕过任何平台的访问限制，更不应该做任何形式的批量滥用。

我在 skill 的配置里写死了一条约束：只处理用户有权访问的内容，不破解任何登录或访问限制。如果在实际操作中遇到需要授权才能查看的内容，直接跳过并在报告里标注“需人工确认”。守住这条线，工具才能长久地用下去。

4. Skill二号：图片本地化与公众号排版发布

4.1 公众号排版最烦的一件事：图片外链失效

公众号后台的编辑器是所有排版工具的终点站，但如果你直接把网上的图片链接粘进去，翻车概率非常高。最常见的两个问题：一是某些平台开启了防盗链，图片在其他域名下直接显示裂图；二是外链域名可能有访问时效，过几个月图片就挂了。

所以 Skill B 的第一职责，是把草稿里所有图片先下载到自己服务器，再把链接替换成自己的地址。只有图片在自己的服务器上，才能保证长期稳定显示。这个需求说出来简单，但实际操作里藏着一个很深的坑，后面踩坑章节我会专门讲。

4.2 图片上传与链接替换的实现思路

先看一下整套逻辑。输入是一个 Markdown 草稿，里面图片都是本地相对路径或者外部链接。Skill B 分四步处理：

1. 扫描草稿正文里所有图片引用，把它们提取出来。
2. 对每张图片计算 MD5 值，先查一下是否已经上传过，避免重复上传。
3. 把新图片通过 HTTPS 接口上传到自己的服务器，拿到永久链接。
4. 把草稿里的原始图片引用全部替换成新链接。

核心去重逻辑可以参考下面这段伪代码：

import hashlib def upload_image(path, remote_base_url): content = open(path, "rb").read() file_hash = hashlib.md5(content).hexdigest() if file_hash in uploaded_map: return uploaded_map[file_hash] resp = upload_to_server(path, remote_base_url) uploaded_map[file_hash] = resp["url"] return resp["url"]

这段逻辑看着简单，但它帮我省了无数重复劳动。以前手动上传图片的时候，最烦的就是同一张图传了好几次，服务器里一堆垃圾文件。有了 MD5 去重，服务器清爽多了。

4.3 一键生成公众号风格的排版

第二步是排版标准化。公众号文章的排版风格如果每次手动调，色号、字号、间距都不一样，读者体验就很差。Skill B 内置了一套我自己的排版规范：

• 一级标题用加粗大字，二级标题用带编号的加粗文字
• 引用金句统一用引用块样式
• 代码块使用等宽字体并加浅色底纹
• 关键结论用加粗强调，不滥用颜色
• 段落间距固定，图片下方统一加居中的图注

Skill B 拿到 Markdown 草稿后，会按照这套规则生成一份结构化的富文本内容。我只需要复制粘贴到公众号后台，再微调个别细节就行。整个排版过程从原来的半小时压缩到三分钟以内。

4.4 发布接口对接与测试号验证

最后一步是发布。公众号平台有官方的素材管理接口和发布接口，Skill B 可以先帮你把内容和封面图上传到素材库，生成一个待发布的草稿，然后由人工确认后正式发布。

这里强烈建议用一个公众号测试号先跑通全流程，再在正式账号上操作。测试号可以走一遍从上传素材到创建草稿的完整链路，但不会真的推送给粉丝，容错率极高。我第一次对接的时候就因为一个参数写错导致发布失败，如果直接在正式号上试，就是一次真实的推送事故。

另外，如果你希望 Skill B 在排版之前顺带生成一段推荐摘要，可以给它配置一个兼容 OpenAI 格式的模型 API，比如 DeepSeek 这类服务，传入草稿正文让它提炼三句话。但这只是锦上添花，不是核心链路，配不配都不影响主流程。

5. 两个skill协作跑通全流程：从选题到发文只用20分钟

5.1 完整流程演示：从一篇原始笔记到已发布文章

拿我最近写的一篇关于效率工具的推文举例。整个流程是这样的：

早晨我把一条需求扔给 WorkBuddy：“把上周收藏的 5 篇效率工具相关文章整理成选题素材库。”Skill A 立刻开始工作，解析文章列表、提取正文、下载图片、生成素材卡。五分钟后，工作目录里躺着一份整洁的素材库。

我打开素材库，扫了一眼那些文章的核心观点和引用金句，确定了一个切入点。然后花了十分钟写下八百字左右的草稿，把我的观点和素材卡里的案例串起来。这一步完全人工，因为观点和判断是文章的灵魂，我不想交给机器。

草稿完成后，我把文件丢给 Skill B。它自动上传了文中的三张配图，替换了链接，套用了排版规则，还帮我生成了一段摘要。最后我在后台预览、微调、点击发布。整个过程下来，不到二十分钟。

5.2 时间对比：改造前后单篇文章的耗时差异

我特意记录过改造前后的耗时，整理成一张表：

总耗时从接近三小时压到了二十五分钟，节省出来的时间我用来做一件事：多读两篇资料、多改两遍稿件。这才是公众号自由真正有价值的地方——不是让你少干活，而是让你把时间分配给真正重要的事。

5.3 质量兜底：发布前的五分钟人工检查清单

自动化程度再高，发布前的人工检查也不可省略。我给自己定了一份五分钟清单：

1. 标题是否夸大，是否有标题党嫌疑（AI 生成的内容容易过度承诺）。
2. 文中的数据、引用、案例是否核实过来源（AI 引用容易漂移）。
3. 引用的原文是否保留原意，有没有被断章取义。
4. 图片是否清晰、是否被压缩变形、链接是否替换成功。
5. 文末的引导关注、合集标签、封面图是否更新。

说白了，这套流程把重复劳动外包给了机器，但把责任留给了人。你不审核就发布，出了问题是账号的问题，不是 skill 的问题。

6. 踩坑实录：发布失败、链接归属报错和二维码失效的排查链

6.1 “链接内容不属于当前公众号”到底是怎么回事

第一次跑通全流程的时候，我在发布环节遇到了最让人头疼的报错：“链接内容不属于当前公众号”。这个报错看起来像密码不对，其实是链接归属问题的提示。

我的排查思路是反着来的。先看这个报错出现的时机——它只在“原文链接”字段校验时出现。也就是说，我在草稿里填的原文链接，并不是当前公众号体系内的文章链接。常见原因有三个：

• 从第三方平台复制的链接带了跳转参数，导致平台识别不到原始站内路径。
• 原文链接字段直接填了其他公众号的文章 URL。
• 正文里的图片链接指向他站图床，被平台校验拦截。

解决方案也很直接，把“原文链接”改成当前账号已发布的文章链接，或者干脆留空。正文里的图片全部通过 Skill B 替换成自己服务器的地址，绕开跨域校验。

6.2 发布失败后去哪里看日志：三种定位手段

发布失败之后最怕的就是对着屏幕干瞪眼。我的排查顺序是固定的，三层日志逐级看：

第一层看 WorkBuddy 的任务运行日志。每次任务执行都会有记录，按任务 ID 筛出来，能看到每一步的输入和输出，定位是哪一步出的问题。

第二层看 API 返回的错误码。微信类接口返回的errcode和errmsg信息量极大，比如40078 invalid url基本可以确定是链接格式问题，48001 api unauthorized则说明权限没配好。

第三层看我自己的服务端记录。我会在调用发布接口前把请求参数完整打出来，包括媒体素材 ID、原文链接、封面图地址，这样一旦出现问题，可以直接比对参数和平台要求。

一层层往下看，大多数问题十分钟内可以定位。找不到日志才是最大的问题，所以我从一开始就在 skill 的配置里写死了“每个步骤结束必须输出结构化日志”这条规则。

6.3 图片防盗链和二维码失效：一个隐藏很深的坑

这是我在图片处理上踩过最深的一个坑。第一次跑 Skill B 的时候，所有图片都显示上传成功了，但文章发布后预览，有一张大图直接裂掉。排查之后发现，那张图所在的源站做了 Referer 防盗链，直接下载时返回的是 403。

解决方案是：下载图片时带上原始响应头信息，特别是上游域名。但代码里写死 Referer 不够，因为不同源站的校验规则不同。我索性在 Skill B 里加了一个规则：下载失败时自动重试三次，带上原始页面的 Referer 和 User-Agent，如果还失败就把该图片标记为“需人工处理”，而不是让它静默失败。

二维码失效则是另一个隐蔽的坑。很多平台生成的二维码本质上是带时效参数的短链，抓取下来的时候是好的，但存到本地一百年后它还是同一个文件，里面的内容早已过期。所以我在 skill 里规定：遇到二维码类图片，默认不做静态存档，而是记录二维码所指向的原始链接，由人工决定是否需要重新生成。

6.4 持续改进：skill版本化与回归测试

Skill 写完之后不是一劳永逸的，平台接口会变、排版需求会变、你的内容策略也会变。我给两个 skill 都加了版本号，每次改动都记录在职责描述里。同时沉淀了一套回归测试用例，选了十篇风格迥异的历史文章，每次修改后批量跑一遍，确认排版输出还是原来的样式。

这个习惯帮我避免了很多次“改一处、坏三处”的尴尬。Skill 本质上也是代码，是代码就要有版本管理和回归测试意识。没有这套兜底，你根本不敢放心升级。

我在实际使用中最大的体会是，公众号自由的核心不是“不用写”，而是“终于可以把力气花在值得花的地方”。两个 skill 解决的从来不是写作问题，而是写作前后那些琐碎却消耗人的环节。它们不替你思考，但帮你把思考之外的一切安排得明明白白。

最后分享一个小技巧：给 skill 命名和写描述的时候，多写动词，少写形容词。像“采集、归类、生成、上传、替换、校验”这些词，AgEnt 理解得远比“智能处理”“高效整理”准确。你在定义上省下的每一分钟，都会在执行时十倍还给你。