这一个月，但凡你关注Text-to-SQL或者"智能问数"这个话题，很难没刷到这股复盘风。8月17日到21日这一周，知乎上密集出现了《ChatBI退潮：AI问数这条路，到底哪里出了问题？》《ChatBI试点为什么会失败？三个真实客户复盘》《企业上线AI问数后，为什么业务部门还是不用？》《SQL执行成功，为什么答案仍然可能是错的？》这一连串标题。B站那边也一样：《企业级落地：DataAgent目前真正的难点是啥》拿了2.6万播放、两千多收藏，评论区高赞清一色在聊数据治理；《AI写SQL翻车实录：语法全对，数据全错》这种标题也开始变多。知乎上甚至有人直接问：AI现在都这么强大了，为什么chatBI还像是个玩具？这不是某一家公司翻车被围观，而是一整代产品在集体过"试用期考核"。把这十几份复盘、案例和评论区对完之后，我发现一个反直觉的共识：绝大多数失败，跟"模型不会写SQL"没什么关系。
翻车的方式，惊人地一致
先看点具体的。B站一位做数据分析的UP主记录过一次典型事故：AI生成的SQL语法完全正确、执行不报错、数字看起来也合理，但GMV是实际的2.8倍——根因是AI做了一对多JOIN，用户渠道变更历史把行数放大了，而这份数据已经自动同步进了管理层周报。哔哩哔哩另一份复盘里，NL2SQL把"新客"定义成"注册7天内用户"，企业内部标准是"首次下单30天内用户"，业务拿到数直接质疑整个系统。知乎再看试点层面的。观远数据复盘的三个客户案例很有代表性：一家集团客户上来就全量接入近千张数据集，表名有的用英文缩写、有的带空格、还有表名字段重名，随机抽样问答准确率不到50%；一家零售客户按传统BI思路配权限，结果80%的一线店长找不到问数入口，总部个别人反而能看全区域利润和薪酬，试点被安全部门叫停；还有一家经销商初始准确率70%左右，上线后没人运营，一个月后日常活跃用户不到初始人数的20%，最后得出结论"ChatBI不行"。知乎把这堆案例摆一起会发现：除了第一类"SQL对了但数错了"，其余几乎都不是模型能力问题，而是数据基础、权限设计和运营节奏的问题。模型只是把企业过去靠人肉经验掩盖的坑，一次性照了出来。
把数字排开：哪些是普查，哪些是厂商自报
这个圈子里流传着好几个数字，值得逐个标上出处，因为它们性质完全不同：“超过60%的企业ChatBI试点未达预期”，来自观远数据对自己落地项目的整理统计；“纯NL2SQL路线准确率仅60%-70%”，是帆软在FineBI Next发布会上给出的说法；“10家制造企业上线90天，员工自助问数率从27%提升到71%”，同样是厂商自报的成功案例。知乎知乎知乎至于"Text-to-SQL在中大型企业BI分析中渗透率破30%"，出自知乎文章转引的一份行业智能BI报告，报告原文我没核到；“实验室准确率95%，真实业务场景直接打对折”，则是一线工程师的个人复盘体感。
我的建议是：任何一个数字都不要直接当行业全貌用，包括本文引用的这些。但有意思的是，这些立场各异的厂商（有卖BI的、有卖语义层的、有卖开源方案的）和独立工程师，指向的方向却高度一致——瓶颈不在SQL生成这一环，而在SQL之前（语义、口径、选表、权限）和SQL之后（校验、解释、运营）。B站那个高收藏视频下，42赞的评论说，取数听起来简单，但是做好很难，用户意图理解和数据治理都是头疼的脏活。哔哩哔哩35赞的补了一句，这里最难的是数据治理，很多时候企业自己的表都乱七八糟。厂商的PPT会骗人，评论区里工程师的吐槽通常不会。
绕了一圈，行业又绕回了语义层
为什么SQL执行成功，答案仍然可能是错的？因为数据库只能验证语法和表字段存在，验证不了"收入"该用开票金额还是确认收入、“区域"该取注册地还是结算地、“上季度"该按哪个日期字段算。用一份复盘里的话说：真正危险的错误是"SQL正常、数据真实、结果合理，但业务含义错了”。所以有团队开始给每个答案建"证据链”——记录用了哪个版本的指标定义、哪几张表、哪条Join、哪个时间规则、真正执行的SQL和返回结果，让答案可以被追溯和复核。知乎工程上对应的做法，是SQL先过安全检查，再过语义二次审查，最后按PASS、REVISE、CLARIFY、BLOCKED四种分支处置，而不是一路绿灯直接执行。
这也是2026年厂商动作的主线：在LLM和数据库之间加一个结构化的约束层。有的叫语义层加确定性编译，有的叫BI底座Tools化，有的做多Agent校验、多路径并行投票。需要说明的是，“纯NL2SQL路线已被头部厂商普遍放弃"这个说法目前主要来自语义层路线厂商的叙述，还不能算行业定论；但方向上大家确实在收敛——问题不在于"用了LLM”，而在于"只用LLM"。知乎落到工程上，有团队甚至把表的语义就绪度做成S到D五级评分，B/C/D级的表先回去补字段注释再谈问数，流程里直接设STOP门禁。
不过社区里也有真实的反对声，而且值得认真听。那条17赞的评论说：数据要求确定性，这和AI的灵活性完全背离，“语义层、RAG、口径、数据治理做得越好，流程越固定，AI反而显得越傻，结果更像BI而不是AI”，甚至认为把AI变成文档SQL翻译器是巨大浪费，“还不如给配Codex，让它连数据库查文档”。哔哩哔哩这个分歧其实不是技术对错，而是产品定位的分歧：语义层解决的是"可信"，不是"聪明"。如果你要的是一个敢拿去做经营决策的取数入口，约束层是必须的；如果你要的是一个探索性的分析搭档，那是另一种产品，用评价取数工具的标准去评价它，自然会得出"玩具"的结论。知乎那篇《ChatBI退潮》里说的"查数和分析从来不是一回事"，指的也是这条分界线。知乎
先别谈准确率，先谈"拿什么题测"
这个圈子里最被滥用的词就是"准确率"。有篇选型分析说得很透：当一个纯NL2SQL产品说"我们准确率90%“，你得追问——用哪批题测的？换成你的真实业务问题还是90%吗？模型升级后之前测过的题还能复现吗？由于temperature、采样策略、prompt的微小变化都会影响输出，纯NL2SQL的准确率本质上是个统计值，不是可以回归验证的工程指标。知乎所以务实的团队都在自建小评测集：有人认认真真出了41道题让AI正式考了一次试，得了78分；有人在200多张表的电力问数系统上，靠表选择器、few-shot示例和校验重试三板斧把准确率从60%磨到85%，但复杂查询仍然只有60%，最后只能"简单查询自动化、复杂查询半自动化”。知乎知乎做法不复杂，但顺序很重要——先用自己的业务问题建题库，再谈选型和调优，而不是拿厂商的demo问题验证厂商的产品。评测也不只看最终答案，最好按环节拆：指标解析对不对、选表对不对、Join对不对、时间规则对不对，错在哪一环，补救方案完全不同。
三类人，现在分别该干什么
如果你正在选型，别只看功能清单，追问三个问题：第一，每个答案能不能展示中间产物——指标版本、所用表字段、Join关系、时间规则和实际执行的SQL，答不上来的，出了问题你连排查入口都没有；第二，指标口径变更时系统会发生什么，是静默出错还是有版本和校验机制；第三，权限和审计怎么落地，做过行级安全的团队都该想想：报表里权限是对的，AI问数会不会越权？知乎这三个问题的回答质量，比demo里回答得多流畅重要得多，因为智能问数不是用半年就换的工具，选定厂商后企业会持续投入数据治理、语义建模和团队培训，三五年很难切换。知乎如果你正在试点，避开那三个经典坑的办法其实很朴素：首次只切单一业务域、单个主题，试点人数控制在10到30人；接入的表统一梳理命名，尽量中文、别用缩写和空格、严禁表字段重名；权限按管理员、所有者、使用者分层配，别沿用传统BI的角色逻辑一刀切；从上线第一周开始看反馈后台，每周花一两个小时针对点踩问题优化知识库。知乎ChatBI不是一次性交付的项目，准确率是靠运营磨出来的，初始70%不丢人，扔下不管一个月掉到20%活跃才致命。
如果你在自研，优先级建议是：先上只读执行和SQL安全检查，有团队真被AI生成过DELETE语句，还好先EXPLAIN没真跑；再做错误反馈闭环，让数据库当裁判，把原生报错喂回模型重试；然后才是小评测集和语义层。知乎知乎别一上来就建全量语义层，那是把三年后的债提前借过来。元数据治理可以做成闭环：表注释变更触发校验、字典自动更新、置信度回升后再放开问数，小步滚动比大爆炸式建设现实得多。
接下来盯什么
三个信号值得继续观察：一是"语义层构建Agent"能不能把语义层从手工雕刻变成Agent治理加人工审核，这决定了语义层路线的实施成本曲线，已有厂商在把金融、制造、能源等行业的指标资产作为语义层初始资产往这个方向推。知乎二是"答案证据链"会不会成为产品标配，能展示推理链路和指标版本的产品，和只能吐数字的产品，会很快拉开信任差距；三是独立评测的扩散，CSpider消融实验、自建几十道题的评测这类方法越多，厂商自报数字独大的时代就越快结束。知乎
最后说回这股复盘潮本身。它不是Text-to-SQL的失败，恰恰是这个行业开始说实话的标志——Demo时代的叙事是"AI会写SQL了"，复盘时代的共识是"AI会写SQL只是入场券"。对真正在推项目的人，这可能反而是个好消息：问题终于被说清楚了，剩下的就是老老实实把数据变成AI能理解的样子。下次经营会上再有人问"这个数字怎么来的"，你的系统能不能把证据链拍在桌上，才是这一轮复盘留给每个人的真正考题。
