朋友经营盲盒平台，要对订单数据做清洗和分析（消费时间、盲盒类型、单价、盈亏、出货率、流水等），数据还经常更新，希望搭一个他能自助复用、不必每次找人的流程。
第一个决策：不用大模型
用户原本想调大模型 API 来分析。我一行都没用，理由三条：① 清洗 + 分类汇总是确定性的数值计算，pandas 几行就准；② LLM 不可复现——同样的数据问两次可能给不同结果，这是财务分析的大忌；③ LLM 会编数字——让它算总流水，它可能把 91.9 万说成 90 万。LLM 唯一有价值的地方是「把结论写成人话」，但用户只要一份多 Sheet 的 Excel，所以连这一行 API 也省了。
这条分界我讲给用户听过：精确、可复现、纯算数的事用代码；需要主观判断、没有标准答案的事才用大模型。 财务分析显然是前者。
真正难的：揪出污染流水的充值订单
数据本身看着干净，但分析时发现一个致命的口径问题：有一批「未知」订单（名称和玩法都缺失）只占 2% 的笔数，却贡献了 52.5 万流水（占总流水的 57%），单抽均价高达 1181 元、平台盈亏却约等于 0。
拆下来真相是——这些是充值订单：玩法为空、付的是现金、赏品金额约等于实付 1:1 返还（用户充值拿平台币）。用户充值再用平台币去抽盒，如果把充值也算进盲盒流水，就是重复计算。判据是「真实的盲盒抽奖必有玩法」，所以把玩法为空的订单拆到单独 Sheet、从盲盒分析里剔除（但保留可查），加一个开关。剔除后真实盲盒流水从 91.9 万降到约 39.6 万。这种口径错误不会报错、数字看着还挺大，只有逐字段摸清业务含义才发现。
类似的还有两个：「是否出货」一开始想用赏品金额=0 判断，但所有订单的赏品金额都 >0（最小 0.1）——0.1 元是保底安慰返币，所以出货定义改成「赏品金额 > 购买数量 × 0.1」；优惠金额里有 88888 这种脏值（均值 1511 但中位数 0），设个异常阈值标记但不参与核心金额计算，核心一律以实付金额为准。
性能：为百万行换引擎
真实文件有 95.8 万行。我先造了 100 万行数据实测，发现 pandas + openpyxl 读要 2-3 分钟，换成 pandas + calamine（python-calamine，Rust 实现）只要 25.6 秒、内存 545MB。polars 还要额外装包、没必要。另外百万行明细不全量写回 xlsx（极慢、几十 MB、Excel 都打不开），单独导成 CSV，报告 xlsx 只放聚合汇总（100KB 秒开）。最终端到端 40.7 秒跑完 95.8 万行。
还提醒了用户一个隐患：xlsx 硬上限 104 万行（1048576），现在 95.8 万已逼近，撞上限会静默丢行不报错——建议导出系统优先导 CSV。
.bat 中文乱码的彻底根治
交付物里有个 run.bat（双击即用、自动装依赖找最新文件）。用户报有乱码。根因是 bat 存成了 UTF-8，但 Windows cmd 默认按 GBK 解析 bat 文件，chcp 65001 只改输出显示、改不了 cmd 解析 bat 本身的编码。
第一版我把 bat 转成 GBK 编码、去掉 chcp、用 CRLF 换行，.py 保持 UTF-8（Python3 默认 UTF-8 读源码不受 cmd 影响）。用户追问「有彻底根治的办法为什么不直接用」，于是彻底改：打包进 zip 的文件名全改英文（避免 zip/cmd 转换），运行时生成的中文名报告不经转换不会乱，明细 CSV 用 utf-8-sig（带 BOM）让 Excel 双击不乱码。中文编码在 Windows 上的坑，得从「文件名 + 文件内容编码 + 换行符 + cmd 解析」几个层面一起堵。
交付
5 个文件：analyze.py（核心引擎，口径 CONFIG 在顶部，支持 csv/xlsx、百万行）、run.bat（双击即用）、build_exe.bat（生成 Win10 免安装 exe）、README.md（傻瓜说明 + 口径解释）、requirements.txt。输出多 Sheet Excel + 逐笔明细 CSV。zip 约 30KB，故意不含真实订单和报告（业务数据）。真实数据跑出来的结论（94 天，注意「6 月数据」其实跨了 3 月到 6 月）：盲盒流水 3869 万、平台盈亏 970 万、毛利率 25%、出货率 7.92%，充值订单 2351 万已单独剥离。
小结
这个项目最能说明问题的不是技术，是判断：敢对「用大模型分析」说不（财务要的是可复现和精确），以及在搭流程前先逐字段摸清口径——结果揪出了「充值污染流水 57%」这个用户自己都没意识到的错误。工具做得再快，口径错了，整份报告就是错的。