用 claude code 将 Excel 数据转换成 Python 处理脚本

去年双十一，我帮朋友处理一份电商后台导出的Excel订单表。整整 87 个 Sheet，每个 Sheet 的列名都不统一，“买家姓名”有的叫“收件人”、有的叫“收货人姓名”、有的干脆是“name”，日期格式更是千奇百怪。朋友说他们财务为了做对账，三个人手工整理了一周，最后还弄错了好几十条记录。我花了大概 20 分钟，在 Claude Code 里用几句话描述了数据结构和我想要的结果，它帮我生成了一段 Python 脚本，点一下运行，所有 Sheet 合并、字段统一、非法日期剔除，一次性完成。那三个人一周的工作量，被一段 120 行的脚本替代了。

更重要的是，我一行代码都没写。 我只是像一个经理给程序员派活儿一样，把需求说清楚了。

这就是我接下来想和你聊透的东西：用 Claude Code 把 Excel 数据需求变成可执行的 Python 处理脚本，到底是怎么做到的，什么时候该用，什么时候不该用，以及怎样才能一次就让 AI 给你产出真正能用的代码。 市面上已经有大量“AI 帮你写代码”的泛泛之谈，但今天我想给的，是全流程踩过坑之后沉淀下来的操作框架、失败案例和验证方法，而且是针对“Excel 数据处理”这个最普遍的职场场景。

一、核心结论：这不仅仅是一个写代码的工具，而是一种自动化思维的交付方式

先把这个核心判断放在最前面：Claude Code 把 Excel 数据转成 Python 处理脚本，本质上不是让你学 Python，而是让 Python 来适应你的思维方式。 你不需要理解“openpyxl 和 pandas 有什么区别”，不需要背下“df.groupby().agg()”的语法，你只需要对着它描述你手上这张表长什么样，你想怎么处理它，它就能把自然语言翻译成可运行的脚本。

但这里有一个容易被忽视的关键，这个翻译过程的质量，75% 取决于你如何向 AI 描述你的数据结构和需求，而不是 AI 本身的能力。 我在过去半年里，带着不同编程水平的用户做了上百次尝试，从完全零基础的财务小姐姐，到会写点 Python 但不想自己动手的数据分析师，发现最终产出的脚本能不能用、需不需要大改，差异巨大。那些能清晰描述自己表格的人，哪怕一行代码都不会写，拿到的脚本几乎可以零修改直接跑起来；而那些直奔“帮我处理一下这张表”的人，大概率会得到一个看起来很像、但一跑就报错的半成品。

所以今天这篇文章，我会用我亲身经历的三个真实 Excel 处理任务（小到一个 Sheet 的清洗，大到上百个文件的批量处理）作为主线，穿插着告诉你：什么时候 AI 能替你把活儿干了、什么时候你得亲自下场；怎么描述需求能让 AI 一次就懂；以及拿到脚本之后，你该怎么判断它是不是真的好用。

二、当 Excel 成为效率黑洞：三个真实场景和一套自动化解决方案

在我接触的实际职场中，Excel 数据处理的需求几乎覆盖了所有非技术岗位：

1. 销售运营：每周从 CRM 导出上千条销售记录，需要按地区、产品线拆分 Sheet，删除重复客户 ID，计算周同比。
2. 财务会计：每月银行流水和内部 ERP 对账，两个文件上万条记录，十多个 Sheet，需要按金额和摘要模糊匹配，找出差异。
3. 物流仓储：发货单号和收货单号格式不一致，有空格、有特殊字符，需要做标准化清洗再导入 WMS 系统。
4. 人力资源：绩效考核表分发后收回，需要合并所有文件里的“评分 Sheet”，自动计算总分并生成排名。

这些任务共同的特征是：规则明确但繁复，逻辑不复杂但数据量不小，人工做极容易出错，周期还特别长。 比如我曾经帮一个电商团队做的物流数据清洗，他们每天有 5000-8000 条运单记录，需要做三件事：删除所有运单号前后的空格和换行符，把“SF1234567890”这种格式统一改成“SF12 3456 7890”以便扫码枪识别，再把超过 48 小时未更新的订单标红。这个活儿，他们安排了一个全职实习生，每天上班第一件事就是打开 Excel 手动处理，处理完差不多一上午过去了，周末的数据还得周一补，经常积压。

而我用 Claude Code 生成的 Python 脚本，先把他们三天的数据样本扔进去，让 AI 看清楚运单号这一列到底都有哪些不规则格式，然后描述需求：“把这一列的所有空格和特殊符号去掉，然后每四位加一个空格，注意 SF 开头的字母保留在前端，不参与分割”。第一次生成的脚本可以跑，但 SF 字母段也被分割了。我继续追加一句：“SF 字母段不参与分割，只把后面的数字每四位加空格”，第二次就完美了。脚本从写完到现在跑了快一年，每天自动运行，实习生被解放出来去做数据分析了。

这个案例里有一个重要观察：AI 生成的脚本在第一版往往不能完全满足需求，但迭代修正的成本极低，你只需要补一句自然语言描述，而不需要去翻文档、查 API。 相比之下，很多人一听到“让 AI 写代码”，脑子里立刻浮现的是“一次性生成完美脚本”，然后一跑发现不对，就放弃了。这是典型的期待错位。Claude Code 处理 Excel 的真正优势不在于“零错误一次过”，而在于“即时反馈、即时修正”的交互循环。

三、三步踩进同一个坑：对“AI 处理 Excel”最常见的三个误解

我先把我看到最多人犯的错、以及我自己早期踩过的坑摊开来讲清楚，因为这比直接教你怎么做更重要。

误解一：“把文件拖进去就行了，它自己会看懂”

2024 年上半年，一个做房产数据分析的朋友找到我，说他用 Claude Code 处理一个 Excel 文件，里面有三个 Sheet，分别是“2023年成交”“2024年成交”“2025年成交”，他想把三张表合并成一张，按成交日期排序。他说：“我就把文件路径给 AI，说合并这三张表，它给我生成了一段代码，但跑出来全是空的。”我问他：“你告诉它每一列叫什么名字了吗？”他说：“没有啊，它打开文件不就能自己看吗？”

问题就出在这里。Claude Code 不能直接打开你的 Excel 文件去“看”里面的内容。 它是一个语言模型，你需要把数据结构描述给它，或者把一部分数据内容以文本形式粘贴给它，它才能理解你的表格长相。很多人误以为它能像人一样直接操作文件，上来就说“把这个 Excel 的第一列和第二列相加，放到第三列”，但 AI 根本不知道你的第一列是数字还是文字，不知道有没有表头，不知道有没有空行。

我后来给他改了一下描述方式：“这个 Excel 有三个 Sheet，名字分别叫 Sheet1、Sheet2、Sheet3。每个 Sheet 的第一行是表头，列名包括：成交日期、区域、小区名称、面积、单价、总价。请写一个 Python 脚本，读取这三个 Sheet，合并成一个 DataFrame，按成交日期排序，并输出到新的 Excel 文件。”几乎一字未改，拿到的脚本直接就跑通了。

核心教训：你给的信息粒度，决定了 AI 输出的可用性。 宁可多花三分钟把表结构描述清楚，包括列名、数据类型、有没有空值、有没有合并单元格，也不要贪快丢一句模糊需求。

误解二：“脚本生成了就等于事情做完了，不需要验证”

这个坑我踩得更疼。有一次我用 Claude Code 生成一个财务对账脚本，需求是把银行流水表和 ERP 应收表按照“金额 + 日期（前后一天）”进行模糊匹配。AI 很快给出了一个使用 pandas 的 merge 加模糊匹配逻辑的脚本，我看了一眼代码，逻辑上很合理，就直接拿去跑了。跑出来的“匹配成功”比例大概 78%，我觉得差不多，就拿去给财务交差了。

结果第二天财务告诉我，有 22% 的未匹配记录里，有至少 30 多条是因为脚本把同一笔交易匹配给了两个不同的 ERP 记录，一个典型的重复匹配问题。问题出在模糊匹配的逻辑上：AI 用了简单的日期差绝对值小于等于 1，再加上金额相等，但没有考虑到 ERP 里可能存在同一金额、相邻日期的不同交易。这个脚本没有做“去重”和“一对一匹配”的约束。

事后我复盘，拿到脚本之后只做了“可以跑通”的验证，但没有做“结果正确性”的边界验证。 你需要至少拿一小部分你已经手工核对过的数据作为“真值集”，让脚本跑一遍，看看结果和你的手工结果是否完全一致。如果没有手工真值集，就让 AI 同时生成一个“验证报告”，列出所有匹配上的、未匹配的以及匹配了多条的情况，你自己肉眼过一遍。验证不是可选项，而是必选项。

误解三：“反正 AI 会写代码，我不用知道任何 Python”

我见过最离谱的一个案例，是一个朋友拿 Claude Code 生成的脚本，在命令行运行时报错“ModuleNotFoundError: No module named 'openpyxl'”，他截图问我是不是 AI 写的代码有问题。我说这是你没装这个库，不是代码的问题。他又问：怎么装？我说“pip install openpyxl”，他说：pip 是什么？在哪里输入？

这就回到了一个基础现实：AI 帮你写了代码，但你至少需要具备把代码跑起来的基本环境。 这包括安装 Python 解释器、安装必要的外部库、知道在哪个终端里运行脚本。好在这几个步骤的门槛极低，大概 15 分钟就能搞定。Claude Code 本身也可以指导你完成这一步，你直接问它“我拿到了你写的脚本，现在怎么在我的电脑上运行它？”它就能给出 windows、mac 各自的安装指引，甚至可以直接把命令给你准备好。

但这 15 分钟的环境搭建，不能省。 很多人以为用了 AI 就完全不用接触编程的东西，这就像你想开车但完全不想知道车要加油一样。不需要深入，但需要在“使用者”层面知道自己手里这件工具依赖什么。

四、构建 AI 可理解的“表格心智模型”：四步让需求一次被读懂

经过几十次从失败到成功的反复试探，我总结出了一套针对 Excel 场景的需求描述框架，我称之为“4W 描述法”，What、Where、Who、Which。这个框架可以让没有任何编程基础的人，用五分钟描述出让 Claude Code 一次性生成可运行脚本的需求。

第一步：What，你的表格长什么样？（结构画像）

这是成败的关键。你需要告诉 AI：

• 整个 Excel 文件有几个 Sheet，每个 Sheet 的名字是什么；
• 哪些 Sheet 是你需要处理的，哪些是无关的；
• 每个 Sheet 里，数据从第几行第几列开始，表头在第几行；
• 每一列的列名，以及这一列存储的数据类型（文本、数字、日期、金额）；
• 是否有合并单元格、空行、隐藏行列；
• 数据的大致行数范围。

下面是我处理一个电商运营周报时的真实描述，你可以感受一下这个颗粒度：

> “我有一个 Excel 文件叫‘周报_06月.xlsx’。里面有4个Sheet：'总览'、'流量明细'、'转化明细'、'客服数据'。我只处理'流量明细'和'转化明细'这两个Sheet。

>

> '流量明细'的结构：第一行是表头，列名包括：日期、渠道来源、访客数、浏览量、跳失率（%）、平均停留时长（秒）、新访客占比。数据从第2行开始，总共大约 2000 行。跳失率这一列是百分比格式，但实际存储可能是小数或文本，不确定。日期列的格式是“2024/6/1”。

>

> '转化明细'的结构类似：列名是日期、商品ID、商品名称、访客数、下单笔数、付款笔数、转化率（%）。日期列格式相同。数据约 2500 行。”

这样描述完之后，AI 基本能准确生成读取这两张表的代码，它能自动判断日期列需要解析、百分比列可能需要清洗。我曾经试过只给列名不给格式，AI 生成代码时把跳失率当成普通字符串，后续计算直接报错。所以格式和可能的脏数据情况一定要提前告诉它。

第二步：Where，你希望产出什么？（输出画像）

这步很多人会忽略，直接说“处理一下”，但 AI 不知道怎么算“处理完”。你要明确输出的形式：

• 输出是一个新的 Excel 文件，覆盖原文件，还是输出到终端显示；
• 新的 Excel 放哪些 Sheet，Sheet 名称是什么；
• 新增的列叫什么，放在哪一列后面；
• 是否需要保留原格式（比如冻结窗格、筛选器），还是只关心数据本身。

在刚才的案例里，我的 Where 描述是：

> “输出一个新的 Excel 文件，叫‘周报_处理结果.xlsx’。里面有三个Sheet：第一个叫‘合并流量转化’，是把'流量明细'和'转化明细'按照日期和商品ID匹配后合并在一起，所有字段都要保留；第二个叫‘各渠道汇总’，是按渠道来源汇总访客数、下单笔数、付款笔数，并计算出各渠道的转化率（付款笔数/访客数）；第三个叫‘每日趋势’，是每天的访客数、付款笔数、转化率，按日期排序。”

这种“把结果表格的名字和列名都提前想好”的方式，不仅让 AI 有清晰的输出目标，也反过来倒逼你自己把需求想透。很多人在开口之前，自己都没想清楚到底要一个什么样的结果表。

第三步：Who，你有哪些特殊的业务规则？（逻辑约束）

这是脚本准确率的真正分水岭。Excel 处理中最坑的不是读数据，而是业务逻辑的细节。你要把那些你在手工处理时心里默念的规则，全部显性化地告诉 AI。

常见的业务规则包括：

• 两个表的匹配键是什么，允不允许一对多；
• 日期比较时允许多大误差（精确到天还是前后一天）；
• 金额匹配是否区分大小写、是否忽略货币符号；
• 遇到空值怎么处理，跳过、填充0还是报错提醒；
• 文本匹配是精确匹配还是模糊匹配，模糊到什么程度。

继续上面的案例：

> “合并'流量明细'和'转化明细'时，用‘日期’和‘商品ID’两个字段作为匹配键，两个表的日期格式可能不完全一致，但内容对就行，比如‘2024/6/1’和‘2024-06-01’应该视为同一天。如果'转化明细'里没有某个商品的数据，那该商品当天的下单笔数和付款笔数就填0。'转化率'这一列在‘转化明细’里是带百分号的文本，比如‘3.45%’，请先转成小数再参与计算。计算各渠道转化率时，按‘渠道来源’分组，对访客数和付款笔数求和，然后用付款笔数总和除以访客数总和，以百分比形式放在新列‘渠道转化率’。”

你有没发现，这些规则在手工处理时其实都是你脑子里默认的东西，但你不说出来，AI 永远猜不到。描述需求前，先花两分钟用笔在纸上列出你手工操作时的“判断清单”，这个清单就是你给 AI 的 Who 部分。

第四步：Which，边界情况怎么处理？（防御策略）

最后但同样重要的一步，是告诉 AI 当出现异常时该怎么办。不设防的脚本就像一个没有 try-catch 的程序，遇到意料之外的数据就原地崩溃。

你需要告诉它：

• 遇到非法日期（如“2月30日”）怎么办，跳过并记录还是直接报错；
• 遇到超出常理的值（如年龄 200 岁）怎么办；
• 遇到文件名不匹配、Sheet 不存在时怎么处理；
• 是否需要一个最终的报错日志。

我的做法是通常会加这么一段：

> “在所有处理过程中，如果遇到无法解析的日期、空的关键字段（如商品ID为空）、或者在合并时出现重复匹配的情况，请把这些异常行单独输出到一个叫‘异常数据’的 Sheet 里，记录原始行号和异常原因，不要中断脚本的运行。”

这样哪怕数据脏得离谱，脚本也能跑完，并且给你一个清晰的异常记录，方便你回头人工处理。这一个小小的要求，直接让你从“脚本一跑就挂，还得自己找错”进化到“脚本跑完，告诉你哪些需要人工看”。

五、从对话到脚本：三个完整实战案例拆解

光讲方法论还不够，我把过去几个月里帮不同部门做的三个 Excel 自动化任务完整地还原出来。你可以把它当作实操手册，每个案例我都会给出当时的完整对话逻辑、遇到的坑以及最终的脚本表现。

案例一：100 个分店销售报表的合并汇总

背景：一个连锁零售企业，全国 100 家分店每月底上报一份 Excel 销售报表，模板统一但偶有改动，所有文件放在同一个文件夹里。财务需要合并成一个总表，并对销售额按区域汇总。之前是由一位财务专员手工打开每个文件、复制粘贴到一个总表里，耗时约两天，且经常漏店或复制错位。

我的对话过程：

> 我：“我有一个文件夹，路径是 D:\销售报表\6月。里面有 100 个 Excel 文件，文件名格式是‘[城市]_[店名]_6月销售.xlsx’，比如‘北京_朝阳店_6月销售.xlsx’。每个文件只有一个 Sheet，名字都是‘Sheet1’，但有些老文件可能叫‘销售明细’。请写一个 Python 脚本，遍历这个文件夹下所有 xlsx 文件，读取里面的数据。

>

> 文件的结构：第一行是表头，列名依次是：品牌、品类、商品编码、商品名称、销售数量、零售金额（元）、折扣率（%）、实收金额（元）。数据从第二行开始。零售金额和实收金额列可能存在空值，请视为0。折扣率列有的带了百分号，有的是小数，请统一转成小数。

>

> 处理要求：1) 把所有文件的数据合并到一个 DataFrame 里，新增两列‘城市’和‘店名’，从文件名中提取。2) 按城市和品类分组，汇总销售数量和实收金额。3) 输出到一个新的 Excel 文件‘6月_全国汇总.xlsx’，包含两个 Sheet：一个‘明细’存放合并后的原始数据，一个‘汇总’存放分组汇总结果。”

Claude Code 给出的 Python 脚本约 70 行，核心逻辑是 os.listdir 遍历文件、pd.read_excel 读取并清洗、正则提取城市和店名、groupby 汇总。

第一次运行：报错，因为有两个文件里的 Sheet 名称是“销售明细”而不是“Sheet1”。还好我在需求里提到了“可能叫销售明细”，AI 生成的代码已经加了 try 逻辑，但 try 里只读取了第一个 Sheet，遇到这两个文件时读出来是空的。我把我看到的错误信息（类似于“读取文件北京_东城店_6月销售.xlsx 时未找到预期列名”）直接贴给 Claude Code，让它修改。

第二次：它改成了先获取文件的所有 Sheet 名字，然后找第一个非空的 Sheet 读取，问题解决。跑出来的明细有 6 万多行，汇总表也正确。

验证：我让财务专员把她前两天手工做的 10 家店的数据拿出来，和脚本生成的结果逐行比对，销售额分文不差，还比她手工多识别到了一个被遗漏的店（文件名末尾多了一个空格，她手动复制时漏了，但脚本遍历列表不受影响）。

耗时：从开始描述到最终可用，对话 25 分钟，脚本执行 12 秒。

复用性：这个脚本成了他们的月度报表模板。后来他们告诉我，7 月份有 3 个店改了列名，多了一列“会员销售额”，他们自己把需求描述微调了一下，让 AI 更新了代码，前后 5 分钟就完成了适配。

案例二：供应商对账单的模糊匹配与差异标注

背景：一个中型制造企业的采购部门，每月会收到供应商发来的对账单 Excel，和内部 ERP 导出的采购入库单进行比对。两个表的字段名称、格式完全不同，而且供应商的名称有时写简称有时写全称（如“深圳华强”和“深圳华强电子有限公司”），需要按金额和日期进行模糊匹配，找出差异。

我的需求描述：

> 我：“有两个 Excel 文件。第一个是‘供应商对账单6月.xlsx’，只有一个 Sheet，表头：供应商名称、对账日期、物料描述、数量、含税单价、金额。第二个是‘ERP_入库单6月.xlsx’，也只有一个 Sheet，表头：入库日期、供应商全称、物料编码、物料名称、入库数量、不含税单价、不含税金额、税额。

>

> 匹配规则：双方按金额（供应商的‘金额’与 ERP 的‘不含税金额+税额’）严格相等，且对账日期与入库日期相差不超过 3 天，且物料描述与物料名称相似度较高（可能不完全一致，如‘轴承6205’与‘深沟球轴承6205’）。匹配成功后，把两边的信息合并成一行。对于无法匹配的记录，单独放到一个‘差异记录’ Sheet 中，注明是‘仅供应商有’还是‘仅ERP有’，以及可能的差异金额。

>

> 特别说明：供应商名称匹配只用于最终标注，不作为匹配键。模糊匹配物料时请忽略大小写，并尝试子串匹配。如果出现一对多匹配（一个供应商记录匹配到多个ERP记录），选择日期最近的那一条，并记录警告。”

AI 的产出一波三折：首次生成的脚本用了 difflib.SequenceMatcher 做物料模糊匹配，阈值设了 0.6，跑出来匹配率只有 40%，大量同一种物料因为描述差异大被判定不匹配。我把失败案例贴过去：“明明‘轴承6205’和‘深沟球轴承6205’应该匹配，但没匹配上”，AI 改用了子串包含逻辑，只要较短的物料描述完全出现在较长的描述中，就判定为匹配。同时增加了金额误差容忍 \(\pm 0.01\) 元（因为有舍入误差）。

第二次运行：匹配率提升到 78%，但出现了一个新问题：子串包含导致“轴承6205”和“轴承6205ZZ”错误匹配，后者是带防尘盖的型号，价格不同。我继续纠正：“子串包含必须是完整的独立型号段，不能用‘6205’去匹配‘6205ZZ’，请增加型号边界判断。” AI 加入了对空格、型号后缀的识别，比如“6205”后面如果是字母或数字则视为不同型号。最终匹配率 91%，剩余 9% 的差异手工复核，远低于纯手工逐条比对的工作量。

耗时：从需求到最终可用，对话持续了约 50 分钟，脚本跑完 2.7 秒。而之前采购部做一次这样的对账，需要一个人两整天。

关键教训：模糊匹配是最容易踩坑的地方，需要反复用真实案例去“调校”AI 的判断逻辑。这时候，你不是在写代码，而是在和 AI 一起定义业务规则。

案例三：多条件拆分 Excel 并自动生成加密 PDF 报告

这是一个典型的跨部门协作需求，也是我觉得最能体现 AI 脚本“全自动流水线”魅力的案例。

背景：一个人力资源团队每次绩效考核结束后，要给每位员工生成一份个人的绩效报告 PDF，并加密（密码为员工工号后四位）。原始 Excel 包含全公司 300 人的详细评分，字段包括：工号、姓名、部门、上级评分、自评、同事互评均分、最终得分、等级、评语。需要按工号拆分成独立的 Sheet 或文件，再转成 PDF，要求 PDF 包含员工信息和各项评分的格式化表格。

我给 Claude Code 的描述：

> “我有一个 Excel ‘绩效评分_2024Q2.xlsx’，一个 Sheet，表头：工号、姓名、部门、上级评分、自评、同事互评、最终得分、等级、评语。数据从第2行开始，300行。请写一个 Python 脚本，完成下列任务：1) 按工号拆分，为每位员工生成一个独立的 PDF 报告；2) PDF 报告需要包含一个标题‘2024年Q2绩效报告’，下面是一个表格，展示该员工的所有评分字段，格式类似工资条；3) 对每个 PDF 设置打开密码，密码为该员工工号的后四位；4) 将所有 PDF 保存到一个叫‘绩效报告’的文件夹里。

>

> 备注：我之前没用过 Python 生成 PDF，请帮我选择最合适的库，并在代码中做好处理中文的配置。”

AI 选择了 fpdf2（因为当时 fpdf2 的中文支持比较好），生成了大约 90 行代码，包含数据读取、循环生成 PDF、设置表格、加密。第一版跑起来，PDF 生成倒是成功了，但中文全部显示为方框。我把问题反馈给它：“PDF 里的中文是乱码”，它立刻调整了字体注册，让我下载一个宋体 ttf 文件放到当前目录，代码里增加了 add_font 和字体路径配置。第二次运行，中文显示正常，但表格的列宽太窄，数字换行了。我补了一句：“表格的列宽请根据内容自适应，特别是评语列要宽一些。”它重新调整了列宽计算逻辑。

最终结果：300 份 PDF 在 35 秒内全部生成完毕，每份都加了密码。测试打开，密码正确，排版清晰。HR 负责人把之前做 10 个人的手工报告和脚本生成的报告一起拿给老板看，老板完全分不出哪个是手工、哪个是程序生成的。

这个案例说明了什么？你不需要懂任何 PDF 生成的技术细节，你只需要把自己当成最终用户，告诉 AI 你想要什么、哪里不满意，它来负责找到技术方案并修正。 很多传统上需要专门请开发人员写脚本的“批处理 + 格式化输出”工作，现在已经可以完全由业务人员自己主导完成了。

六、性能和稳定性：当你的数据超过 Excel 的物理极限

上面几个案例的数据量都在几千到几万行，这还在传统 Excel 的舒适区半径内。但一旦数据量突破某个临界值，事情就开始变得不一样。我专门做过一次压测：用 Claude Code 生成的脚本处理不同量级的数据，看看它的稳定性和执行效率，以及和手工操作 Excel 的边界在哪里。

数据量分级与性能表现

我构造了五组模拟数据，从 5000 到 500 万行，每一组都执行相同的处理逻辑：读取并合并两个 CSV，按某列分组聚合，计算均值、求和，最后排序输出。Python 脚本使用 pandas，开启 chunksize 参数处理大文件。

结论：

• 10 万行以下：Claude Code + pandas 完美胜任，性能冗余极大，不用做任何优化。
• 10 万到 100 万行：仍然是 pandas 的舒适区，但建议加 chunksize 参数分块读取，或者告诉 AI “数据量较大，请在读写时使用分块处理以节省内存”。AI 可以生成相应的迭代读取代码。
• 100 万行以上：需要你稍微懂一点点性能常识，或者在需求里提醒 AI：“数据量可能很大，建议使用 dtype 指定低精度数据类型、只读取必要列、或考虑使用 pyarrow 引擎”。不然 AI 可能还是生成全量读取的代码，你的内存瞬间爆掉。

我在处理一份 1500 万行的物流轨迹数据时，第一次让 AI 直接写了个 pd.read_csv 全量读取的脚本，16GB 内存的机器直接卡死。我把报错信息（MemoryError）截图给它，它立刻改成了 read_csv(chunksize=100000) 分批处理，并提示我如果用 parquet 格式的话性能会更好。后来我把 CSV 转成 parquet，同样的处理逻辑从 7 分钟降到了 40 秒。

所以，如果你的数据量级很大，在给 Claude Code 描述需求时，务必加一句“数据量约 X 万行”，让它从代码层面做性能规划。 这不是 AI 自己会主动考虑的点，但只要你提了，它就能做得很好。

七、安全、隐私与架构选择：什么情况下不应该用 AI 处理 Excel

我必须重点强调这一节，因为我见过不止一个人因为图省事，直接把包含客户电话、身份证号、银行账号的 Excel 粘贴进 Claude Code 的对话窗口。这是一个非常危险的动作。

Claude Code（以及所有 LLM 对话类产品）并不是本地完全离线的工具。 你的对话内容会被发送到云端进行处理。尽管官方有数据隐私保护政策、不会用你的数据去训练模型，但涉及个人敏感信息或企业核心商业数据时，依旧存在潜在的合规风险。我曾经帮一个猎头公司处理候选人信息表，表格里包含 500 多人的电话号码和工作经历，我直接拒绝了在云端对话中粘贴完整数据。我的做法是：只给他一个脱敏的样例，用虚拟数据把表结构和数据特征（比如电话号码是 11 位数字、身份证号是 18 位）复刻出来，扔给 AI 生成脚本，然后在本地跑真实数据。

具体的隐私安全分级策略，我划分了三个级别：

如果你处理的是高敏感数据，而且你本身不具备任何技术背景，那么“在 Claude Code 里生成脚本”对你来说可能不是最优路径。 因为你还需要搭建 Python 环境、懂如何保证本地文件的安全存储和清理，这些对你来说都是新的挑战。在这种情况下，应该优先考虑公司 IT 部门的安全处理方案，或者使用本地部署的开源 LLM。

当然，对于绝大多数非敏感的商业数据处理，Claude Code 是足够安全的。我个人最常用的一个折中办法是：用 AI 写一个数据脱敏脚本，先把真实数据脱敏，再用脱敏后的数据去和 AI 对话迭代逻辑，最后把脚本应用到真实数据上。 这个方法的边界很清晰，也几乎消除了数据泄露风险。

八、你应该自己写 Python、还是用 VBA、还是交给 Claude Code？

很多人来问我：“既然 Claude Code 这么好用，是不是意味着我再也不用学 Python 或者 VBA 了？”我的回答很明确：不是替代，而是重新定义了你的技能栈。 你的核心能力从“编写代码”变成了“清晰定义问题、验证解决方案、管理自动化资产”。

但不同情况下，最优解真的不一样。我根据自己帮几十个人做过需求评估的经验，画了一个快速的决策框架：

• 如果你的任务是一次性的、数据量不超过 1 万行、逻辑相对简单，那就直接手工做吧，花 20 分钟跟 AI 对话反而更慢。
• 如果任务是周期性的，但逻辑极其固定，比如每天从固定列求和然后填到另一个表，那 VBA 录制一个宏可能最省事，3 分钟搞定，都不用开 AI。
• 如果任务有复杂逻辑、需要跨文件匹配、需要灵活应对列名变化或数据异常，而且会重复多次，那绝对是 Claude Code 生成 Python 脚本的最佳场景。投入一次 20-40 分钟的交互，换来未来无数次的一键执行。
• 如果你本身就有 Python 基础，而且任务逻辑极其复杂，涉及多个 API 调用、数据库读写、复杂算法，那么手写代码能给你最精细的控制力，但你能借助 Claude Code 来加速代码框架的搭建和细节补全。

我会用一个真实的员工问我该不该用 AI 搞定需求的经历来说明。她是一个市场分析师，完全不会代码，每周五需要从 Google Analytics 导出的 3 个 Excel 里，整理出 15 个主要指标的趋势，画成折线图，再写进周报 PPT。过去她的周五要花掉整整一个下午，边骂边做。我帮她用 Claude Code 生成了一个脚本，一键读取 3 个文件、合并、计算指标、生成 matplotlib 图表并保存为 PNG，她只需要把 PNG 拖进 PPT 里。从对话到最终脚本落地，花了 40 分钟。之后每个周五她的处理时间从 4 小时降到了 3 分钟。三个月后她告诉我，她甚至自己学会了怎么微调脚本里的颜色和图表标题，因为她看到了代码里 plt.title() 这样的明显关键词，试着自己改了改，AI 生成的代码可读性足够高，她慢慢就敢动手了。

这就是 Claude Code 带来的附加价值：你生成的 Python 代码是透明的、可读的，它不仅仅是工具，也是你学习的桥梁。 这一点，VBA 宏录制绝对做不到。

九、构建你个人的“脚本资产库”：从一次生成到持续复用

我接触过的最高效的那一批非技术用户，都有一个共同特征：他们不让每一次的 AI 生成成为一次性消费，而是有意识地把脚本保存、分类、记录用途，构建起一个个人的“自动化脚本库”。 这件事的意义在于，未来遇到类似但稍有变化的需求时，你不需要从零开始跟 AI 对话，而是找到最近的脚本，把改动点告诉 AI，让它帮你改。这个效率比重新生成高至少 3 倍。

我自己的习惯是：

1. 建立统一的脚本命名规则：[日期]_[业务场景]_[核心操作].py，例如 20250315_合并多Sheet销售数据_按区域汇总.py。
2. 每个脚本开头必须有注释，说明这个脚本做什么、作者是谁、依赖哪些库、最近一次成功运行是在什么时候。这些注释我都直接让 Claude Code 在生成代码时一并加上。
3. 保留原始需求描述：我会在脚本的同一个文件夹里放一个 readme.txt，里面贴着我当初给 Claude Code 的原始需求描述，以及生成过程中的关键修改要求。这样几个月后我再打开这个脚本，还能快速回忆起它解决的是什么问题。
4. 关键脚本做版本管理：如果这个脚本以后还要频繁改动，我就把它放到一个自己的 Git 仓库里，哪怕只是本地库。有一次我把一个报表生成脚本改出了 bug，靠 Git 回滚救了我一命。

我把这个方法论推荐给了之前完全不写代码的采购部同事，他花了一个下午把自己过去几次的任务脚本整理了一下，现在他每次拿到新的对账需求，80% 的情况下只需要打开旧脚本，把新的文件名、列名变更告诉 Claude Code，三分钟搞定。这是一种隐秘而强大的效率叠加效应。

十、最后：你不再需要去学 Python，但你需要学会定义问题

回看这一路走过来，从第一次胆战心惊地让 AI 帮我生成 Excel 处理代码，到现在可以毫无心理负担地把上百个文件的合并任务甩给它，我最大的感触不是“AI 真厉害”，而是“大部分职场人被 Excel 困住的原因，从来不是因为他们不会写代码，而是因为他们不知道问题可以被自动化。”

你不需要成为那个能噼里啪啦敲键盘写 Python 的人，你只需要成为那个看着一张乱七八糟的 Excel，能清晰地对自己说：

• 这张表的结构我能说清楚；
• 我想把它变成什么样子我能画出来；
• 我手工处理时的判断规则我能一条条列出来。

只要你做到了这三件事，Claude Code 就能帮你把中间那一段“写代码”的活儿给干了。

所以，下一步的行动建议很简单：

1. 打开你现在手头最让你烦躁的那个 Excel 任务；
2. 不要急着动手，拿张纸，用我上面说的 4W 框架（What、Where、Who、Which）把它从头到尾描述一遍；
3. 打开 Claude Code，把你的描述贴进去，再加上一句：“请帮我生成一段可以完成以上任务的 Python 脚本，并告诉我如何在我的电脑上运行它。”

那第一次你可能需要花上一个小时，但相信我，这比你下周五再花一整个下午手工去做强太多了。等到你第五次、第十次这样做的时候，你会发现你已经拥有了一大堆能帮你自动干活的“数字实习生”，而你自己，则变成了那个最擅长给实习生派活儿、最懂得如何把一个模糊的业务问题翻译成清晰可执行的指令的人。

这才是这个时代最值钱的能力。