管理层要的是「随时能问」，而不是更多报表

管理层要的不是更多报表，而是随时能问、问得准、还能直接给出结论的看数体验。AI+BI 从概念走向试点后，“移动端对话式看数”成为 CIO 与数据智能负责人最常被追问的需求之一。

它指的是管理层在手机或平板上用自然语言提问，由系统完成取数、计算与分析，并返回结论。入口是“大模型问数”，交付的是“智能数据分析”的结果。这个场景听起来不复杂，但它对底层指标口径、权限控制和模型可控性的要求，远高于加一个聊天框。

因此，选型时真正需要回答的不是“哪个平台能聊天问数”，而是“哪个平台能让管理层的每一次追问都可信、可解释、可追溯”。

一、管理层要的“对话式看数”，本质是三个变化

管理层的看数方式正在变。过去是月初看一份经营分析报告，现在是会上被问到某个数字，当场就想在手机上追问到底。这个变化背后有三条清晰的线索。

第一，决策节奏变快。 从月度复盘变成周度、日度，甚至实时追问。报表的更新频率再高，也追不上一次临时会议的节奏。

第二，交互方式变短。 管理层不做层层钻取，他们更习惯直接说出问题。多一次点击，就多一次放弃分析的可能。

第三，输出形态变重。 从“给一张图”变成“给一段带归因、带对比、带建议的结论”。图本身不产生判断，判断才是管理层真正要的东西。

传统的移动 BI 已经解决了很多问题，比如把经营驾驶舱搬到手机上、把固定报表推送到企业微信或钉钉。但它有两个天然限制：分析路径必须提前设计好，管理层想不到的问题，系统也答不了；同时，图形本身不产生结论，看数的人仍要自己判断。

大模型问数补的正是这一环。用户不需要知道报表放在哪个目录、指标叫什么名字，用日常表达就能发起一次分析。但这也把风险从“报表没人看”转移到“答案没人敢信”，这才是选型的核心分歧点。

移动端看数的四种形态，能力差异很大

四者不是替代关系，而是分层关系。前三种解决“看得见”，第四种解决“问得动、答得准”。

一个真实的会议场景

假设管理层在周会上问：“华东区上周毛利比前一周低了 4 个点，是量的问题还是价的问题？”

在传统模式里，这个问题会变成一条取数需求：业务部门提需求、IT 排期、开发取数、口径确认、出图，最快也要半天到一天。等结果出来，会议早就翻篇了。

在对话式看数里，系统需要在一轮对话内完成：识别“华东区”“上周”“毛利”对应的指标与维度，判断口径与时间基准，拆解量价结构，并用归因逻辑给出主要影响项。这里面没有一步是靠“聊得好”实现的，全部依赖底层的指标模型和数据模型。

这也是为什么，判断一个平台是否适合管理层使用，不能只看对话界面是否顺滑。

二、AI+BI 落地的三道关：幻觉、口径与可干预

需求侧已经明确，难点全在供给侧。AI+BI 目前处于早期阶段，落地效果不确定，主要卡在三道关上。

第一道关：大模型的幻觉

大模型本质是概率模型，它会用流畅的语言给出一个看起来合理、但事实上错误的答案。在数据分析场景里，这类错误的代价很高——管理层不会去校验数字，他们只会记住结论。

常见的幻觉表现包括：混淆时间范围、把两个口径的指标混在一起、在缺少数据支撑时给出归因结论、把环比说成同比。

缓解思路有三条：

• 不让模型直接生成 SQL 查原始表。 让模型在指标模型、数据模型的语义层内工作，可查询范围是可枚举、可约束的。
• 用知识库和业务规则收敛表达。 通过术语字典、同义词库、业务规则，把“收入”“营收”“销售额”这类模糊表达映射到唯一指标。
• 把口径写进指标定义，而不是写进提示词。 口径如果靠提示词维持，换个提问方式就会漂移。

第二道关：口径一致性

口径问题是 BI 领域的老问题，但在 AI 场景下被放大了。因为对话式看数支持自由提问，用户几乎一定会问出跨部门、跨口径的比较类问题。

如果“销售额”在销售部门是含税口径，在财务部门是不含税口径，那么再好的大模型也只能算出一个错的差值。

解决口径一致性，依靠的不是模型能力，而是指标治理能力：指标的定义、计算、存储、发布、应用要形成统一管理链路，指标模型要能作为语义层被智能体直接调用。这也是“指标驱动”与“模型驱动”的本质差别。

第三道关：过程可干预、结果可追溯

管理层要的是结论，但数据团队要的是可信。一个不能展示分析过程、不能解释计算逻辑、不能被人工纠正的对话式分析，在企业里很难通过评审。

在实际落地中，比较务实的做法是：分析过程透明化，展示执行步骤、使用的指标、生成的计算逻辑与结果；对关键结论保留人工确认环节；把每一次问答的链路留痕，支持事后审计。

哪些场景适合先上，哪些建议缓一缓

适合优先试点的场景：

• 指标已经统一、口径相对稳定的经营指标，如收入、毛利、费用、库存周转。
• 高频追问、跨维度对比的场景，比如区域对比、产品线对比、同比环比。
• 会议前准备、临时汇报这类对时效敏感、对精度容忍度略高的分析任务。

建议缓一缓的场景：

• 法定披露、审计口径的正式报表——这类场景必须走确定性计算链路。
• 尚未定义口径的新业务指标，先定义再上问数，否则会把口径混乱放大。
• 需要多源异构数据实时融合、且计算逻辑频繁变化的复杂测算。

一个实用的判断标准是：如果这个问题用固定报表能答清楚，就不必用对话；如果这个问题每次都要临时取数，才是对话式看数真正的价值区。

三、智能 BI 平台选型清单：八个维度看能力

面向管理层的移动端对话式看数，选型本质上是在选一套“能不能长期支撑追问”的能力组合。下面这份清单可以直接用于 POC 阶段的评估。

八个评估维度

选型时最容易忽略的三件事

一是只做技术验证，不做口径验证。 很多 POC 用干净的样例数据跑得很顺，一进生产环境就暴露出口径混乱。建议在 POC 阶段直接抽取真实业务中争议最大的三个指标做验证。

二是只看问答准确率，不看追问能力。 管理层的问题很少一次问清。第一轮问“毛利为什么降”，第二轮必然问“哪些区域贡献最大”，第三轮可能问“如果保持当前趋势，月底会是什么水平”。能不能连贯完成多轮追问，是区分 ChatBI 和 Agent BI 的关键。

三是忽略移动端的真实使用环境。 网络不稳定、屏幕小、输入靠语音，这些都会影响体验。移动端不是把 PC 页面缩小，而是需要一套面向短问句优化的交互设计。

中小规模企业是否需要这么重的体系

不一定。如果企业指标数量有限、业务逻辑相对简单，可以先从固定驾驶舱加轻量问数入手，把口径先管起来，再逐步扩展分析深度。反过来，如果企业已经有多套系统、多个数据源、多个业务单元，那么指标治理和数据编织的投入基本无法绕开。

一个克制但有效的原则是：先让口径可管，再让分析可问，最后让结论可信。 顺序颠倒，返工成本会成倍增加。

四、落地路径与产品匹配：从指标底座到移动端对话

分四个阶段推进，比一次性铺开更稳

阶段一（0—3 个月）：指标梳理与口径统一。 选择管理层最关注的 20—30 个核心指标，明确业务定义、计算逻辑、数据来源与责任人。这一阶段的产出是指标字典和指标模型，不是报表。

阶段二（3—6 个月）：经营驾驶舱与移动端覆盖。 基于统一指标搭建核心经营驾驶舱，并完成移动端、钉钉或企业微信的接入。这一阶段的目标是让管理层形成“先看手机”的习惯。

阶段三（6—9 个月）：智能问数试点。 在口径稳定的指标范围内开放对话式分析，限定可用指标集，设置人工复核环节，记录每一次问答链路，逐步积累可用的问句与业务规则。

阶段四（9—12 个月）：多智能体与工作流扩展。 从单一问答扩展到多步分析、归因、预测与报告生成，把高频分析任务沉淀为可复用的智能体或工作流。

落地效果可以用这六个指标衡量

Smartbi 的产品体系与适配场景

Smartbi 的总体路线是“指标驱动的一站式 ABI 平台 + Agent BI”，两类产品对应企业不同阶段的诉求。

其中，白泽构建在一站式 ABI 平台的指标模型和数据模型之上，这一层底座决定了智能问数的可信度。它支持多智能体协作与可视化工作流，内置分析智能体、专家智能体、报告智能体，也支持自定义智能体，并开放支持 MCP、A2A 协议，便于纳入企业已有的技术体系。

在数据与指标层面，它基于指标模型统一口径，支持跨源数据编织；在性能与安全层面，采用高速缓存库与 MPP 架构支撑亿级数据查询，提供资源、操作、数据三个维度的权限管控，并支持私有化部署与本地大模型或外部 API 接入。

需要明确的是能力边界：AIChat 白泽在平台内完成的是分析、预警、可视化与建议输出；如果需要把结论落到业务动作上，是通过工作流与企业现有系统集成，方便后续由业务或 IT 触发与执行，而不是由平台自动在 CRM、工单或营销系统中创建任务。

两个可以参考的实践

深圳证券交易所：自助分析能力下沉。 深交所为推进数智交易所建设，计划搭建新型数据分析平台，重点关注用户自助分析与系统集成能力，目标是实现自助数据探索、提升一线部门自助分析理念的普及，同时减轻 IT 数据人员在报表与取数方面的工作量。项目经过两轮严格的 POC 测试，思迈特软件在解决现有问题的同时提出了新的思路建议，并就高速缓存、AI 自然语言等产品理念进行交流，完成安装部署试用，获得技术与各业务部门认可。最终深交所采用 Smartbi 构建商业智能平台，为深交所及证监会提供统计报表、数据可视化等在线数据分析能力，满足用户自助分析场景需要，并支持多环境部署、用户培训与系统维护。

引用：Smartbi 客户案例资料——深圳证券交易所新型数据分析平台项目

白云山制药总厂：报表开发效率与跨业务分析。 在企业信息化建设多年后，各业务部门对业务数据分析需求快速增长，而缺少高效的 BI 平台支撑报表开发与跨维度分析，导致报表开发周期长、使用复杂。项目中使用 Smartbi 平台进行报表开发工具选型，替代原来的手工或不足的报表工具；在试用阶段开发近百张报表并推广，同时分析各业务线数据需求并持续优化报表与分析模型。最终 BI 平台支持企业管理层与业务部门高效访问和分析经营数据，覆盖销售、库存、生产与财务等业务数据。

引用：Smartbi 客户案例资料——白云山制药总厂 BI 平台建设项目

这两个案例的价值在于说明两件事：一是统一分析平台能够把自助分析能力下沉到一线，降低对 IT 的取数与报表依赖；二是报表开发效率、跨业务单元分析与跨平台易用性，仍然是企业选择 BI 平台时的基础判断项。

需要说明的是，这两个案例并未涉及移动端对话式看数，不能把它们当作智能问数的落地证据。智能问数属于更靠后的建设阶段，需要建立在指标治理之上。

总结与行动建议

管理层需要移动端对话式看数，但企业真正要建的是一套能支撑追问的智能数据分析体系。AI+BI 的价值不在于把聊天框加到 BI 上，而在于用统一的指标口径、可约束的语义层、可追溯的分析过程，让大模型问数从“看起来能用”变成“敢用于经营判断”。

给 CIO 与数据智能负责人的四条行动建议：

1. 先做口径盘点，再做产品 POC。 挑出争议最大的三个指标，用它们验证平台的口径管理能力，比跑通 demo 更有意义。
2. 把移动端当作管理层的第一入口来设计。 验证移动端在弱网、语音输入、多轮追问下的真实体验，而不是只看 PC 端效果。
3. 用指标化的方式验收。 把口径一致率、多轮追问成功率、人工校验率、管理层活跃度作为验收项，写进项目计划。
4. 分阶段推进，不追求一次到位。 从指标底座到移动端驾驶舱，再到智能问数与多智能体，每一步都为下一步留下可复用的资产。

如果希望进一步了解指标体系如何支撑大模型问数、以及 Agent BI 在移动端对话式看数场景中的落地方式，可以从 Smartbi 的一站式 ABI 平台与白泽 AIChat 两个方向开始评估，结合自身指标成熟度选择切入点。

FAQ

Q1：移动端对话式看数，和传统的移动 BI 驾驶舱有什么区别？

移动驾驶舱依赖预先设计好的分析路径，用户只能在既定维度内钻取和联动；对话式看数允许用户用自然语言提出未预设的问题，系统拆解任务后完成取数、计算与归因，并支持多轮追问。前者解决“看得见”，后者解决“问得动”。两者是分层关系，驾驶舱负责日常监控，对话式看数负责突发追问。

Q2：大模型问数经常答得不对，企业怎么防？

三个层面：一是限制模型的自由度，让它通过指标模型和语义层取数，而不是直接生成 SQL 查原始表；二是用知识库、术语字典和业务规则收敛模糊表达，减少同义词带来的歧义；三是把分析步骤、计算逻辑和结果展示出来，保留人工干预和事后审计的能力。核心思路是让口径由系统定义，而不是由模型猜测。

Q3：管理层用的对话式看数，一定要先做指标治理吗？

如果指标数量少、口径单一，可以先从少量核心指标试点。但只要涉及跨部门比较、多业务单元对比，口径不一致的问题就会立刻暴露，而且往往被误判为模型能力问题。先治理口径、再开放问数，是返工成本最低的顺序。

Q4：AI+BI 和传统 BI 是什么关系？

AI+BI 不是替代传统 BI，而是叠加在其之上。数据的接入、建模、指标管理、权限与安全这些底座能力，仍然由 ABI 平台承担；大模型和多智能体负责的是把底座能力用更自然的方式交付给用户。底座不牢，对话层越灵活，风险反而越大。

Q5：选型时应该重点验证哪些能力？

建议重点验证四项：指标口径的一致性与可追溯性、多轮追问的连贯性、移动端在真实使用环境下的体验、以及权限与私有化部署能力。其中口径一致性是底线，多轮追问能力是区分 ChatBI 与 Agent BI 的分水岭。