2026年10月8日，Anthropic 在官方公告中发布了测试版本的Claude Dashboards和Claude Motion，据路透社报道，文档、幻灯片和设计工具也在同一天正式推出。用户在对话框中输入一些日常用语后，界面可以生成一个交互图表看板。技术人员第一次看到这样的演示时，往往会觉得对话式数据分析终于变得实用了。
从更长的时间尺度看，这已经是对话式数据分析十年来的第二次浪潮。图表渲染作为通用能力早已成熟，真正让一个看板能跑的，是后面算出来的聚合数据是否准确可信。
一个 AI 看板可不可信，要看它把这份信任托付给了谁。一种做法是提前把业务口径定死，让模型照着算；另一种是把查询过程摊开，让人自己去核对。前一种把责任交给定义口径的人，后一种把核对的活儿推回给看表的人。
自然语言转 SQL 不是大模型的特产。WikiSQL 与 Seq2SQL 论文在 2017 年就提出来了，Spider 评测基准论文在 2018 年也显示，当时最强的模型在没见过的数据库上跨库精确匹配率只有 12.4%，可见机器理解陌生表有多难。
在大模型兴起以后，这个问题反而更突出了。2023 年的 BIRD 评测基准论文显示，ChatGPT 在这个基准上的执行准确率只有 40.08%，而人类可以完成 92.96%。到 2024 年 11 月，Spider 2.0 评测论文把题目换成了真实企业的复杂数据库（它是 2018 年那个 Spider 的升级版，难度高得多），结果即便是当时最前沿的 o1-preview 智能体，执行准确率也只有 21.3%；同一个模型回到早期的 Spider 上，能拿到 91.2%。题目一换成真实企业，能力就现了原形。
甚至我们用来考核它们的标尺都不靠谱。2026 年发表在 VLDB 的评测分析里指出，BIRD 和 Spider 2.0-Snow 的标注错误率分别达到 52.8% 和 66.1%。测试集本身错漏百出，光刷榜拿高分，和企业实际用起来能不能顶事，完全脱节。
商业软件也一样。Tableau 在 2019 年上线的 Ask Data 就支持用自然语言问数（Tableau 产品回顾），ThoughtSpot 在 2023 年的发布通告里宣布接入 GPT-3 推出 Sage。但很快大家就撞上同一个坎：工具只会把话翻成 SQL，算出来的数字却对不上业务口径，前后打架。
做指标层的 AtScale 后来复盘过这段（他们自己卖指标层方案，有广告嫌疑）：第一代自然语言查询只会把用户的话翻译成 SQL，却不懂业务规则，导致口径打架、没人敢信，整条赛道在 2021 到 2023 年明显退了潮（AtScale 复盘）。卡住的从来不是写代码，是指标口径与可信度。
既然十年前的老办法老是卡壳，为什么对话式分析偏偏在 2026 下半年又一次集中爆发？归根结底，是四个支撑技术刚刚在最近完成工程闭环。
首先是模型具备了自主写代码、跑代码的闭环。2023 年 7 月 6 日，OpenAI 在 ChatGPT 更新日志中上线了 Code Interpreter，给模型配备了一个能够执行代码和验证数值的沙盒环境，让模型终于拥有了自主取数和算账的能力。
第二件重要的事是，输出结果变成了可以独立交互的工件。Anthropic 在 2024 年 6 月 21 日的 Artifacts 发布公告里推出了独立窗口呈现机制，紧接着在 10 月 24 日的代码分析工具说明里加入了对表格数据的直接处理。
再次是企业数据连接协议走向标准化。为让模型能统一接入数仓、CRM 和 SaaS 工具，Anthropic 在 2024 年 11 月 25 日发布 MCP 开源公告，推出 Model Context Protocol（MCP），构建一条标准化的安全通道。
最后是前端产品形态和协作机制的大融合。Anthropic 在 2026 年 1 月开放 Cowork 预览，3 月 12 日发布 自定义可视化介绍，4 月 17 日推出 Claude Design 公告，9 月 16 日通过 协作形态整合博客全面整合，至今用户已经建了超过 4500 万份文档、幻灯片和设计。
而竞品的节奏同样紧凑：OpenAI 早在 2026 年 9 月 10 日就发布了 OpenAI 数据智能体公告中的 Data agent，比 Anthropic 快了四周；10 月 7 日又发布了流式组件编译器的 GPT-6 发布说明。Anthropic 的官方账号在 10 月 8 日推出 Dashboards 和 Motion，也反映了技术成熟与竞争压力的共同作用。（官方社交平台动态）
对话实时生成看板在跨过门槛后，各家公司在确保数据真实性方面采取了不同的方法。
一条路是先把规矩定好，同一个词比如销售额，不同人的算法可以不一样（退不退款？未支付订单算不算？汇率按下单当天还是出库当天算？）。所以在数据库上面加一层，把业务规则和口径先统一定死，让模型只负责根据这些定义去做查询。这套集中管理口径的东西叫语义层。
这种设计思路强调可信度在定义和口径的选择上。因此，OpenAI的Data agent也采用了类似的策略，它利用的是企业内部已有的定义和指标，因此只保证能理解每个数字的来源是哪些证据，而不保证会展示SQL语句。其他数据平台和BI厂商也普遍采取这样的策略，微软在Copilot中加入了受管理的语义模型，而Databricks则明确提到，如果不给模型提供业务上下文，它的”数据智能体”的表现极差，甚至到了不可接受的程度。
另一个方向靠的是把过程摊开，代表是 Anthropic 的 Claude Dashboards。它给每幅图配一条自己的 SQL，点一下图上任意数字就能展开这条查询，角落还会显示数据最后更新的时间（入门指南）。按官方说法，看板默认只给自己看，分享出去后每个人用自己那份权限重跑一遍，看到的还是他本来就能看到的数据，不过这套权限模型还没有第三方穿透测试（The New Stack 转引官方）。同批推出的动画工具 Motion 也是用代码驱动画面、不生成视频，改起来方便（Motion 入门指南）。
Google 站在中间。它的对话式分析在给出答案前，会把推理步骤和生成的精确 SQL 一起亮出来，还标出每个结论的引用来源，同时让回答走自己那套受治理的建模层，最后把每次查询记进审计日志（BigQuery 公告）。既立了规矩，也留了痕迹。
Anthropic 则相对低调。它坦诚地声明，Dashboards 用于快速探索和即时问答，不会替代专业 BI，并支持一键对接 Grafana、Hex、Sigma 等分析平台（未来会加入 Looker 和 Tableau）（官方公告）。Sigma 在同日发布了对应的接入集成（Sigma 合作声明），将这一分工落到实处。
将查询摊开、点一点就能看到它是如何计算出来的，相比几年前那些黑盒，确实是一个进步。但它解决的只是能不能查，而不是要不要信。把 SQL 直接怼到业务人员面前，等于把挑错的活儿又丢回给了他：他用这个工具，本来就是不想读代码，现在却要他去判断这条查询的逻辑对不对（Omni 的批评）。要是每个数字回头还得自己验一遍才知道准不准，那这套工具到底替他省了什么？
但更麻烦的是，因为用的是大模型来自由生成 SQL，同一个问题每次得到的答案可能都不一样。dbt 做过一组对照实验：同一个模型直接写 SQL，准确率在 84% 到 90% 之间；一旦把查询统一到一个口径上，准确率就到了 98% 到 100%，几乎不出错（dbt 的评测）。dbt 自己也卖口径产品，所以数字要打折扣，但至少说明一点：飘的不是模型，是口径。
离现实企业越近，反差越大。学术测试集上模型八九成准，一落到企业没清洗的脏库，直接写 SQL 只剩一到三成，复杂的多表关联甚至归零（colrows 的断崖分析、promethium 的基准指南）。这些数字也来自卖口径的公司，要打些折扣，但和一线工程师的体感吻合：模型越自信，错了越没人看出来。
但这个行业其实已经用脚投票了。Gartner 把语义层列成 2030 年跟数据平台、网络安全并列的关键基础设施，还直说缺少治理的模型直接参与决策，短期内就会给公司带来财务或声誉损失（Gartner 趋势预测）；Forrester 干脆把语义层定义成整个数据应用生态的控制平面（Forrester 观点）。分析机构看重的不是那个聊天框。
回头看看，这场竞赛表面上在卷谁能让AI更快出图，实际上在比谁替数字的正确性兜底。立规矩的一派把责任交给定口径的人，摊过程的一派把责任推回给看表的人。两条路都不便宜：前者需要有人先把口径建起来，后者需要有人读得懂 SQL。选哪边，看你手里的数字有多重。只是找灵感、先摸个方向，怎么都行；要拿去汇报、决定花钱，那就得先问一句，这个数错了，谁来担。
Claude Dashboards 有没有补上语义层、行列级权限、审计和定时刷新，官方公开材料里一个字都没提，至今是未知数；至于准确率，两家其实半斤八两，Claude Dashboards 和 OpenAI 的 Data agent 都没公布能比的数字。谁能一边留住随手一问的灵活，一边啃下口径这块硬骨头，答案还没到。但有一点已经清楚：出图早就不值钱了，真正稀缺的，是那个愿意为数字负责的环节。