实测 Excel AI 辅助工作流：数据清洗、模型推理与载体形态深度横评

实测 Excel AI 辅助工作流：数据清洗、模型推理与载体形态深度横评 作者构建了覆盖数据清洗、公式编写和复杂交付等多场景的数据集，针对 OpenAI、Anthropic、Kimi、DeepSeek 等大模型在官方插件、开源多模型载体及独立工作台中的表现进行了横评，分析了模型决策机制与载体环境对交付成品质量的具体影响。 在未明确补全规则的模糊与冲突数据处理中，多数 AI 倾向于擅作主张匹配默认值甚至凭空捏造，仅 Claude Cowork 等少数产品能主动停下向用户确认。 透视表操作与复杂清洗中，AI 常因 pandas 自动类型推断将文本型数字洗白，导致 Python 计算与 Excel 原生计算脱节，22 个透视表输出中仅 27% 结果正确。 设置高强度推理容易引发模型过度思考与自我怀疑，长流程复杂任务人工干预率升至 51%，且易受载体 token 限制导致中断后重复计算。 在相同底层模型下，独立工作台运行更耗时且硬编码比例更高，而基于 Office.js API 的加载项更能调用现代动态函数，是目前处理 Excel 的更优选择。 测试框架与载体界定 测试界定了不同调用模型的方式（载体），包括官方 Office 加载项（基于 Office.js API）、支持 Python 代码片段的开源多模型载体 Pi for Excel，以及端到端直接交付文件的独立工作台（如 Codex、Claude Cowork）。评测在最新正式版环境下运行，评估维度包含硬编码情况、无损原则（是否擅改原表结构）以及实际交互轮次。 数据清洗陷阱与黑盒决策 在匹配员工信息等含重名或缺失数据的清洗任务中，绝大多数模型在未明示规则时倾向于擅作主张，如默认取第一个匹配项或硬凑名称。此外，由于模型常借助 pandas 读取转化为 CSV 后的数据，其自动推断机制将文本型数字静默转为数值，但回写至 Excel 后原生计算引擎依然将其视为文本排除计算，导致后续原生汇总与后台分析产生脱节。即使要求模型在歧义时停下提问，模型也难以做到完全零干预清洗。 透视表操作与过度思考瓶颈 在图书销售分析两项任务的 22 个产出文件中，虽然有 16 个成功创建数据透视表且 14 个引用区域正确，但仅有 6 个（27%）计算结果完全正确，排序等操作也屡屡受挫。同时，开启高强度深度思考后，短流程题目的人工干预率为 12%，而长流程复杂任务升至 51%。部分模型（如 Kimi K3）容易因细节纠结浪费大量词元陷入卡顿，加之载体单次推理思考长度限制，中断恢复后往往无法断点续传而是从头开始，整体耗时显著增加。 Office 加载项对比独立工作台 在底层模型相同的情况下，Codex、Claude Cowork 等独立工作台的执行耗时通常更长，且向单元格写入静态数据的硬编码比例更高。加载项依托 Office.js API 能够调用 XLOOKUP、FILTER 等现代化原生公式；而独立工作台由于后台多依赖开源 LibreOffice 解析与生成表格，加之无法在云端无授权运行完整 Excel，更倾向于退回使用传统老旧公式或通过 Python 处理后硬编码交付。

实测 Excel AI 辅助工作流：数据清洗、模型推理与载体形态深度横评 作者构建了覆盖数据清洗、公式编写和复杂交付等多场景的数据集，针对 OpenAI、Anthropic、Kimi、DeepSeek 等大模型在官方插件、开源多模型载体及独立工作台中的表现进行了横评，分析了模型决策机制与载体环境对交付成品质量的具体影响。 在未明确补全规则的模糊与冲突数据处理中，多数 AI 倾向于擅作主张匹配默认值甚至凭空捏造，仅 Claude Cowork 等少数产品能主动停下向用户确认。 透视表操作与复杂清洗中，AI 常因 pandas 自动类型推断将文本型数字洗白，导致 Python 计算与 Excel 原生计算脱节，22 个透视表输出中仅 27% 结果正确。 设置高强度推理容易引发模型过度思考与自我怀疑，长流程复杂任务人工干预率升至 51%，且易受载体 token 限制导致中断后重复计算。 在相同底层模型下，独立工作台运行更耗时且硬编码比例更高，而基于 Office.js API 的加载项更能调用现代动态函数，是目前处理 Excel 的更优选择。 测试框架与载体界定 测试界定了不同调用模型的方式（载体），包括官方 Office 加载项（基于 Office.js API）、支持 Python 代码片段的开源多模型载体 Pi for Excel，以及端到端直接交付文件的独立工作台（如 Codex、Claude Cowork）。评测在最新正式版环境下运行，评估维度包含硬编码情况、无损原则（是否擅改原表结构）以及实际交互轮次。 数据清洗陷阱与黑盒决策 在匹配员工信息等含重名或缺失数据的清洗任务中，绝大多数模型在未明示规则时倾向于擅作主张，如默认取第一个匹配项或硬凑名称。此外，由于模型常借助 pandas 读取转化为 CSV 后的数据，其自动推断机制将文本型数字静默转为数值，但回写至 Excel 后原生计算引擎依然将其视为文本排除计算，导致后续原生汇总与后台分析产生脱节。即使要求模型在歧义时停下提问，模型也难以做到完全零干预清洗。 透视表操作与过度思考瓶颈 在图书销售分析两项任务的 22 个产出文件中，虽然有 16 个成功创建数据透视表且 14 个引用区域正确，但仅有 6 个（27%）计算结果完全正确，排序等操作也屡屡受挫。同时，开启高强度深度思考后，短流程题目的人工干预率为 12%，而长流程复杂任务升至 51%。部分模型（如 Kimi K3）容易因细节纠结浪费大量词元陷入卡顿，加之载体单次推理思考长度限制，中断恢复后往往无法断点续传而是从头开始，整体耗时显著增加。 Office 加载项对比独立工作台 在底层模型相同的情况下，Codex、Claude Cowork 等独立工作台的执行耗时通常更长，且向单元格写入静态数据的硬编码比例更高。加载项依托 Office.js API 能够调用 XLOOKUP、FILTER 等现代化原生公式；而独立工作台由于后台多依赖开源 LibreOffice 解析与生成表格，加之无法在云端无授权运行完整 Excel，更倾向于退回使用传统老旧公式或通过 Python 处理后硬编码交付。

自从 Agentic AI 火起来，我就一直在期待一件事情：有一天我能用自然语言来操控我的电脑做事情，又或者可以用自然语言告诉一个程序它应该做什么¹。 两年多前，微软推出 Office Copilot Pro 时，铺天盖地的宣传语仿佛在向大家宣告 AI 已经无所不能。实际[测试](https://sspai.com/post/86677)下来我才发现，Copilot Pro 不仅经常误解我发送的自然语言指令，而且实际 Office 操作水平也令我不敢恭维。 过去两年里，大模型的能力突飞猛进，各类配套插件与工具也如雨后春笋般涌现。这不禁让我越发好奇：在今天的日常办公中，当我们用 AI 辅助处理 Excel 时，哪些东西会影响到交付成品的质量？ 但实测下来我发现，影响最终成品的因素远比想象中复杂。下面我就用具体的测试数据和盲评结果，聊聊当下 AI 辅助制作 Excel 的真实水平，以及我使用 AI 辅助制作 Excel 的心得。 **TL;DR** 本次测试用到的模型与各类载体主要对应关系如下表所示。 在此需要先界定一下「载体」（即所谓的 Harness）到底是什么？我觉得，载体可以简单理解为调用模型的方式。在 Excel 里，不同的载体会给模型配备不同的工具、接口、环境和规则。 比如，Pi for Excel 属于典型的多模型载体，Pi for Excel 可以安装自定义的技能和插件。我们也可以在 Pi for Excel 保持技能、插件不变的前提下，通过 OAuth 登录或 API Key 自由在模型之间切换，对比不同模型的效果。 又例如，Codex 是独立的工作台，OpenAI 的模型可以不再依托于 Office Add-in（加载项）操作 Office 文档。 对于原生支持推理能力的模型，我在测试中均统一开启 「High 或深度思考」。目前仅有 OpenAI 与 Anthropic 推出了官方 Excel 插件，因此这两家不仅会使用第一方的加载项，也会使用 Pi for Excel 加载它们的模型来测试。其余模型则统一通过开源插件 Pi for Excel（详见 [GitHub 页面](https://github.com/tmustier/pi-for-excel)）在 Excel 侧边栏中调用。 常规 Office 加载项主要基于 [Office.js API](https://learn.microsoft.com/en-us/office/dev/add-ins/develop/understand-the-javascript-api-for-office) 与表格交互；值得一提的是，Pi for Excel 额外支持执行 Python 代码片段来处理复杂数据，所以测试流程里我同样会开启这个功能。 与嵌入 Excel 内部的插件不同，独立工作台（如 Codex 等）采用「文件+提示词一同提交」的端到端交互形式，在独立应用内完成分析并生成最终文件。 我根据我之前的文章[《常用 Excel「奇技淫巧」，助你在新的一年处理数据事半功倍，「马到成功」》](https://sspai.com/prime/story/excel-tips)中所提到的大部分场景，编制了全新的测试用数据集，具体如下表所示。 所有的测试用例及题目所用到的提示词，可以在[我的 Notion 页面](https://kostyasheng.notion.site/excel-agent-analysis?source=copy_link)找到。如果你有自己偏好的模型和载体，也非常欢迎下载本文提供的测试用例和提示词自行测试，看在你的实际工作流中，不同模型和载体的组合能不能复现这篇文章的结果。 其中，在相同的环境下，用所有软件最新的正式版测试。每轮测试均在全新的独立 Excel 文件中执行，文件统一按「题号-三位随机编号」命名。 各题主要观测指标如下图所示： **硬编码情况**用于评估 AI 输出的是 Excel 原生动态公式，还是通过 Python 在后台计算完成后直接向单元格写入静态数据（也就是硬编码）。这里会影响表格后续的维护成本。 **无损原则**则考察 AI 在提示词未明确要求的前提下，是否擅自改动、覆盖或破坏了原始表格中的数据与版式结构。 在这次测试中，我们还会记录任务从发起到交付所需的**实际交互次数**，当然理想状态是一次就交付。如果执行中出现中断卡死、格式错漏需要人工纠错或催促，则需要额外的交互，我也会记录具体的原因。 最后我想通过数据，回答这三个问题： 我平时用 AI 帮我处理 Excel 表格的场景，不外乎用来：**数据清洗**、**高频重复公式编写**以及**成品交付**。针对这三类场景，我分别设计了难度递进的测试，并在实测中发现了一些非常有意思的现象。 在我的工作中，最耗费精力的就是数据清洗。因为不管是分类汇总、还是分析统计，都需要有可靠、统一的数据。那面对这些繁琐琐碎的脏活累活，AI 的实际表现又如何呢？ 大模型从原理来看很擅长处理这类任务，能识别「表述不同但含义相同」的模糊数据；且在正则表达式或 Python 的帮助下，也能批量地处理文本。但不同的 AI 实际表现也不同。例如，在「按姓名匹配员工信息」（测试 A09）这个题目中，姓名存在重名，同时还有两个姓名是找不到的，AI 处理的方式各不相同。 表现最好的是 Claude Cowork，它会主动停下来问我重名员工应该如何处理，并提供了几个选项：备注、只匹配第一个，或者是两个都写上。 ChatGPT for Excel、Claude for Excel、DeepSeek（Pi for Excel） 虽然都在对话里提到了重名，却已经擅自替我做了决定，使用了 XLOOKUP 默认匹配第一个值的情况；Kimi-K3（Pi for Excel） 更进一步，直接在单元格里加了注释。 而 Claude（Pi for Excel）和 Gemini（Pi for Excel）则没有提到重名的情况，直接 XLOOKUP 默认匹配第一个值。 最离谱的是 Workbuddy，对于两个找不到的名字，直接凭空硬凑了两个最像的名字填进去。 面对数据冲突、重复项或匹配缺失等异常情况，在提示词未明确指定清洗与补全规则的前提下，绝大多数产品都选择了「擅作主张」²，出乎了我的意料。 在我看来，任务场景越复杂，「主动向用户提问确认」 就越关键。测试里，AI 翻车也大多数是因为要求模糊，或者数据存在歧义。目前，解决这个问题最好的办法就是，告诉 AI：**有歧义要提问**。 后续，「图书销售数据分析任务」（测试 A11）复杂程度更高³，在数据清理的基础上，还要分析。我也在提示词中规定了有歧义要提问： 这是某小型连锁书店2025年销售订单记录。现在需要完成以下任务，需要保证可读性。如有任何模糊不清的地方，停下来问我： 1. 找出数据中任何不合理的地方并清理，包括但不限于重复订单、数据格式问题等。 2. 使用数据透视表分析不同销售渠道中客户类型的订单分布，列出每种图书的详细情况。 3. 形成数据看板，按季度汇总、加热力图色阶、并给出各种图书占其所在大区销售额的比例。同时画一个你认为能够体现数据全年变化的统计图。 不过，即使明确告诉 AI 要「停下来问我」，也并非所有 AI 都会严格执行这一指令。数据错误的类型一多，即使是火眼金睛的 AI 也很难一次就扫到全部的数据问题。 从最终实测结果来看，能够零干预、一次性彻底完成数据清洗的模型很少。不是没能统一同义词、异构字段，就是不能准确理解文本型数字。 我认为，不能准确理解文本型数字，很多时候因为习惯将其转化为 CSV 格式并直接通过 `pandas` 读取，pandas 的自动类型推断机制把文本型数字悄悄「洗白」了。 一旦 AI 后续尝试用 Excel 内置函数或数据透视表生成结果，Excel 引擎却依然会将这些原始单元格视为文本并排除在计算之外，最终导致 Python 算出的结果与 Excel 原生汇总对不上。 不难发现在清洗数据任务上，我们一定要小心 AI 擅作主张的黑盒决策。而且这些黑盒决策，也容易让我们找不到真正的问题。所以，我们一定要在编写提示词时，更加周密严谨。 测试用例中，「图书销售透视汇总」（测试 A10）和「图书销售数据分析交付」（测试 A11）两个任务在提示词中明确需要创建「数据透视表」，并对透视表字段操作。要做数据透视表的前提就是数据足够规整。 所以，这个测试除了能检测 AI 能不能清洗数据，也能测试 AI 分析数据和操作数据透视表的能力。 最终结果如下，在这两个任务的 22 个输出文件中，16 个（73%）都创建了数据透视表，且 14 个引用了正确的数据源区域，但只有 **6 个（27%）**的计算结果是正确的。 另外，对数据透视表的排序也是难倒一大片 AI。Kimi K3（Pi for Excel）为了给数据透视表排序，硬生生思考到了载体最大限制好几次。最终没有在数据透视表中实现「按照销售额从高到低排序」。 深度思考能显著提升推理能力、减少幻觉。因此在测试中，我给予了模型充分的思考空间，统一将思考强度设定为「高」档。但思考深度并非越高越好，当思考链路过深、耗时过长时，我发现模型更容易陷入自我怀疑与反复推演的过程里。 如上图所示，随着任务难度层级的攀升，模型的运行耗时明显变长。特别是，在长流程复杂任务（A08、A10、A11 及 Q11）的 45 次实测中，需要人工介入干预的比例高达 51%；而相比之下，A01 到 A07 等短流程基础题目的人工干预率仅有 12%。 我也简单分析了下模型为什么运行时间会变长。最主要的就是模型会**因为小问题过度思考**。比如：Kimi K3（搭载 Pi for Excel）在执行 A10（图书销售透视汇总）任务时，反复纠结于如何使用 Office.js API，在超过 25 分钟后选择放弃使用数据透视表对数据排序。类似的，在人工提示分类计算有误后，DeepSeek v4 Flash 在思考 10 分钟后，才意识到「数据类型不匹配」。 其次，模型卡住了。比如：Claude Cowork 在执行「考核成绩信息表及分析交付」（测试 A08）任务时，因为之前的 LibreOffice 文件残留，卡住了 10 分钟。Workbuddy（使用 Hy3 模型）执行 A10 任务时跑了 40 分钟还没有解决问题，且没有任何后续输出。 最后则是载体本身的限制。Pi for Excel 对单次推理设置了 4096 个词元的思考长度上限，所以一旦模型单次思考过长，就会被 Pi for Excel 截断，只能依靠我的提示继续。 我还发现各个模型喜欢在思考里浪费词元。比如：不少模型会把数据完完整整地在思考过程中抄写一遍；又比如： Kimi K3 在「图书销售数据分析交付」（测试 A11）时，为了「支付方式缺失值究竟该填『未知』还是『未知支付方式』」这种无关痛痒的细节反复纠结，思考日志中甚至直接蹦出了 I keep flip-flopping. 和 Ugh.等极度纠结的心声，前后来回拉扯了六七次。 当我让 Kimi K3 继续的时候，它并不会接着断点往下做，反而从头开始。所以，Kimi K3 没有完成这个任务。 这里最后的表现也和之前的一样，Kimi 与 GLM-5.2 的平均任务耗时显著长于 GPT、Claude 及 Gemini，也需要更多轮才能达到结果。 所以，光有更强的思考并不能让模型交出更好的结果，还要看模型是不是能配合好载体。 接着我们来看看，在模型一致的前提下，使用「Office 加载项」和「独立工作台」这两个不同的载体，做出来的成品之间的区别。在这组讨论里，我们还会对比这两个不同载体在执行耗时、交互路径上的不同，以及各自的优缺点。 测试中，底层模型相同的情况下，我发现独立工作台，即 Claude Cowork 和 Codex，一般所用的时间更长（如下图 1 所示，点为实测数据，曲线为指数型趋势线）。 同时，在使用同一底层模型的情况下，独立工作台的硬编码比例也更高（如上图 2 所示，数字为硬编码的比例）。 由于加载项本身基于微软官方的 Office.js API 构建，自然能够比独立工作台更了解当前版本的 Excel 能做哪些事。 即便是相同的模型，使用加载项做出来的 Excel 表格就明显比独立工作台做出来的更现代一点。比如，都是 Claude 模型，Claude for Excel 加载项会根据当前使用的 Excel 版本，更多地使用 XLOOKUP、FILTER、SORT 等比较现代的公式；在 Cowork 里，它倾向于退守到古早的 VLOOKUP 乃至 INDEX + MATCH 等传统方法检索，也出现了提取复杂数据时，会直接硬编码写入静态数据的情况。 我认为这和 Claude Cowork 在后台依赖开源的 LibreOffice 来解析与生成 .xlsx 文件有关，LibreOffice 又因为这些年支持 Excel 新版高级函数的速度比较慢，就不得不用更老的公式来达到相同的目的。 所以载体、软件版本和 AI 模型的能力，都会影响 AI 在 Excel 里的表现。且目前来看，**Office 加载项就是用 AI 处理 Excel 最好的选择。** **独立的 AI 工作台更喜欢用 Python 等编程方式寻求问题的答案。**这背后的原因也很好理解，因为 Office 加载项需要经过微软审核才能上架，而且也没有商业授权不能在云端挂载一个 Excel 处理文档。