WorkBuddy保姆级教程｜把Markdown做成精美Word和PDF

最近还在给电子工业出版社录 WorkBuddy 实战课。上一篇文章，我拆了 WorkBuddy 的 Deep Research。为了把整个过程讲清楚，我让它围绕 Loop Engineering 重新做了一次深度研究。几个 Subagent 并行找资料，主 Agent 负责汇总，十几分钟后生成了一份 14 章、3 个附录、约 12000 字的白皮书。

内容完成了，新的问题也来了：这份白皮书是一个以 .md 结尾的 Markdown 文件。在 WorkBuddy 右侧的渲染界面里，它有标题、有目录、有表格，看起来和普通文档没有太大区别。但如果打开原始文件，里面会出现大量 #、** 和 -。这些符号对 Agent 很友好，对准备接收材料的领导、客户和学员就没那么友好了。

 

Markdown语法是非人类友好的

如果你把这样的原始 Markdown 直接发给领导肯定是要挨骂的～接收者要先理解这些符号，也很难按照熟悉的 Word 方式批注和修改。内容虽然写完了，文件还没有进入大多数业务场景真正可交付的状态。

所以接下来的两节课，我分别跑了一遍 Markdown 转 Word 和 Markdown 转 PDF。这篇把两节课合到一起，讲清楚一条完整的文档交付链路。你不需要学习 Markdown 语法，也不需要自己写代码。你真正需要学会的是：先判断文档的终态，再让 Agent 选择正确的工具和路径。

 

Agent默认产出Markdown文档

面向业务交付时，Markdown 更适合作为 Agent 的工作底稿

在没有指定终稿格式时，WorkBuddy 这类 Agent 通常会把长文写成 Markdown。原因并不复杂：Markdown 本质上还是纯文本，Agent 可以直接读取和修改；标题、列表、引用、表格和代码块又都有清晰的结构，不容易在多轮编辑中把层级弄乱。所以 Markdown 不是一个需要马上消灭的中间产物。对 Agent 来说，它反而是一种非常合适的工作格式。

问题出在后半段。Agent 的工作格式和人的交付格式不是一回事。一个文档到底该转成 Word 还是 PDF，不能只看哪个文件更常见，要看它接下来还要经历什么。我现在会连续问三个问题：发布前还要不要由人继续修改？如果需要，先转成 Word，方便人修改、批注和协作；内容已经定稿后，是「能发就行」，还是需要正式、好看并且带有品牌特色？前者生成基础 PDF，后者走品牌化排版；PDF 生成后还要不要合并、拆分、加水印或加密？如果需要，再进入 PDF 后处理。

把这三个问题回答清楚，工具选择就不会乱：

 

先问终态，再选 Skill

Markdown 转 Word：不要被 Skill 的名字骗了

我一开始也走了一条很自然的路：打开 WorkBuddy 的 Skill 商店，搜索 Word。当时搜到的「Word 文档生成」对应 minimax-docx。只看名字，很容易理解成「把任何内容转换成 Word」。但真正把 Skill 的说明读完之后，我发现它的定位并不是一个简单的 Markdown 转 Word 工具，而是一套 Word 创建和编辑引擎。

 

Minimax开源的minimax-docx skill

minimax-docx 主要有三条工作管线：从零创建 Word、编辑已有 Word、把已有内容套进 Word 模板。里面还内置了 13 套美学配方，可以控制标题、正文、颜色和版式。它的设计思路挺有意思：给你的是经过组合的配方，不是一桶颜色随便往文档上刷。它很适合制作和美化 Word，却不负责原生解析 Markdown。

这就是我建议大家安装一个 Skill 后，先不要急着执行任务的原因。我通常会先把下面这段话发给 WorkBuddy：

请介绍这个 Skill 的主要功能、工作流程和能力边界。 它能不能直接把 Markdown 转成 Word？ 能不能指定一级标题、二级标题和正文的字体、字号与颜色？ 能不能使用我提供的 Word 模板？ 哪些事情是它明确做不到的？

 

minimax-docx的能力边界

我第一次测试时，没有先把「格式转换」和「Word 排版」拆开，直接要求 minimax-docx 把一千多行的白皮书从 Markdown 做成 Word。Agent 开始分析表格和代码块，初始化运行环境，还要安装一个约 600 MB 的 .NET SDK。七八分钟过去，任务仍然没有完成。

 

minimax-docx不适合用来转换Markdown

最短路径：先完成转换，再处理排版

把能力边界看清之后，稳定路径就很简单了：

先用 Pandoc 把 Markdown 转成一个结构完整的基础 Word，再让 minimax-docx、docx 或 Agent 编写的脚本处理字体、字号、页眉页脚和公司模板。这里有一个容易忽略的认知：文件格式转换和文档设计是两件事。

Pandoc 擅长的是把标题、段落、列表、表格等结构从 Markdown 搬进 Word。它解决「有没有」的问题。Word Skill 和排版脚本解决的是模板、字体、颜色、页边距和品牌规范，处理「好不好用、好不好看」的问题。把两件事拆开，每个工具只负责自己最擅长的部分，整条链路反而更稳定。

 

格式转换和模板排版是两个不同阶段

我在另一场线下培训里还跑过一个更直接的案例。当时我没有手动指定 docx，只告诉 WorkBuddy：「使用 Skill，把这份 Markdown 按照下面的标题和正文要求做成 Word。」WorkBuddy 自动加载了 docx，最后成功输出了 Word，而且我要求的标题和正文格式都生效了。

后来我专门追问它是怎么实现的。答案是：docx 本身也不是一个 Markdown 转 Word 的按钮，它更像一份操作指南。它教会 Agent 如何使用 docx.js 这类文档库，真正干活的是 WorkBuddy 临时写出来的转换脚本。

这件事把 Skill 的作用讲得很清楚：一个 Skill 不一定要从头到尾包办整个任务。它也可以只教会 Agent 某个专业模块，例如怎样使用一个文档库、怎样处理表格、怎样验证输出。Agent 学会方法后，再根据当前任务写脚本完成剩下的工作。

 

docx教会Agent如何使用docx.js

真正执行时，我会把输入文件、参考模板和输出文件都放在指定的工作空间里，让 Agent 持续读取同一套上下文，也方便以后重新调用和修改。引用文件时可以点击加号添加本地文件，也可以用 @ 在当前工作空间里准确选择；我更常用 @，因为它明确告诉 Agent「这次处理的是哪一份文件」，不用根据模糊描述猜。

一次跑通以后，再考虑做成 Skill

Word 文档生成后，我把这条成功路径继续往前推了一步。如果公司的一级标题、二级标题、正文、页眉页脚和页面尺寸都有固定要求，而且以后会反复处理不同的 Markdown，就没有必要每次重新描述一遍。

我让 WorkBuddy 调用 skill-creator，把这条路径做成一个 MD-to-Word-template Skill。正式设计前，我要求它先通过提问与我对齐。完整过程可以概括成四步：

它会继续确认页面尺寸、标题颜色、字体、页眉页脚和需要兼容的文档元素，然后再创建、测试和验证。

 

把成功路径固化为 Skill 前先对齐

这里不展开 Skill 的完整设计方法，我后面会单独做一节高阶课程。你现在只要记住一个判断：适合固化成 Skill 的事情，通常同时满足三个条件——出现频率高、执行流程固定、最终结果容易验证。

 

高频固定可验证的成功路径才值得固化成Skill

公司模板、团队模板和不同甲方的交付模板，都符合这三个条件。一次性的文档就直接完成，尚未跑通的探索也不要急着封装。Skill 应该沉淀的是已经验证过的最短成功路径，而不是把一整段失败过程保存下来以后再失败一次。

Markdown 转 PDF：先区分「能发」和「正式交付」

前面的 Word 案例写得更长，是因为它帮我们跑出了两个可以继续复用的判断：不要根据 Skill 名字猜能力，格式转换和文档设计要分开。内容定稿后进入 PDF 环节，沿用的还是这套判断。下面对 pdfkit-py、/pdf 和 Kami 的比较，来自我这次录课使用的版本、配置和实际产出；它们都和 PDF 有关，输入、输出和适用场景却完全不同。

 

根据文档终态选择三条PDF交付路径

/pdf 更像一个 PDF 工程工具。它希望输入是 PDF，输出仍然是 PDF，中间负责合并、拆分、加水印、加密和填表。它不负责把 Markdown 排版成一份漂亮的 PDF，也不适合作为 Markdown 排版的主引擎。

pdfkit-py 是一个更全面的 PDF 转换 Skill。它支持 Markdown 转 PDF，也能处理 Word 和 PDF 之间的转换。实际运行时，它会先把 Markdown 排版成 HTML，再通过浏览器把 HTML 输出为 PDF。页边距、字体、字号、页眉页脚、颜色和水印都可以继续调整。

我第一次运行时，它发现本地有 Chrome，却找不到可用路径。WorkBuddy 自己检查了环境，换了一条可用工具链，最后完成了转换。对于普通用户来说，你不需要理解环境变量和浏览器调用的每个细节，重点是看最终文件是否生成、内容有没有缺失、版式是否满足要求。

生成基础 PDF 后，我又让它把正文设置为小四号宋体，多级标题使用楷体，并加了一层颜色较淡的「智见 AI」水印。这个版本已经达到可以分享的水平。做课程资料、内部报告或者临时交付，走到这里通常就够了。

 

pdfkit-py是非常强的PDF编辑skill，转换Markdown做的比较基础

如果你需要的是一份更正式、更像品牌出版物的材料，Kami 更合适。Kami 不是一个把 Markdown 一字不差地「硬转」成 PDF 的转换器。它会先蒸馏内容，再把核心信息放进一套正式的模板系统中。它有固定的视觉语言，也可以配置姓名、身份、公司、Logo、主色、强调色、默认语言和文档类型。

这也决定了它的边界：如果原文每一句都必须保留，Kami 不是首选；如果你接受它重新组织内容，希望得到一份适合对外展示的长文档、一页纸或者演示材料，它的优势才会出来。

我已经在本地配置了一份「智见 AI Brand Profile」。这次直接让 Kami 使用这个品牌配置，把同一份 Loop Engineering 白皮书做成长文档。任务运行了五六分钟，最后生成的 PDF 自动带上了我的名字、身份、公司、Logo 和品牌颜色，整体已经有了比较统一的 IP 感。

 

Kami允许用户自定义很多参数

品牌配置不需要直接打开 Markdown 手改，你可以告诉 Agent 自己的品牌规范，也可以提供一张已有的品牌材料，让它帮助提取颜色和视觉特征。

 

Kami Skill 安装方式与品牌 PDF 成果

真正的文档自动化，是从工作底稿走到交付终稿

回看这两节课，Word 和 PDF 只是表面上的两个文件格式。背后真正需要建立的是一条文档交付链路：Agent 先在 Markdown 里生产和修改内容；内容需要人继续协作，就转成 Word；内容已经确定，就根据交付标准生成基础 PDF 或品牌 PDF；需要合并、水印和加密，再做 PDF 后处理；当某条路径高频、固定而且容易验证，再把它固化成 Skill。

下一次你让 AI「帮我做成 Word」或者「帮我导出 PDF」之前，可以先停一下，回答四个问题：谁要看，后面还改不改，要不要体现品牌，这个过程以后还会不会重复。这四个答案，会直接决定你该选哪条路径。

AI 写完内容，只完成了文档生产的前半段。让内容真正进入人的工作流程，变成能修改、能发送、能代表你的正式材料，才算完成交付。