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

告别Markdown符号困扰！保姆级教程教你用WorkBuddy一键生成精美Word和PDF，轻松搞定文档交付。

核心内容：

1. Markdown直接交付的痛点（符号不友好，领导客户难理解）

2. 转换前终态判断方法（三问确定工具路径）

3. 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 后处理。

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

继续协作 -> Word -> 方便修改、批注和多人协作

快速交付 -> pdfkit-py -> 生成一份可以直接发送的基础 PDF

品牌成稿 -> Kami -> 蒸馏内容并套用品牌视觉系统

工程处理 -> /pdf -> 合并、拆分、水印、加密和填表

先问终态，再选 Skill

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

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

Minimax开源的minimax-docx skill

WorkBuddy 调用 Skill 的三个入口，可以从加号菜单、斜杠命令和自然语言调用。知道名称时更常用 `/`；不知道名称时就描述任务，让 WorkBuddy 去商店里查找。无论从哪个入口找到，都先看说明，再安装和执行。

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

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

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

先问清能力边界，很多人问 Skill 只会问「它能做什么」，更关心「它明确做不到什么」。能力说明决定你会不会用，能力边界决定这个任务值不值得让它来做。如果准备把 Skill 分享给同事或学员，还要问清它来自 WorkBuddy 内置、商店安装，还是自己的本地目录；本地 Skill 需要单独打包交付。

minimax-docx的能力边界

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

注意这条工具路径已经选错了。让一个更擅长 Word 创建、编辑和套模板的引擎，额外承担它原本不擅长的 Markdown 解析工作。任务能启动，不等于路径合理。

minimax-docx不适合用来转换Markdown

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

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

STEP 01: Markdown -> STEP 02: Pandoc 转结构 -> STEP 03: Word 基础稿 -> STEP 04: 模板排版

先用 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「这次处理的是哪一份文件」，不用根据模糊描述猜。

安装依赖不一定是故障。Agent 处理 Office、PDF 等非纯文本文件时，安装依赖、检查环境和编写脚本都很常见。如果初始化越来越重、等待时间越来越长，就要回头检查工具路径。模型能力决定任务能不能做，工具路径决定它能不能稳定地做好。

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

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

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

STEP 01: 对齐模板 -> STEP 02: 创建 Skill -> STEP 03: 测试验证 -> STEP 04: 重复调用

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

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

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

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

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

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

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

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

后期处理: /pdf -> 输入和输出都是 PDF，适合工程处理

快速转换: pdfkit-py -> Markdown 或 Word 转成基础 PDF

品牌成稿: Kami -> 内容蒸馏与品牌模板一次完成

/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 安装命令：`npx skills add tw93/kami/plugins/kami`

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

品牌化排版之后仍要人工复核。Kami 会蒸馏和改写内容，人必须重新检查事实、数字、引用和关键结论。视觉更精美，不代表内容自动更准确。正式白皮书、客户报告和教学材料的最终交付责任仍然在人。

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

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

Agent 负责执行，人负责定义标准并验收。

“Agent 负责读取文档、选择工具、安装依赖、编写脚本和反复调整。人负责决定受众、交付标准、品牌规范和最终验收。”

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

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