结论：答案要附决策所需的最小解释

只返回“华东下降 8%”无法让用户判断采用哪种收入、哪个时间范围、是否扣退款。直接展示 SQL 又会暴露表名、字段与复杂实现。合适的解释层位于二者之间：用业务语言陈述查询计划，并能追到受控技术证据。

解释目标不是证明模型很聪明，而是帮助发现误解。高风险答案应先展示指标版本、过滤、范围、水位、关联与限制；探索性问题可折叠细节。解释深度按错误后果和用户角色分级。

将查询拆成稳定的计划节点

计划可以包含 ResolveMetric、ResolveScope、SelectSource、JoinEntity、Filter、Aggregate、Compare、Rank、Validate 和 Present。每个节点保存业务描述、输入输出粒度、执行状态和证据 ID。

计划节点比自然语言长解释更容易测试，也比 SQL 更稳定。数据库方言或物理表改变时，业务计划仍可保持；指标语义变化则必须生成新版本并触发复核。

展示采用的指标、维度、时间角色、比较基准、币种和默认条件。例如“本月”按业务时区从月初到共同完整水位，“客户”按去重企业 ID，而不是订单联系人。

若系统继承上轮条件，应标明来源。默认地区、组织和状态不能藏在后台。存在候选冲突时先澄清；在解释页列出一个确定选择并不能补救未经确认的歧义。

业务用户不必阅读 JOIN 语句，但需要知道订单行按商品键连接商品、按客户键连接客户，且订单头金额不会在行级重复。可展示“每个订单对应多行商品，汇总前先固定订单金额”的说明。

关联节点记录左右粒度、预期基数、未匹配率和重复保护。多对多桥、迟到维度和当前/历史状态应明确。查询成功不代表关联正确。

结果应列出订单状态、测试账号、取消退款、组织范围、数据截止时间和缺失分区。排除项往往比公式更能解释差异。对敏感范围只显示业务标签，不暴露未经授权的值。

多数据源的共同截止时间取最慢关键输入，不能用最新表时间代表全部数据。若采用上一个完整批次、采样或缓存，应和数字同屏提示。

毛利率应展示毛利额/净收入，而不是仅给公式 ID；同比要说明可比日历、门店范围和分母零处理。排名、份额与平均值都要标明聚合层级和权重。

复杂公式可分层：页面显示可读定义，受权用户再查看指标版本、血缘和技术表达。不要暴露数据库凭据、内部主机、原始 SQL 常量或受限列。

Top N、采样、近似去重、超时降级和缓存会改变结果性质。解释节点应标记 exact/approximate、误差或覆盖范围、触发原因和可否重算。

事实、统计关联和生成式总结也要区分。“促销期间同时下降”不能写成促销导致下降。行动建议列出证据与替代解释，不让自然语言把不确定性抹平。

对黄金问题检查计划节点是否完整、业务描述是否与实际 SQL 一致、术语是否符合角色。计划与执行日志用同一 IDs 关联，避免页面说扣除退款而 SQL 没有过滤。

采用分层展示、键盘导航和清晰文本，不只用颜色表达风险。移动端先展示结论与关键限制，细节可展开；导出报告应携带同一解释版本。

反例包括解释模板固定不随查询变化、SQL 与解释版本错位、只显示模型思考过程、泄露表结构、隐藏默认过滤、把近似写成精确。模型内部推理不是审计证据，结构化计划才可复核。

验收要求每个数字能映射计划节点；指标、范围、时间、水位、关联、公式和限制齐全；权限过滤后解释不泄密；SQL 改写仍保持一致；抽样问题由业务负责人能判断是否答对了题。

建立 explanation_coverage，统计关键节点是否都有业务描述；建立 consistency_error，抽查解释与实际计划是否一致；再记录用户展开率、纠错类型和澄清后是否改问。展开率低不一定代表无价值，也可能是说明过长或入口难找。

每次语义编译器、SQL 生成器或页面模板升级，都用黄金问题比较计划节点和关键文本。高风险答案若缺少范围、水位或近似状态，应阻止发布；低风险探索可允许降级，但必须留下原因。

业务用户关注口径、范围和限制，数据负责人还要看血缘、基数和质量检查，安全人员关注身份与策略。三种视图引用同一个 plan_id，只调整可见字段，不能生成三套互不一致的说明。

管理员也不应默认看到所有样本值。解释权限按最小必要原则设计，结构证据与数据内容分开授权；审计人员可验证哈希和执行状态，而不必获得全部业务明细。

先从财务或经营的高风险问题试点，定义最小解释字段，连接语义计划与执行证据，开展业务可读性测试，再按风险分级扩展。运营监控解释缺失、解释与执行不一致和用户纠错。

AskTable.ai 可作为自然语言分析入口参与评估，但本文不证明其当前页面已呈现上述全部查询计划节点或技术证据。SQL 可见性、数据血缘、近似标记与导出解释需按版本和权限核验。

预约一次场景交流，了解 AskTable.ai 如何接入你的业务。