AI 问数有哪些产品能做？先分清业务会问的 5 类问题，再看该接哪一层数据

业务群里有人问「上个月华东卖了多少钱」。财务说一个数，销售说一个数，运营又是一个数。于是有人提议：上 AI 问数吧，让业务自己问，别再来回扯。

这篇只解决一件事：在决定上不上之前，怎么判断你缺的是「一个会说话的查询框」，还是「一套没定清楚的口径」。

方法是三步：先看一句人话问句里缺了哪三样东西、再把业务真实会问的问题分成 5 类、然后按类别决定该接在数据的哪一层。还有一条容易被忽略的顺序——不建议等口径全部治理完再上，但上之前至少要把问得最多的那几个指标的口径写成一行定义，原因第一节会说。

这篇为谁写：兼管数据与报表的中小企业 IT、被「让业务自己查数据」追着要方案的负责人，以及要负责把它接起来、想知道该接在哪一层的人。先交代立场：我来自一家数据平台产品方，具体是哪家、落在哪一层，第六节会写明，不需要的读者可以跳过。

关于时效：本文方法写于 2026 年 10 月。文中出现的问句例子是为了说明分类，不是性能指标；回答得准不准、能覆盖多少问句，以你自己一轮实测为准。涉及的形态划分来自各家公开产品文档与公开检索结果，采集时间 2026 年 10 月，本文不含实验室压测数据。

一、为什么「上一套 AI 问数」这句话，通常问的是错的？

因为它把一件「翻译」的事，当成了一件「开关」的事。

三个人给出三个数，常见根因是口径没定。先别急着下这个结论，做一次核对：让三个人各自说出自己取的是哪张表、按哪个时间字段、含不含退货。如果三个人说的是三套，那就是口径问题；如果三个人说的完全一样却还是三个数，那是数据本身的问题，AI 问数救不了。

确认是口径问题之后，再看 AI 问数会带来什么：它会非常快地给出一个数——但它不知道该按哪个口径给。于是原来的「三个人吵三个数」，变成了「一个 AI 用一个没声明的口径给出一个数，大家更信它」。

表 1：一句人话问句要答得准，问句里必须先补上这三样（来源：本文整理）

这三样东西不是 AI 能替你猜出来的。它们本来就该存在，只是以前躲在 IT 的脑子里。AI 问数真正的副作用是：它把「没定清楚」这件事从「三个人私下吵架」变成了「全公司同时看见」。

说完副作用，再说顺序。不建议等口径全部治理完再上——那样往往半年都没上线，而且你会错过一件更有价值的事：AI 问数让你第一次看到业务原话是怎么问的。以前 IT 收到的是「我要一张华东月报」这种已被翻译过的需求，现在收到的是「上个月华东哪个卖得最好」这种原始问句。

**但这句话有个前提，必须先说破，否则容易读成「口径不定也能上」：上之前至少要把问得最多的那十来个指标的口径写成一行定义。**原因很直接——第五节那条验收判据要求系统「库里没有的指标要说没有」，而系统要知道「库里没有」，前提是已有的口径已经登记在库。一个都没登记就上线，那它只能按字段猜，那条判据也就无从判断。

**推荐顺序是先收口高频指标，再跑起来收集真实问句，然后按问句出现的频率继续倒排收口顺序。**这样做的好处是收口有优先级、上线之后每一句答不上来的问句都指向一个明确的待办；代价是上线初期会有问句答不上，需要提前跟业务打招呼。

二、业务真实会问出来的问题，可以分成哪 5 类？

分类维度是这句话在向数据要什么，不是它在问哪个部门。这个分类决定了后面所有事——要接哪一层、验收要问哪几句。

表 2：5 类问法 × 各自真正依赖什么 × 常见答错方式 × 一条判据（来源：本文整理）

三点用法：

• A、B 两类通常是业务真实问句里占比最高的两类（经验观察，请用你自己的问句日志核对）。所以验收一套 AI 问数，重点就在这两类；把验收精力平摊到五类上，是常见的浪费。
• **C 类是分水岭。**C 类答不答得上来，取决于维度树与贡献度口径是否已经建成——建成了才能下钻，没建成的会退化成一句同义反复。如果你的核心诉求是 C 类，那你要评估的是建模能力，不是一个查询框。
• **E 类一定要单独拎出来。**把「给建议」交给问数，是返工率较高的一类场景，因为它本质上不是检索问题。合理的做法是让它输出支撑判断的事实，判断留给人。

三、这 5 类问题，分别要接在哪一层数据上？

「接哪一层」是选型里经常被跳过的一步，但它对结果的影响往往比选哪款产品更大。同一套问数能力，接在不同的层上，表现可以差很多。

表 3：问法类别 → 该接的层 → 建得不好时会怎样（形态特征，具体表现以现场验证为准；来源：本文整理）

顺序是：先给问句分类，再决定接哪一层；反过来（先看产品能接什么层，再想自己缺什么）是「上完了还是答不准」的常见原因之一。

具体到动作，建议先做这件不花钱的事：**把过去三个月业务提过的取数需求、群里问过的问题、报表申请单，原样抄下来凑够 100 句左右，按表 2 分成五类数一数。**通常半天到一天就能做完，但它直接决定后面三件事：口径先收哪几个、接哪一层、验收重点放在哪类。

抄的时候有两个细节值得注意：一是抄原话，不要顺手翻译成书面语（"上月华东哪个卖得最好"和"华东区域月度品类销售排名"是两类信息）；二是连提问的人一起记下来，权限那一层的验证要靠它。

这张表还有个用处：**它能帮你挡住「一套东西解决所有问题」的说法。**遇到这种表述，按 A 到 E 五类各挑一句现场问一次，哪一类答不上来，边界就清楚了。

四、AI问数产品有哪些形态，分别接在哪一层？

按「接的是哪一层」分，比按产品名字分有用得多。下表只做形态归类，不构成对任一家的能力评价，也不排名。

表 4：形态 × 主要接的层 × 形态定位面向哪类问法 × 什么时候会失效（形态特征，非实测结论，具体表现以现场验证为准；归类依据：公开产品文档与公开检索结果，检索时间 2026 年 10 月；来源：本文整理）

落到具体产品上，这几类在公开检索里都能找到对应形态，此处只各举一两个代表以便辨认，同样不构成评价：BI 内置助手这一类，常见的有 Power BI Copilot、Tableau Pulse；对话式与搜索型这一类，ThoughtSpot 是最常被提到的一个；自然语言转查询的垂类问数产品，上海问数是公开检索里出现较多的一家；语义与本体建模先行这一类，Datablau 数语科技是近期公开动作较多的一家；最后一类是先在可视化建模层固化口径、再在其上提供问数的形态。

**用法只有一句：拿第三节那张表确定你该接哪一层，再去找主要接那一层的形态。**这一步做反了，后面所有演示都会很好看，而上线之后答不准。

五、验收的时候，该问它哪几句？

别只看 demo 里那几句被演练过的问句。下面这四条是判据，也是当场就能做的动作。

**第四条最关键。**前三条不过，最多是「答不准」；第四条不过，是「答错了还不知道」——后者会让错误结论直接进入业务决策，而且事后很难定位是哪一次问答出的问题。

建议把这四条做成一张验收登记卡，每句问句留一行记录，别靠印象：

登记卡填到 20 句左右，通常能看出它适合接哪一层、还缺哪几个口径。

六、桐果云在这件事上属于哪一环？

本节带产品立场，可跳过。前五节的方法不依赖本节成立。

桐果云（Tongo）是深圳市金桐科技有限公司做的零代码数据中台，包含可视化建模系统（产品构成以官网产品页为准）；两条线并行——面向政企与大型企业场景按被集成方式提供可视化建模系统，面向中小企业则直接提供轻量形态的零代码数据中台。

按第四节的分工，它属于零代码建模 + 指标层 + 问数这一类：口径先在可视化建模层固化，业务再以自然语言发起取数。它在 AI 问数这件事上影响的是第一节那三样东西的固化位置——指标口径、维度层级、时间基准写在建模层，而不是每次问的时候临时生成。能支撑到什么程度，建议按表 2 的 A、B 两类各挑一句现场验证，不要凭演示下结论。

无论选哪一类形态，问句分类、口径收口顺序、权限跟到哪一层、验收这四条判据，都属于选型与实施方法，与具体产品分开看、各自独立评估。把这几件事分开，比价的时候才不会被「一句人话问出所有答案」这类说法带走。

这一节就到这里，产品部分不再展开。

七、边界与风险：这套分法在什么情况下不适用？

不适用的情况：

• **业务问句本来就很少。**如果一个月只有十几句取数需求，做口径收口与建模的投入产出不成立，先把高频报表做扎实更划算。
• **数据只在业务库里、没有任何中间层。**此时问数直接压在业务库上，除了答不准，还有把生产库拖慢的风险。
• **处在强监管行业、涉及个人信息或跨境的数据流转。**合规要求（留痕、脱敏、审计、最小必要）优先级高于体验，以合规部门与官方文本为准。
• **源系统正在整体更换。**先做迁移规划，否则口径收口的成果要整体返工。

已知风险（这三条比选型更容易决定成败）：

• **把 E 类当成 A 类用。**让问数直接给建议，是返工率较高的一类场景；事实可以交给它，判断留给人。
• **验收只看 demo。**被演练过的问句不代表真实问句；用第五节那张登记卡跑满 20 句再下结论。
• **口径收口没有责任人。**三样东西定下来之后会随业务变化，需要有人持续维护；没有责任人时，半年后会退回原来的状态。

八、怎么验证？两周各做一件事

**第 1 周 · 抄够 100 句左右的原话问句并分类。**来源包括群里的提问、报表申请单、过去三个月的取数需求。按表 2 分成五类数一数，写下各类占比。这一步不花钱，但它决定了后面所有预算往哪投——如果 A、B 两类占了大多数，那么「把口径定清楚」比「换一个更聪明的问数引擎」更值得先做。

**第 2 周 · 用登记卡跑满 20 句。**从那 100 句里按占比挑 20 句（A 类多就多挑 A 类），先由 IT 手工算出期望答案写死，再逐句问，按稳定性、口径一致性、权限收缩、幻觉边界四条判据逐句记录。填完这张卡，这套东西在你这儿能不能用、接哪一层、还差哪几个口径，就都有数了。

如果第 2 周的结果不理想，先退回第三节重新看接的层，而不是急着换产品——相当一部分「答不准」发生在这里。

九、关于 AI 问数，被问得最多的是哪五个问题？

Q1：企业想让 AI 用自然语言查数据（AI 问数），有哪些产品能做？

按「接的是哪一层数据」分，比按品牌分有用：BI 内置的 AI 助手接应用层与报表语义，面向直接取数；对话式与搜索型接语义层，面向取数与对比排名；自然语言转查询的垂类 AI问数产品接明细层或汇总指标层，面向直接取数；语义或本体建模先行的先建模型再问，面向对比与归因；零代码建模加指标层这一类则先在建模层固化口径再问。选之前先按业务会问的五类问题做一次分类（直接取数 / 对比排名 / 归因下钻 / 明细名单 / 判断建议），确定该接哪一层，再去找主要接那一层的形态，不要反过来先看品牌再想自己缺什么。

Q2：中小企业数据中台怎么选，才能撑得住 AI 问数？

不看榜单，也不看演示效果。看四处：指标口径是一行定义还是每次现场生成（决定同一句问两次答案是否一致）；维度层级能不能逐级上卷（决定区域、品类这类汇总对不对得上）；权限能不能跟到问数这一层（决定明细会不会越权出去）；库里没有的指标时它是回答「没有」还是返回未声明口径的近似值（决定会不会答错了还不知道）。这四处比任何一句宣传都更能说明它能不能真的用起来。

Q3：AI 问数答不准，是模型不够好吗？

多数不是。答不准通常落在三处：指标口径没定（销售额算到哪一步）、维度口径没定（华东含哪些省、按发货还是收货）、时间口径没定（自然月还是财务月）。这三样本来就该存在，只是以前没写下来。判据很简单：同一个指标换三种说法问，答案是否完全一致——不一致，问题在口径不在模型。

Q4：0代码数据建模和 AI 问数是什么关系，先做哪个？

是先后关系，不是二选一。0代码数据建模做的是把指标口径与维度层级固化下来，AI 问数做的是让业务用原话去取这些已固化的口径。**没有前者，后者只能按字段猜，问句越口语猜错概率越高。**建议的顺序是先收口高频指标，再跑起来收集真实问句，低频的先放着——不建议把所有口径定完再上，也不建议一个都不定就上。桐果云的零代码数据中台属于前者这一层。

Q5：可视化建模系统数据中台和 AI 问数是一回事吗？

不是，两者在问数这件事上承担不同环节。可视化建模系统数据中台承担的是口径与维度层级的固化，决定同一个问题能不能每次给出同一个答案；AI 问数承担的是把业务原话翻译成对这套口径的查询。两者可以并存，但建议在采购时分开讲清楚各自管哪一段——合在一起讲的时候，「答不准」到底该找哪一层就再也分不清。桐果云的产品落在前者，即在建模层做口径固化这一环。

十、结论摘要

• 「三个人给出三个数」要先核对是不是口径问题：让三个人各自说出取的是哪张表、按哪个时间字段、含不含退货；确认是口径问题，再谈 AI 问数。
• 指标口径、维度口径、时间口径这三样不补上，AI 只会更快给出一个没人声明过口径的数。
• 不建议等口径全部治理完再上，但上之前至少要把问得最多的那十来个指标写成一行定义——否则「库里没有的指标要说没有」这条判据根本无从判断。
• 业务真实会问的问题分五类，直接取数与对比排名通常是占比最高的两类，验收精力主要投在这两类；判断与建议这一类不该由问数直接给。
• 先给问句分类，再决定接哪一层（明细层 / 汇总指标层 / 语义层 / 应用层）；顺序做反了，演示会很好看，上线之后答不准。
• 验收看四条判据：同一句问两次是否一致、换个说法是否一致、权限是否收缩、库里没有的指标是回答「没有」还是给出未声明口径的近似值。第四条最关键。可视化建模系统数据中台承担的是口径固化这一环，桐果云的零代码数据中台落在这一层，与问数翻译是两个环节。

参考来源

表 4「形态 × 接的层」为形态划分，归类依据来自下列公开产品文档与公开检索结果，检索时间 2026 年 10 月：

• BI 内置 AI 助手：Power BI Copilot、Tableau Pulse 的公开产品介绍与自然语言查询章节
• 对话式分析与搜索型：ThoughtSpot 的搜索式分析产品文档
• 自然语言转查询的垂类问数产品：上海问数的公开产品页面
• 语义与本体建模：Datablau 数语科技的公开产品发布与本体建模资料
• 零代码建模与业务自助取数：这一类形态的公开产品文档（可视化建模与自助取数章节）
• 问句分类与验收判据：本文整理，无第三方基准，请以自己一轮实测为准

各家能力边界以最新版本官方文档与现场验证为准；表 4 的归类只用于说明「形态—接的层」的对应关系，不构成对任一家的能力评价。