格式即信息：AI 文档处理的 Markdown 陷阱

最近在技术社区看到一篇很有意思的分享。一位开发者讲了他用 AI 做论文格式审查的经历，过程大致是这样：他有一批学生的毕业论文需要审，想着这活儿规则明确、标准清晰，正好适合交给 AI 来做。

但结果反复翻车。AI 总是"看起来理解了内容，一到格式审查就不对劲"。他一开始以为是 AI 不够聪明，后来去看了实际的执行过程，才发现问题根本不在"够不够聪明"，而在最开始的那个环节——AI 在处理 DOCX 文件时，底层走的是"先转 Markdown，再分析"的路径。

字体、字号、段落间距、标题层级、缩进、批注、色块，这些格式信息在转换的第一步就被丢了个干净。后面的分析能力再强，审查对象已经不存在了。

这件事的巧妙之处在于，它不是个例。这位开发者遇到的问题，本质上揭示了当下 AI 处理文档时一个被广泛忽视的结构性缺陷。而这个缺陷的影响范围，远比"论文格式审查"要大得多。

他文章里有一句话概括得很到位："AI 看到的，还是不是那个真正要交付的文档？"

DOCX 转 Markdown：一条"隐形的信息折损链"

要理解这个问题的严重程度，得先看清楚 DOCX 和 Markdown 之间到底差了什么。

DOCX 本质上是一个基于 Open XML 标准的压缩包，里面装着文档的全部信息：文字内容、字体样式、段落属性、页面设置、批注、修订记录、嵌入对象、域代码，甚至自定义 XML 标签。而 Markdown 的设计哲学是"内容与样式分离"——它只关心文字的基础结构（标题层级、粗体、列表、链接），对于字号、行距、段间距、缩进方式、页边距、批注、修订等文档属性，几乎没有表达能力。

从 DOCX 到 Markdown 不是"无损压缩"，更像是"选择性过滤"。那些在论文答辩中被严格检查的格式要素——一级标题是不是黑体三号居中、段落行距是不是 1.5 倍、参考文献格式对不对——在转换过程中几乎全部被丢弃。AI 在分析之前，就已经把自己需要审查的东西弄丢了。

而且这个折损是双向的。不仅"读"文档会丢格式，"写"文档也一样。如果你要求 AI 生成一份格式规范的 Word 文档，但底层仍然是"先生成 Markdown 再转 DOCX"，输出结果在格式细节上大概率经不起推敲。因为生成端面临同样的问题：格式信息从哪来？Markdown 的语法体系里就没有这些信息。

所以，不管是输入端还是输出端，"绕经 Markdown"这条路径都存在一个根本性的信息断层。这不是 AI 模型能力的问题，而是技术路径选择的问题。

问题不在 AI，在路径

那为什么主流的 AI 工具几乎都走这条"转 Markdown"的路径？

原因很简单：通用大模型的接口是纯文本。不管是 GPT、Claude 还是 Gemini，它们的输入输出都是一串文字。文档对于这些模型来说，只是一个需要被"翻译"成文字的载体。在模型眼里，DOCX 和 PDF 没有本质区别——都是需要先"提取文字内容"再理解的东西。

这条路径在"总结文章""翻译段落""改写文本"这类纯语义任务中确实够用。但当任务本身就和格式强相关——论文格式审查、公文版面检查、合同批注修订、报表结构校验——纯文本接口的局限性就彻底暴露了。模型能判断"这段话的逻辑是否自洽"，但无法判断"这个标题的字号是不是三号"，因为字号信息从来就没到过它手里。

这意味着，要让 AI 真正胜任这类任务，仅靠"更强的模型"是不够的。你需要一个根本性的路径变化：AI 不应该通过一个纯文本接口去"翻译"文档，而应该直接"活在"文档里面——能直接读取文档的样式树、段落属性、版面结构，也能直接在文档上写批注、调格式、改样式。

换句话说，你需要一个不是"从外部观察文档"的 AI，而是一个"在文档内部工作"的 AI。

这个方向上的自然推论是：最适合做这件事的，恰恰是那些本身就长在文档编辑器里的 AI——它们不需要转换格式，因为文档原生环境就是它们的"母语"。

当 AI "活在"文档编辑器里

顺着上一章的逻辑，如果让 AI 直接工作在文档的原生格式上——不需要转 Markdown，不需要走中间层——很多问题会从根源上消失。

以 WPS AI 为例来解释这条路径的具体实现。WPS 本身就是文档的运行环境，AI 直接嵌入在 WPS 文字、WPS 表格、WPS PDF 这些组件内部。这意味着它处理的始终是文档的完整结构，而不是经过转换的纯文本。当用户打开一份论文，AI 看到的就是包含所有样式信息的那份 DOCX——字体是什么、行距是多少、标题是几级、批注在哪个段落——和用户在屏幕上看到的完全一致。

基于这个前提，"格式审查"这个任务就变得自然了：AI 直接解析文档的样式树和段落属性，对照模板要求逐项比对，生成标注了具体问题和位置的审查报告。不需要转格式，不需要"先把文档变成别的样子再处理"。

输出端也一样。当你要求"按学校论文模板调整排版"，操作的是文档的真实样式系统——修改标题样式、调整段落间距、设置页边距和页眉页脚。输出的就是一份格式齐全的 DOCX，不需要二次加工。这条路径直接消灭了前面提到的"格式交付问题"。

WPS AI 目前在办公场景中提供了四个助手：写作助手生成内容，阅读助手解析文档，设计助手处理排版，数据助手分析表格。它们的共同特点是都运行在文档的原生环境中，处理的都是用户正在编辑的那份文档。阅读助手在 PDF 里做全文总结时，可以直接标注引用页数并跳转到原文；写作助手生成的内容直接写入文档，格式随写随有。全程没有格式转换的环节。

这其实就是上一章提到的那个"活在文档里"的路径的具体实现。不是靠更强的模型参数，而是靠路径选择从根本上消除了格式信息丢失的可能性。

38 年的积淀，藏在 AI 看不见的地方

不过，"在文档原生环境中工作"这句话说起来轻巧，做起来需要的东西远比想象中复杂。

文档格式不是简单的"字体加字号"。一份 DOCX 涉及的格式维度包括：上百种字体与字号组合、段落间距（段前、段后、行距、行距规则）、缩进方式（首行缩进、悬挂缩进、左缩进、右缩进）、标题样式的多级嵌套、目录域代码与标题样式的联动、页眉页脚与页面设置的关系、批注和修订的元数据、嵌入对象的容器结构——更不用说 PDF 和扫描件中涉及的版面识别问题。

要让 AI 准确理解这些维度，前提是你自己对文档格式有足够深的认知。这是一个"理解文档世界"的问题，不是靠喂更多训练数据就能解决的。每一种文档格式的细节、每一种排版规则的边界条件、不同版本 Office 之间的兼容差异——这些知识需要长时间的积累。

金山办公在文档处理领域深耕 38 年，对上万种文档格式有解构级的拆解能力。2025 年联合华中科技大学发布的自研文档解析模型 MonkeyOCR，就是这种积淀的产物。它采用 SRR（Structure-Recognition-Relation，结构-识别-关系）三元解析范式：先用目标检测模型识别文档的版面结构——标题、段落、表格、图片、公式各自在哪里——再对每个区域做细粒度识别，最后推断各区域之间的逻辑关系。这条路径既避免了传统 OCR 多模型串联的误差累积，又大幅降低了端到端大模型的算力负担。在 OmniDocBench 全球权威文档解析评测中，MonkeyOCR 以 93.01 分位列综合性能全球第一，领先于当时国外主流大模型。

这个结果说明了一个事实：在文档理解这个垂直领域，对文档格式的深度认知，其价值不亚于模型参数本身。格式理解能力不是一朝一夕能"训"出来的，它更像是一种隐性知识——你得在文档世界里摸爬滚打足够久，才能真正理解"格式"这两个字背后有多少层含义。

AI 文档处理的下一个拐点

回到最初那个问题。一位开发者发现 AI 做不了论文格式审查，排查后发现是因为格式信息在第一步就丢了。这个发现看似是个体踩坑，实则指向了整个行业的结构性问题。

过去两年，AI 在文档处理领域的能力提升集中在"语义理解"维度——能不能读懂、能不能总结、能不能改写。这确实是重要的进步。但格式层面的理解一直是一个被低估的维度，而这个维度恰恰决定了 AI 能否从"好玩的工具"变成"真正好用的助手"。

论文需要格式审查，公文需要版面规范，合同需要批注修订，财务报表需要结构校验。这些真实场景的共同特征是：格式和内容从来不是割裂的。一个不能理解格式的 AI，在这些场景中就只能做到"说了对"，做不到"做得到"。

问题的答案不在更大的模型参数，而在更正确的技术路径。当 AI 从"外部观察者"变成"文档内部的协作者"，从"读懂文字"进化到"理解文档"，那些曾经困扰用户的问题——格式丢失、交付错位、二次加工——才会从根源上得到解决。

这个拐点刚刚开始。但它的影响，会比任何一次大模型的参数升级都更直接。