AI+Excel的真实难点：为什么说Claude方向对了，但挑战才刚刚开始

北京时间 10 月 28 日，Anthropic 张贴了 claude-for-excel 和 advancing-claude-for-financial-services 两篇文章，彰显了它将 Claude 引向金融领域办公软件的野心。

本文正文包括三个部分：

1. 猜测 anthropic 的实现路径

2. 基于我同 excel 打交道的经验，指出大模型赋能电子表格的实际困难

3. 针对 2 的困难，探讨潜在解决方案

读者可以根据兴趣跳转到特定板块阅读。

第一部分稍偏技术，但也十分容易理解。读者甚至可以拿手头的表格试一试。

1 XML 解析——从底层代码解构 xlsx，或许是目前表格类 AI 的最有效做法

Anthropic 在 claude-for-excel 这篇文章中，提出了四类功能：

Get answers about any cell in seconds

即时浏览复杂模型，解释公式、工作表、跨表流程

Test scenarios without breaking formulas

更新模型假设，并高亮结果（即，what-if/压力测试/情景分析的自动化）

Debug and fix errors

解析#REF! #VALUE! N/A 等错误

Build models or fill existing templates

创建财务模型，或基于模板填数（此类工作在金融机构中后台非常常见）

——工作表导航、解释公式、更新假设、调试错误、填充模板、单元格写入、分析模型。这些，都可以通过 XML 解析实现：

每一个 .xlsx 都可以通过修改后缀为 .zip 得到一个压缩包，其中有一个核心的“蓝图”文件，叫做 xl/workbook.xml。
这个文件内有一个叫 的标签，它列出了所有的工作表（Sheet），像这样：

在每个工作表文件（如 xl/worksheets/sheet1.xml）中，一个包含公式的单元格（比如 C1）是这样存储的：

SUM(A1:B1) 150

因此，通过 workbook.xml 文件，就能瞬间拿到一个包含所有 Sheet 页名称、ID 和顺序的完整列表，从而可以通过代码实现“工作表导航”或“跨 Sheet 页引用”。

在 sheet1.xml 内能找到坐标为 C1 的单元格。 标签里的纯文本是公式“SUM(A1:B1)”，标签里的纯文本是值“150”。
提取上述公式或值，就可以把这个字符串喂给大模型，并附上一个提示，如：“请用大白话解释这个 Excel 公式：SUM(A1:B1)” 或者 “请检查这个公式有什么错误：...”。这就能实现“解释公式”和“调试错误”。本质上和复制公式到 chatbot 的聊天框没有太大差别。

当用户说：“请把我的‘假设’（A1 单元格）从 10 改成 20”，或者“请帮我填充这个模板（把 A1, B1, C1 填上数据）”，程序执行的是一个非常简单的“查找与替换”操作：
修改 .xlsx 后缀为 .zip，然后解压，打开 sheet1.xml。
找到 这个单元格。
把它里面的 10 修改为 20。
保存 sheet1.xml 文件。
把整个文件夹重新压缩回 .xlsx 文件，还给用户。
这就能实现“更新假设”“填充模板”“输入单元格”。

通过“遍历”整个工作簿里所有的 sheetN.xml 文件，读取所有的单元格。
它能读到：

• A1 是一个值（Value）
• A2 是一个值（Value）
• B1 是一个公式（Formula），内容是 A1+A2
  基于此可构建一个“依赖关系图”：[B1] -> 依赖 -> [A1, A2]。然后，可以把这个“关系图”用文本的方式喂给 LLM：“我分析了这个表格，我发现 B1 是 A1 和 A2 的总和。A1 和 A2 是输入值。”这就是最基础的“模型分析”。

与此同时，在文章的 FAQ 中，Anthropic 还提出这个项目暂不支持 VBA：因为 vba 代码通常存储在 vbaProject.bin 二进制文件里，这需要额外的工具来解析。（这样看来，这个工具上架也挺仓促的，因为解析 vba 的工具并不麻烦。claude for excel 大概率是 Anthropic 对 OpenAI 招募兼职投行家的回应...）

Anthropic 支持的所有功能，都是对 .xlsx 压缩包内的 XML 文件进行纯文本的“读、写、改” 操作，以及将读到的文本（如公式）交给 LLM 去“理解”。
他们不支持的所有功能（VBA、复杂的数据透视表、条件格式），要么是非 XML（如 VBA），要么是极其复杂的 XML（如图表、透视表），解析起来吃力不讨好。

至此可以确定，Claude for Excel (Beta 版) 的核心，就是一个“OOXML 解析器 + LLM 接口”。

PS: 在 office2007 以后，微软将 office 套件的保存格式按照 ooxml 标准重新设计。这也是.doc .xls .ppt 与.docx .xlsx .pptx 有所区别的原因。以后者格式保存的文件，本质上是一堆 xml 文件的压缩包。因此，你可以将任意一个.xlsx 文件的后缀修改成.zip，然后用解压工具看见内部结构。（我曾用这种方式拆过 wind excel 插件的密码，看来确实没有无用的经历。）

更方便的方式，是调用 Python 的 openpyxl 库直接解析表格。openpyxl 是基于 xml 封装的一层解析工具，通过它，可以用 json 格式输出表格信息，为大模型解析提供结构化输入。

这个思路是社群大佬 l 提供的，在此向大佬表示真挚的感谢。

电子表格之于金融民工，类比于枪支之于士兵。

从香港到北京，从券商到银行，从前台到中后台……

数以千万计的金融从业者，都离不开 excel 或 wps 或 google sheet。

可以说，这个市场质量很高，用户付费能力和付费意愿都很强，office 365 copilot 和 OpenAI 先后入局，都说明 anthropic 方向对了。

但这里的坑，同样是难以想象的多和深。

2 四大困境——本质都是上下文问题

演示很惊艳，实战就拉跨。用大模型处理电子表格，往往逃不掉报表结构太复杂、人类习惯太糟糕、数据与脚本割裂、无声的默会知识四大问题。

问题一：报表结构太复杂

金融建模的复杂，不仅仅在于单个公式的层层嵌套，更在于单元格如同“地下蛛网”般的复杂跨簿、跨表引用。（或者说，两者是达成一个目标的不同途径，只不过后者更常见，也更有用。）我拿手头几年前泸州老窖的预测模型数了下，光资产负债表的预测工作表的公式，就有 3,489 个，引用关系数量会是公式数量的数倍。在这些引用中，有“交叉引用”（如财报间的勾稽关系）。有“链式引用”（A 引用 B，B 引用 C…）。除此之外，还要考虑单元格所在行列表头的索引关系，名称管理器与区域（Range）的映射关系……对上述每一种关系的刻画，都是对模型上下文容量和模型智力的挑战。

问题二：人类习惯太糟糕

规范、整洁的报表是少数，绝大多数表格都充满了“坏习惯”。比如：多个含义不同的表格，割据在同一张报表的不同位置，且毫无规律或可言；表头的缺失导致单元格含义不明；大量孤立区域被充当“临时辅助计算器”。

问题三：数据与脚本割裂
部分表格的单元格数值，不是来自公式，而是来自 VBA 脚本。AI 在“阅读”表格（静态）时，很难预知这段代码（动态）会做什么。它的理解，在表格公式和 VBA 代码这两个割裂的世界里是断层的。如果表格和代码只是被简单前后拼接，就输入给大模型，那么过长的距离会使模型的理解效果大打折扣。

问题四：默会知识
Excel 面向人类设计，UI 是主要交互方式。合并单元格、高亮、筛选……这些功能为了方便人类使用，在设计时提供了一些不利于机器识别的视觉信息。这些默会知识如果不作特别说明，会在不同区域、不同行业、不同部门的报表间造成混淆。比如，黑色字色单元格所载的是源数据，蓝色字色单元格代表假设数据（超参），绿色高亮单元格代表由公式自动算出的结果，这对于境内投行部底稿来说是约定俗成的；但在券商的其他部门或其他细分行业，这是无稽之谈。

综合看来，上述问题都指向一个本质：无法向大模型提供完整的上下文。这里的完整，既包括在模型注意力窗口长度限制内提供主要信息，也包括表格本身和 vba 等代码在约束下的巧妙结合，更包括向模型提供表格之外人们约定俗成的默会知识，还包括描述图形界面中的视觉信息。

所以我认为，当我们能够用大模型实现金融建模时，离高质量的 computer use，离可靠的 AI OS，也就不远了。

（我非算法科班出身，描述如有错误请批评指正）

3 抛砖引玉——数据的归 DB，逻辑的归代码

任何报表，都可以被视为一个采用 MCV (MVC) 架构搭凑的小程序。它一定有数据源——要么来自粘贴，要么来自导入，要么来自引用，要么来自蒙特卡洛模拟。它也一定有计算过程——可能是 vba 脚本，也可能是公式。它或许有展示，这个展示可以是经调整格式的表格本身，也可以是插入的图，或经加工的透视表。

因此，任何报表可以还原为数据-算法-展示的形式。忽略展示，因为它相对独立，是 BI 该做的事。

那么，报表=数据+算法。

互联网貌似也等于数据+算法
理论上，excel 能干的，Python 也能干。那为何不将报表抽离成数据和算法，让数据归数据库，让逻辑归代码？

公众号：刺猬的记事本

用大模型赋能电子表格，这件事我想了快两年。到目前为止，结合诸位大佬的观点，我真的觉得，与其让大模型适应我们，不如我们主动做些改变。

Anthropic和OpenAI目前在做的，是试图让AI扮演一个更聪明的助手，帮助人类在债台高筑的“四大困境”中艰难穿行。

我认为这只是一个过渡态。与其让LLM“将就”人类的坏习惯，不如利用LLM强大的代码生成和理解能力，执行一次“代码重构”。

LLM在Excel领域的终极价值，不是充当一个“并行的Copilot”去适应混乱的表格，而是作为一个“一次性的重构工具”（AI-Assisted Refactor），帮助人类彻底还清“报表债”。
这个工具的理想任务流应该是：

输入： 接收这个混乱的 .xlsx 文件。
理解： 直面Part 2的“四大困境”，去拆解“蛛网结构”、解析VBA逻辑、甚至通过RAG（检索增强生成）读取“行业规范”来理解各种默会知识。
输出：“把混乱的Excel表格，重构为一个清晰的Python脚本（逻辑）和数据库文件（数据）。”
将电子表格转化为脚本，或许是更有效、更经济、更面向未来的解决方案。