过去一年，随着智能问数项目的不断落地，大家对智能问数的态度变得更加理性，甚至开始怀疑。
相信很多人都遇到过 Demo 很惊艳，落地很尴尬的情况。
问简单问题还可以，一进入真实业务场景，就会遇到口径不一致、字段语义不清、权限复杂、答案不可追溯等问题。
究其原因，归根到底，智能问数最难的是业务语义，在传统企业里，连人都很难说清楚的口径和指标，不能指望 AI 天然就能理清楚。
所以也出现了明显唱衰的声音，说智能问数根本没法落地。
其实，智能问数可以换一种落地方式。
不再继续把智能问数强行塞进所有历史数据系统里，而是寻找那些历史包袱更轻、语义边界更清楚、结果更容易验证的新场景。
这类新场景大致有两种：一种是从零建设的新业务系统，尤其是 AI-native 系统；另一种是围绕外部互联网数据展开的运营辅助场景。
新场景一：从语义原生的新业务系统开始
如果说传统企业数据环境最大的难点是历史包袱，那么对于那些脱离历史包袱的新场景，问题可以小得多，比如各种 AI-native 业务。
AI-native 场景，指的是从产品设计之初就假设 AI 会参与查询、分析、决策和运营的新业务系统。
在 AI-native 场景，可以从一开始就把数据和语义设计好。
在一个从零开发的新系统里，我们不必等数据跑乱了之后再治理，而是可以在业务建模阶段就定义清楚：
有哪些核心事件？ 比如注册、浏览、点击、下单、支付、退款、转化、留存、复购。
有哪些核心指标？ 比如 GMV、净收入、转化率、留存率、复购率、客单价、ROI、LTV。
这些指标的默认口径是什么？ 谁负责解释？ 哪些角色能看？ 答案是否需要返回 SQL、来源和证据？
这也就是一条更适合智能问数的新路径：语义原生。
所谓语义原生，不是先有一堆表，再补一个语义层；而是在业务系统诞生时，就把业务对象、事件、指标、权限和解释能力一起设计进去。
传统路径是“先乱后治”。 AI-native 路径应该是“边建边沉淀语义”。
前者让大模型去理解历史混乱。 后者让业务系统从一开始就更容易被大模型理解。
这会让智能问数的落地难度大幅降低。
新场景二：从互联网数据和运营辅助切入
除了从零建设的新业务系统，围绕外部互联网数据展开的运营辅助场景，也是一类历史包袱相对较轻的新场景。
比如把智能问数用在电商运营、竞品分析、内容运营、广告投放、评论分析、市场趋势分析，也更容易产生价值。
这些场景的问题通常不是：
“公司上个月真实利润是多少？” “这个季度绩效奖金应该怎么算？”
而是：
“最近 7 天这个类目的爆款价格带有什么变化？” “竞品差评主要集中在哪些方面？” “哪些关键词近期热度上升？” “同类商品的主图和卖点有什么共性？” “哪些广告素材正在被更多商家使用？”
这类问题更偏运营辅助、趋势判断和机会发现，不一定要求财务级、审计级的唯一口径。
当然，外部数据也不是完全不需要治理，但治理重点发生了变化：
来源是否可靠？ 采集是否合法合规？ 商品、店铺、品牌如何对齐？ 数据是否过期？ 结论有没有证据链？ 不同来源之间能不能互相验证？
也就是说，互联网数据场景可以避开一部分企业内部数据治理的历史泥潭，但不能跳过数据可信度管理。
只不过这种治理更轻、更贴近场景，也更容易产品化。
下一代智能问数
从可落地的角度看，除了传统企业中的高价值窄场景外，以后的智能问数会更多从历史包袱较轻的新场景里长出来。
之前以为只要把大模型接到数据库上，企业就能立刻进入人人会分析、人人能问数的时代。
真实世界却没有那么简单。
但这并不意味着智能问数没有未来。相反，它的未来可以更加清晰：
从新业务开始， 从小场景开始， 从高频问题开始， 从轻量语义层开始， 从可追溯、可解释、可行动的业务闭环开始。
智能问数没有失败，只是需要换一种落地方式。