Markdown 转 Word：不要被 Skill 的名字骗了
我一开始也走了一条很自然的路：打开 WorkBuddy 的 Skill 商店，搜索 Word。当时搜到的「Word 文档生成」对应 minimax-docx。只看名字，很容易理解成「把任何内容转换成 Word」。但真正把 Skill 的说明读完之后，我发现它的定位并不是一个简单的 Markdown 转 Word 工具，而是一套 Word 创建和编辑引擎。
Minimax开源的minimax-docx skill
提示WorkBuddy 调用 Skill 的三个入口 可以从加号菜单、斜杠命令和自然语言调用 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
最短路径：先完成转换，再处理排版
把能力边界看清之后，稳定路径就很简单了：
先用 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。正式设计前，我要求它先通过提问与我对齐。完整过程可以概括成四步：
它会继续确认页面尺寸、标题颜色、字体、页眉页脚和需要兼容的文档元素，然后再创建、测试和验证。
把成功路径固化为 Skill 前先对齐
这里不展开 Skill 的完整设计方法，我后面会单独做一节高阶课程。你现在只要记住一个判断：适合固化成 Skill 的事情，通常同时满足三个条件——出现频率高、执行流程固定、最终结果容易验证。
高频固定可验证的成功路径才值得固化成Skill
公司模板、团队模板和不同甲方的交付模板，都符合这三个条件。一次性的文档就直接完成，尚未跑通的探索也不要急着封装。Skill 应该沉淀的是已经验证过的最短成功路径，而不是把一整段失败过程保存下来以后再失败一次。
粤ICP备14082021号
免费POC，
零成本试错
