ARTICLE · 1319122

Excel 89行差1分钱:DeepSeek写VBA,一秒定位“幽灵数字”

发布时间：2026-11-06 12:07:21 最近访问：2026-11-06 12:07:22

先问你一个问题：如果一份Excel报表，每一行的合计金额单独看都一模一样，最后列的总计却差了一分钱，你信不信？

以前我不信，直到昨天，它真真切切地发生在了我面前。

89行数据。表1按支付款项统计，表2按固定资产分配统计，两边的统计口径不同，但每一行“摊”到具体的项目上，金额分毫不差。我把两列并排放在一起，从上扫到下，又从下扫到上，眼睛都快对穿了——每一行的数字都长一样。可一拉到最底下，总计栏，一个比另一个多出了0.01。下图是通过VBA程序最后揪出来的“内鬼”（数据已脱敏）。

表1：

表2：

我第一反应是：单元格格式。是不是一边设置了保留两位小数，一边设置了保留一位，显示上凑巧对齐了，实际值在打架？打开单元格格式一看，全是两位小数，一模一样。

第二反应是：是不是有隐藏行？之前吃过这个亏，Excel的某些统计函数在筛选、隐藏状态下会悄悄把不该算的行也算进去。检查了一遍，没有筛选，没有手动隐藏。

能肉眼想到的、能手动点到的，我都过了一遍。89行，逐行比对，眼睛看瞎了也没找出哪一行“叛变”了。那种感觉就像——你明明知道屋子里多了一个人，但每个角落都翻遍了，就是看不见他。

一、让程序去和Excel的“内置机制”对话

人眼是靠不住了，那就上程序。

我心里其实有一个隐隐的推测：问题大概率出在舍入机制上。但显示格式一致，肉眼比对也一致，说明差异被藏在了Excel存储值和显示值之间的那道缝隙里。Excel有一个很多人不知道的行为：你看到的“89.10”，在底层二进制里可能存的是“89.09999999999999”。单独看一个数，四舍五入后显示成89.10，没问题。但当89个这样的“近似值”被累加起来，微小的误差就会像雪球一样滚成可见的0.01。

这不是逻辑错误，是IEEE 754浮点数存储规范在Excel里的固有特性：很多十进制小数无法用有限二进制精确表示，Excel只能存一个“最接近的近似值”。Microsoft官方文档里写得清清楚楚，只是绝大多数人不会读到那一页。

方向定了，接下来就是让VBA去干一件人眼干不了的事：不比较显示值，比较单元格的底层存储精度。

二、VBA能解决精度问题，但AI生成的代码，不能拿来就跑

自从开始用DeepSeek生成VBA来处理工作中的真实数据，我对“AI生成代码”这件事的态度就变了。代码能跑通、结果正确，只是及格线。数据安全，才是那条不能碰的底线。

近期AI编程工具的数据泄露事件密集曝光：有工具被曝在用户不知情的情况下，将整个项目工作区——包括Git历史、密钥、敏感配置——静默打包上传云端，用户连关闭的开关都找不到。这些事离Excel VBA看起来很远，但逻辑是一样的：只要你的数据离开了本地，你就失去了对它的控制。

所以我的做法很“笨”，但足够稳。三个层面，层层卡死。

第一层：物理隔绝，不让数据出门。

DeepSeek在云端生成代码，但Excel文件从头到尾不碰网络。我从来不把包含真实数据的Excel文件上传给AI，也不使用任何声称“自动连接AI处理表格”的插件。提示词里只描述数据结构——“A列是金额，B列是科目，共89行，需要比对两列对应行的底层数值精度”——不出现任何一个真实的客户名称、金额数字、内部科目编码。数据留在本地，AI只产出代码，这是不可协商的前提。

第二层：在提示词里就把“安全围栏”扎好。

这是我的数据安全前置的标准化提示词：

1.优先保证代码是安全可运行的，而不是仅仅能运行的。如果安全约束与功能需求冲突，先向我说明冲突，不要默默绕过。

2.不得以任何形式硬编码API密钥、密码、令牌或连接字符串。从Windows环境变量读取（Environ），读取后检查是否为空；为空时用 MsgBox 提示并 Exit Sub，不要继续执行。

3.除非我明确说“需要从网络获取/发送数据”，否则不要使用 XMLHTTP、WinHttp、MSXML2、URLDownloadToFile或任何形式的外连调用。如果功能确实需要外连，在代码注释中写明目标地址和发送的数据字段。

4.除非我明确要求执行系统命令，否则不要使用 Shell、WScript.Shell、CreateObject("WScript.Shell")、ExecuteGlobal。任何情况下都不要把单元格值或用户输入直接拼接进命令字符串。

5.除非我明确要求“打开文件时自动运行”，否则不要生成 Workbook_Open、AutoOpen 或 Document_Open 过程。

6.对所有来自单元格或外部数据的输入，验证非空、类型和长度；对文件路径，验证解析后的路径仍在预期目录内。验证失败时给出可读提示，不要静默跳过。

7.包含结构化的 On Error GoTo 处理，错误路径要么写入日志，要么弹窗提示，不要用 On Error Resume Next把异常吞掉继续跑。

8.生成代码后，用一段注释列出这段代码的“安全假设”：它访问了哪些外部资源、依赖哪些前提条件、在什么情况下可能产生副作用。不要省略这一步。

9.请用VBA代码在Excel表格中实现同一工作表中的两个独立表数据对比功能，具体如下：

（1）弹出提示框，选择第一个要对比的表格里面列；

（2）对该列内数据为0的行进行数据清洗，不包括含0的数据；

（3）弹出提示框，选择第二个要对比的表格里面的列；

（4）对该列内数据为0的行进行数据清洗，不包括含0的数据；

（5）对比时不按照顺序，可转化为数值型比较，只对比两列数据中不一致的单元格，并用红色标注。

这段提示词的作用，一是让你对代码的数据安全有底气，二是实现你的需求，以下主要摘录代码生成的安全排查情况。

第三层：代码到手，先“目检”，再“隔离”，最后才“放行”。

AI生成的代码，不能直接在生产文件上运行。目检只盯三样东西：注释（有没有含糊其辞的说明）、危险关键字（Shell、CreateObject、FileSystemObject、XMLHTTP、SaveAs到外部路径）、外联痕迹（任何形似URL或IP地址的字符串）。哪怕代码逻辑看起来再合理，只要出现其中任何一项，就值得深究。

通过目检的代码，先在数据副本上跑。把生产文件复制一份，删掉大部分真实数据，留一个覆盖正常值、空值、边界值的“测试样本”。副本放在独立文件夹里，在Excel信任中心将该文件夹设为受信任位置，宏只在这个范围内生效。测试通过，才放到真实的文件。

知根知底，才能百战百胜，老祖宗留下的真谛。这不是疑神疑鬼，是在AI生成代码成为日常工具之后，一个Excel重度用户应有的基本肌肉记忆。效率是AI给的，安全必须是自己守的。

这笔一分钱差异的案例，最终通过VBA比对底层存储值，在一秒内锁定了问题单元格。解决方案本身并不复杂：在关键汇总环节使用ROUND强制对齐至两位小数，或对涉及货币的中间计算统一进行精度截断。但比具体修复更有价值的，是该案例验证了一项判断：在Excel中，肉眼观察与显示格式均属于表层信息，真正的差异存在于存储层与计算机制之中。而VBA，是普通用户能够直接触达该层面的最短路径。

同样，在“用AI写VBA”这件事上，效率提升是客观现实，安全底线亦是客观现实。物理隔绝、提示词前置、代码目检、隔离执行——这三个层面中，没有任何一层属于多余步骤。因为当一段AI生成的代码被放入装有真实业务数据的Excel中时，所涉及的不仅是单张表格，而是整条数据链的信任基础。

眼睛看到的不一定是真的。但一套设计良好的安全流程，可以使“看不见的风险”在落地之前即被拦截在外。

语言到不了的地方，DeepSeek可以。这世间没有解决不了的问题，只有愿不愿意去思考的大脑。