企业 AI 问数的澄清与拒绝：比“回答一切”更重要

很多 AI 问数 demo 会强调一个目标：用户怎么问，系统都能回答。

这在演示阶段很有吸引力。用户输入一句自然语言，模型自动理解业务含义、选择数据表、生成查询、执行分析、返回结论。过程越顺滑，看起来越像一个真正的“数据分析助手”。

但在企业系统里，尤其是 ERP、CRM、财务、库存、人事这类业务数据场景里，“尽量回答一切”不是一个可靠目标。

更合理的目标是：

能回答的问题，给出可复核的答案；
语义不清的问题，先澄清；
权限不足或能力超界的问题，明确拒绝。

这听起来不如“什么都能问”有吸引力，但它更接近生产系统需要的边界。

AI 数据访问不是聊天续写。它连接的是真实业务数据、权限模型、指标口径和审计责任。一个看起来流畅但实际越权、误解口径或缺少证据的回答，比一个明确的拒绝更危险。

不确定时硬答，是企业问数里的高风险行为

大模型擅长生成连贯文本，也擅长在不完整信息下补全上下文。

这对写作、代码辅助、知识问答有帮助。但在企业数据查询里，这种能力会带来一个问题：模型可能把“不确定”包装成“看起来合理”。

例如用户问：

上个月销售怎么样？

这句话至少有几类不确定性：

• “销售”指销售订单、已开票收入，还是已收款收入；
• “上个月”按自然月、会计期间，还是当前用户所在时区；
• 是否排除取消订单和草稿订单；
• 是否按当前用户可见公司过滤；
• 是否包含跨公司数据；
• 返回总额、同比、环比，还是按产品 / 区域拆分；
• 当前用户是否有权查看销售金额或毛利。

如果系统直接生成一个 SQL 并返回“上个月销售额为 X”，用户可能会相信这个结果。但这个答案可能只是模型在多个可能口径中选了一个，并没有说明选择依据。

生产系统不能把这种隐含选择藏起来。

对于关键业务问题，系统应该能判断：当前问题是否足够明确；需要哪些参数；当前用户是否有权限；所需指标是否存在；查询是否能在已定义模型边界内执行。

如果不能判断，就应该澄清或拒绝。

澄清不是体验倒退

很多产品会担心澄清问题影响体验。

确实，如果系统对每个问题都反复追问，用户会觉得低效。但这不意味着应该取消澄清，而是澄清应该有明确触发条件。

AI 问数里常见的澄清触发点包括：

• 时间范围不明确：例如“最近”“这段时间”“上个月”在业务口径里有多种解释；
• 指标口径不明确：例如“销售额”“利润”“库存”“客户价值”没有绑定明确指标；
• 维度含义不明确：例如“华东区”“大客户”“重点产品”需要业务定义；
• 查询粒度不明确：用户要汇总、明细、趋势、排名，还是异常列表；
• 多个模型都可能匹配：例如“订单”可能是销售订单、采购订单或生产工单；
• 当前模型缺少必要字段：系统不能确定是否应该换模型或拒绝；
• 查询结果可能过宽：例如用户要求导出所有客户明细，但未说明范围。

澄清的目标不是让用户补完所有技术参数，而是把会影响结果含义或权限边界的关键选择暴露出来。

一个好的澄清问题应该具体、短、可选择。例如：

你说的“销售额”是指已确认销售订单金额，还是已开票收入？

或者：

当前可以按“自然月”或“会计期间”统计。你希望使用哪一种？

这比系统默默选择一个默认口径要好。默认值可以存在，但默认值应该来自查询模型或业务配置，而不是模型临场猜测。

拒绝不是失败，而是安全边界

除了澄清，企业 AI 问数还需要明确拒绝。

拒绝不是“系统能力差”的表现。相反，拒绝是生产级数据工具必须具备的安全状态。

典型的拒绝场景包括：

• 当前用户无权访问目标模型；
• 当前用户无权访问请求字段；
• 查询需要跨公司或跨租户数据，但上下文不允许；
• 查询试图访问敏感字段，例如成本、薪资、供应商价格或内部审批意见；
• 请求要求导出过大范围的明细数据；
• 请求要求写回、修改、审批或删除业务数据；
• 请求超出当前工具支持的查询能力；
• 请求需要的指标没有被定义；
• 问题要求系统给出无法由数据支撑的判断或承诺。

拒绝应该清楚说明原因，但不泄露不该泄露的信息。

例如，系统可以说：

当前用户无权访问该查询模型。

或者：

当前查询需要字段“成本金额”，该字段不在你的可见字段范围内。

但系统不应该为了“解释清楚”而把完整敏感字段列表、隐藏模型名称或权限规则细节全部暴露给用户。

拒绝也不应该伪装成空结果。空结果表示查询合法但没有匹配数据；拒绝表示查询不允许执行。两者必须区分，否则用户和审计系统都无法判断发生了什么。

fail closed 比静默降级更可靠

企业数据工具常见的一个危险做法，是在无法满足请求时静默降级。

例如：

• 用户请求毛利，系统无权访问成本，于是只返回销售额；
• 用户请求全公司数据，系统只查了当前公司，但没有说明；
• 用户请求按客户等级分组，模型没有客户等级字段，于是改用客户类型；
• 用户请求明细导出，系统自动截断前 100 行，但回答里没有提示；
• 用户请求“所有逾期应收”，系统没有应收模型，于是改查发票状态。

这些行为看似提升了回答率，实际上会降低可信度。

更好的策略是 fail closed：当查询意图无法在当前授权和模型能力内被准确执行时，系统应该停止执行，并返回结构化错误、澄清问题或明确拒绝。

fail closed 并不意味着系统不能提供帮助。它可以给出可行替代方案：

当前用户不能访问毛利字段。可以查询销售额、订单数量和已开票金额。是否改为查看销售额趋势？

或者：

当前模型没有“客户等级”字段。可以按客户类型或区域分组。你希望使用哪一个？

区别在于：替代方案必须显式呈现，由用户确认，而不是系统悄悄改变问题。

澄清与拒绝应该进入工具契约

如果 AI 问数是通过 MCP 或其他 tool calling 协议实现，澄清和拒绝不能只停留在最终回答文本里。

它们应该进入工具契约和返回结构。

一个面向生产的查询工具，不应该只有成功返回数据这一种状态。至少应该区分：

• ok：查询成功执行；
• clarify_required：需要用户补充业务参数或选择口径；
• rejected：由于权限、能力或安全边界拒绝执行；
• invalid_request：请求结构不合法或引用了不存在字段；
• unsupported：当前模型或引擎不支持该能力；
• error：系统错误，需要运维或开发排查。

这些状态的价值在于：LLM client、前端 UI、审计系统和运维系统可以基于结构化状态做不同处理，而不是从自然语言回答里猜。

例如，当工具返回 clarify_required 时，AI client 可以把候选选项展示给用户；当返回 rejected 时，client 应该停止继续尝试绕过边界；当返回 invalid_request 时，模型可以在同一查询模型内修正字段或操作符。

这比让模型在自由文本里自我解释稳定得多。

查询模型需要表达“不能做什么”

很多 schema 或 API 描述只告诉 AI 能做什么。

生产级查询模型还需要表达不能做什么。

例如：

• 某个字段可用于筛选，但不可返回明细；
• 某个指标只能聚合返回，不能按单据明细展开；
• 某个模型最多允许查询 12 个月范围；
• 某个维度只允许在当前公司内使用；
• 某类查询需要用户确认后才能导出；
• 某些字段只能用于内部计算，不能直接暴露给 AI；
• 某些聚合粒度会产生小样本泄露风险，需要拒绝。

这些限制如果只写在文档里，模型未必稳定遵守。它们应该成为查询模型和执行引擎的约束。

当请求违反约束时，工具应该返回明确状态，而不是把约束交给提示词处理。

审计需要记录澄清和拒绝

审计不应该只记录成功查询。

澄清和拒绝同样重要。

一个完整的 AI 问数审计记录，至少应该能回答：

• 用户原始问题是什么；
• 系统选择了哪个查询模型；
• 是否发生澄清；
• 澄清问题是什么；
• 用户选择了哪个口径；
• 是否发生拒绝；
• 拒绝原因是什么；
• 请求引用了哪些字段或指标；
• 权限上下文是什么；
• 最终是否执行查询；
• 如果执行，生成了什么查询证据。

这些记录可以帮助团队发现两类问题。

第一，模型或查询模型设计是否不足。如果大量问题都因为指标不明确而澄清，说明业务口径需要更好地建模。如果大量问题都因为缺字段被拒绝，说明模型边界可能需要评估。

第二，是否存在异常访问尝试。如果某些用户频繁请求敏感字段、跨公司数据或大范围导出，审计系统应该能看到这些被拒绝的请求。

只记录成功查询，会漏掉很多安全和产品改进信号。

对 Odoo / ERP 场景的具体含义

在 Odoo 或其他 ERP 系统里，澄清和拒绝尤其重要。

因为 ERP 问题经常带有隐含业务口径。

用户问“这个客户的应收情况”，系统需要知道：

• 是看未结清发票、逾期应收，还是全部账龄；
• 是否只看当前公司；
• 是否包含草稿单据；
• 当前用户是否有会计模块权限；
• 是否允许看到发票明细；
• 是否允许跨联系人合并客户主体。

用户问“本月库存够不够”，系统需要知道：

• 是按现有库存、预测库存，还是可用库存；
• 是看所有仓库还是指定仓库；
• 是否扣除已预留数量；
• 是否按产品变体维度统计；
• 当前用户是否有库存数量权限；
• 是否需要结合销售预测或采购在途。

这些问题如果都由模型临场猜，结果很容易看起来顺畅但实际不可复核。

更可靠的方式是让 Odoo 相关的查询模型显式表达可用指标、字段、公司上下文和权限规则。AI 只在这个边界内构造查询；遇到业务口径不明确就澄清；遇到权限或模型边界就拒绝。

结论

企业 AI 问数不应该把“回答率”作为唯一目标。

真正需要优化的是：在正确权限、正确语义和可复核证据下回答问题；在不确定时澄清；在越权或超界时拒绝。

这要求系统把 clarify、reject 和 fail closed 设计成一等能力，而不是失败后的补丁。

更具体地说：

• 查询模型要定义可用字段、指标、限制和默认口径；
• 工具返回要区分成功、澄清、拒绝、无效请求和系统错误；
• 执行引擎要在查询前做字段校验、权限注入和能力检查；
• UI 或 AI client 要把澄清问题明确展示给用户；
• 审计系统要记录成功查询，也要记录澄清和拒绝；
• 系统不能为了提高回答率而静默降级或绕过边界。

Foggy Data MCP / Foggy Odoo Bridge 的设计方向也是如此：AI 可以辅助用户查询企业数据，但不应该被赋予任意解释、任意 SQL、任意导出或绕过宿主权限的能力。生产级 AI 数据访问需要清楚知道什么时候回答，什么时候追问，以及什么时候停下来。