前几天在办公室，我经历了一场让人如坐针毡的系统试用。
一位高级管理角色花了将近一个小时试用我们正在研发的数据智能问数系统。光是找对应业务的数据源就花了七分多钟；好不容易输入了一个问题，界面在漫长的两三分钟里没有任何明确反馈；最后吐出结果，系统先自作聪明选了一个主题，接着又弹出一堆指标、维度和过滤条件，让用户继续在对话框里手动点选确认。折腾到最后，这道题依然没有跑出一个准确的有效答案。
那一刻坐在旁边，我的体感极其强烈：这根本不是什么划时代的 AI-Native 体验。这本质上就是一套传统的手工多维分析系统，只是工程师把原本在页面上点选的复杂配置，极其生硬地切碎后塞进了对话框里。更糟糕的是，系统不仅没有替业务解决问题，反而在把数据治理的缺口、指标口径的歧义和底层的判断责任，一股脑地甩锅给屏幕前的用户。
这场试用让我们团队彻底停了下来。当天上午，我们做出了一个在过去几个月里最艰难、但也最清醒的决定：全面叫停“全业务自由问数”的宏大叙事，删掉汇报材料里所有关于“全覆盖”的承诺，把交付范围断崖式收缩到少数几个业务；在没有业务语义、权限不足或证据不全时，必须坚决、可靠地拒答。
很多人以为，企业 AI 的成熟度体现在它能支持多少个业务场景。但真实生产环境的残酷教训告诉我：生产级 AI 最重要的能力不是多回答，而是在语义、权限和证据不足时可靠拒答，并把用户导向一条可控的责任路径。
为什么删承诺比加功能难十倍
在技术团队里，做加法永远是顺人性的。
业务方提一个新诉求，工程师顺手加两张表、再包一个 Prompt、多挂一个组合 Skill、在中间抽象一层动态路由。每个人在周报和汇报材料里都能写上光鲜的“新进展”，架构图越来越花哨，支持的业务线列表越来越长。
但这种热闹掩盖了一个极其致命的事实：在没有业务知识和语义治理的前提下，让大模型直接面对裸库生成查询，准确率普遍只有 30% 到 40%。
我们拉出现场的真实评测数据：即使是由懂业务、懂数据的专业人员去使用主题路径，评测准确率大概也只能到 69%，换成普通业务人员只会更低；几个刚启动语义初版的业务线，正确率只有 30% 到 35%；唯独治理较早、沉淀了大量口径定义与业务知识的业务，才能勉强摸到 80% 的门槛。
面对这种数字，摆在管理者面前的其实只有两条路。
第一条路是继续自欺欺人：把容差放宽到 5%，对模糊问题默认替用户选第一个选项，然后在演示和汇报时宣称“我们已经实现了全业务覆盖”。反正只要演示时不翻车，大家都有交代。
第二条路则是直面现实：在临近交付节点时主动踩刹车，把 8 月底的口径明确修改为 Preview，正式版推迟到 9 月底；删掉所有关于跨表自由分析的宣传，自然语言语义问数只保留信用卡、分付、证券三个具备治理基础的业务，并且把数值容差从虚胖的 5% 硬生生收紧到千分之五。
我们最终选了第二条路。
做出这个决定的过程极其痛苦。你要去向管理层解释为什么之前说的“全都能问”现在变成了“只能问三个”，你要承受“是不是团队进度不及预期”的质疑。但只要你真正对生产交付负责，你就会明白：删掉虚假的承诺，比硬着头皮继续堆功能需要大得多的勇气。
因为用户不会因为系统号称支持一百个场景而留下，却会因为在第一个关键决策上拿到一个看似煞有介事却完全错误的数字，从此彻底对这个系统丧失信任。在真实的业务周会和财务对账上，80% 的准确率约等于 0 分，千分之五的容差才是及格线。
模型最大的危险，是它的“讨好型人格”
大模型在本质上是一种概率自回归系统。如果不做极其严格的外挂约束，它天然带有一种令人绝望的“讨好型人格”：逢问必答、过度自信、强行编造。
你给它一段缺少字段定义的模糊提问，它不会主动停下来告诉你“我的知识库里没有定义这个指标”，它会下意识地根据字面相似度，找一个长得很像的字段拼凑出一条看似合法的 SQL；你给它一个超出了它当前权限的数据查询，它如果不做前置鉴权，甚至会试图用模拟的汇总数来搪塞你。
这种现象在 Demo 阶段往往被当作“泛化能力强”，但在严肃的企业生产环境里，这就是一场灾难。
我在《AI 不是来替你查报表的》里写过：AI 和结构化数据之间，缺的从来不是连接器，而是受治理的业务语义。大模型再聪明，它也无法凭空猜出你们公司“昨天”到底算自然日还是交易日，更不可能知道“活跃用户”在两个部门之间为什么差了三十万。
所谓“语义问数”的壁垒，从来不在大模型技术本身，而在于模型背后装入了多少被确认过的业务知识、指标口径和治理规则。
如果这层资产没有建好，所谓的“自然语言张口就问”，就只是把大模型当成了一个昂贵却不可靠的随机数发生器。
因此，生产级系统的第一道防线，就是打破模型的过度自信，在系统架构中引入确定性的门禁与拒答机制。当用户的提问超出了已治理的语义空间、或者当前用户的权限并未覆盖目标资产时，系统必须在生成任何有害查询之前，干净利落地停下来。
拒答不是报错，而是一条责任路径
很多人抗拒“拒答”，是因为在传统软件的交互认知里，“拒答”等同于“系统报错”，等同于弹出一个冰冷的 Error 404 或“系统无法处理您的请求”。如果 AI 只会说“我不知道”，那产品的可用性确实会瞬间跌入谷底。
但在生产级系统里，优秀的拒答绝不是一句推卸责任的报错文案，而是一条清晰可控的责任路径。
我们在这次收敛中，把问数模式极其严格地拆成了三条各自独立、绝不互相混淆的轨道：
第一条是面向普通用户的“语义问数”。默认走自然语言，但仅限于那三个已经把业务知识、权限和口径治理好的业务域。在这些域里，我们追求 80% 以上的准确率和千分之五以内的精度。一旦用户的提问超出了这三个域，或者涉及未治理的长尾指标，系统绝不强行编造，而是明确告诉用户：“当前业务尚未建立已验证的语义模型，系统无法确保计算准确。”
第二条是面向专业分析师的“主题问数”。退回至专业入口。当用户明确知道自己要查哪张主题表或哪个 Cube 时，他可以显式指定数据源，系统在这个限定范围内辅助他确认指标、维度和过滤条件。在这个环节中，系统不能无限期等待用户，也不能在用户正操作时强制跳过。我们设计了 20 秒确认倒计时，一旦用户开始产生点击交互，倒计时立刻暂停，既防止链路无限阻塞，又保留了人工介入的从容。
第三条是资产沉淀的闭环（Skill Creator）。当一位专业分析师通过主题问数完成了一次复杂的多维分析、或者探索出一条高频分析链路后，系统会提供一个极其自然的出口：将这次分析沉淀为一个可复用的 Skill。这个 Skill 可以被显式调用、可以分享给团队、可以设置可见权限，但绝不默认参与全量问答的泛化召回，防止近似匹配污染普通问数。
你看，当拒答被设计成这样一条责任路径时，它不仅没有压低可用性，反而把原本混乱的“黑盒瞎猜”，变成了层次分明的人机协作：能自动保证准确的，由语义层直接交付；边界之外的，引导至专业可控入口；专业探索沉淀下来的有效经验，又反哺为整个组织的数字资产。
生产级 AI 的壁垒是托付成本
AI 发展到今天，一个越来越清晰的趋势是：功能的制造成本正在被压缩到接近于零，但系统的托付成本却被推到了前所未有的高度。
用现成的 Agent 框架搭一个能查库的 Demo，一个工程师花两天就能跑通；但要让一个涉及真金白银、风控合规和业务决策的核心团队，敢于在每天早上的例会上直接引用 AI 吐出来的数字，背后需要付出的治理成本、权限对齐成本和边界兜底成本，往往是前者的百倍以上。
我在《AI 时代，给别人做东西反而更难了》里写过一个观点：当每个人都拥有生产能力时，功能本身不再稀缺，信任才真正稀缺。
一个敢在证据不足时主动拒答的系统，远比一个什么都敢答、但时不时给你埋一颗暗雷的系统，更值得被业务托付。
因为在真实的商业世界里，管理者和业务专家最害怕的从来不是“这个问题工具暂时不支持”，而是“工具给了我一个自信满满的错误答案，而我毫无防备地把它当成了决策依据”。
删掉“全业务覆盖”的虚假承诺，把防线退回到受治理的语义与权限边界，在每一个不确定的节点建立可靠的拒答与责任分流。这看起来是一次后退，但恰恰是在这一天，AI 才真正脱掉了实验室的玩具外套，开始拥有了走进严肃生产环境的资格。