!封面
我每周都要处理大量 Word 文档——合同、诉状、尽调报告、法律意见书。这些文档在人类同事和客户之间流转顺畅，批注、修订、签字、盖章，一切正常。
但一丢给 AI，问题就来了：条款编号丢了，表格读乱了，修订痕迹和正文混在一起，页眉里的合同编号直接消失。
不是 AI 不行。是 .docx 这个格式，从一开始就没打算给机器读。
.docx 是一个以"视觉排版还原"为核心目标的复杂文档容器。AI 喜欢的是"语义清晰、结构稳定、文本连续、差异可比"的格式。两者目标天然冲突。
打个比方：.docx 像一个装修完成的办公室——人走进去很舒服，知道哪里是会议室、哪里是前台。但 AI 要的是建筑图纸：房间 A 是会议室，30 平米，位于一层东侧，相邻走廊和茶水间。Word 给你看装修效果，AI 要的是 CAD。
一、自己动手拆一个 .docx
在讲原理之前，先做一件事——这件事比任何解释都有说服力。
你手边随便找一份 .docx 文件，合同、报告、诉状都行。然后：
第一步，复制一份（别直接改原文件）：
合同.docx→ 复制为 →合同-拆解用.docx
第二步，把扩展名改成 .zip：
合同-拆解用.docx→ 改名 →合同-拆解用.zip
第三步，双击解压。
你会看到这些东西：
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 600 640">
<!-- 顶部：三步流程 -->
<rect x="40" y="15" width="140" height="38" rx="4" fill="#f0f0f0" stroke="#ccc" stroke-width="1"/>
<text x="110" y="39" text-anchor="middle" font-size="13" fill="#333" font-weight="700">合同.docx</text>
<text x="195" y="39" text-anchor="middle" font-size="12" fill="#999">改名</text>
<line x1="185" y1="34" x2="205" y2="34" stroke="#999" stroke-width="1"/>
<line x1="205" y1="34" x2="210" y2="30" stroke="#999" stroke-width="1"/>
<line x1="205" y1="34" x2="210" y2="38" stroke="#999" stroke-width="1"/>
<rect x="220" y="15" width="155" height="38" rx="4" fill="#f0f0f0" stroke="#ccc" stroke-width="1"/>
<text x="297" y="39" text-anchor="middle" font-size="13" fill="#333" font-weight="700">合同-拆解用.zip</text>
<text x="390" y="39" text-anchor="middle" font-size="12" fill="#999">解压</text>
<line x1="380" y1="34" x2="400" y2="34" stroke="#999" stroke-width="1"/>
<line x1="400" y1="34" x2="405" y2="30" stroke="#999" stroke-width="1"/>
<line x1="400" y1="34" x2="405" y2="38" stroke="#999" stroke-width="1"/>
<!-- 分隔线 -->
<line x1="40" y1="68" x2="560" y2="68" stroke="#ddd" stroke-width="1"/>
<!-- 左侧：目录树 -->
<text x="40" y="92" font-size="14" font-weight="700" fill="#333">解压后的目录结构</text>
<!-- 文件夹和文件树 -->
<text x="40" y="118" font-size="12" fill="#666">📄 [Content_Types].xml</text>
<text x="40" y="140" font-size="12" fill="#666">📁 _rels/</text>
<text x="55" y="160" font-size="12" fill="#999">└─ .rels</text>
<text x="40" y="182" font-size="12" fill="#666">📁 docProps/</text>
<text x="55" y="202" font-size="12" fill="#999">├─ core.xml</text>
<text x="55" y="222" font-size="12" fill="#999">└─ app.xml</text>
<text x="40" y="248" font-size="12" fill="#333" font-weight="700">📁 word/ ← 重点看这里</text>
<text x="55" y="270" font-size="12" fill="#c41e3a">├─ document.xml</text>
<text x="55" y="292" font-size="12" fill="#333">├─ styles.xml</text>
<text x="55" y="314" font-size="12" fill="#333">├─ numbering.xml</text>
<text x="55" y="336" font-size="12" fill="#333">├─ comments.xml</text>
<text x="55" y="358" font-size="12" fill="#999">├─ footnotes.xml</text>
<text x="55" y="380" font-size="12" fill="#999">├─ header1.xml</text>
<text x="55" y="402" font-size="12" fill="#999">├─ footer1.xml</text>
<text x="55" y="424" font-size="12" fill="#333">├─ settings.xml</text>
<text x="55" y="446" font-size="12" fill="#333">├─ fontTable.xml</text>
<text x="55" y="468" font-size="12" fill="#333">├─ theme/</text>
<text x="55" y="488" font-size="12" fill="#333">├─ media/</text>
<text x="55" y="510" font-size="12" fill="#999">└─ _rels/document.xml.rels</text>
<!-- 右侧：注释框 -->
<rect x="230" y="80" width="335" height="142" rx="4" fill="#fff" stroke="#c41e3a" stroke-width="1.5"/>
<text x="245" y="100" font-size="13" fill="#c41e3a" font-weight="700">document.xml — 正文</text>
<text x="245" y="120" font-size="11.5" fill="#555">你写的每段文字都在这里。但正文被大</text>
<text x="245" y="138" font-size="11.5" fill="#555">量 XML 标签包裹，一句话可能被拆成多</text>
<text x="245" y="156" font-size="11.5" fill="#555">个文本片段（run），因为加粗/字体/拼写</text>
<text x="245" y="174" font-size="11.5" fill="#555">检查等原因。</text>
<text x="245" y="198" font-size="11.5" fill="#555">例如你看到的"第一条 合同目的"：</text>
<rect x="245" y="204" width="310" height="14" rx="2" fill="#f8f8f8"/>
<text x="250" y="214" font-size="10" fill="#888" font-family="Menlo, monospace"><w:r><w:t>第一条</w:t></w:r></text>
<rect x="250" y="240" width="300" height="100" rx="4" fill="#fffef5" stroke="#e0dcc0" stroke-width="1"/>
<text x="260" y="260" font-size="11.5" fill="#997a00" font-weight="700">styles.xml — 样式定义</text>
<text x="260" y="280" font-size="11" fill="#666">正文、标题1、标题2的字号/字体/间距。</text>
<text x="260" y="298" font-size="11" fill="#666">问题：很多人手动加粗调字号，不使</text>
<text x="260" y="316" font-size="11" fill="#666">用"标题1"样式 → AI 认不出层级结构。</text>
<rect x="250" y="350" width="300" height="80" rx="4" fill="#fffef5" stroke="#e0dcc0" stroke-width="1"/>
<text x="260" y="370" font-size="11.5" fill="#997a00" font-weight="700">numbering.xml — 自动编号</text>
<text x="260" y="390" font-size="11" fill="#666">"一、""（一）""1."这些编号是动态生成</text>
<text x="260" y="408" font-size="11" fill="#666">的，不是正文文字。解析器处理不好 →</text>
<text x="260" y="426" font-size="11" fill="#666">条款编号丢失（对法律文书尤其致命）。</text>
<rect x="250" y="440" width="300" height="65" rx="4" fill="#fffef5" stroke="#e0dcc0" stroke-width="1"/>
<text x="260" y="460" font-size="11.5" fill="#997a00" font-weight="700">comments.xml — 批注</text>
<text x="260" y="480" font-size="11" fill="#666">律师意见、风险提示、谈判底线都在</text>
<text x="260" y="498" font-size="11" fill="#666">这里。不读丢上下文，读了可能污染正文。</text>
<rect x="250" y="515" width="300" height="50" rx="4" fill="#fffef5" stroke="#e0dcc0" stroke-width="1"/>
<text x="260" y="535" font-size="11.5" fill="#997a00" font-weight="700">media/ — 图片 & _rels/ — 资源关系</text>
<text x="260" y="553" font-size="11" fill="#666">图片不在正文XML里，靠关系文件串联。</text>
<!-- 底部提示 -->
<rect x="40" y="565" width="520" height="52" rx="4" fill="#f5f5f5" stroke="#ddd" stroke-width="1"/>
<text x="55" y="585" font-size="11.5" fill="#888">⚠ 两个提醒：① 先复制再改扩展名，别直接改原文件；② 老式 .doc 是二进制格式，改名 .zip 解不开——只有 .docx/.pptx/.xlsx 可以。</text>
<text x="55" y="605" font-size="11.5" fill="#888">结论：.docx / .pptx / .xlsx 本质都是 ZIP + XML；.doc 是另一回事。</text>
</svg>你亲手拆过一次之后，很多事情就清楚了：.docx 不是一个"文档文件"，而是一个"压缩后的文档工程包"。正文、样式、编号、批注、图片、页眉页脚分散在十几个文件里，靠关系文件（.rels）把它们串在一起。
注意：只有 .docx 能这样拆。老式 .doc 是二进制格式，改成 .zip 解不开。同样 .pptx 和 .xlsx 也是 ZIP + XML，都适用这套操作。
二、人类为什么离不开 Word？
因为它解决的是办公世界最重要的问题：文档看起来对不对，能不能打印，能不能签字，能不能交付。
所见即所得——你看到什么，打印出来就是什么。合同里的页眉页脚、页码、首行缩进、签字页位置、盖章空间，这些东西在 Markdown 和纯文本里都是灾难。
修订和批注——法律场景里这几乎是不可替代的。律师、客户、对方律师都能看到：谁删了哪句话，谁加了什么，批注里写了什么意见，修订接受了没有。这是 Word 在商业协作里的核心壁垒。
它承载的是"文档状态"——这个编号是不是自动编号，这个表格是不是跨页，这个脚注是不是对应正文，这个页眉是不是只在首页不同，这个条款是不是还保留着谈判痕迹。对人来说这是完整的文档感知，但对 AI 来说，这里面大量信息是噪声。
三、AI 为什么头疼？
五个核心原因。
1. 文本不连续。 AI 要的是连续、线性的文字流。但 .docx 里同一句话可能被拆成三四个 run——只是因为字体变了、加粗了、有拼写检查标记、中英文混排、或者复制粘贴带入了格式。人眼看是一句话，机器看是一堆碎片。
2. 结构和视���混在一起。 AI 想知道"这是标题""这是正文""这是引用"。但 Word 告诉你的是"这行字加粗了""这行缩进了 2 字符""这段段前距 12 磅"。更麻烦的是，很多人不用"标题 1"样式，而是手动把一行字加粗放大——人类看起来是标题，机器看到的只是一段格式特殊的大号文字。
3. 样式信息大量冗余。 同一句话在 .docx 里可能附带几十行字体、颜色、间距、语言的 XML 标签。这些对排版有用，对理解内容没用，但清洗起来很费劲。
4. 信息散落在十几个文件里。 正文在 document.xml，图片在 media/，脚注在 footnotes.xml，批注在 comments.xml，页眉在 header1.xml，超链接关系在 .rels 里。AI 想"完整理解"一份文档，得自己判断：页眉读不读？批注读不读？修订前还是修订后？文本框里的字算不算正文？表格按行还是按列？没有标准答案。
5. 版本管理极不友好。 .docx 是 zip 包。Git 看到它只会说 Binary files differ。哪怕你只改了一个字，压缩包内部也可能整体变化。Word 自己有"修订模式"和"比较文档"，但那是 Word 生态内的机制，不是通用版本控制。
四、法律场景下问题更大
法律文档对结构的要求比普通文档高得多。合同、诉状、代理意见、判决书，核心信息严重依赖条款编号、层级结构、表格、批注和修订痕迹。而 .docx 的复杂性在法律场景里会被放大：
条款编号丢失。 你看到"第三条 付款条件"，AI 提取后可能只剩"付款条件"。因为编号可能是 numbering.xml 动态生成的，不是正文文字。引用直接错位。
表格读取错位。 付款节点 | 付款比例 | 付款条件——这个三列关系在 AI 提取后可能变成一串无结构的文字流，法律含义完全改变。
修订痕迹的不确定。 谈判稿里一方删了"不承担违约责任"，但修订还没接受。AI 到底读删除前的还是删除后的？读错了，结论就反了。
页眉页脚的关键信息。 合同编号、项目名称、版本号、保密标识——经常在页眉页脚里，普通提取器直接跳过。
批注里的谈判信息。 法律文档的批注不是普通备注，里面可能有律师意见、风险提示、客户决策、对方让步和谈判底线。只读正文不读批注，丢掉了最重要的上下文。把批注当正文，又污染了正式文本。
五、Markdown / HTML / TXT 为什么更适合 AI？
这三种格式的共同特点是：文本连续，语义明确，结构稳定，版本差异可追踪。
Markdown 是最理想的中间格式。# 就是标题，- 就是列表，> 就是引用。没有隐藏信息，没有排版噪声，Git diff 清清楚楚。AI 读起来最省力。
HTML 比 Markdown 对表格和链接的支持更完整。 明确告诉机器"这是一级标题"，不会跟加粗文字搞混。
纯文本 最朴素但最稳定。不会隐藏内容，不会携带格式噪音，任何系统都能读。代价是结构弱，得靠人为规范来补。
六、"人喜欢"和"AI 喜欢"为什么正好相反？
| 维度 | 人喜欢 Word 的原因 | AI 不喜欢 Word 的原因 |
|------|-------------------|---------------------|
| 排版 | 所见即所得，能打印能签字 | 排版信息过多，干扰语义 |
| 修订 | 方便审阅和谈判 | 修订前后文本混杂 |
| 批注 | 协作讨论很方便 | 批注和正文边界不清 |
| 表格 | 视觉上很清楚 | 提取后结构错乱 |
| 编号 | 自动编号省事 | 编号可能不是正文 |
| 图片 | 直接嵌入截图扫描件 | 需要额外 OCR |
| 版本 | Word 内部能比较 | Git 外面没法 diff |
| 文件 | 一个文件好传输 | 实际是复杂 zip 工程包 |
核心矛盾一句话：人类靠视觉理解文档，AI 靠结构和文本理解文档。Word 强在视觉，弱在结构稳定性。
回到开头那个比喻——人需要装修好的办公室，AI 需要建筑图纸。两种需求都是真实的，但服务于完全不同的目的。
七、实际怎么做？
不要幻想"不用 Word"。在法律行业不可能。
更务实的策略是建立一条转换流水线：
Word 接收材料 → 转 Markdown / HTML / JSON → AI 分析处理 → 生成结果 → 回写 Word → PDF 固化交付
也就是三层分工：
- 人类协作层：docx（接收、修订、交付）
- 机器处理层：md / html / json（AI 分析、比对、提取）
- 最终交付层：docx / pdf（签字、盖章、归档）
转换工具的选择取决于目的：普通文本分析转 Markdown 就够了；需要保留表格和页面结构用 HTML；做条款数据库和 RAG 检索用 JSON。
这篇文章本身就是一个例子——我用 Markdown 写的，结构干净，改起来方便，发到公众号时再转成微信 HTML。如果一开始用 Word 写，中间每一步都要多花时间清洗格式。
八、一句话总结
.docx 不是文本文件，是页面排版容器。它和人办公的习惯严丝合缝，和 AI 的工作方式处处冲突。
不怪 Word，也不怪 AI。它们本来就是在为两个不同的读者服务。
作者简介： 陈石律师，浙江海泰律师事务所副主任、高级合伙人、房地产与建设工程部主任，宁波市律师协会副秘书长、第七届宁波仲裁委员会仲裁员，聚焦建筑房地产、投融资、并购重组及商事争议解决。曾获多家法律媒体与专业机构认可，荣登 LegalOne 2025 中国区建工及房地产实务先锋 45 强、律新社 2025 年度管理合伙人 20 佳（华东），入选《商法》The A-List 法律精英，获评 ALB China 区域市场十五佳长三角地区律师新星，并获律新社 2024 年度并购领域品牌之星。长期为万科、华润置地、信达地产、保利置业、招商蛇口、中海地产等企业提供法律服务，承办"首宗百亿地王""长春第一高楼""台州第一高楼"等代表性项目，累计服务项目投资额超千亿。近年来持续推动 AI 与法律实务融合，强调以结构化方法打通技术逻辑、法律判断与商业场景；著有《赋能法律人：AI 底层思维与应用范式》，并在多地开展相关主题讲座与分享。四明山法师 AI 夜校（legalAGI.cn）发起人。