最近圈子里用OpenClaw的人越来越多了这个开源的Agent自动化工具跑任务、写报告、整理数据确实顺手。可能因为名字里带个Claw圈里人习惯管它叫龙虾。我用它跑了两个月的周报、数据汇总和项目复盘默认输出全是markdown格式内容结构漂亮是漂亮但真到了要发给领导、丢给客户、交到教务系统的时候对方只认doc/docx文件。于是OpenClaw生成的markdown怎么转成doc这个问题就成了我群里反复被问的热门话题。这篇就把我踩过的坑和最终的完整方案写出来从格式拆解、工具选型到Pandoc实操、常见故障排查都有顺带教你怎么把这个转换动作嵌进自动化工作流里让龙虾吐出来的md一键变成能交付的Word文档。1. OpenClaw到底输出了什么样的markdown1.1 为什么OpenClaw偏爱markdown先说个很多人忽略的问题OpenClaw为什么不直接生成docx非得给你markdown答案其实很简单——markdown是纯文本格式跨平台、体积小、容易版本管理而且LLM输出文本时天然就擅长生成markdown的标记语法。你让模型直接产出Word二进制文件别说格式容易乱token消耗和生成稳定性的代价都高得多。OpenClaw在OpenClaw在生成报告、日记、任务总结、数据分析结论时默认采用markdown层级标题#、##、###、无序列表、表格、代码块、行内代码、引用块和数学公式这些标准语法。它本质上是在用一套约定俗成的结构化文本协议把Agent思考过程的产物固化下来。这里有个关键认知markdown是一种轻量级标记语言它描述的是一份文档的逻辑结构而不是物理排版。换句话说它只告诉你这里是一级标题这里是个表格这里要放图至于标题用几号字、表格边框多粗、图片居不居中它一概不管。所以从markdown到doc的转换本质上是把逻辑结构翻译成Word物理排版的过程。理解这一点后面所有转换参数你都能自己推出来不用死记命令。1.2 一份典型OpenClaw markdown里都有哪些元素我抽样看了十几份OpenClaw生成的文件常见的元素基本逃不出下面这张单子元素类型markdown表现形式转doc时的风险点层级标题#、##、###需要映射到Word的标题1/标题2/标题3样式正文段落普通文本块中文字体、行距、首行缩进要处理表格管道符|分隔的表格语法列宽、换行、合并单元格都可能出问题代码块三个反引号包裹Word里没有原生代码高亮需要处理字体和底色行内代码code字体变等宽字体中文容易错位图片相对路径解析是最容易翻车的地方数学公式$...$ 或 $$...$$需要额外开启公式扩展才能转成Word公式引用块 前缀Word里对应正文引用样式宽度和缩进要调链接文字默认转成超链接安全性要检查我建议你在转换之前先用任意一个markdown阅读器把文件整体过一遍确认这些元素的语法都是规范的。尤其是表格和公式——你手写的表格管道符没对齐、公式的$符号不配对Pandoc转换时要么直接报错要么出来的Word表格缺列排错成本比转换本身还高。1.3 转换前先做一次格式体检这里分享一个我个人的操作习惯算是从翻车里总结出来的拿到OpenClaw输出的markdown文件后我从来不会直接甩给转换工具而是先做三件事。第一检查编码。确认文件是UTF-8编码Windows记事本另存时常见的UTF-8 BOM会导致文档开头出现一个看不见的字符Pandoc转换后第一段会莫名多一个空行或乱码符。第二检查图片路径。如果markdown里引用的是相对路径比如images/xxx.png你要确保图片目录和markdown文件是配套移动的。我见过太多人只把md文件发给别人图片一张不带转出来的Word全是裂图。第三检查公式定界符。OpenClaw输出的数学公式可能是$公式$这种单美元符也可能是\(...\)这种LaTeX定界符这两种在Pandoc里需要不同的扩展参数。我后面第三章会给出针对性的命令。这三步加起来不到两分钟但能帮你省掉后面一小时的排查时间。2. 六种markdown转doc方案我建议你这样选先别急着复制命令转换方案不止Pandoc一种我把市面上主流的六条路挨个试过各有优劣先把选型逻辑说清楚你再根据手头环境挑。2.1 Pandoc命令行方案稳且全Pandoc是瑞士军刀级别的文档转换器被称为文档界的格式转换万能工具能把markdown转docx、html、pdf、epub等几十种格式。它的优势有三个完全本地运行、格式转换保真度高、支持通过自定义reference.docx模板精确控制Word样式。代价是上手有门槛。你要熟悉命令行参数理解markdown扩展比如tex_math_dollars、gfm的意思还要会处理中文字体映射。对于需要用脚本批量转换、或者想要固定输出格式的人来说Pandoc是唯一值得投入学习成本的方案因为一旦配好就是一劳永逸。2.2 Typora所见即所得导出最省心Typora是最省心的可视化方案。打开markdown文件界面里就是渲染好的效果左上角菜单文件→导出→Word.docx点击完事儿。它对表格、图片、代码块的转换效果都很好内置了预设样式中文字体处理也比Pandoc默认值好看。局限在于Typora是收费软件买断制支持14天免费试用而且它的导出依赖Pandoc内核——本质上Typora是把Pandoc封装成按钮了。如果你不想装Pandoc也不想敲命令只做零星几份转换Typora是体验最好的选择。我自己在电脑上就常驻一个Typora专门应付临时转换。2.3 VSCode插件程序员顺手方案VSCode搭配Markdown All in One插件可以预览markdown再搭配Markdown PDF或vscode-pandoc扩展完成导出。这个方案适合本来就在VSCode里改文档的人它的转换内核依然是Pandocvscode-pandoc或者走浏览器渲染打印Markdown PDF导出的其实是打印版。说实话这个方案对纯Markdown写作者来说有点绕配置起来不如Typora直观。它的价值在于你可以在同一个编辑器里同时改md和跑任务不用来回切换窗口。我不建议新手优先选这条但如果你日常开发就在VSCode里顺手装上也无妨。2.4 在线转换工具应急可用别太依赖很多人在群里问的markdown转word在线工具我用过几款比如Markdown to Word、md2docx这类网页工具。它们的特点是免安装、打开就能用适合偶尔转一两份小文件。但我要提醒你三个坑一是文件隐私OpenClaw生成的报告里往往有业务数据上传到第三方在线工具处理等于把数据交给了别人公司内部的敏感资料不建议这么干二是大文件和复杂文档容易超时或转换失败公式和图片路径支持很差三是转换效果基本不可控输出样式是写死的你没法调字体和页码。结论很明确在线工具只适合非敏感、简单格式、单次应急的场景想稳定产出符合交付要求的docx还得回到本地方案。2.5 Word/WPS直接打开只能应急有人问能不能直接用Word打开md文件——Word 2016以下的版本基本打不开新版Word可以把md当作纯文本打开但没有任何标记渲染满屏都是##和|符号排版全乱。WPS也是类似表现。这条路的唯一价值是应急你没有装任何转换工具只是想快速看一眼md的原始内容用Word的打开方式选择纯文本查看即可。真要交付别走这条路。2.6 选型对照表方案学习成本转换质量批量/自动化费用适用场景Pandoc中高可定制强免费生产级交付、批量转换Typora低高预设好弱收费单份快速转换VSCode插件中中高中免费开发者日常顺手用在线工具低中低弱免费/订阅非敏感应急Word直接打开零极低无已有纯文本应急预览LibreOffice扩展中高中中免费开源环境强制要求我的建议很简单如果你只想要能用装个Typora如果你想要可控、规范、能自动化直接上Pandoc。下面第三章就围绕Pandoc展开完整实操这是我最推荐的生产级方案。3. Pandoc实操完整走一遍markdown转docx3.1 安装Pandoc三种系统Pandoc的安装在不同系统上有不同姿势我实测过的命令如下。Windows环境最简单的是用包管理器winget打开PowerShell执行winget install --id Pandoc.Pandoc -e --source winget如果没有winget也可以走Chocolateychoco install pandoc。装完后新开一个终端输入pandoc --version确认版本号Pandoc 2.x以上都对本文的命令兼容。macOS用户用Homebrew最省事brew install pandocLinuxUbuntu/Debian系用aptsudo apt update sudo apt install -y pandoc注意Ubuntu自带源里的Pandoc版本可能偏老有些还是2.9老版本对某些markdown扩展的支持不完整。如果你要转换的文档里有复杂公式或YAML元数据块建议去GitHub Releases下载最新的deb包安装或者用pandoc-crossref这类配套工具时再考虑版本匹配。安装完在命令行执行pandoc --version看到类似pandoc 3.1.3的输出就说明OK了。3.2 最简单的转换命令与参数说明Pandoc转换单份markdown到docx最基本的命令只有一行pandoc input.md -o output.docx如果你在命令行工作目录下直接运行Pandoc会根据-o参数的后缀名.docx自动推断输出格式非常聪明。这条命令适合纯文本、标题、简单列表这类基础文档实测转出来直接能打开Word样式已经帮你套好了内置的标题1/标题2/正文层级。但从OpenClaw出来的文档往往不只是基础元素所以我平时会加几个参数。这里给一条我常用的完整命令后面逐一解释每一项pandoc input.md -o output.docx --from markdowntex_math_dollarspipe_tables --resource-path. --highlight-styletango --reference-docmy-reference.docx--from markdowntex_math_dollarspipe_tables的意思是以标准的markdown语法为基础额外开启两个扩展——tex_math_dollars负责识别$...$和$$...$$包裹的数学公式pipe_tables负责识别管道符表格。这里解释一下为什么必须这么写Pandoc默认的markdown解析器会安全地忽略掉那些看起来像公式但实际不是公式的文本而$符号在普通文章中并不少见比如价格、变量名不显式开启数学公式扩展你的$x^2$就不会被转成Word公式而是原样以文本形式出现在docx里。--resource-path.指定资源查找路径让Pandoc在转换时从当前目录及相关子目录找图片这个参数后面在图片问题那节还会细讲。--highlight-styletango给代码块设置高亮主题。Pandoc转换代码块进Word时会把代码文本包在带底色的段落里设置这个参数后代码会有类似编辑器里的颜色区分默认的pygments主题在中文环境里偶尔发暗tango是我试下来对打印最友好的。--reference-doc是自定义Word模板的核心参数稍后专门讲。3.3 图片路径问题怎么治图片是OpenClaw生成markdown里最常见也最容易翻车的部分。原因在于OpenClaw在本地跑任务时生成图片的保存路径可能是绝对路径比如/home/user/openclaw/output/xxx.png也可能是相对路径比如./images/xxx.png还有一种情况是直接把图片以Base64编码嵌进markdown里。针对这三种情况处理方式不同。绝对路径和相对路径的图片Pandoc转换时会尝试按原路径读取图片文件并嵌入到docx里。如果报错找不到图片常见的排查是你的当前工作目录不在markdown文件所在目录。举个例子markdown文件在/data/report.md里面引用images/chart.png你在/home/user目录下执行pandoc /data/report.mdPandoc默认会在/home/user下找images/chart.png自然找不到。解决办法就是在命令里指定资源路径把它指向markdown文件所在目录pandoc /data/report.md -o report.docx --resource-path/data如果你把markdown和images目录一起拷到别的机器转换记得保持这个相对关系也就是让images目录和md文件在同一级目录下。Base64内嵌图片的情况OpenClaw在把图片塞进markdown时会以这种形式存在。好消息是Pandoc 2.10以上版本默认支持解析data:协议的图片直接就能提取并嵌入到docx不需要额外处理。如果你用的老版本发现转换后图片丢失建议优先升级Pandoc而不是去手动把Base64提取出来存成文件后者成本高得多。还有一个细节图片的alt文本也就是![]()里的说明文字在docx里会变成图片的替代文字描述建议你在OpenClaw生成报告时给它明确指令让每张图都带上语义化的alt说明这样转出来的Word里图片的辅助信息也完整给客户交付时显得专业很多。3.4 数学公式如何正确渲染OpenClaw在输出数据分析、算法说明这类文档时经常会出现数学公式。markdown里的公式有两种定界方式行内公式用单美元符$...$包裹独立公式块用双美元符$$...$$包裹实际上底层是LaTeX语法。Pandoc转Word公式的规则是这样的它会把LaTeX公式转换成Office的OMML公式格式这样docx里的公式是活的——在Word里双击可以编辑、可以和正文对齐、可以参与编号。为了让Pandoc正确识别公式你必须显式开启tex_math_dollars扩展。我踩过最经典的坑是这个在GitHub Flavored MarkdownGFM模式下Pandoc默认不带tex_math_dollars所以如果你用了--from gfm还指望公式能出来那转出来就是一堆$符号包裹的纯文本。正确的写法是pandoc input.md -o output.docx --from markdowntex_math_dollars或者你想保留GFM的表格和任务列表特性同时也要公式就显式追加pandoc input.md -o output.docx --from gfmtex_math_dollars顺带说一句如果你文档里公式特别多强烈建议在转换前去markdown里检查一遍公式定界符是否配对。比如$p \frac{a}{b}$写成$p \frac{a}{b}这种漏了尾部美元符的情况Pandoc会直接把后面一大段普通文本都吞进公式里转换结果会让你怀疑人生。我一般在转换前用任何支持markdown渲染的编辑器预览一遍看到公式区域是正常高亮显示的再转。3.5 自定义Word样式中文字体与排版Pandoc默认生成的docx样式套用的是它内置的reference.docx模板英文环境没问题但中文环境下有几个尴尬点中文字体可能被设置成不适合的默认值容易变成Calibri或思源黑体的怪组合、正文没有首行缩进、标题层级字体大小偏大偏硬。解决办法是用--reference-doc指定一个你自己的Word模板。生成模板的命令pandoc -o custom-reference.docx --print-default-data-file reference.docx这会在当前目录生成一个custom-reference.docx它本质上是一个空的Word文档但内含Pandoc规定的样式结构。你用Word打开它直接修改正文样式把中文字体设为宋体或思源宋体、字号小四、首行缩进2字符、修改标题1/2/3样式设置黑体、字号、颜色、段前段后间距保存后下次转换时带上这个参数pandoc input.md -o output.docx --reference-doccustom-reference.docx这样所有转换出来的文档都会套用你调好的样式模板。这个技巧对需要统一规范输出的团队特别有用比如公司宣发报告有固定VI模板你只需要让行政给一份模板源文件把你要的样式定义进去以后所有OpenClaw生成的报告转出来都是统一的版式。我自己就把模板里的正文设置成了宋体小四、1.5倍行距、首行缩进两字符标题2设为黑体三号加粗表格字体设为微软雅黑五号实测交付的文档基本不需要二次调整。4. 转换后最常见的五个坑与排查方法这部分我把实际转换过程中踩过的坑和对应的解决方案整理成一个速查表你遇到类似问题直接对照着查。4.1 图片裂开docx里图片全是红叉原因几乎只有两个--resource-path没指对或者markdown里的图片路径写的是绝对路径但源文件目录已经变了。排查顺序先在终端里尝试pandoc input.md -o test.docx --resource-pathmarkdown所在目录看能否解决。不行就打开markdown源文件搜索 --resource-pathC:\reports --reference-docC:\templates\my-reference.docx }Linux/macOS下用bash一行搞定for f in /data/reports/*.md; do pandoc $f -o ${f%.md}.docx --resource-path/data/reports --reference-doc/data/templates/my-reference.docx; done这里有个细节脚本运行时建议把图表等资源目录一起包含进--resource-path不然批量转的时候图片会集体丢失。我一般把--resource-path指向reports目录的父级让它递归查找。5.2 在OpenClaw里加一个转换skillOpenClaw本身就有skill技能机制你可以给龙虾定义一个转换技能让它输出markdown文件后自动执行转换命令。这个思路很多人想不到但实际效果很好Agent跑完任务直接产出一个docx交付链路一步到位。具体做法是在OpenClaw的skill配置里加一个名为md_to_doc的技能定义大致是这样的技能描述写明当需要将markdown报告转换为Word文档时执行命令先确认文件路径然后运行pandoc转换命令带--reference-doc参数指定模板。这样你给OpenClaw下指令时只要说生成数据报告并转成docx它就会先输出md再调用你定义的shell命令完成转换最后把docx路径返回给你。我在实测中发现一个稳定性的问题Agent调用shell命令的环境变量和PATH可能和你手动终端不一样首次调用pandoc会报command not found。解决方法是把pandoc的完整路径写进skill的命令里Windows下比如C:\Users\xxx\AppData\Local\Programs\Pandoc\pandoc.exe或者在skill配置里先执行export PATH$PATH:/usr/local/bin这类环境初始化命令。这个坑我不说你十有八九会撞上。5.3 云端自动化coze工作流兜底如果你不想依赖本地环境也可以把markdown转doc放到Coze这类工作流平台上。思路是这样的在Coze里搭一个自动化流程输入端接收markdown文件或内容中间节点调用文档转换接口或直接在服务器上执行Pandoc命令行最后输出docx文件。这类工作流的价值在于你不用管转换工具装没装也不用管操作系统差异上传md就能拿到docx。适合那种同事给你一个md你转完发回的协作场景。要注意的是云端转换涉及文件上传敏感内容自己掂量最好用私有化部署的转换服务或者自建服务器跑Pandoc别把公司数据传到公共工作流上。我在实际使用中体会最深的一点是markdown转doc这事工具本身都不难难的是知道自己要什么格式。你花半小时把reference.docx模板配好把Pandoc命令参数琢磨透后面每次转换都是顺手的事比每次都在线找工具、手动调格式要省太多时间。最后再分享一个小技巧批量转换后顺手用Word打开docx检查一遍标题导航窗格如果各级标题都正确出现在导航栏里说明样式映射成功这份文档就可以放心交付了。格式这条路上最大的成本从来不是转换本身而是你对产出标准的定义是否清晰。