SpreadJS · AI 时代企业级电子表格开发基座

页面像 Excel，不等于系统级 Excel。真正的系统级 Excel 需要计算引擎、文档模型、文件兼容、打印分页、权限保护、历史兼容等能力共同支撑。

AI 编程工具普及之后，很多团队第一次生成电子表格页面时，都会经历一个兴奋时刻：页面有了，单元格能编辑了，公式能算了，样式也像那么回事。

于是一个判断很容易出现：Excel 好像也没那么难，剩下只是继续补功能。

这个判断非常危险。

因为 Excel 从来不是一个“表格界面”。它是计算系统、文档系统、数据建模系统和企业工作流入口。浏览器里复刻 Excel，难点并不是把 A1、B1、C1 画出来，而是复刻几十年电子表格软件演进中沉淀下来的计算语义、兼容行为、文档模型和用户习惯。

AI 可以帮你更快写出一个表格的样子，但它很难凭空生成一个成熟的 Excel 级电子表格引擎（Spreadsheet Engine）。

页面像 Excel，为什么会误导团队？

AI 生成一个 Web 表格并不难。它可以快速写出网格 UI、单元格编辑、排序筛选、冻结行列、基础公式、JSON 数据绑定，甚至导入导出的样例代码。

这些能力很适合 Demo，也很适合早期原型验证。问题在于，Demo 阶段看到的是“页面能力”，企业上线需要的是“系统能力”。

Demo 看到的能力	企业真正需要的能力
网格 UI	工作簿、工作表、单元格模型
简单编辑	数据验证、保护规则、撤销重做
简单公式	依赖图、增量重算、动态数组
样例导入导出	历史文件、样式、图表、打印兼容

第 01 篇我们讲过，AI 降低的是 Demo 门槛，不是企业级电子表格引擎的工程复杂度。第 02 篇要继续往下拆：Excel 的复杂度到底藏在哪里？

Excel 不是 Grid，而是业务运行环境

普通 Grid 关注的是结构化数据展示。它通常围绕行、列、字段、排序、筛选、分页、编辑和后端接口展开。它的模型接近数据库表。

Excel 的模型完全不同。Excel 单元格既可以是数据，也可以是公式；既可以是展示层，也可以是业务规则；既可以是输入控件，也可以是报表模板。

一个真实 Excel 文件里可能同时存在：

• 原始数据、业务参数、跨表引用、命名区域、财务模型、图表和仪表板、条件格式、数据验证、打印版式、保护规则、宏和外部数据、多人传阅形成的隐性流程

这就是为什么很多企业说“我们只是有一些 Excel 文件”，实际上是在说“我们的业务逻辑沉淀在 Excel 里”。

当企业希望把这些能力搬到 Web 端时，真正要迁移的不是格子，而是业务资产。

公式系统是第一个深坑

让 AI 写一个 SUM、AVERAGE 或 IF 的实现并不难。难的是构建一个完整的公式系统。

真实 Excel 文件里的公式会涉及大量复杂行为：

• 相对引用和绝对引用
• 跨工作表引用
• 命名区域
• 数组公式
• 动态数组和溢出区域
• 财务函数、统计函数、查找函数、文本函数
• 易失函数带来的重算问题
• 循环引用和迭代计算
• 自定义函数
• 错误值传播
• 公式审计和依赖追踪

根据 Microsoft 官方文档，Excel 的计算过程包含依赖树、计算链和单元格重算。依赖树用于判断哪些单元格依赖哪些单元格，计算链用于决定包含公式的单元格应按什么顺序计算。当工作簿结构变化时，Excel 会重建依赖树和计算链；当数据或公式变化时，Excel 会标记直接和间接依赖项需要重算。

这意味着，公式系统真正的核心不是“有多少函数”，而是能否正确维护依赖关系，并在变化发生时只重算需要重算的部分。

从 SUM 到动态数组，复杂度不是线性增加

简单公式很好理解：

=SUM(A1:A10)

但真实业务公式经常会跨 Sheet、引用命名区域：

=SUM(华东销售!B2:B100) + SUM(华南销售!B2:B100) - 退货金额

动态数组进一步改变了公式和单元格之间的关系：

=SORT(FILTER(A2:D100,D2:D100>10000),4,-1)

一个公式不再只返回一个单元格结果，而是可能返回一片区域。根据 Microsoft 关于动态数组的说明，返回多值的公式会把结果“溢出”到相邻单元格；如果溢出范围被已有数据阻塞，就会出现 #SPILL! 错误；溢出区域通常只有第一个单元格可以编辑。

再看一个间接引用：

=INDIRECT("'"&A1&"'!B2")

这类公式会让依赖关系变得更难静态分析，也会影响重算策略和性能。

Excel 兼容不是“支持几个函数”

很多人会把 Excel 兼容理解成“支持多少函数”。函数数量当然重要，但它只是兼容的一部分。

真正的兼容还包括：

• 文件结构兼容
• 数字格式兼容
• 日期系统兼容
• 错误值语义兼容
• 合并单元格行为兼容
• 条件格式兼容
• 表格和结构化引用兼容
• 数据透视表兼容
• 图表对象兼容
• 打印分页兼容
• 复制粘贴行为兼容
• 快捷键和编辑体验兼容很多兼容问题并不会在 Demo 阶段暴露。它们会在客户导入真实文件时出现：一张财务报表格式错位，一个日期被解释错，一个公式结果不同，一个打印分页偏移，都会让用户失去信任。

企业用户不会关心“技术上为什么不兼容”。他们只会说：这个文件在 Excel 里是对的，为什么到你的系统里就错了？

Excel 文件本身就是复杂文档

根据 Microsoft 官方规格，Excel 单个工作表最大为 1,048,576 行 x 16,384 列，单元格可包含 32,767 个字符，公式内容长度上限为 8,192 个字符，函数嵌套层级上限为 64，函数参数上限为 255，唯一单元格格式 / 样式上限为 65,490。

这些数字不是为了说明“Excel 很大”这么简单，而是说明 Excel 是一个庞大的文档系统。

一个工作簿里可能有多个工作表、隐藏表、冻结区域、筛选区域、表格对象、命名区域、图表、形状、图片、批注、条件格式、数据验证、保护规则、打印设置和主题样式。它们之间相互引用，也共同影响用户看到和操作的结果。

如果只是做内部小工具，很多对象可以暂时不支持。但一旦目标是“在浏览器中复原 Excel 功能”，这些对象就会陆续找上门。

从 LIMS 和金融行业的实际场景看，企业 Excel 资产通常不是孤立文件。在检测行业，一个报表模板可能同时承载检测数据录入、标准判定、复杂公式、数据修约、打印输出和结果回写；在金融行业，一个监管报送、薪酬管理、精算或投资分析表格，往往又牵涉模板还原、公式计算、权限控制、数据校验、图表展示和历史文件迁移。

这也是为什么“AI 生成一个像 Excel 的页面”并不等于“复刻 Excel”。真正进入业务系统后，电子表格（Spreadsheet）承担的是业务规则、计算模型、文档格式和合规流程的组合。

历史兼容也是工程壁垒

Excel 的复杂度还来自历史兼容。它不是一张白纸上的现代设计，而是几十年演进的结果。大量行为之所以存在，不是因为优雅，而是因为全球无数文件依赖这些行为。

比如日期序列、浮点计算、函数边界、文本数字转换、区域引用、旧版本数组公式和新版本动态数组之间的差异，都可能影响计算结果。一个企业级电子表格引擎（Spreadsheet Engine）必须理解这些历史行为，并在导入、计算、导出时尽可能保持一致。

AI 可以根据公开代码和文档生成一个“合理实现”，但企业客户需要的往往不是合理，而是兼容。兼容意味着：即便历史行为不完美，也要尊重用户已有资产。

本地化会继续放大复杂度

中国企业使用 Excel 时，还会遇到大量本地化问题。

日期、数字、货币、会计格式、百分比、千分位、中文表头、打印习惯、地区设置，都会影响真实业务使用。一个预算表、报价单、财务报表、供应链计划表，往往不仅要“算得对”，还要“显示得对、打印得对、导出后在 Excel 里仍然对”。

这也是为什么“页面像 Excel”远远不够。企业真正需要的是一个能够承接历史文件、业务模板和本地化习惯的系统。

SpreadJS 解决的是体系问题

我们做 SpreadJS 时，并不是从“画一个表格”开始定义问题，而是从企业级电子表格（Spreadsheet）的完整体系来定义问题。

根据 SpreadJS 中文官网口径，SpreadJS 是可嵌入系统的在线 Excel，是纯前端表格控件，功能布局与 Excel 高度类似；它支持 Excel、CSV、JSON 等文件导入导出、PDF 导出、打印及预览，并兼容 450 种以上 Excel 公式。

这些能力背后的价值不是“功能清单很长”，而是它们被放在同一个电子表格模型里共同工作。企业采购 SpreadJS，本质上是采购这套产品化的体系，而不是采购某一个按钮、某一个函数或某一个 UI 样式。

AI 的正确位置

AI 并不是没有价值。相反，AI 会成为电子表格开发的重要助手。

它可以帮助开发者：

• 生成 SpreadJS 初始化代码
• 编写业务数据绑定逻辑
• 根据需求生成公式
• 辅助分析 Excel 文件结构
• 生成报表模板
• 编写自定义函数
• 自动化测试常见交互

但 AI 更适合站在成熟引擎之上做加速，而不是替代引擎本身。让 AI 从零实现 Excel 级能力，相当于要求它在项目周期里重建一个几十年演进出来的复杂生态。这不是工程效率，而是工程幻觉。

SpreadJS AI 智能体的方向也应该放在这个逻辑下理解：AI 不是绕开电子表格引擎，而是通过可控工具操作和增强业务系统中的电子表格。

结语

“复刻 Excel”比 AI 想象中难 100 倍，不是因为画格子难，而是因为 Excel 早已不是格子。

它是企业业务逻辑的容器，是计算模型，是文档格式，是协作习惯，也是历史资产。AI 能生成一个像 Excel 的页面，但很难凭空生成一个真正兼容 Excel、能支撑复杂业务、能长期维护的电子表格引擎（Spreadsheet Engine）。

所以，当客户问“AI 能不能替代商业表格控件”时，真正要回答的是：你要的是一个 Demo，还是一个可以承载企业资产的系统？

如果答案是后者，成熟的电子表格引擎（Spreadsheet Engine）依然不可替代。

判断问题	如果只是页面	如果是系统
能不能编辑？	单元格输入	数据验证、保护、撤销重做
能不能计算？	简单函数	依赖图、增量重算、动态数组
能不能打开文件？	样例导入	历史文件、样式、图表、打印兼容
能不能上线？	Demo 可运行	长期维护、性能、兼容、技术支持

参考资料

• Microsoft Excel specifications and limits
• Microsoft Excel Recalculation
• Microsoft Excel performance: Improving calculation performance
• Microsoft Dynamic array formulas and spilled array behavior
• SpreadJS 中文官网
• SpreadJS AI 智能体