背景：底稿的入口关是"读得进来"
审计工作流里，70% 的原始资料是 Excel：余额表、序时账、明细账、试算平衡。任何"AI审计平台"要发挥作用，第一步是把这些 xlsx 读进来、抽成结构化表。但 Excel 远比想象复杂——合并单元格、隐藏行列、自定义格式、公式、多 sheet、甚至损坏文件。本文对比三种解析路线的工程取舍，帮你在落地"智能审计工具"时少踩坑。
三种解析路线对比
| 维度 | openpyxl / pandas（开源） | 商业组件（如 Spire/商业库） | 云端渲染（上传后服务端转） |
|---|---|---|---|
| 读取公式 | 只能读缓存值，读不到实时计算 | 可重算公式 | 服务端重算后给结果 |
| 合并单元格 | 需自行展开 | 库已处理 | 渲染后天然展开 |
| 样式/图表 | 基本丢 | 部分保留 | 视觉完整 |
| 大模型友好 | 中（需自行规整） | 中 | 高（直接出图/HTML） |
| 成本 | 零 | 按席位/按量 | 按调用/订阅 |
| 数据出境风险 | 无（本地） | 无（本地） | 有（文件上云） |
| 大文件 | 慢、占内存 | 较稳 | 稳但受网络限制 |
开源路线：零成本但要自己擦屁股
openpyxl 读值、pandas 读表，几乎零门槛。问题是它"读的是文件结构不是人的意图"：合并单元格只给左上角值，其余空白；公式只给上次保存的缓存值（若文件从未在 Excel 打开过，公式值为 None）；自定义数字格式（如"0.00%"）读出来是原始小数。要做成能喂给模型的干净表，得写一堆规整逻辑：展开合并、填充上下文、识别表头行。适合数据规范、格式统一的内部导出。
商业组件：省心但要算账
Spire.Office 一类商业库能重算公式、较好处理样式，少写很多胶水代码。代价是授权费用（按机器或按量），以及仍跑在本地、对极端损坏文件未必救得回。适合把"解析"当核心能力的产品团队，用钱换开发时间。
云端渲染：更懂模型但有出境账
把 xlsx 传到服务端，用 Office 在线或自研渲染成 HTML/图片，再交给多模态模型读。优势是"所见即所得"——合并、公式、图表都按显示效果给，模型理解成本低。代价是数据出境：审计底稿含客户机密，上云前必须确认加密、权限与合规边界。这也是为什么不少"智能审计工具"同时提供本地解析与可选云端增强，把敏感字段留在本地。
工程建议
- 优先本地解析：用 openpyxl 打底，规整逻辑沉淀成工具函数。
- 公式别信缓存：关键报表用商业库或本地 LibreOffice 重算一遍。
- 上云先分级：只有脱敏后的非敏感底稿才走云端渲染。
- 输出统一 schema：无论哪条路线，最终都收敛成"字段名+类型+行"的结构化表，下游才好接。
以审小匠为例，其"财审 PDF 解析 / 余额表清洗"类能力，本质是把上述解析+规整做成面向审计场景的预处理流水线，让审计师上传后直接拿到可分析的结构化表。但它同样受源文件质量约束——扫描件、拍照件、合并乱飞的表，仍要靠人工先整理。
小结
解析不是炫技，是地基。开源能跑通但费人力，商业库省心但要付费，云端渲染更懂模型但有出境账。选型看三件事：数据敏感度、文件规范度、团队工程力。
