从文件到数字资产：一次 AI 文件解析工程实践

在数字化转型浪潮中，许多传统企业仍面临一个尴尬的现状：大量核心业务数据以 Office 文件、PDF、扫描件等非结构化形式散落在各个角落。Excel 被当作数据库使用，邮件正文和聊天记录成为信息传递的载体，文件在业务人员之间反复流转、下载、转发、复制，却始终无法真正融入企业的数据体系。这些数据不仅利用效率低下，而且往往存在时效性，最终沦为「过期」的无用信息。

企业文件解析的核心困境

一个关键的问题是：文件究竟算不算数据？严格来说，文件只是信息的载体，还不能称之为真正的数据。真正的数据至少要满足三个条件：能够被查询、能够被关联复用、能够追溯来源。否则，它只是一个看起来完整的 JSON 文档，一旦出错却没人敢使用。许多团队在引入 AI 能力时，犯了一个典型的错误：试图直接让大模型读取文件并输出业务所需的 JSON 结构。这个思路看似直接，实则忽略了企业文件解析最核心的挑战——不是模型能否识别字段，而是系统敢不敢相信这些字段。

Excel 解析的技术演进路径

企业文件与机器可读数据之间存在一道天然的鸿沟。企业文件最初是为人设计的，人可以理解标题的含义、备注的意图、合并单元格的逻辑、上下文的关联，但机器看到的只是行列坐标、文本块和页码。这种差异导致同一个字段在不同文件中可能有着完全不同的表达方式：同一个表格今天从第 3 行开始，明天可能从第 7 行开始；同一个业务对象的信息可能被分散在多个 Sheet、多个段落甚至多个附件中。因此，在考虑如何引入大模型之前，更应该先思考几个关键问题：哪些内容可以稳定识别？哪些内容必须结合上下文？哪些字段即使识别出来也不能直接入库？哪些地方必须保留来源以便后续复查？

构建可靠的数据生产线

经过大量实践探索，Excel 文件解析技术经历了三个阶段的演进。第一阶段是直接用大模型解析，团队尝试将 Excel 或 CSV 转换为 Markdown 后交给大模型理解，输出符合业务 Schema 的结果。这个方案上手快，但面对大表时问题明显：等待时间长、输出过大、容易触发上下文限制，更关键的是字段错位时很难追溯具体是哪个单元格出了问题。第二阶段是让大模型参与 Layout 处理，尝试用模型做结构判断而非直接输出事实金额，同时引入 MarkItDown 等工具辅助转换。但这个方向存在根本缺陷：Markdown 转换可能丢失合并单元格语义，横向块和空表头列的坐标信息会变弱，模型读取后仍可能生成事实，且解析结果难以回到原始的行列位置。

工程化落地的关键保障

经过反复验证，当前最有效的方案是「后端规则 + 通用布局层 + LLM 校验器」的组合模式。这个方案的核心思路是：文件预处理只负责识别类型和读取字节，不做业务解释；高确定性规则优先执行，提供快速、可测试、可追溯的解析路径；当面对复杂 Excel 时，引入 LayoutPlan 布局中间层来描述 Sheet 范围、行列范围和数据结构映射；Executor 必须直接回读 Workbook 的原始单元格，而非依赖模型的理解结果；LLM 则退居校验位置，用于低置信解析结果的风险检测。这个组合的优势在于：标准文件可以通过规则快速处理，非标准文件可以通过扩展布局原语来兼容，关键金额数据来自原始单元格而非模型推断，LLM 有价值但不控制事实，每一步解析都可以通过 Trace 追溯原因。

如有侵权，请联系删除。