我们常把 AI 产品的失败归结为答错，却很少追问另一个问题：它为什么非要回答？在搜索、客服、代码生成和企业流程里，系统经常面对资料缺失、权限不足、目标含糊或规则冲突。此时最有价值的输出可能不是一个完整答案，而是一句准确的“不知道”，以及下一步该向谁、要什么信息。可惜许多界面只为答案留了位置，没有为不确定性留位置。于是模型被鼓励把空白填满，用户也很难区分事实、推测和建议。
先区分四种不知道
第一种是资料里没有。系统检索过授权范围内的内容，但没有找到能支持结论的证据。第二种是看到了，却无法判断哪份材料有效，例如两个制度版本互相冲突。第三种是权限不够，答案可能存在，但当前用户或智能体无权访问。第四种是问题本身不完整，缺少时间、对象或约束条件。
这四种情况不能共用一句模糊的“抱歉，我无法回答”。它们对应不同的下一步：扩大检索范围、请求负责人确认、发起授权，或者向用户补问。只有把原因说清楚，不知道才不是终点，而是流程中的可操作状态。
不要把置信度做成装饰
很多产品喜欢在答案旁显示一个百分比，看起来精确，却未必能帮助决策。模型给出的 82% 如果没有校准方法、样本范围和对应动作，用户只会把它理解成另一种语气强弱。
比单一分数更实用的是证据状态。例如“已找到正式制度并核对发布日期”“仅找到内部讨论稿”“两个来源存在冲突”“未检索到相关资料”。这些状态能直接连接产品行为：允许引用、要求二次确认、禁止自动执行，或转交人工。
不确定性界面的目标不是展示模型有多诚实，而是帮助人选择下一步。一个好的提示应该同时包含缺口、影响和补齐办法。
给不知道安排出口
如果系统说不知道之后只能结束对话，团队很快会把拒答阈值调低，因为用户体验看起来太差。正确做法是提前设计出口：可以补充哪些字段，可以上传哪类材料，可以请求谁审批，也可以把任务降级成不会造成损失的部分结果。
例如采购助手无法确认供应商是否满足某项合规要求时，仍可以整理已获得的证照清单、标出缺失项，并生成一封待人工确认的询问信。它没有越过判断边界，却继续推进了工作。
对于能执行动作的智能体，出口还应包含明确的停止状态。没有确认时，不发送、不付款、不删除、不对外承诺。停止不是失败，而是系统正确遵守边界的证据。
用真实缺口测试产品
上线前不要只准备有标准答案的测试集，还要加入资料缺页、版本冲突、用户表述含糊和权限不足的任务。观察系统是否能识别缺口，是否会编造连接句，是否给出合理的补问，以及在无法确认时是否真的停止动作。
评估指标也要随之改变。除了答案正确率，可以记录不当确定率、有效补问率、人工接管成功率和高风险动作拦截率。一个系统少回答了几次，却避免了错误执行，可能比一个始终流畅的系统更有生产价值。
让 AI 学会说不知道，不是降低能力，而是让能力拥有边界。只有当用户能看见系统知道什么、缺什么、准备做什么，信任才不必建立在盲目的流畅感上。