在最近为亿问进行产品架构设计的无数个深夜里,我时常会停下来反思我们正在做的事情。
在这个大语言模型(LLM)和AI智能体(Agent)技术以天为单位迭代的时代,我们对于企业商业智能(BI)的想象,似乎仍然被困在上一个时代的遗迹里。
除去 ChatBI 本身 NL2SQL 的尝试以外,似乎大家都还是沿用着传统BI工具的那套解题思路在前行——必须得有个能拖拉拽、甚至支持中国式报表的Dashboard看板开发能力,才能配被叫做ChatBI,才能被称为 Data Agent。
我觉得这个是不对的。
不瞒各位,我自己越用 Dashboard 我越觉得鸡肋 —— 这玩意真的能给企业经营指导带来输入性的价值增长么?
所以一个极其大胆甚至有些离经叛道的想法开始在我脑海中盘旋:商业智能软件,就真的必须是用传统BI工具引以为豪的大屏和各种固定样式的图表拼凑而成的Dashboard(仪表盘报表)来展示吗?

在今天这个瞬息万变的商业环境里,Dashboard上那些精心排版、却永远滞后于业务发生时间的信息,真的还能像我们预期的那样,为企业经营管理者提供精准、快速、直观的决策指导吗?
事实上,如果我们剥开“数据可视化”这层光鲜亮丽的外衣,深入到企业真实的运作肌理中,困扰万千职场人的现状不就摆在我们面前么?
为了应对高层汇报,将大量宝贵的时间和精力耗费在制作一份精美的PPT、调整字号和对齐图片上一样,数据团队也正深陷在“制作精美Dashboard”的泥潭中。
我们把时间花在了“怎么展示更好看”上(有可能只是为了满足被汇报对象的个体审美),却忽略了BI的核心本源——更为有用的、更为迅速的精准数据解析与归因推演。
站在亿问产品负责人的角度,我认为Data行业在汇报和决策这件事情上,已经到了必须再往前走一步的十字路口。
本篇我想要探讨的,不仅仅是如何把图表画得更漂亮,而是如何彻底摒弃传统Dashboard的僵化形态,去迎接行为可交互、内容更丰富、格式更自由的HTML+CSS+JS动态生成形态(Generative UI)。
而在这一切华丽的前端演进之下,我们又必须守住数据准确性的绝对底线——利用 NL2LF 和语义数据库,将AI的幻觉扼杀在摇篮里。
这是一场关于企业决策链路的深度重构。
要理清这其中的逻辑,我们需要先从历史中寻找答案,看看那些曾经无比辉煌的技术,是如何一步步沦为阻碍效率的绊脚石的。
在软件工程的发展史上,有一个非常著名的技术演进案例,那就是数据库“存储过程(Stored Procedures)”的兴衰。理解了存储过程的命运,我们就能看清今天BI Dashboard的结局。
在二十世纪九十年代和本世纪初,企业级应用开发极度推崇存储过程 。在那个网络带宽有限、云计算尚未普及的年代,将复杂的业务逻辑、数据提取规则和计算步骤直接封装在数据库内部,似乎是一个完美的解决方案 。它减少了数据在网络中的传输,提升了执行效率。
然而,随着企业业务规模的指数级膨胀和现代软件工程理念(如微服务、CI/CD)的兴起,存储过程的致命缺陷暴露无遗:它导致了业务逻辑与底层数据存储的极度耦合 。
存储过程变成了一个庞大且难以维护的“黑盒”,当业务需求发生微小变更时,开发人员不得不在成百上千行的SQL代码中寻找逻辑,这种不透明性极大地增加了系统的脆弱性和维护成本 。
最终,现代数据栈(Modern Data Stack)通过计算与存储分离、将业务逻辑上移至代码层,果断地将这种上个世纪的历史产物扫进了故纸堆 。
今天,当我们审视企业中泛滥的BI Dashboard时,会惊讶地发现:它完美复刻了存储过程当年的困境。
传统的Dashboard本质上是将“数据查询逻辑”和“前端展示视觉”进行了深度耦合。一个大屏上的柱状图,其背后往往死死绑定着一段特定的SQL查询和固定的过滤条件 。这种设计在应对静态的“监控”需求时或许有效,但决策者的思维是跳跃的、发散的。

当一位企业高管在Dashboard上看到“华东区本季度利润率下降了15%”时,这块大屏的使命就结束了。因为它只能回答“发生了什么(What happened)”,却无法回答决策者紧接着冒出来的疑问:“为什么会下降(Why it happened)?” 。
是因为某个核心客户的流失?是因为供应链成本的上升?还是因为营销费用的错配?
面对这些追问,Dashboard是沉默的 。
高管只能被迫离开这个精美的界面,转而去给数据分析师发IM信息,要求拉取新的维度数据。数据团队接到需求后,又开始编写新的查询逻辑,甚至制作一个新的Dashboard页面。
当然,很多企业管理层用各种大屏、Dashboard,仅仅只为了满足个人的情绪价值——炫酷的未来感。
所以你一定听过一个时髦的名词:领导驾驶舱。
久而久之,企业内部衍生出成百上千个相互孤立、指标定义冲突的仪表盘,形成了业界痛恨的“Dashboard蔓延(Dashboard Sprawl)” ,实际上这不仅造成了信息过载,更导致了事实上的“决策瘫痪” 。
如果存储过程因为逻辑耦合与难以维护被历史淘汰,那么非要一味兼容这种僵化模式、做着重复且脏乱活儿的传统BI Dashboard,为什么不能被抛弃?
如果放弃了Dashboard,企业内部的经营分析和汇报应该采用什么形态?在寻找这个答案时,我们不妨看看那些对沟通效率有着极致苛求的顶尖科技公司是如何做的。
这让我们回到了你在开头提到的那个现象:许多企业为了汇报,把大量时间耗费在PPT的排版上。PPT和Dashboard一样,是一种“以展示者为中心”的单向输出工具。它通过提炼几个简短的Bullet Points(要点)和堆砌一些图表,很容易掩盖掉业务逻辑中的致命缺陷。
早在2004年,亚马逊创始人Jeff Bezos就敏锐地察觉到了PPT对深度思考的破坏,并在公司高管会议中全面禁用了PPT 。取而代之的,是要求提案者撰写结构严密、逻辑完整的“6页纸备忘录(6-pager memo)” 。
在会议的前20分钟,所有人保持静默,仔细阅读这份充满完整句子和深度因果推演的文档 。这种方式强迫汇报者把业务逻辑想透彻,也让阅读者能够在一个高信息密度的载体中进行深度思考 。
无独有偶,字节跳动在内部沟通中也掀起了一场效率革命。他们摒弃了传统的汇报方式,全面推行基于飞书(Lark)文档的“同频会议” 。会议同样从静默阅读开始,参与者在阅读多维表格和深度文档时,如果遇到问题,可以直接在文档的上下文中进行批注和异步讨论 。
这种做法极大地消除了“人际沟通的中间件”,将原本可能需要几个小时的汇报和争论,压缩到了精准的上下文对齐中,极大地提升了企业的沟通效率,降低了成本 。
亚马逊和字节跳动的实践,为我们在BI领域的产品设计点亮了一盏明灯:最高效的商业决策载体,绝不是华而不实的静态图表,而是具备丰富上下文、支持深度逻辑推演、且行为可交互的“动态文档”。
既然PPT只是一种展示工具,如果企业内部实在喜欢PPT的阅读习惯,那我们为什么不能用HTML+CSS和JS,在前端动态渲染出一个类似PPT或者流式文档的交互界面呢?
这就引出了我们将在亿问产品演化上的大刀阔斧的尝试:
抛弃固定面板,迎接Generative UI。

这里的 Generative UI 不单单是图表,还应该能是更进一步的深度洞察报告。
但在我们尽情想象前端UI的无限可能之前,必须先勒住狂奔的野马,回到一个极其冷酷且严肃的核心点上:
无论前端的演示多么精美或多么丑陋,样式的改变多么随心所欲,这一切的基础都必须是准确无误的数据。
在大模型时代,我们赞美AI的“发散性思维”,因为它类似于人类的创造力和想象力。在生成前端样式、排版和配色时,这种发散性(甚至可以说是某种程度的“美学幻觉”)是我们获取惊艳效果的基础保证 。
然而,当涉及到企业研发、生产、供应、销售、服务等经营数据时,那些推导出的指标数字、计算逻辑,以及基于此进一步得到的归因推演和深度洞察结果,是绝对、绝对不能有任何幻觉的 。
如果一个AI系统在回答“上个月华东区A产品的毛利是多少”时,靠着概率模型“猜”出了一个看似合理的错误数字,那么这套系统对企业而言不仅毫无价值,甚至是一场灾难。
目前市面上的许多所谓的“对话式BI”产品,大多采用直接的NL2SQL(自然语言转SQL)技术。这种技术在标准测试集上表现尚可,但在复杂的企业真实环境中却频频翻车 。为什么?因为LLM懂SQL语法,但它不懂你的“业务黑话” 。
当用户问“找出优质客户”时,LLM无法知道在你们公司,优质客户究竟是指“消费超过10万”,还是指“近三个月复购超过3次” 。在缺乏语义结构约束的情况下,LLM会自信地编造一段SQL,返回一个错误的数据 。而这种“静默的语义失效”,会真正的摧毁企业对AI建立的脆弱信任。
这正是亿问AI可信辅助决策平台为什么要坚守三大基石的原因:NL2LF2SQL、语义数据库和自研推理模型。

这三大基石,在底层构筑了一道密不透风的防御墙,实现了数据获取和指标计算的“零幻觉”能力。这就像是建高楼,只有当地基打得深不见底、坚如磐石时,我们才能在云端之上,自由地搭建那些玻璃幕墙与空中花园。
正是基于这种绝对的数据确定性,我在产品设计上,才敢拥有更多游刃有余的想法。
当地基牢不可破,我们就可以进一步的去探索:
未来的BI领域里,行为可交互、内容更丰富、格式更自由、样式更好看的HTML+CSS+JS形态会给整个行业带来怎样的变化。
这就是 Generative UI(生成式UI) 所要描绘的蓝图。
传统的软件界面开发是一种静态的“契约式”开发。前端工程师预先写好页面的路由和组件,不管用户查什么数据,系统都只能把数据塞进那个早就定死大小的框框里。如果业务需要一个新的分析视角,就需要经历漫长的提需求、排期、开发、测试、上线流程。
而Generative UI从根本上打破了这种束缚。在亿问的构想中,大语言模型可以作为UI的实时生成器。当我们向智能体输入数据和意图后,我们完全可以交由Agent的Skill(技能)去实时生成前端代码 。
试想一下这个场景: 你向亿问平台提出:“分析一下Q3产品线的盈利情况,并给出优化建议。” 在底层,NL2LF引擎和语义数据库瞬间完成了无幻觉的数据提取与归因推演。而在表层,智能体并没有返回一张死板的柱状图,而是根据当前数据的复杂度和你的阅读习惯,动态生成了一个完整的HTML页面 。
这个页面里,可能包含了一段逻辑严密的类似亚马逊6页纸的分析摘要,下方配有可以通过点击进行下钻交互的数据表格,旁边甚至还生成了几个类似PPT风格的轮播卡片,用来突出展示异常指标。
如果你觉得当前的风格不够炫酷,你只需要在Prompt里加上一句“帮我做一个HTML的炫酷大屏,越炫酷越好”,整个界面的CSS样式和交互逻辑会在几十秒钟内重绘 。

在这个模式下:
在这个维度上,大模型的发散性思维和创造力被完美地释放到了UI的排版、配色和组件编排上 。

只要底层的数据是准确无误的,样式的千变万化不仅不会带来风险,反而会极大地降低使用者的认知负荷,提升信息接收的愉悦度。
回顾我们在产品设计上的这一次次思维推演,其实是一场从“破”到“立”的艰难旅程。
很多人可能会说:做好历史兼容的功能,才会扩大产品的可被接受度,才能活下去。
很抱歉,我不是一个中规中矩的产品,我也不希望亿问的产品变为一个中规中矩的产品。
我知道这样做会有很多已经习惯传统 BI 报表和中国式报表的中高层觉得有学习成本,进而不愿意选择一个想改变行业的乙方,但是我依旧相信一定会有更多着眼于未来的企业家、管理者,会和我们一起积极拥抱 AI 的浪潮,带领企业走向下一个巅峰。
所以我们希望能助力那些愿意尝试新事物且愿意拥抱变化的管理层,使用我们的产品来快速拉开与其他竞对决策效率和精准度的差距,从而拉开企业之间的市场竞争差距。
我们看透了传统BI在Dashboard这种上个世纪历史产物的僵化与局限,它像沉重的存储过程一样,拖慢了企业敏捷决策的步伐。我们从亚马逊和字节跳动的文档文化中汲取了灵感,确认了高密度、可交互的信息载体才是未来的方向。
更重要的是,我们在对AI的产品构想中保持了绝对的清醒。
我们深知,没有任何一种炫酷的前端技术,可以掩盖底层数据的错乱。
因此,亿问选择了最难、但也最正确的一条路:死磕NL2LF2SQL、建设语义数据库、自研推理模型,以保证零幻觉的绝对理性。
在这条护城河的保护下,我们才可以大刀阔斧地引入Generative UI,让每一次数据汇报都变成一场行为可交互、样式可定制的动态体验。
当然,如果你老板实在喜欢PPT,那我们就用HTML和CSS为他实时生成一个比PPT更智能的交互页面。

我们的产品介绍PPT,就是用这套技术完成的,浏览器打开即可
这不仅仅是在做一款 BI 软件的演化,这是在构建企业经营分析的全新范式。这条路注定充满挑战,需要对底层技术的深度敬畏和对前端体验的极致追求。但当我们真正将这一切融合时,我们将不再只是数据的搬运工,而是企业在数字孪生世界里,最可靠、最敏锐的智能决策引擎。
这一步,Data & BI 行业必须迈出去,亿问,就是这条路线的领航者。
看到这里了,来个点赞、在看和转发吧,有空给大家再分享分享产品设计角度的一些新视角,你的一键三联就是我更新的最大动力了。
本文分享自 Apache Doris 补习班 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!