让AI真正会用表格：从“读文本”到“理解结构”的插件设计思路

一、问题的起点：把表当成文本，后面几乎必然出错

很多表格处理方案在第一步就做了一个看似无害的决定：把表格读成文本。这个选择一旦定下来，后续几类失败几乎就是注定的。

把单元格读成字符串，数字就丢了类型。1234.5 会变成 "1234.5"，再求和就得先猜它到底是不是数字。公式被读成字符串，就变成死文本——哪怕它开头是 =SUM，也只是几个字符，不会参与计算。样式被忽略，版式也没了：加粗、底色、边框、合并单元格，全在转换过程中蒸发。

这类错误还会往下游传。数字变成文本之后，求和得到 0，平均值报错，排序按字典序而不是按数值大小。一个看似无害的类型丢失，会在后续每一处计算里继续放大。这些错误单看都不致命，叠在一起就变成了返工，而返工的成本通常比第一次做还高。

更麻烦的是，错误常常要等到别人打开文件才会被发现，做表的人反而最后一个知道。

还有一种更容易被忽略的丢失：关系。一张工作簿里可能有跨表引用、命名区域、数据验证规则、条件格式。这些东西单独看都不是单元格的值，但决定了一张表能不能用。按文本方式处理，它们要么消失，要么变成一段没人认识的碎片。

二、为什么“转成 CSV 再处理”也补不上这个缺口

有人会问，转成 CSV 再处理行不行。CSV 是文本，任何工具都能读懂。但它只保留值。样式、公式、合并、多张工作表、数据验证，在转成 CSV 的那一刻全部丢弃。只想要一组数字时，这没问题；要交付一张报表时，这是把表格降级成了数据。

于是常见的场面是：AI 说已完成，打开文件，数字全变成文本；公式还在，却算不出来。表格本身没错，只是不像原来那张表了。

单看每一个问题，像几件不同的倒霉事。往根上看，是同一件事：都在用文本的方式处理一套结构。解析得再好，也补不上这个缺口——因为缺的不是解析精度，而是对“结构”的建模能力。

三、根因分析：文本模型缺失的三层语义

要设计一个真正“会用表格”的插件，首先要明确文本模型到底丢了什么。可以归纳为三层语义：

第一层：类型语义。 单元格的值不只是字符序列，还带有类型标签——数值、日期、布尔、错误值、文本。类型决定了它能否参与算术、如何排序、如何格式化显示。文本化把这层标签抹掉了。

第二层：计算语义。 公式不是字符串，而是一张依赖图。=SUM(A1:A10) 表达的是“对区域 A1:A10 求值”，并且当这些单元格变化时需要重算。文本化把依赖图压平成一串字符，计算能力随之消失。

第三层：结构语义。 工作簿是多表、有命名区域、有跨表引用、有验证规则和条件格式的复合体。文本化只保留扁平的二维值矩阵，表与表之间、规则与单元格之间的关系全部断裂。

三层语义对应三类失败：类型丢失导致计算错误，计算丢失导致公式失效，结构丢失导致交付物不可用。插件要做的，就是把这三层语义重新建起来。

四、插件设计：用结构化模型替代文本管道

4.1 单元格模型：值 + 类型 + 样式 + 公式

插件的核心数据结构不应是 string[][]，而应是带元信息的单元格对象。示意如下：

{
  "value": 1234.5,
  "type": "number",
  "display": "1,234.50",
  "formula": "=SUM(B2:B10)",
  "style": { "bold": true, "fill": "#FFF2CC", "border": "thin" }
}

关键点在于：value 保留原始类型，display 只用于展示，formula 与 value 分离存储。这样求和时直接用 value，展示时用 display，重算时用 formula，三者互不污染。

4.2 公式处理：解析依赖图而非保存字符串

公式应当被解析为表达式树，并从中提取引用区域，构建依赖关系。伪代码示意：

expr = parse_formula(cell.formula)      # 解析为 AST
refs = collect_references(expr)          # 提取 A1:B10、跨表引用等
graph.add_edges(cell.id, refs)           # 建立依赖边

有了依赖图，才能做到“改一个单元格，相关公式自动重算”，而不是把公式当死文本存着。对于插件而言，至少应保证：公式能被识别、能被求值、在被引用单元格变化时能被标记为待重算。

4.3 结构建模：工作簿、工作表、命名区域、规则

结构语义需要用显式的对象来承载：工作簿包含多张工作表，工作表包含单元格区域，命名区域是指向区域的别名，数据验证和条件格式是挂在区域上的规则。插件在读写时应保留这些对象，而不是把它们拍平成一张值表。

只有在结构完整的前提下，跨表引用才能解析，条件格式才能随单元格变化而重新判定，数据验证才能在写入时生效。

五、工程落地：读写链路上的四个检查点

把上述模型落到工程实现，可以在读写链路上设置四个检查点，避免退回文本管道：

1. 读取检查点：解析文件时，逐单元格保留类型与公式，禁止在入口处统一 toString()。
2. 计算检查点：任何涉及数值的操作，先校验类型标签，类型不符时显式报错或按规则转换，而不是静默地按字符串处理。
3. 写入检查点：写回文件时，按类型写值、按公式写表达式、按样式写格式，确保打开文件看到的就是原来那张表。
4. 校验检查点：交付前做一次结构自检——公式是否可求值、引用是否可解析、规则是否仍挂在正确区域上。

这四个检查点本质上是在防止“文本化”从入口悄悄渗透回来。很多方案失败不是因为解析器不够强，而是因为中间某一层又把结构化对象降级成了字符串。

六、效果对比：从“看起来完成”到“打开就能用”

维度	文本化方案	结构化插件方案
数值求和	文本拼接或得 0	按数值类型正确求和
公式	死字符串，不计算	解析依赖图，可重算
排序	按字典序	按数值/日期语义排序
样式与合并	丢失	保留
跨表引用/命名区域	断裂	可解析
交付结果	打开才发现问题	交付即可用

对比的核心不在“解析得更准”，而在“是否保留了结构”。文本化方案即使解析得再精细，只要中间层把类型、公式、关系丢掉，最终交付物就仍然不是原来那张表。

七、小结

把表格当文本，是把一套有类型、有计算、有关系的结构，压成一条扁平字符流。类型丢失让计算失真，公式字符串化让计算失效，结构拍平让交付物不可用。CSV 之类的中转只能保留值，补不上这三层缺口。

表格插件的价值，在于用结构化模型替代文本管道：单元格带类型与公式，公式带依赖图，工作簿带表间关系与规则。读的时候不丢，算的时候不错，写的时候还原。做到这三点，AI 才谈得上“真正会用表格”，而不是“把表读了一遍”。