如果你和我一样公众号后台的“定时群发”按钮按了四年你应该早就发现一个事实写字本身从来不费时间真正吃掉你精力的是写字之外的那条流水线。我现在的做法是把整条流水线交给WorkBuddy再给它装上两个自建skill一个负责把历史文章和碎片素材变成结构化的选题库另一个负责把草稿变成能直接发布的公众号排版。做完这件事之后日更对我来说不再是负担而是每天早上二十分钟的固定动作。这篇文章想把整个过程拆开讲清楚包括两个 skill 的功能设计、任务拆解思路、中间产物怎么组织以及我在实际运行中踩过的几个坑。如果你也在做公众号或者你正在用 WorkBuddy 之类的智能体工具但不知道怎么真正落地这篇文章应该能给你一套可以直接抄走的方案。1. 被公众号日更拖垮之后我决定让WorkBuddy接管1.1 我的时间都去哪了写作之外的五个重复环节先说一个真实的场景。我有一次从下午两点坐到晚上九点七个多小时里真正用于“写”的时间不超过一个小时。剩下的时间全部耗在五个环节上找素材翻自己的收藏夹、翻历史文章、翻各个群里转发的链接就为了确认某个观点我之前有没有写过。配图找图、裁剪、压缩还要改文件名把图传到服务器上拿到链接之后再插进文章。排版标题层级、加粗、引用块、代码块样式每次都在编辑器里手动调一遍。检查外链点开每一个链接确认没有失效确认图片没有被防盗链拦截。发布前的最后核对看一遍按钮、合集标签、摘要、封面确认别出乌龙。这些事情单看都不难但凑在一起就是一座山。更崩溃的是这套流程每周要重复五到六次每次都要重来。说白了公众号运营根本不缺写作能力缺的是对重复劳动的容忍度。1.2 为什么是WorkBuddy而不是ChatGPT加一堆插件我也试过用对话式 AI 来加速这个流程比如直接在对话框里让它“整理这篇文章”“生成排版 HTML”。结果发现一个问题每次都要把上下文重新描述一遍它给出的结果格式还不稳定有时候给我 Markdown有时候给我带样式的 HTML有时候干脆漏掉图片。零零散散凑合能用但离“解放自己”还差得远。WorkBuddy 打动我的地方是它的skill 机制。你可以把一个 skill 理解成一个高度定制化的岗位说明书加操作手册——它定义了输入是什么、输出是什么、中间按什么步骤执行、遇到什么情况怎么处理。装好之后只要用自然语言发出触发指令整个流程就会按预设逻辑跑而不是每次现场“即兴发挥”。我还特意对比过 skill 和 agent 的区别。Agent 是那个做决策的主体skill 是技能包一个 agent 可以挂载多个 skillskill 也能被不同的 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 分四步处理扫描草稿正文里所有图片引用把它们提取出来。对每张图片计算 MD5 值先查一下是否已经上传过避免重复上传。把新图片通过 HTTPS 接口上传到自己的服务器拿到永久链接。把草稿里的原始图片引用全部替换成新链接。核心去重逻辑可以参考下面这段伪代码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 时间对比改造前后单篇文章的耗时差异我特意记录过改造前后的耗时整理成一张表环节改造前耗时改造后耗时找素材、回顾历史文章45 分钟5 分钟图片处理与上传20 分钟2 分钟排版30 分钟3 分钟发布前外链与图片检查15 分钟5 分钟撰写正文60 分钟10 分钟总计170 分钟25 分钟总耗时从接近三小时压到了二十五分钟节省出来的时间我用来做一件事多读两篇资料、多改两遍稿件。这才是公众号自由真正有价值的地方——不是让你少干活而是让你把时间分配给真正重要的事。5.3 质量兜底发布前的五分钟人工检查清单自动化程度再高发布前的人工检查也不可省略。我给自己定了一份五分钟清单标题是否夸大是否有标题党嫌疑AI 生成的内容容易过度承诺。文中的数据、引用、案例是否核实过来源AI 引用容易漂移。引用的原文是否保留原意有没有被断章取义。图片是否清晰、是否被压缩变形、链接是否替换成功。文末的引导关注、合集标签、封面图是否更新。说白了这套流程把重复劳动外包给了机器但把责任留给了人。你不审核就发布出了问题是账号的问题不是 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 理解得远比“智能处理”“高效整理”准确。你在定义上省下的每一分钟都会在执行时十倍还给你。