从 Markdown 稿件到公众号草稿箱传统流程走完一遍大概一个半小时起步其中真正花在“写字”上的时间反倒不多大量时间都烧在排版、调样式、逐段贴图、改格式这些机械操作上。最近我把整套流程搬到了 WorkBuddy 上测试完发现从一份纯 Markdown 文稿到打开公众号后台可直接发布的草稿耗时稳定在 7 分钟左右。这篇文章就把这套工作流的具体搭建过程、Skill 配置、踩过的坑和最终效果完整拆开讲清楚。先说结论这不是一个“一键全自动”的神话而是一套“人写稿、AI 负责排版规范、人审核发布”的人机协作流程。核心思路是把公众号排版规则固化成 WorkBuddy 的 Skill让 AI 替你把 Markdown 转成符合公众号规范的 HTML 内容再半手动粘贴进草稿箱收尾。这套方案对公众号运营者、技术博主、习惯用 Markdown 写稿的创作者应该都适用尤其适合稿件量大、排版要求统一、又不想被编辑器锁定的场景。1. 公众号排版那 90 分钟都耗在哪些环节了很多不写公众号的人不理解一篇文章从 Word 或者 Markdown 到公众号后台到底要折腾什么我用一次实际记录的数据来说明。以一篇 3000 字左右、带 10 张配图、6 段代码的 Markdown 技术稿为例逐项计时:环节耗时说明调整正文段落20 分钟公众号不支持标准 Markdown粘贴过来需要重设段间距、行距、字体字号标题层级样式10 分钟大标题、小标题要分别设置颜色、粗细、大小还要保证全文统一代码块处理20 分钟每段代码要重新套代码块样式改背景色、字体处理换行和缩进引用与强调10 分钟Markdown 的引用符号、加粗斜体在公众号里全部丢失需要逐段补图片上传与位置调整20 分钟每张图单独上传确认顺序和说明文字对应表格与特殊元素5 分钟表格宽度、样式几乎都要手动调整预览与修改5 分钟手机预览、发现问题、再修改一轮合计约 90 分钟一篇技术稿从成品到可发布如果稿件带有复杂表格、流程图说明、多级嵌套列表时间还会往上走。这里还没算一个隐性成本排版过程中会不断打断写作思路改完一排样式回到行文逻辑里往往需要重新进入状态。传统 Markdown 转公众号方案存在一个共同痛点它们解决的是“格式搬运”问题而不是“样式适配”问题。你把 Markdown 粘贴到在线转换器得到的是通用 HTML贴进公众号后台后字体、行距、颜色这些视觉层面的规范依旧需要手动调。这正是 90 分钟里最耗时的部分光是逐段调段间距、字号、行距就能耗掉四分之一的时间。我最初的尝试是把“公众号排版规范”写成一个固定 CSS通过工作流自动化替换。但固定模板的问题很明显文章结构不固定有得有代码、有的没表格、有的引用多、有的全是短句一套死板模板根本兼顾不了。真正需要的不是模板是一个能理解“哪种情况配哪种样式”的执行者。WorkBuddy 的 Skill 机制刚好能承载这件事。2. WorkBuddy 能上场靠的是它跟普通 Markdown 转换器的本质区别先说 WorkBuddy 是什么避免有人理解偏了。它本质上是一个本地优先的 AI 自动化工作台核心能力是通过自定义 Skill、指令和工作流把一系列重复性内容生产任务固化成可一键执行的操作。它跟传统“格式转换器”的区别不在“转换”这个动作上而在“理解”这个能力上。普通 Markdown 转 HTML 工具是纯规则驱动的某个 Markdown 语法对应某个 HTML 标签一一映射但映射完之后样式的美化、结构的判断、内容的完善比如统一为图片添加说明文字就没人管了。WorkBuddy 做的事情是规则 模型判断规则部分负责结构映射这是确定性的AI 部分负责样式决策这是场景性的Skill 机制负责把这套流程固定下来形成可复用的“知识包”理解的差异决定了结果的差异。比如同样是一段引用普通转换器输出的是一个 blockquote 标签公众号粘贴后丑得没法看而 WorkBuddy 在 Skill 的约束下会把引用段落转成“灰色竖线、浅底色、圆角”的公众号适配排版连引用里嵌套的强调文字也一并处理到位。这个差异正是从“能用”到“能直发”的分水岭。从部署方式讲WorkBuddy 支持本地安装Windows、Linux、Ubuntu 都行也有工作台式的管理界面。我目前的配置是WorkBuddy 客户端部署在本地 Ubuntu 机器上Skill 库集中管理多台设备同步大模型接口使用的是 DeepSeek 的 API Key成本和效果比较平衡这个组合的好处是数据不出本地对内容安全敏感的团队比较友好。你也可以配置其他兼容 OpenAI 接口的大模型WorkBuddy 在这块的适配做得比较开放不影响 Skill 和流程本身。3. 把排版规则“教”给 WorkBuddy:Skill 编写实战如果只把 WorkBuddy 当做一个能跑模型的对话工具那不叫工作流叫聊天。让它真正替我省下那 90 分钟的关键是把排版规则沉淀成一个 Skill。这个 Skill 相当于你给 AI 写的一本“公众号排版操作手册”它读懂了手册干活才不容易跑偏。3.1 Skill 文件的结构与定位WorkBuddy 的 Skill 机制本质上是一个包含指令、示例和约束条件的结构化提示词包。我一般把核心排版规范整理成下面几个部分角色与任务明确 AI 的角色是“公众号排版编辑”任务是把输入的 Markdown 稿件转换为符合规范的公众号富文本 HTML样式规范参数字号、行距、段间距、标题层级、对齐方式等所有硬性参数元素处理规则代码块、引用、表格、图片、列表、强调文字分别如何渲染转换禁忌不改变原文语义、不乱加内容、不用公众号不支持的特性等输出格式要求要求输出 HTML 片段不是完整 HTML 文档方便直接粘贴进后台一个精简过的 Skill 配置文件大概长这样name: wechat_md_publisher description: 将 Markdown 稿件转换为公众号适配的 HTML 富文本 role: 公众号排版编辑 rules: - body_font_size: 16px - line_height: 1.75 - paragraph_spacing: 24px - h1_size: 22px - h1_color: #333333 - h1_bold: true - h2_size: 18px - h2_color: #444444 - h2_bold: true - blockquote_style: 左侧 #dddddd 竖线浅灰底色 #f7f7f7圆角 4px - code_block_style: 等宽字体背景 #f2f2f2圆角 4px水平滚动 - table_style: 全宽边框合并表头加粗带底色 - image_rule: 图片添加说明文字居中显示 constraints: - 保持原文语义不新增、不删减内容 - 不使用公众号富文本不支持的 CSS 特性 - 输出格式: HTML 片段不包含 html 和 body 标签 - 代码块内文本原样保留不自动转义高亮这些参数的设定不是拍脑袋我是先做了一个 5 篇文章的小样本测试把过去在公众号里手动排版时用的参数逐项提取出来形成规则。比如正文 16px、行距 1.75、段间距 24px这三项就是公众号读者反馈阅读体验最好的参数组合。3.2 为什么要把样式规范写得这么细很多人写 Skill 喜欢写“把排版做得美观大气”这种描述对 AI 来说等于没说。美观是主观的AI 会自由发挥结果每次输出的风格还不一样。公众号排版要的是确定性读者每天看到的样式必须一致这是品牌认知的一部分。我把所有数值都写进规则里目的就是消除随机性。测试下来只要规则定义足够细AI 在不同时间、不同稿件上输出的排版结果能做到肉眼无法区分的稳定。如果你对排版风格没有积累可以直接参考我的这套参数起步。等你有自己明确的视觉偏好后把参数替换掉就行。3.3 让 Skill 学习你的历史排版风格还有一个很实用的技巧如果你电脑里存着之前排好的公众号文章 HTML 片段可以挑两三篇有代表性的丢给 WorkBuddy让它在生成新文章的排版时参考这些样例。这个步骤不是必须的但对风格一致性要求高的人帮助很大。具体操作是在 Skill 里增加一个 reference_samples 字段把样例 HTML 的路径写进去。WorkBuddy 读取后会把样例当作风格参考基准生成结果会更贴近你账号实际呈现的样式。我把之前一篇阅读量最高的技术教程的 HTML 作为样例喂进去后后续文章排出来的版式几乎就是同一个模子省去了大量微调。4. 七分钟发布流程的完整还原工具配好之后整套流程的实际运行过程大概是这样的。我用一个非常具体的时间轴来还原你可以照着复现。4.1 执行前的三件事约 1 分钟把写好的 Markdown 稿件放到指定目录确认图片素材路径正确稿件中引用的图片路径与实际文件一致检查 Markdown 语法没有硬伤尤其是表格、代码块、引用这些特殊元素这一步主要靠人为保证AI 不是不能处理错误语法但处理的结果不一定是你想要的源头干净一点下游就少一个问题。4.2 WorkBuddy 执行转换约 30 秒到 1 分钟在 WorkBuddy 工作台选中 wechat_md_publisher 这个 Skill指定输入文件路径执行。它会读取 Markdown 全文按 Skill 里定义的规则逐步处理输出一个 HTML 文件。如果稿件比较长超过 1 万字耗时可能到两分钟左右技术类稿子普遍在 1 分钟内能跑完。执行过程不需要我盯守切出去处理别的事情等回来产物已经生成好了。4.3 微信公众号后台粘贴与微调约 4 分钟打开公众号后台新建图文编辑器切到“富文本”模式直接粘贴转换出来的 HTML 片段。粘贴完成后基础样式基本都在了标题层级统一、段落间距均匀、引用样式正常、代码块可横向滚动、图片位置顺序正确。剩下要做的是逐张检查图片是否显示正常确认说明文字位置对不对预览几遍特别是手机端预览确认没有溢出或挤压如果有特殊需求比如某段需要单独调整颜色手动微调一下这 4 分钟主要花在检查上不需要从零排版。我实测下来一篇 3000 字带代码的稿件粘贴后需要手动微调的频率已经很低大部分文章几乎原版可用。4.4 发布约 1 分钟检查完毕点击保存为草稿。至此从 Markdown 到公众号草稿箱全流程走完。发消息的时间因人而异有人习惯定时推送有人习惯立即发送这不影响前面流程的效率。整个流程的耗时分配是这样的3 分钟人工准备与检查 3 分钟 AI 转换含等待时间 剩余时间发布收尾。相比原来动辄 90 分钟提升幅度是数量级的。5. 踩坑清单从“能用”到“敢直发”之间隔着的几个问题这套流程不是第一次跑就完美期间确实踩过不少坑。我挑几个最有代表性的问题把排查链路和最终解法完整写出来给后来的人做参考。5.1 换行问题Markdown 软换行在公众号里消失这是最早遇到的问题。Markdown 中两个空格 回车表示软换行在编辑里显示正常但转换成 HTML 后软换行只对应一个br标签粘贴进公众号后台经常不渲染或者渲染出来的行距跟自然段完全一样读起来一团糟。排查链路先确认 Markdown 源文件里软换行的具体情况再查看转换后的 HTML 结构发现段落间没有p标签分离最终定位为 Skill 里没有明确“每段必须用p包裹”的规则解决方法很简单在 Skill 规则里增加一条——所有正文段落一律使用p标签包裹段间距由 CSS 统一控制不使用br做段间分隔。另外在 Markdown 写作阶段也同步调整习惯段落之间用空行分隔少用软换行这样从源头上就避免了一半问题。5.2 表格宽度溢出公众号后台的老毛病有段时间转换出来的表格在电脑端看没问题手机预览直接溢出屏幕右侧一大截被裁掉。这个问题很典型公众号的富文本编辑器对表格的默认渲染并不友好如果表格列数多、内容长不做特殊处理很容易出问题。排查链路先在手机端重现问题确认与浏览器无关检查转换后的 HTML 表格结构发现table标签没有设置宽度约束单元格内容也没有做换行处理对比之前手动排版时能正常显示的表格找到差异点手排时通常给表格加width: 100%以及单元格不换行控制解法在 Skill 的 table_style 规则里明确要求表格宽度为 100%单元格内的长文本允许换行同时表头设置固定底色以增强辨识度。改完之后表格在手机端不再溢出但这个规则对太宽的表格超过 6 列依旧不够友好保守建议是超过 6 列的内容尽量在写作阶段就拆分成两张表排版效率和阅读体验都更好。5.3 代码块样式时好时坏另一个高频问题是代码块。早期 Skill 处理代码块时有的段落正常显示为带底色、等宽字体的“块”有的直接丢失了背景色变成普通文本整个稿子的可信度瞬间下降。排查链路对比正常和异常的 HTML 片段发现异常代码块外层没有pre标签代码内容被直接嵌进了p标签里进一步检查 Skill 的 rules发现只写了代码块的视觉样式没有强制指定用precode结构原因是 Markdown 中部分代码块没有按规范使用三个反引号包裹AI 无法正确识别为代码块退化成普通文本这个问题的根子有两层一层是 Skill 规则不完整把结构要求和样式分离了另一层是源文件不规范。我做了两个调整——Skill 里强制规定代码块必须使用precode结构包裹同时在写作规范上也要求自己统一使用带语言标识的围栏式代码块即三个反引号 语言名。修复后代码块的稳定性大幅提升再也没有出现过样式丢失的情况。5.4 图片路径指向本地文件公众号后台无法加载图片问题在最初测试时属于致命伤转换出的 HTML 里图片用的是本地相对路径比如./images/1.jpg粘贴进公众号后台图片区要么空白要么直接显示坏图图标。原因是公众号后台并不能读取你电脑里的文件需要先把图片上传到公众号的素材库拿到网络 URL 后再引用。排查链路查看转换后的 HTML确认图片路径是本地路径还是网络 URL发现是本地路径定位为 Skill 里没有针对图片上传的流程设计思考自动化上传方案能否让 WorkBuddy 直接调公众号素材库接口把图片传上去再替换路径这个流程比较复杂需要配置公众号开放平台的 API 凭证WorkBuddy 支持自定义 API 调用但搭建门槛高于普通体验。对大多数个人创作者来说更务实的方案是图片处理单独做一个半自动化步骤——先用工具批量把本地图片上传到某个图床或公众号素材库拿到 URL 列表后替换 Markdown 里的图片路径再交给 WorkBuddy 执行转换。我这里目前的实际操作是稿件里的图片本身就使用云端 URL 引用比如存在自己的对象存储或图床转换后直接可用不需要额外处理。如果你还没有图床方案可以把图片上传作为一个独立前置步骤不塞进 Skill 里保持链路简单可靠。6. Skill 的迭代方法论从“凑合能用”到“稳定直发”很多人搭建完一个流程就跑路了觉得“能用就行”。但“能用”和“稳定直发”之间差着好几个版本。我是用了一套笨但有效的迭代方法来打磨这个 Skill 的分享出来做一个参考。6.1 每次发布后记录问题样本我给自己定了一个小规则每次发布文章后如果发现任何排版问题不管多小比如某个字间距不对、某行缩进偏了都截图存档并简单描述问题点。这些样本就是 Skill 迭代的训练素材。积累两三篇之后问题样本里就能看到明显的共性。比如我发现连续三次文章里的列表都出现了“第二级列表缩进丢失”的问题于是针对这个单一问题修改 Skill 规则新增一条多级列表必须显式设置缩进层级。每次只改一个点改完用历史所有出过问题的文章做回归测试确保修复旧问题不引入新问题。6.2 建立回归测试集这个方法最初是从软件开发里借过来的。我把之前处理过的文章按类型归类预留一个 test 目录里面包含技术教程、行业分析、个人随笔、活动公告等不同品类的典型稿件。每次修改 Skill 后用这些稿件全部跑一遍检查排版结果。这样做的好处是你改了一个影响代码块的规则不会导致表格样式出现回归。毕竟公众号排版这个东西是一环扣一环的你动了段间距可能引用块的观感就变了。测试集不大每次多花 10 分钟换来的是发布时的安心。6.3 版本号管理Skill 文件我启用了版本号v1.0、v1.1 这样的命名每次修改明确记录变更日期和摘要。最开始觉得没必要直到有一次改出了一个严重的回归问题因为没有版本记录花了不少时间才定位到是哪条规则变动引起的。从那以后所有 Skill 迭代一律写版本记录。所谓工具越用越顺靠的不是运气是每一次小修小补的累积。7. 从“单篇 7 分钟”到“批量生产能力”的延伸思考当单篇流程跑顺之后我很快意识到一件事这套方案的想象空间不在省下写稿后的 90 分钟而在这条链路本身可复用、可扩展。它把“从文稿到发布”这个环节从“每次手动重复劳动”变成了“一次搭好、长期复用”的管道工程。进一步的实际衍生场景包括批量已经完成的稿件处理。以前积压了一批 Markdown 稿件想整理成公众号文章但懒得排版现在只需要批量交给 WorkBuddy 跑一遍统一转成 HTML 草稿轮换着发布就行完全不占用写新稿的时间。多平台分发。公众号只是其中一个分发渠道。我在尝试把 Skill 的输出目标扩展到知乎、掘金、CSDN 等平台它们的富文本规范跟公众号不完全一样比如代码块样式偏好、标题层级默认样式都有差异但思路完全通用——每个平台对应一个专属 Skill输入同一个 Markdown输出不同平台的适配版。量产逻辑成立后一周多平台更新五篇内容也能扛得住。团队协作与统一规范。团队里如果有多个编辑在维护同一个公众号Skill 文件可以直接共享。每人执行同一套规则产出的排版风格完全统一省去大量“这期标题字体怎么不一致”的沟通成本。新人上手时也不用从零学排版的细枝末节跑一遍 Skill 就能输出符合规范的草稿。回到最初的那个问题——为什么 90 分钟能压到 7 分钟核心不是 AI 替你“写”了什么而是你把决策规则明确下来了什么情况用什么样的排版什么元素对应什么样的样式这些本来是你脑子里的隐性经验现在被外化成了 Skill 文件里的显性规则。工具只是加速器真正值钱的部分是你对内容规范的整理和沉淀。最后分享一个我个人的小建议如果你也想搭这套流程别急着追求“全套自动化”先手动搭好规则再逐步交给 WorkBuddy一段一段验证把问题集中解决后再上强度。我在这个过程中最大的体会是这套流程上线后释放出来的不仅是时间更是写作心态——不用再为“写完稿还要排版”这件事产生心理负担写稿的意愿和产出效率也随之涨了不少。内容生产的瓶颈不该停在排版这种机械动作上把时间还给创作本身这套配置就值回投入了。