备选标题（按我自己觉得点击欲排序）：
- 让AI写脚本分析几十万行数据，那些临时文件我踩了3个坑才清明白
- 为什么我不让AI往userdata里瞎写：几十万行数据分析的落地方案
- AI自己写脚本分析数据，临时文件到底存哪？我最后塞进了一张小表
那条帖子问的，其实不是「怎么分析」
前几天在社区刷到一条提问，说想把服务端数据丢给AI，让它照着列名自己写脚本，过滤、汇总出用户要的东西。思路是写个MCP把数据集拉下来存成jsonl或者xlsx临时文件，用resource link的形式连着列名、字段类型、条数这些元信息一起返给AI，AI拿到路径就开始跑。
听着挺顺，对吧。但发帖人后面那句话才是真痛点：文件写到哪里？
直接往userdata里塞，垃圾文件只会越攒越多，而且对话删了它也不会跟着删。
我看到这句直接笑出声，因为这就是我半年前趟过的水。当时我做一个让AI跑脚本做数据汇总的小功能，前两周demo跑得飞起，第三周打开工作目录一看，几百个 `tmp_20260812_final_v2_really_final.csv` 躺在那，我自己都分不清哪个是哪个对话生成的。
那一刻我才明白，让AI写脚本这事早就不难了，难的是它写出来的那堆中间产物，谁来管。
帖子底下的回复也挺有意思。有人说必须上duckdb，有人说别让大模型去处理大数据、它吃不消，还有人干脆说「让AI写个离线分析的数据库，把数据插进去再写SQL」。
这几句其实已经把方向点出来了：真正要分析的是逻辑，不是让模型去啃原始数据；而落地的关键，是给中间产物找个有秩序的家。
先划清楚边界：这不是大数据
说方案之前得先泼盆冷水。如果你的数据是真·上百万行还带着复杂join，那该上专门的引擎就老老实实上，别硬套。
我这篇聊的场景是单机、几十万行这个量级——CSV几十兆、内存装得下、Python几秒能扫完的那种。这个量级下你完全不需要分布式那套重家伙，需要的只是让AI写的脚本「可控地落地」。
把预期摆正了再往下看，不然容易被「百万数据」四个字吓得过度设计。我见过太多人一上来就搭一堆中间件，最后发现pandas读一遍就完事了。
坑一：别往一个共享目录里瞎写
我最早的错，就是让AI脚本往一个固定目录写临时文件。看着省事，实际是灾难。
因为每一轮对话、每一次重试，AI都可能生成一批中间文件，命名还全靠它临场发挥，结果就是目录越来越肿，没人敢删——你根本不知道哪个还在被引用。
后来我改成按会话隔离：每个对话开一个独立的工作区，脚本产生的所有中间文件都只落在这个会话自己的目录里。会话结束或者被删除，整个目录一锅端。
这一步其实靠平台的文件管理器就能理清楚，把「谁生成的、归谁管、什么时候能扔」这条线捋直，比你后面写一百行清理逻辑都管用。
原则就一句：临时文件的生命周期，要跟对话绑死，别跟目录绑死。
坑二：脚本到底放哪个环境跑
第二个卡了我很久的问题——AI写出来的脚本，在哪执行。本地开个子进程？
那你得管环境、管依赖、管它会不会把我机器写崩。这块我后来是直接用Python在线运行把脚本跑在一个受控的执行环境里，AI生成过滤汇总的代码，我把数据路径和元信息喂进去，它算完把结果吐回来，中间产物就落在那个会话的工作区，不脏我本地。
这里有个我一开始没想明白的点：AI不需要看到全部几十万行数据，它只需要列名、字段类型、条数这些元信息，就够它写出正确的脚本了。真正扫数据的是脚本本身，不是模型。
这跟社区里那句「分析的是逻辑而不是真正的数据处理」是一个意思。想通这层，你会发现token省了一大截，模型也不会因为塞进去几十万行就开始胡言乱语。
坑三：结果别丢一堆散文件，落进一张小表
这是我改动最大、也最舒服的一处。
以前我算完一批结果，随手存成 `result_xxx.json`，下次想复用或者对比，得挨个翻文件。翻到第三个我就崩溃了。
后来我干脆建了一张结构化的小表，把每次任务的元信息和处理结果逐条落进去：这批数据的列名是啥、字段类型、原始条数、用了什么过滤条件、汇总出来的关键指标、算完的时间戳,一行一条,清清楚楚。
这活儿交给SQLite再合适不过,单文件、零配置、几十万行毫无压力。想看某次任务到底处理了啥,打开SQLite编辑器直接看表结构和数据,不用再去猜某个散文件里装的是哪次的结果。
这也正好呼应了帖子底下那位说的「让AI写个离线数据库,插入数据再写SQL分析」——只不过我把「存结果和元信息」这件事也一并交给了同一张表来管。
从「一堆散文件」变成「一张能查的表」,体感差别巨大。以前排查一个结果对不对要翻半天文件,现在一条SQL就定位到了。
我自己那次是怎么串起来的
把上面三块拼一起,我用VicroCode跑了一下一个几十万行的CSV场景,流程大概是这样:
先扫一遍数据,把列名、字段类型、条数这些元信息抽出来,写进那张SQLite小表的一行,顺手拿到一个任务ID。然后把元信息（不是原始数据）连同用户的需求一起交给模型,让它照着写Python过滤汇总脚本。
脚本在受控环境里跑,输出的中间文件落在这个会话的独立工作区。算完把关键结果回写到同一行任务记录里,原始的临时文件因为绑着会话,该清的时候连目录一起清掉。
整个链路里,原始几十万行数据我碰得很轻,模型看到的永远只是元信息和结果,中间产物有明确的归属和寿命。没有满地散文件,也没有那种删不敢删的僵尸目录。
如果这套东西你想让别人也能用,平台的API端点托管可以把这条分析链路包成一个接口对外提供,别人传数据、拿结果,不用关心里面这堆脏活。这算是白捡的一层复用。
一个反常识的小结论
折腾完这一圈我最大的感受是:让AI分析数据,80%的工程量根本不在「让它会算」,而在「管好它算之前和算之后的那些文件」。前者现在模型基本白送,后者才是决定这功能能不能长期跑下去的地方。
如果你也准备做类似的东西,今天就能上手的一个最小动作:先别急着接模型,先建一张表,把「一次分析任务」需要记录的字段列出来——数据来源、列名、字段类型、条数、过滤条件、结果、时间。就这一张表,能帮你把后面80%的混乱提前挡在门外。
真别不信,我就是被那几百个 `final_v2` 文件逼出来的。