澄清与词汇缺口
澄清是兜底，不是常规路径
普通问数最多展示一张业务确认卡，且只在两种情况下出现：
- 同名语义元素：同一个名字命中多个已发布业务定义
- 跨事实根的指标短语：同一短语落到多个事实根上的不同指标
确认卡不暴露内部 Scope、Dataset 或语义 ID。
需要用户确认的永远是业务含义，不是内部执行计划。
用户点名的是门店的属性，就不该被追问「你要分析销售单还是销售明细」。
人工选择必须真的被用上
人工在确认卡上做的选择，必须在最终 S2SQL 里真的被使用，否则这次查询不执行。这条规则防止「问了但没用」的假澄清。
选择不会被记住
v0.0.2 起移除了确认记忆。人工选择只在当次查询内生效，长期修复走业务词典。
时间维不参与歧义结算
时间维进入查询是因为「按月」「同比」必须落在时间轴上，与某个名词怎么读无关。因此时间维不参与同名歧义结算——否则会陷入选一次弹一次的无限澄清。
词汇缺口收件箱
问不出来的说法不会就这么算了。六类信号进入同一个收件箱：
| 类别 | 含义 |
|---|---|
| 拒答 | 系统无法证明安全而拒绝执行 |
| 澄清 | 触发了确认卡 |
| 模型猜测 | 模型自己猜的成员 |
| 取值不认识 | 过滤值不在已发布取值里 |
| 点赞 | 用户认可结果 |
| 点踩 | 用户否定结果（必须选原因） |
收件箱按说法聚合，可分页、可标记已处理，并能一键补进业务词典。
推荐的迭代节奏
上线 → 收集词汇缺口 → 按频次补词典 → 发布新 Release → 再收集
这比逐条改 Prompt 可控得多：词典是可审核、可发布、对所有人生效的语义资源。
拒绝执行的几种情况
如果 S2SQL 出现下列情况，查询不会进入数据库：
- 引用了未发布的名称
- 丢失了已确认的过滤值
- 跨越了不安全的关系
- 没有落实人工选择
- 任一
WHERE/HAVING经常量折叠归约为 FALSE
最后一条修复的是一类危险行为：模型表达不了某个条件时，自己发明一个「永不成立」的过滤条件顶掉它，执行成功但返回 0 行，界面显示「查询成功，但没有返回数据」——用户读到的是一句关于自己业务的假话。