先说结论：AI做数据分析这件事，今年已经不是"要不要用"的问题，而是"哪些环节绝对不能撒手"的问题。
两天前刚出现一个标志性节点：在Text-to-SQL领域最主流的评测集BIRD上，模型ReViSQL-BIRD-K2.6通过16份候选答案投票的方式拿到了92.97%的执行准确率，首次越过92.96%的人类基线。知乎但仔细研究会发现两个边界：单次直接生成是91.37%，还没过人类线；而且评测集再接近真实业务，也和你公司那张口径混乱的表不是一回事。这个节点真正说明的是：执行层的门槛，正在被抹平。
这跟一线从业者的体感完全对得上。一位做数分九年的朋友说，他今年加起来写的SQL，没有过去一天的多，日常取数需求九成以上都是AI跑完的。小红书另一边，一位日常SQL占比很高的分析师专门写了篇复盘，结论是：AI能保证SQL"能跑通"，但只有人能保证"跑对了"，两者之间的差距，就是业务理解力的价值所在。知乎
两句话不矛盾，合起来才是真相：执行层被抹平了，判断层反而更贵了。问题在于，大多数人只学会了前半句，还没建立后半句的防线。我把最近知乎、小红书、B站、36氪上从业者的踩坑记录翻了一遍，发现翻车的位置高度重合，基本就四个地方。
第一，指标口径，最贵的坑。一位分析师要查"老用户GMV"，AI按字面意思理解成"订单序号大于1的GMV"，而他们业务的真实定义是"注册满30天的用户产生的非首单GMV"——两个口径，数值能差出20%以上。1的GMV。但我们业务的实际定义是"注册满30天的用户产生的非首单GMV"，这两者在数值上可能差20%以上。" data-highlight-text="这两者在数值上可能差20%以上">知乎指标口径是业务约定，不在代码里，不在表结构里，只存在于需求文档和团队共识里，AI天然拿不到。有工程师专门提出过"答案证据链"的概念，第一句就说透了：SQL能执行，只能证明数据库接受了这条SQL，不能证明它正确表达了业务问题。知乎
第二，数仓分层选择。同一个业务实体，在数仓里往往有ODS、DWD、DWS好几层表：做明细归因用DWD，看趋势用DWS，排查数据问题要回溯ODS。知乎AI不了解你公司的分层设计，会非常自信地挑一张"看起来对"的表，语法完全合法，跑出来的数也是错的，而且错得很安静。
第三，字段与逻辑幻觉。有篇专门梳理大模型SQL幻觉的文章，把它分成四类：结构幻觉（引用不存在的表和字段）、关系幻觉（JOIN语义连错）、逻辑幻觉（过滤和聚合条件写反）、性能幻觉（语法正确但能拖垮数据库）。知乎最危险的是第一种：AI会非常自信地使用一个表中根本不存在的字段名，生成的SQL语法完全合法，运气好直接报错，运气不好就关联到错误字段，输出一套看起来合理的错误结果。再往深一层，如果底层数据本身是脏的，AI只会更快地产出更漂亮、更有信心的错误结论——以前数据错了，分析师从原始数据一路看过来还能发现；现在AI直接从库里取数出报告，中间没有人的眼睛。
第四，合规边界。AI不了解哪些字段属于个人身份信息，不会主动脱敏，也没有数据权限的概念。在合规要求严格的公司，这一条不是效率问题，是红线问题。
那正确的姿势是什么？那位用了大半年AI写SQL的从业者给出了一个很稳的工作流，可以直接抄：定义问题（人）→生成初稿（AI）→审核逻辑（人）→优化迭代（AI）→验证结果（人）。知乎再配四个实操细节：一是把需求一次给全，业务口径、涉及的表和字段、筛选条件、输出格式一起喂给AI，输入越完整输出越靠谱；二是复杂查询拆开做，每一步确认后再进下一步，别在一个庞大的SQL里找问题；三是AI出稿后固定做三件事——查字段是否真实存在、核对口径是否和文档一致、抽样几条明细肉眼对一遍；四是高频场景沉淀成模板，同样的逻辑反复描述，既费token又容易跑偏。
最后说说为什么现在值得认真对待这件事。行业结构正在变：36氪最近翻译的一篇行业文章说得很直白——正在消亡的是被动的、请求驱动的分析工作流，以前分析师的输出是一条查询，以后是一个受控的定义。分析师脑子里的机构知识，一旦被编码进语义层，价值会比只存在脑子里时高得多。36氪小红书上那篇1500多赞的"老板催数据分析？我反手一个AI连招"也说明，会用AI的人，正在把效率变成自己的筹码。小红书
所以真正该担心的不是"AI会不会取代数分"，而是分化：能驾驭AI的人效率成倍提升，不能驾驭的人可能连错在哪都发现不了。给你三个可以继续观察的信号：你所在的公司有没有在建指标语义层；招聘JD里"熟练使用AI分析工具"出现的频率；以及你的日常工作里，"提需求、对口径、下判断"的占比是在上升还是下降。这三个信号，比任何焦虑帖都更能告诉你下一步该往哪儿走。
