同一份表，第一次处理花 13 万 token，第三十次处理还是 13 万 token------这就是积分制下最容易被忽略的成本结构。本文给一套可落地的三段式做法：脱敏样本喂给模型生成处理逻辑，逻辑固化成脚本，原表留在本机跑。首次之后，处理动作不再产生模型调用。
一、省不下来的从来不是单价，是"重新想一遍"
过去两年大模型的调用单价一直在掉，但很多人的月度账单反而在涨。原因不复杂：单价降了，调用次数涨得更快。一份月报从"月底做一次"变成"随时想问就问"，从"问一次"变成"改口径再问一遍、换个维度再问一遍、领导要看另一种排法再问一遍"。
在积分制的计价方式下，这个结构性矛盾会被放大。积分是按调用次数和输入长度扣的，而 Excel 数据处理这件事，恰恰是"同一套逻辑要跑很多遍"的典型场景：这个月的销售明细、下个月的销售明细，字段一样、口径一样、要出的结论也一样，唯一变的是数据本身。
于是每一次处理，模型都要从头做一遍相同的工作：重新读一遍字段名，重新判断哪一列是金额、哪一列是数量，重新理解"毛利"在这家公司指什么，重新推导分组的层级，重新写一遍处理步骤。你把两万行明细贴进去，等于让它把已经想明白过二十九次的事情再想第三十次，然后按第三十次的费率收费。
按一份十二个月合并、约两万行的销售明细估算，纯文本约二十万字符、折合约十三万 token。一个月处理三十次，就是将近四百万 token 的输入------而这些输入里有九成以上是重复的。
真正的问题不是"用不起大模型"，而是把"想清楚怎么处理"和"照着处理"这两件成本结构完全不同的事，捆在同一次收费的调用里。
二、把这两个动作拆开，成本结构立刻变了
"想清楚怎么处理"是创造性动作：需要模型理解业务口径、理解表格结构的坑、决定分几步走。这个动作做一次就够，而且做一次值得付费。
"照着处理"是机械动作：按既定步骤读表、清洗、合并、分组、算指标、排版输出。这个动作做三十次、三百次，逻辑完全一样，理论上不该产生任何模型调用。
把这两件事分到不同的层里，方案就有了骨架。
图 1 方案骨架：模型只在中间层出现一次，上下两层都不消耗积分
第一层是脱敏样本层：交给模型的不是真表，是一份结构和语义完全保真、数值全部替换过的样本。模型看到的是"字段长什么样、脏数据长什么样、口径是什么"，看不到"这家客户叫什么、这单卖了多少钱"。
第二层是逻辑生成层：模型在这里产出可执行的、带注释的处理逻辑------哪一步去重、按什么键合并、空值怎么填、负库存怎么标、指标怎么算。这是整个方案里唯一花钱的地方，也只花一次。
第三层是本地执行层：真表和这套逻辑都在本机。跑一遍，出结果，零调用。下个月换一份同口径的表，再跑一遍，还是零调用。
三层之间是可以拆开替换的：换模型不影响第二层以下的执行，换数据不需要回到第二层重新生成。这是这套做法比"每次直接问"更值钱的地方------它把一次性的对话，变成了一份可以留存的处理能力。
三、第一步：怎么用脱敏数据把处理逻辑"问"出来
这一步做得好不好，决定了后面能不能真的把积分省下来。很多人以为脱敏就是把姓名打码，结果样本交上去，模型生成的逻辑在真表上跑不通------因为样本被"修干净"了，真实世界里的坑一个都没保留。
脱敏的目标不是"看不见真数据"，而是"让模型看到和真表一样难看的表"。具体有五件事要守住。
第一，结构必须一比一。表头文字、列顺序、数据类型、有没有合并单元格、日期是文本还是日期格式、金额带不带千分位、哪些列有前导空格，全部照抄。模型对这些细节非常敏感，一处不同，生成的清洗步骤就会错位。
第二，数值要按规则替换，不能乱打码。客户名换成"客户A、客户B"这类保持唯一性的代号，手机号保留位数和分段格式，金额保持量级和分布------该有负数的地方留负数，该有零的地方留零，几万和几百万的差别要在样本里体现出来。分布一旦失真，模型对"异常值"的判断就会失准。
第三，脏数据要原样复刻。这是最关键也最常被跳过的一条：重复行、负库存、文字型数字、别名不统一的商品名、跨表对不上的编码、跨月重复的汇总行、本该有值却空着的分类，这些坑必须在样本里出现。你要是把样本洗得干干净净，模型生成的逻辑就是给干净数据写的，放到真表上第一个坑就翻车。
第四，口径要写在需求里，别让模型猜。"毛利 = 实收金额 - 成本 - 折扣分摊""负库存单独成表不强平""零销量商品不参与周转计算"------这三句话写清楚，模型生成的逻辑能少迭代两三轮，而每一轮迭代都是实打实的积分消耗。顺带说，字段的业务含义如果能先在工具里定义好，模型对语义的判断会更稳，不需要每次靠猜。数以轻舟里的语义自定义就是干这件事的：把字段含义先写下来，模型每次不用重新揣摩。
图 2 字段语义提前定义，是把"多轮试错"压成"一轮成型"的前置条件
第五，样本跑通后抽检。用一到两行真实数据（这里可以只留数值，不带任何身份信息）验证逻辑的输出是否对得上。这一步不产生调用，只是确认逻辑没走偏。
做完这五件事，你手里拿到的不是一段聊天记录，而是一份可以反复执行的逻辑。它的价值在于：逻辑描述的是"处理规则"，不是"这次的数据"。规则和数据一旦分开，规则就可以复用，数据就不用出门。
四、第二步：把逻辑固化下来，让它变成可复用的资产
逻辑生成出来之后有两种命运：留在对话框里，下个月再问一遍；或者固化成脚本，下个月直接跑。
这两种命运的积分差距是数量级的。前一种是每个周期重新付费，后一种是一次付费、长期复用。
数以轻舟在这一步做的是"把逻辑固定成本地可执行脚本"这件事：生成好的处理逻辑在本地保存下来，下次遇到同口径的表，直接匹配到已有脚本执行，不再走模型。这里的机制值得说清楚------省下来的不是"用了更便宜的模型"，而是"压根没有发生模型调用"。这两件事在账单上的差别非常大：前者是打折，后者是归零。
图 3 处理逻辑固化为本地脚本后，同口径数据可以重复调用同一套流程
需要区分清楚的一点是：能归零的是"处理动作"。报表处理这条路------读表、清洗、合并、对账、算指标、出中间结果------逻辑固定之后，重复执行不产生任何模型调用。而报告成文、PPT 排版这类需要模型现场组织语言的动作，是不可能归零的，它必须联网调模型。把这两件事混为一谈，方案就会在落地时翻车：承诺了做不到的事，用户第一次要报告就发现对不上。
所以准确的表述是：把"可重复的处理"归零，把"一次性的生成"压缩到最少次数。
图 4 命中已有逻辑时，执行链路上没有模型节点
另外要说清角色包这条线和 token 的关系，很多文章在这里写错。角色包解决的是"核查标准和口径能不能打包导入、导一次反复用"的问题，它沉淀的是分析逻辑本身，价值在一致性和复用性上，不要把它和"省 token"直接绑在一起讲。真正让 token 归零的是脚本固化这条路，两者是不同层面的东西。
五、第三步：原表在本机跑，安全账和成本账一起算
这一步是整套方案真正闭环的地方：真表始终留在本机，作为文件被本地程序读取，不进任何对话框，也不上传到第三方服务。在数以轻舟里，原表就是这样被当作本地文件读进来的------它参与计算，但不参与传输。前面交出去的只有脱敏样本，而样本里没有可识别的业务信息。
于是两个账同时改善。
成本账很好算：一次性生成逻辑的那点消耗，摊到后面每一次复用上，边际成本趋近于零。执行的耗时也从"贴数据、等响应、校验、返工"的四十分钟级，压到"跑一遍、核十分钟"的水平。
安全账则是很多人一开始没意识到的隐性收益。用对话方式处理真实业务表，风险点其实不少：表被完整贴进了聊天窗口，留在服务商的会话记录里；提示词里顺手写了客户名和金额；处理逻辑只存在于某次对话中，没法审计、没法版本管理；模型供应商换了接口或改了策略，原来那套"人机约定"就失效了。
用这套三段式做法，每一条都有对应的解法。
| 风险点 | 直聊式处理 | 本方案对应做法 |
|---|---|---|
| 原始明细出域 | 整表粘贴进对话窗口，明细进入第三方会话记录 | 只提交结构与语义一致的脱敏样本，原表只在本机被读取 |
| 提示词夹带真实信息 | 顺手把客户名、金额、内部编码写进需求描述 | 脱敏对照关系留在本地，提交前按字段白名单自查 |
| 处理过程不可审计 | 逻辑散落在多轮对话里，无法回看、无法比对 | 逻辑以本地脚本形式留存，可以逐行看、逐行改、留版本 |
| 供应商变更导致返工 | 换模型或接口调整，原有对话式约定失效 | 逻辑独立于模型存在，换接口不影响已固化的处理 |
| 人为误操作传播 | 一次贴错表，错误结论被复制到多处 | 同口径固定流程，输入输出路径固定，异常由校验拦住 |
表 1 五个风险点在两种做法下的差异
这里要说一句不那么讨喜的话：这套做法不是把风险降到零，而是把风险从"不可控的传输"转移到"可控的本地操作"。脱敏做得不彻底、样本里残留了真实姓名、本地脚本被人乱改，这些依然是风险，只不过它们变成了你自己能看见、能检查、能修正的风险。安全的本质从来不是"没有风险"，而是"风险落在你看得见的地方"。
六、成本：同一份表跑三十次，三条路线差多少
把账算细一点更直观。假设条件写在这里，方便你自己按实际情况替换：一份十二个月合并的销售明细，约两万行、十五列，纯文本约二十万字符，折合约十三万 token；同口径任务每月处理三十次；积分换算按"每一千 token 折一积分"的常见档位估算。这些是测算假设，不是任何一家平台的报价。
| 路线 | 做法 | 单次输入规模 | 三十次累计消耗 | 能否拿到可复现结果 |
|---|---|---|---|---|
| A 直聊直给明细 | 每次把整表贴进对话，让模型现场处理 | 约 13.5 万 token | 约 4050 积分 | 可以，但每次结果格式不保证一致 |
| B 只喂汇总指标 | 人工先算好指标，只问模型怎么解读 | 约 2000 token | 约 60 积分 | 拿不到处理结果，只有解读 |
| C 脱敏生成 + 脚本复用 | 首次用脱敏样本生成逻辑，之后本地执行 | 首次约 3 万 token，之后 0 | 约 30 积分 | 可以，且流程与口径完全可复现 |
表 2 三条路线在三十次任务下的消耗对比
这张表里最值得注意的不是 A 和 C 的差距，而是 B 和 C 的差距。很多人以为"只喂汇总指标"已经很省了，但三十次问答累计下来，仍然比"生成一次逻辑再复用"贵一倍------而且 B 路线省掉的恰恰是最有价值的部分：它没有产出任何可复用的处理能力，只产出了三十段解读文字。
图 5 三十次同口径任务的累计消耗：直聊式约为脚本复用式的 135 倍
A 路线与 C 路线的差距是 135 倍量级。这个倍数不是靠"选一家更便宜的模型"实现的，而是靠"把重复的思考去掉"。即便未来所有平台的单价再降一半，这个倍数关系依然成立------因为 C 路线里那部分消耗是零，零除以二还是零。C 路线落到工具上其实没有多少机关：在数以轻舟里，它就是把生成好的处理逻辑固化成一份本地脚本，之后同口径的表都交给这份脚本。
还有一个容易被忽略的隐性成本：C 路线把"口径"从人的记忆里搬到了脚本里。第三十次处理时，不会有人记得第一次是怎么定义毛利的、负库存当时怎么处理的、重复行是按哪个键去掉的。直聊式做法靠人复述，复述就会有偏差；脚本式做法靠流程固定，固定就不会漂。一份能复现的处理流程，本身就是数据治理的一部分。
七、这套方案什么时候不适用
任何方案都有边界，讲清楚边界比讲清楚优势更能说明它是认真做过的。
第一，口径还没定的时候不要固化。如果业务方自己还在争论"毛利到底含不含运费"，这时候生成脚本，等于把一个错误口径固定成长期流程。正确的顺序是先人工跑通两三次、口径吵完，再固化。
第二，一次性、结构不规则的活不值得固化。只做一次的表、临时拼凑的怪结构，生成逻辑的时间可能比直接问还长。判断标准很简单：这份表你预期还要处理几次？三次以上，固化划算；只有一次，直接问。
第三，需要模型现场判断的活不能归零。异常归因、文本解读、报告成文、给领导写结论，这些依赖模型的表达能力，必须联网调用。这套方案省的是处理环节的重复消耗，不是把模型从流程里赶出去。
第四，表结构漂移要重建。供应商改了表头、系统升级多了一列、业务新增了字段，原来的脚本会失效或算错。这时候需要重新生成一次逻辑，成本回到起点，但仍然是"一次"而不是"三十次"。
第五，数据量大到一定程度要注意执行环境。两万行和两百万行对本地执行的压力不一样，前者毫秒级，后者要考虑内存和分块。这只影响执行的工程细节，不影响"零调用"这个结论。另外，输入范围也有边界：数以轻舟读的是 xlsx 和 csv，PDF、图片、Word 这些格式得先转成表，别指望它直接啃。
八、落地清单六步
如果你打算把这件事做起来，可以按这六步走，不需要一次到位。
- 挑一个每月固定要做、结构稳定的表。月报、进销存、对账表都合适，别挑最复杂的那个，先跑通一个。
- 造一份结构保真的脱敏样本。表头照抄、数值按规则替换、脏数据原样保留。做完之后自己看一遍：这份样本给同事看，他能看出是哪家公司吗？
- 把口径写成三到五句话，随样本一起提交。写清楚指标定义、异常处理约定、输出格式要求。这三到五句话能省掉两三轮迭代。
- 生成逻辑并抽检。用少量真实数据验证输出，重点看边界情况：空值、负数、重复行、跨表对不上的编码。
- 固定脚本，把输入输出路径定下来。在数以轻舟里把验证过的逻辑固定成本地脚本，同口径的表放进约定位置，一键跑完。
- 建立版本记录。口径变了就生成新版本，不要在原脚本上改到面目全非。脚本的价值在于可追溯，改乱了就只剩"能跑"这一个优点了。
做完这六步，你手里会多一样东西：一份不依赖模型存活的处理流程。它在模型涨价时不受影响，在接口停服时不受影响，在换供应商时不受影响。这是"省积分"这件事最终沉淀下来的部分------省下来的钱会被忘记，留下来的能力会继续用。
九、省成本的前提是把一次性和重复性分开
回到开头那个问题：为什么单价在降，账单在涨？因为在积分制的计价方式下，每一次处理都要重新买一遍"理解"。而 Excel 数据处理这件事，理解只需要买一次。
脱敏样本解决的是"敢不敢把表交出去"的问题，脚本固化解决的是"要不要每次都交"的问题，本地执行解决的是"数据落在哪里"的问题。三件事串起来，才是完整的低成本方案：不是省在单价上，是省在次数上；不是靠压缩输入赌运气，是靠流程设计把重复消耗结构性去掉。
一个可用的判断标准是：如果你发现自己在重复描述同一份表的字段和口径，那就说明这份处理该固化了。每复述一次，都是在为同一个理解重复付费。
用数以轻舟这样的本地工具做这件事，好处不在于它能替你算出什么，而在于它能把你已经想清楚的逻辑固定下来，让第二十九次和第一次跑得一样准，且不再产生消耗。数据文件本地处理、处理逻辑本地留存、同口径重复执行不产生模型调用------这三条同时成立的时候，安全和高性价比才不是一句口号，而是一份可以核对的东西。
参考资料
- IBM Security 与 Ponemon Institute：《Cost of a Data Breach Report 2025》
- Gartner：《Market Guide for Data Security Platforms》相关公开摘要
- 中国信息通信研究院：《人工智能白皮书》与数据要素相关公开报告
- OWASP：《Top 10 for Large Language Model Applications》2025 版
- 各主流大模型平台公开的 token 计费与积分换算说明（本文测算所用换算档位取自公开档位区间，仅用于量级比较）