研究口径本文为单案例深度研究。样本是某调味品供应链公司的 8 月、9 月两份商品销售统计表各 15 列、1908 个数据行单文件约 166 KB合计 3816 行。文中所有数据层结论——行数、金额、毛利率、重复行数、零销量行占比、脚本耗时——均由本地脚本对原始文件逐项实跑复核得出可复算效率对比中的人工耗时为按标准操作步骤拆解的工时测算值非秒表实测测算口径在第三章注明。执行载体为本地安装的智能数据处理工具数以轻舟其处理动作在本机完成、不将明细上传公网。一、背景介绍1.1 为什么值得研究「AI 怎么做数据分析」研究一个案例之前先要说明它为什么典型。三个被反复验证、却很少被真正解决的事实构成了这项研究的起点。第一分析人员的时间大头不在分析。《哈佛商业评论》被引用多年的调研口径是数据分析师约 80% 的时间花在准备数据上真正用来下结论的不到两成。这个比例放到月结场景会更极端——报表结构每个月都一样变的只有数据但每个月都要从头再做一遍。第二商业表格的错误率高得超出直觉。一项跨越 35 年、覆盖多国样本的学术综述给出的结论是约 94% 的电子表格存在错误。表格类错误有个讨厌的特点算错了不报错账面看起来一切正常直到某天对不上账才被发现。而月度汇总恰恰是把所有上游错误集中放大的最后一站。第三合规约束正在从建议变成红线。2025 年 1 月 1 日起施行的《网络数据安全管理条例》对数据处理者的义务做了更明确的规定中国信通院相关报告显示相当比例的企业倾向于私有化或本地化部署方式。销售明细、工资表、耗材台账这类表格越来越多企业不愿意整份上传到网页工具的对话框里。三条事实叠在一起指向一个非常具体的需求有没有一种做法既用得上大模型的理解能力又不用把整份明细交出去还能让第二次、第三十次处理不再重复付费这正是本次案例研究要回答的问题。1.2 三条技术路线本案例站在哪一条用大模型做表格分析目前市面上的做法可以归成三条路线路线代表做法代价A · 云端直传把整份表格上传到云端工具模型直接读明细出域、按次或按 token 计费、每次都重新付B · 全栈本地本地部署模型加本地应用硬件投入高、部署运维门槛高C · 云端生成脚本、本地执行、脚本留存模型只负责把需求翻译成处理脚本数据在本机跑首次需要联网生成脚本之后处理环节不再依赖模型路线 A 的成本结构是「每次都全额付费」路线 B 的成本结构是「一次性重投入」路线 C 的成本结构是「只在第一次付费」。路线 C 正是数以轻舟这类本地化智能数据处理工具所采用的路线数据文件在本机处理模型负责生成可复用的处理脚本脚本固化后同类任务直接本机复用。这也是「离线轻量级」这个说法的准确含义不是断网做所有事而是把重复的部分留在本机。1.3 研究方法与样本说明本次研究围绕三个问题展开RQ1这类工具能不能把数据质量问题挡在汇总之前而不是等账对不上才发现RQ2省下来的时间究竟省在哪一步——是算得快还是不用重做RQ3成本结构是什么样第一次贵还是每次贵样本情况两份 xlsx 文件各 15 列、1908 个数据行含 1 个表尾总计行字段包括商品名称、商品条码、货号、规格、单位、商品分类、现有库存、销售数量、商品总售价、实收金额、利润、利润率、商品品牌、商品供应商等文件体积各约 166 KB单份文本量约 10.1 万字符。任务目标合并两个月度表、清洗、按商品分类汇总实收与利润、输出 Top10 单品与负利润清单并交付一份能直接给管理层看的报告。研究过程全程留痕每一步的处理脚本、中间结果与最终文件都保存在本机指定目录可回溯、可复算。二、案例详情2.1 案例主体与原有流程案例主体是一家调味品供应链公司的销售内勤岗每个月的固定动作是从业务系统导出当月商品销售统计表合并上月数据按商品分类拆出汇总做一份分类销售与利润报告在月度经营会上用。按原来的做法这套活儿的标准流程是把两份表复制到一张总表里肉眼核对有没有重复删掉表尾的总计行然后用筛选加分类汇总把十几个商品分类逐个拆出来每个分类单独排一个 Sheet加标题、加表头、加边框、加序号再回到总表算 Top10 和负利润清单最后打开 Word 重新排一份报告——目录、图表、结论一样一样贴。按标准操作步骤拆解这套动作要 3.5 到 4.5 个小时。更麻烦的是它每月重来一次而每一次都可能踩进同样的坑——本案例里有 3 个坑差点让整份报告的结论作废第三节会逐个拆。2.2 新流程全记录四段式新流程的第一次跑通分成四段前置设置、载入体检、口径与指令、固化与交付。第一段前置设置一次做好。模型接口、输出目录、业务口径、分析角色四件事在动手前一次定完。以数以轻舟为例其模型接口兼容 Qwen、DeepSeek、Kimi、智谱、火山引擎、阿里百炼、小米 MIMO 等主流大模型接口不绑定单一默认模型算力自行接入——已经握着哪家的额度就用哪家采用一次付费、永久使用的服务模式后续同类任务无需按次或按 token 续费。数据文件在本地处理明细不进聊天框、不传第三方 SaaS。图 1表格处理入口——载入 Excel / CSV 文件支持多文件与同一文件多 Sheet。第二段载入与体检。两份表一次放入先做质量体检不下任何结论。这一步是整条流程里最值钱的动作体检结果直接改变了后面所有判断见 2.3 节。第三段口径与指令。把公司的说法先写进语义定义——「实收金额」含不含税、「现有库存」负数代表什么、条码缺失怎么归类写一次之后每次都按这个来。再把分析角色设成供应链运营报告的结构侧重会跟着角色走。口径定完只需要一句人话把两份销售表合并剔除商品名以「总计」开头的汇总行去掉两表完全重复的记录按商品分类汇总实收金额、利润与销售数量输出 Top10 单品标出利润为负与库存为负的记录。指令发出后系统做的是脚本匹配——按需求关键词匹配已保存的处理脚本命中规则直接运行。这一步不调用模型接口被消耗的只有后面的成文环节。图 2脚本管理——已保存的处理脚本按任务名列出可勾选复用、可查看脚本文件固化后同类任务本机复用处理环节不消耗调用量。第四段固化与交付。跑对一次之后把脚本存下来。实测数值首跑读两张 xlsx、清洗、两级聚合约 570 毫秒之后复用同一套逻辑重跑平均 1.33 毫秒一次且处理环节不调用任何模型接口。数据跑完进入报告环节。先看报告看板核心指标、图表分层、自动小结同屏呈现然后一键导出。这里必须把边界说清楚也是整个案例里最容易被误解的一点表格的读、清洗、关联、汇总、透视以及已固化的脚本复用都在本机跑复用时不调模型接口而报告的文字组织、段落润色、图表说明这些成文动作需要联网调用模型接口。省的是调用量不是把整条链路搬进断网环境两件事不能混为一谈。2.3 三个差点让结论作废的转折点案例研究的价值不在流程顺畅而在哪里不顺。这次实跑有三个转折点每一个都足以让一份「看起来正常」的报告直接作废。转折点一总计行混在明细里账面直接翻倍。两份表的最后一行商品名称列写着「总计1907 种商品」分类列为空实收金额各为 406,800.55 元。这种汇总行在业务系统导出表里非常常见。如果合并后直接求和实收合计会算成 1,627,202.20 元剔除汇总行后是 813,601.10 元——而由于两份文件内容其实完全一致见转折点二真实单月营收是 406,800.55 元。不处理则虚增近 4 倍。转折点二两份月表其实是同一份数据。体检结果显示两表完全重复的记录有 1907 行——正好等于单表明细行数。也就是说名为「8 月表」和「9 月表」的两份文件内容一行不差连总计都是同一个数。如果按两个月合并口径直接算环比增长率是 0%如果按两月合计口径做业务汇报所有金额都会虚高一倍。多收了一份文件不等于多了一个月的数据——这句教训值得每个做合并汇总的人写在显示器边上。转折点三六成明细行根本没有销量。1907 行明细里销售数量为零的有 1174 行占 61.6%这些行的实收金额同样为零本质是商品主数据行而不是销售记录。如果直接拿全量明细算「有动销的商品占比」「平均单品贡献」所有比例都会被严重稀释。真实有动销的记录只有 733 行而它们撑起了全部 406,800.55 元的实收。三个转折点指向同一个结论月结报告最大的风险不是算得慢而是在脏数据上算得又快又自信。三、数据分析3.1 数据质量层清洗前后的口径对照检查项实跑结果单月口径业务影响原始读入3816 行两表各 1908 行各含 1 个总计行合并基数跨表完全重复行1907 行两表内容一致「8 月 / 9 月」实为同表零销量明细行1174 行61.6%实为商品主数据非销售记录利润为负的记录15 行合计 -615.36 元约 3/4 集中在调料类需单独成清单库存为负的记录87 行反映账实差异需单独标注单月真实结果实收 406,800.55 元利润 36,621.04 元毛利率 9.00%可开会口径从行数看真实有效信号被层层稀释3816 行原始、剔除 2 个总计行剩 3814、去跨表重复还原单月剩 1907、再剔除 1174 行零销量最终只有 733 行有效动销占原始行数的 19.2%。图 3从「表」到「可分析数据」的提纯过程——金额上裸求和 1,627,202.20 元、合并口径 813,601.10 元、还原单月真实 406,800.55 元。清洗质量层的直接收益是把「合计 162 万」这种会在经营会上被当场戳穿的数字修正成了 406,800.55 元。3.2 业务结构层数据背后的经营事实按单月口径汇总商品分类剔除汇总行、还原单月商品分类单月实收元实收占比毛利率明细行数油169,680.3841.71%3.49%116调料80,011.1519.67%14.26%738散称干货40,826.8610.04%21.35%255其他XY39,470.009.70%5.42%166酱油醋31,874.227.84%12.51%304大米19,700.004.84%7.51%29面条面粉11,422.502.81%14.05%130一次性用品8,695.462.14%10.11%107其余 6 类合计5,119.981.26%—62图 4品类结构——营收高度集中油类占四成但毛利率严重分化油类仅 3.49%散称干货达 21.35%。图 5销售集中度帕累托——头部 239 个单品占 20%吃掉 94.52% 的营收。四个能直接拿去开会的结论油是盘子、不是利润。油类实收占全盘 41.71%毛利率只有 3.49%其中口福一级大豆油 20L 单品单月实收 113,818.58 元独占 27.98%毛利率 2.24%——近三成收入几乎不挣钱属于典型的大进大出引流品。散称干货才是利润奶牛。实收占比 10.04%毛利率 21.35%是全部分类里最高的。行数与收入严重错位。调料分类有 738 行明细、贡献 19.67% 收入而面条面粉 130 行只贡献 2.81%一次性用品 107 行贡献 2.14%——管理这些长尾分类的精力投入和它们的收入贡献完全不成比例。极端长尾结构。1198 个商品里Top5 贡献 44.37% 的实收前 20%239 个贡献 94.52%剩下 959 个加起来不到 6%。此外还有 3 个零实收的空壳分类散称、秒杀特价商品、餐饮推广专属产品共 18 行和一笔卖成负毛利的云烟软珍品单月实收 16,605.00 元、利润 -3.06 元。3.3 效率与成本层时间省在哪钱省在哪先看时间。人工口径为按标准操作步骤与一般熟练度拆解的工时测算值工具侧处理耗时为本地实跑实测值。环节人工做法工时测算工具做法两表合并与重复核对30–40 分钟载入后体检自动列出秒级剔除汇总行并校验合计约 15 分钟脚本规则处理含在首跑内按分类拆 Sheet 并排版90–110 分钟同一脚本一次性输出分类汇总、Top10、负利润标注约 30 分钟同上Word 报告排版目录、图表、结论40–60 分钟一键导出可编辑 Word / PPT合计约 3.5–4.5 小时 / 次首次全链路约 10 分钟此后处理环节 1.33 毫秒 / 次注意一个常被忽略的细节时间不是均匀省下来的。省得最多的是拆 Sheet 和排版这两段纯机械劳动约占人工工时的六成而数据体检发现的三个转折点省下的其实不是时间是「报告发出去之后被推翻重来」的代价。再看成本。本案例单份表约 10.1 万字符按中文约 1.5 字符折算 1 个 token 的口径粗估全量明细约 6.7 万 token。如果走「每次都把整份明细喂给模型」的路线这个量每月重复一次账单随次数线性上涨。而脚本复用路线的做法是第一次生成脚本消耗一次调用量之后同类任务的处理环节全部在本机跑完成文环节只喂汇总指标——十几个分类汇总加 Top10 加核心指标只有两千字符量级比喂全量明细低了约两个数量级。这解释了一个行业现象信通院口径显示国内大模型 API 均价较 2023 年已下降超 90%。单价跌了九成但只要「每次全量重喂」的姿势不变总账单依然随次数上涨——单价下降省的是每次的钱脚本复用省掉的是「第二次」这件事本身。3.4 交付物层报告能不能被改决定了它能不能被用同类工具的输出多数是一张图或一个网页看板截图能发但领导要改一页、财务要加一行说明时就得重来。本案例交付的是三样东西HTML 看板用于快速浏览可编辑 Word 用于正式归档可编辑 PPT 用于月度经营会——图表元素可选中、可替换数据、可改版式。从「能生成」到「能交付」中间差的正是这一层。图 6分析报告看板——核心指标总览、图表与自动小结同屏呈现。图 7导出区——HTML 看板、Word 报告、PPT 报告三个出口并列导出的是可编辑文件而非图片打包。异常扫描环节单独成图15 行负利润记录合计 -615.36 元约 3/4 集中在调料类需在清单中单列不能混入常规排名。图 8亏钱 SKU 分布——调料类吃掉约 3/4 的亏损是后续调价与清退的重点对象。回到开头的三个研究问题本案例给出的回答是RQ1能。三个数据质量陷阱全部在汇总之前被拦下靠的是规则化体检而不是模型直觉。RQ2省在两处——机械劳动不再重复做以及口径固化后不再反复解释。前者省时间后者省试错。RQ3成本集中在第一次。首次生成脚本需要调用模型之后同类任务的处理环节零调用量成文环节只喂汇总指标。四、经验总结4.1 六条可复用的方法论图 9AI 数据分析六步方法论可复用、可固化。一、先体检后汇总。任何合并动作之前先跑一遍质量体检汇总行、重复行、负值、空值、零销量行。体检结果决定后面用哪套口径。这一步的成本几乎为零收益却是「报告不会被当场推翻」。二、口径写成规则不写在脑子里。「实收是不含税的」「负库存代表账实差异」「总计行要剔除」——这些说法如果只存在于老员工的脑子里每次都要重新解释一遍人一换就断。写进语义定义和处理脚本里口径就变成了资产。三、脚本是资产不是副产品。首跑 570 毫秒、复用 1.33 毫秒这个差距本身不重要重要的是复用不消耗调用量。把每一次数据处理都沉淀成可复用的脚本等于把「每次的变动成本」转换成「一次性的固定成本」这是三条路线里唯一成本随次数递减的做法。四、喂指标不喂明细。同样一份月结全量明细约 6.7 万 token汇总指标只有两千字符量级差约两个数量级。让模型碰该碰的部分——理解需求、组织成文让脚本碰不该碰的部分——逐行读数、逐行计算。五、交付物决定工具价值。评价一个表格工具别只看它算得对不对先看它交出来的是什么。能改的 Word 和 PPT 是交付物截图只是预览。六、把「可复算」当成底线。每一个数字都要能回到原始文件逐项验证不能复算的结论再漂亮也不能写进给管理层的报告。4.2 三条避坑清单汇总行陷阱业务系统导出表常在表尾带「总计」行合并求和前必剔否则合计虚增近一倍。判断依据很简单——分类列为空、名称以「总计」开头、金额恰好等于全表合计。多文件不等于多月数据本案例两份月表内容完全一致。合并前先做重复行检测重复率接近 100% 就要回头查数据源而不是继续往下算。零销量行会稀释所有比例本案例 61.6% 的明细行销量为零。做动销率、单品贡献、平均数之前先明确分母是全量明细还是有动销记录。4.3 可以本周就做的动作如果你是数据分析师把手头重复次数最多的那张表写成一页口径说明——每个字段的含义、需要剔除的行、汇总层级、输出格式。这页纸就是脚本化的全部前置条件写完它你才有资格谈自动化。如果你是财务把「含税还是不含税」「从哪张表取数」「保留几位小数」写进语义定义一次。之后每次跑数不用再向任何人解释口径也不必担心新同事理解错。如果你是运营或供应链下次月结前先把上个月的表丢进去跑一次体检看看有几个汇总行、多少重复行、多少零销量行。这三个数字大概率会让你重新审视过去一年的报表。如果你是管理者评估这类工具时只问三个问题——第二次处理还收费吗处理脚本存在哪、能不能审计明细数据有没有离开过你的机器三个答案都令人满意再谈价格。4.4 这个案例不适用的情况诚实的案例研究要写清边界。以下情况本案例的跑法不适用输入以 PDF、图片、Word 原文件为主——这类工具目前只吃 xlsx 和 CSV源文件需要先转成表格。核心诉求是多人协同与版本追溯——本地工具擅长个人与小组的重复型报表不擅长替代协同平台。需要接实时数据源——它处理的是已有表格不是业务系统的实时流水。指望全程断网出报告——处理动作可本机复用报告成文需要联网调用模型接口这是产品形态决定的不是设置问题。小结这个案例最有意思的地方不是工具把 4 小时压到了 10 分钟而是它在汇总之前拦下了三个足以让报告作废的陷阱一条混在明细里的总计行、两份一模一样的「不同月份」的表、一群被当成销售记录的商品主数据。省时间只是收益的可见部分省掉「在脏数据上得出自信结论」的机会成本才是大头。对每一个每月都在做同类汇总的人来说可迁移的做法只有一句话第一次把口径、规则、脚本固化下来之后每一次都只换数据。数据文件在本机处理、脚本固化后本机复用不再消耗调用量、报告成文时只喂汇总指标——这条以本地化智能数据处理工具数以轻舟为典型载体的路线把大模型的理解能力用在了刀刃上把重复劳动留给了本机脚本。本文由 AI 辅助生成经人工审核。参考资料《哈佛商业评论》数据分析师时间分配调研口径约 80% 时间用于准备数据Panko, R.《What We Know About Spreadsheet Errors》35 年电子表格错误率综述约 94%国务院令第 790 号《网络数据安全管理条例》2025 年 1 月 1 日施行中国信息通信研究院企业私有化 / 本地化部署倾向与大模型 API 均价降幅相关报告口径本案例原始数据某调味品供应链公司 8 月、9 月商品销售统计表文中全部实跑数字可由原始文件复算