上一篇文章讲 .docx 为什么让 AI 头疼——段落被样式标签切成一堆
答案很朴素：Markdown。
就是那个用 # 标标题、用 - 列清单、用 > 引内容的纯文本格式。你没听错——AI 最喜欢的格式，恰好也是最简单的格式。
Markdown 的本质：纯文本加几个约定
先别把事情想复杂。Markdown 本质上就是一个纯文本文件，里面加了几个轻量标记。# 开头的行是标题，- 开头的行是列表项，> 开头的是引用，文字 就是一个超链接。你在编辑器里看到的样子，和你用记事本打开看到的内容，几乎一模一样——不含任何隐藏信息。
和 .docx 比一下，差异就清楚了。
一个 .docx 文件本质上是一个 ZIP 压缩包。你把它后缀改成 .zip 解压，会看到一个叫 document.xml 的文件，里面装着文档正文；一个叫 styles.xml 的文件，定义所有样式；还有 numbering.xml（编号规则）、settings.xml（文档设置）、comments.xml（批注）……加起来几十个文件。Word 的工作方式是：打开时把这几十个 XML 拼成你看到的文档，保存时再把你的操作拆回几十个 XML。
一个"加粗的一级标题"在 Word 里需要经过四层定义：先建一个样式，关联编号规则，指定字体和字号，再标记加粗属性。在 Markdown 里，它就是 # 标题，七个字符。
这就是 Markdown 的哲学核心：所见即所得，所见即所读。排版交给渲染器去处理，源文件里只留内容和结构。你用眼睛看完整个文件，就真的一行不落地读完了——没有暗箱，没有隐藏层。
为什么 AI 喜欢它？四个原因
一、文本连续，不被切碎
.docx 里有一个叫"run"（文本运行段）的概念。AI 读 Word 文档时最头疼的就是这个东西。
什么叫 run？Word 在底层会把一个段落拆成多个 run 来存储。同一个段落里的文字，因为格式不同——比如前几个字加粗，中间几个字正常，后几个字用了不同字体——会被切成三个独立的 run。AI 读到的不是一段话，而是
这就像你读一封信，但每个词写在不同的便利贴上——核心意思分散在若干 XML 标签之间，AI 在提取之前先得"拼图"。哪怕是最简单的句子，解析器也要在 DOM 树里跳来跳去，把属于同一个段落的 run 节点串回来。
Markdown 没有 run。一段话就是一段话，完完整整。加粗也好、斜体也好，不过是几个 ** 符号包在文字外面，文字本身是连续的。AI 读到的是人类写下的原始形态：完整的句子、完整的段落、完整的逻辑流。
文本连续性是语言模型理解质量的地基。地基碎了，上面盖什么都不稳。
二、语义标记明确，标记即语义
.docx 的"标题"是靠样式 ID 定义的。一个段落被标记为 Heading 1，不是因为它的内容看起来像标题，而是因为它在 XML 里引用了一个叫 Heading1 的样式 ID。这个样式 ID 的实际效果——多大字号、什么字体、是否加粗、前后间距——又在 styles.xml 里层层定义。
这就产生了一个 AI 极难处理的歧义：一个名字叫"标题"的样式，实际渲染出来可能是 14pt 红色仿宋。AI 要通过解析多层 XML 引用关系才能确认"这确实是一个标题"。更麻烦的是，有人可能把一个命名为"标题"的样式用在了正文上——名字叫标题，实际当正文用，AI 根本无从判断。
而 Markdown 是这样处理标题的：
# 这是一级标题# 就是标题。这个符号本身携带了完整语义，不依赖外部样式表、不依赖编号规则、不依赖字体定义。列表的 -、引用的 >、代码块的三个反引号——每一个标记的语义都是自解释的。
标记即语义。你写的是什么，它代表的就是什么。AI 不需要猜。
这个差异在日常使用中几乎感知不到，但换成大规模文档处理，差距会被急剧放大。用 .docx 做 AI 知识库，你得先写一堆解析脚本——样式映射、编号提取、嵌套层级识别。用 Markdown，直接喂就行。
三、Git 友好，版本可追溯
.docx 是二进制和 XML 的混合格式。把两个版本的 .docx 放进 Git，Git 看到的是一坨不可读的二进制差异。谁改了第几段、改了什么内容，完全不可见。
协作场景更糟。张三改了第三段，李四改了第五段——如果他们都改了同一个 .docx 文件，合并时几乎一定会产生冲突。Word 自带的"比较合并"功能也只是在碰运气，遇到复杂格式变化基本歇菜。
所以大多数团队的 Word 文档协作方式是"合同 v1.docx""合同 v2 张三修改.docx""合同 v3 李四修改.docx"——用文件名管理版本。2012 年这么做没问题。2026 年了，不该这样了。
Markdown 是纯文本。改一个字，git diff 那行就亮一下：
- 甲方应于2024年12月31日前支付。
+ 甲方应于2025年3月31日前支付。谁改的（git blame）、什么时候改的（git log）、改了什么（git diff），全链路可追溯。两个人同时改同一个文件的不同段落，Git 自动合并，几乎没有冲突。
合同谈判阶段，用 Markdown 写草稿，每一版修改都有据可查；团队知识库维护，谁更新了什么内容、什么时候更新的，拉一下 log 就清楚；AI prompt 模板库，改了哪个模板、为什么改，提交记录就是文档。
四、无隐藏信息，所见即全部
Word 文档里有大量用户看不见但确实存在的东西：页眉页脚、分节符、样式继承链、自动编号规则、域代码、批注元数据、修订人姓名和时间戳。
这些东西对排版有用——Word 是一个排版工具，它需要这些信息来实现所见即所得。但对 AI 来说，这些都是噪音。AI 不需要知道某段文字用了什么字体，它只需要知道这段文字是什么、它在文档结构中的位置是什么。
Markdown 没有隐藏层。源文件里的每一个字符你都看得见。没有页眉页脚——你想加，就打一段文字标注"这是页脚"；没有自动编号——你手动写 1. 2. 3.；没有样式继承——标题就是 #，一级一级往下排。
这个"缺点"正是它干净的原因。排版靠渲染器，不靠文件内部的样式引擎。你给 AI 的输入里没有意外，没有暗箱，没有"我看不见但 AI 看得到"的东西。
.docx vs Markdown：一张表说完
| .docx | Markdown | |
|---|---|---|
| 文本结构 | 被 run 切碎，一个段落拆成多个 XML 片段 | 连续纯文本，一段就是一段 |
| 语义标记 | 依赖样式 ID，解析多层 XML 引用 | 标记即语义，# = 标题 |
| 版本管理 | Git 不可读，合并靠文件名 | git diff 精确显示，自动合并 |
| 隐藏信息 | 页眉页脚、修订痕迹、样式继承、自动编号 | 无，所见即全部 |
| AI 解析难度 | 需要专门解析器处理多层嵌套 XML | 任何能读文本的程序都能处理 |
| 排版能力 | 强，精细排版 | 弱，不适合正式交付终稿 |
数据结构和语义透明度决定 AI 处理效率。这件事不取决于观点，取决于格式本身的构造。
法律人的 Markdown 场景
说回我们法律人的日常。以下四个场景，用 Markdown 比用 Word 高效得多——不是理论推演，是实际在用。
合同草稿。 一份商业合同在谈判阶段改几十版很正常。用 Markdown 写草稿放在 Git 里，每一轮修改都有记录可查：谁在什么时候改了哪一条、之前是什么版本、为什么改。敲定后转 Word 排版交付给客户——干净、正式、没有修订痕迹。中间过程的混乱，留在 Git 历史里，不影响终稿的体面。
案件分析报告。 事实梳理、争议焦点归纳、法律依据列举、风险判断——这些内容天然是层级化的。Markdown 的标题系统直接对应分析框架：一级标题是争议焦点，二级标题是我方主张，三级标题是支撑依据。写出来结构就立住了，不需要在 Word 里反复调格式、刷编号。
法律知识库。 我们团队在 2025 年开始把知识管理全部迁到 Markdown + Git。法规解读、类案梳理、合同条款库、内部培训素材，全部是 .md 文件放在一个 Git 仓库里。全文检索用 ripgrep，一秒出结果；版本历史靠 git log；团队协作靠 PR 审阅。比 Word 文档散落在各个群聊和传输助手里，可靠性和可维护性高出不止一个量级。
AI prompt 撰写。 这是最直接的场景。好的 prompt 模板需要反复迭代——改一句话、换一种表达、增减一个约束条件。Markdown 的代码块天然适合嵌 prompt 模板，语义清晰，复制即用。整个团队的 prompt 库放在仓库里，版本管理、协作维护、按需调用，一次搞定。
说边界：Markdown 不擅长什么
排版能力弱。 Markdown 没有分页控制、没有页眉页脚、没有多栏布局。对法院提交的正式文书、给客户的终稿合同、需要严格排版的公开发布材料——Markdown 不适合做终稿。我们的做法是：草稿和协作阶段用 Markdown，定稿后转 Word 排版。
表格支持有限。 简单表格够用，但合并单元格、嵌套表格、复杂条件格式——Markdown 的表格语法马上捉襟见肘。这个问题在不同实现里程度不同（GitHub Flavored Markdown 比标准 Markdown 强一些），但和 Excel 或 Word 的表格能力相比，差距是结构性的。
图片管理不便。 Markdown 引用图片用的是本地路径或 URL，不像 Word 把图片嵌入文件内部。文件换位置，图片链接容易断。解决方法也有——图床、相对路径约定、把图片和 .md 文件放在同一目录——但总归多了一步心智负担。
没有"修订模式"。 Word 的修订痕迹是强需求——律师给客户改合同，客户要看"你改了什么"。Markdown 的解决方案是 Git diff，但在不懂 Git 的人面前，这个替代方案并不友好。发给客户的合同草稿，还是得用 Word 的修订模式。
知道边界，用对场景，就够了。Markdown 不是要替代 Word——它替代不了，也没必要。它替代的是"用 Word 写草稿"这个习惯。
收尾
AI 喜欢 Markdown，不是因为它高级，恰恰是因为它低级——低级到没有任何包袱，只有写下的内容和它的结构。你把一个 .md 文件交给 AI，它看到的就是全部。没有隐藏层，没有格式碎片，没有样式歧义。
这恰好是 AI 读文本时最想要的东西：干净的、诚实的、不藏事的。
作者简介： 陈石律师，浙江海泰律师事务所副主任、高级合伙人、房地产与建设工程部主任，宁波市律师协会副秘书长、第七届宁波仲裁委员会仲裁员，聚焦建筑房地产、投融资、并购重组及商事争议解决。曾获多家法律媒体与专业机构认可，荣登 LegalOne 2025 中国区建工及房地产实务先锋 45 强、律新社 2025 年度管理合伙人 20 佳（华东），入选《商法》The A-List 法律精英，获评 ALB China 区域市场十五佳长三角地区律师新星，并获律新社 2024 年度并购领域品牌之星。长期为万科、华润置地、信达地产、保利置业、招商蛇口、中海地产等企业提供法律服务，承办"首宗百亿地王""长春第一高楼""台州第一高楼"等代表性项目，累计服务项目投资额超千亿。近年来持续推动 AI 与法律实务融合，强调以结构化方法打通技术逻辑、法律判断与商业场景；著有《赋能法律人：AI 底层思维与应用范式》，并在多地开展相关主题讲座与分享。四明山法师 AI 夜校（legalAGI.cn）发起人。