AI为什么能处理超大Excel，却不消耗等量Token？

让AI处理十几万行Excel、生成上百MB的SQL，是否意味着模型必须"读完"全部内容，并消耗同等规模的Token？答案是否定的。关键在于：模型负责思考和编排，程序负责批量计算。

01 | Token到底花在哪里

Token可以简单理解为模型读取和生成文本时使用的计量单位。只有进入模型上下文的内容，才会占用对应的Token。

如果把完整Excel转换成文本，再逐行发送给模型，确实会产生巨大的Token开销，还可能超过上下文限制。但在实际工程中，大文件通常留在本地，由Python等程序直接读取。模型只需要看到文件信息、少量样例、异常和汇总结果。

因此，一个145MB的SQL文件可以被生成出来，却不需要让145MB文本全部经过模型。需要说明的是，这里的145MB只是一个示例量级；Token与字节数并非线性对应，具体换算取决于文本编码、语言和分词方式，应以实际模型的计量结果为准。

下面这张图对比了"全量塞给模型"和"本地程序处理"两条路径中，Token实际流经的位置：

flowchart LR subgraph Bad["全量塞给模型（高Token开销）"] A1[完整Excel] --> A2[转成文本] --> A3[逐行发送] --> A4[模型上下文] end subgraph Good["本地程序处理（低Token开销）"] B1[完整Excel] --> B2[本地程序读取] B2 --> B3[文件信息/样例/异常/汇总] B3 --> B4[模型上下文] B2 --> B5[生成SQL文件] end

02 | 模型与程序如何分工

这类任务可以分成"判断"和"执行"两部分。

模型负责设计规则，例如：空单元格转换为NULL，日期转换为Oracle的TIMESTAMP，文本中的单引号需要转义，字段长度要根据数据统计，批量插入不能超过数据库限制。

本地程序负责重复劳动：逐行读取Excel、统计字段、转换单元格、写入SQL文件。相同的规则可以稳定执行十几万次，而不需要模型逐个处理单元格。

可以把模型理解成建筑师，把程序理解成施工机械。建筑师不必亲手搬运每块砖，但需要确定图纸、材料标准和验收规则。

这种分工可以用下面的流程表示——模型只参与"判断"环节，重复的"执行"环节完全交给程序：

flowchart TD M[模型：设计规则] --> R1[空值转 NULL] M --> R2[日期转 TIMESTAMP] M --> R3[单引号转义] M --> R4[字段长度按统计确定] M --> R5[批量插入不超过数据库限制] R1 --> P[本地程序：批量执行] R2 --> P R3 --> P R4 --> P R5 --> P P --> O[逐行读取/转换/写入SQL]

03 | 大文件仍然需要完整读取

不消耗等量Token，不等于不读取完整文件。

为了保证结果可靠，程序仍然可以流式扫描每一行。所谓"流式"，是指读一部分、处理一部分，不把整个工作簿一次性放进内存。需要注意的是，流式读取通常不保留全部原始数据，因此"读取两遍"意味着第二遍需要重新读取源文件（或借助临时文件/中间结果），而不是复用第一遍的内存数据。

例如生成数据库初始化脚本时，可以读取两遍：第一遍统计表头、行数、字段类型和最大长度；第二遍按照确定的规则生成SQL。两次行数不一致时立即报错。该方案假设两遍读取之间源文件未被修改；若文件可能被并发写入，应先做快照或校验和锁定，避免统计结果与生成内容不一致。

文件读取消耗的是本地CPU、内存和磁盘资源，而不是模型Token。

两遍读取的流程如下，第二遍结束后会与第一遍的行数做一致性校验：

flowchart LR F[源文件] --> P1[第一遍：统计表头/行数/字段类型/最大长度] F --> P2[第二遍：按规则生成SQL] P1 --> C{两次行数是否一致} P2 --> C C -- 不一致 --> E[立即报错并中止，不输出SQL文件] C -- 一致 --> OK[输出SQL文件]

04 | 如何保障生成结果准确

准确性主要来自确定性规则和自动校验，而不是依靠模型"记住"全部数据。

• 为源文件计算SHA-256，确认输入是否变化。
• 全量统计数据类型和字段长度，而不是只抽查前几行。
• 对空值、数字、文本、日期分别采用固定转换规则。
• 对日期与文本混用等异常采取保守策略，避免擅自猜测。
• 对比源数据行数和生成SQL中的写入行数。
• 导入数据库后，再核对各表实际行数。

需要注意：静态检查不能完全替代真实数据库验证。数据库版本、字符集、权限和表空间等问题，只有在测试库实际执行后才能最终确认。

这些校验点分布在从输入到入库的不同阶段，可以按下面的顺序逐层把关：

flowchart TD S1[源文件 SHA-256] --> S2[全量统计类型与字段长度] S2 --> S3[固定转换规则处理空值/数字/文本/日期] S3 --> S4[异常保守处理，不擅自猜测] S4 --> S5[对比源数据行数与SQL写入行数] S5 --> S6[导入数据库后核对各表实际行数] S6 --> S7[测试库实际执行验证]

05 | 这种模式适合哪些任务

当工作同时满足"数据量大、规则明确、重复度高"时，通常适合这种模式，例如日志分析、代码批量修改、数据格式转换、报表生成和数据库迁移。但如果规则难以形式化、需要频繁人工判断，或数据中存在大量非结构化异常，则仍需模型或人工介入，不能完全交给程序。

真正高效的AI工程，并不是把所有内容都塞给模型，而是让模型生成可靠的处理工具，再通过摘要、异常和校验结果掌握全局。这既节省Token，也让过程更可重复、更容易审计。

关注我，和AI一起成长~