SQL 规则验证与数据合成¶
- 沉淀时间：2026-09-09
- 来源：IK1CK3 / PR #3 / PR #4
- 成熟度：
confirmed - 适用范围：从真实 SQL 中发现候选规则，并判断是否应进入正式规则库
两条独立工作线¶
候选规则 + 来源 SQL 对
├─ 数据合成：扩展正例 / 负例 / 形态变体 → jsonl
└─ 规则匹配：候选 SQL 对照现有规则库 → 命中与冲突报告
两者只通过测试集 schema 耦合。数据合成不决定规则是否采纳，规则匹配也不关心样本如何生成。
数据合成¶
每条来源 SQL 对应扩展以下维度：format、alias、identifier、predicate、nesting、constant 和 negative。每条样本必须有 expected_hit，并通过 SQL 语法校验。
模型生成不能替代人工抽检。人工重点检查：
- 正负例标签是否正确；
- 负例是否真的越过了触发边界；
- 改写前后语义是否仍然等价；
- 是否混入不存在的表、列或方言语法。
规则匹配¶
现有规则库是外挂的唯一真相源。匹配器对一条 SQL 逐条判断候选规则，输出 hit / miss、理由和命中的完整规则段落。下游应用阶段消费规则原文，匹配阶段不摘要改写策略，也不直接执行改写。
规则库较大时可以先做确定性指纹预筛，但最终判定必须回到规则正文。预筛索引不能成为第二份规则实现。
原子性诊断¶
若一条规则同时描述多个独立策略，应做排除实验：临时去掉该规则，观察相关规则能否凭自身触发条件继续命中。若相关规则仍正确命中，问题通常是当前规则单方面越界，应瘦身该规则，而不是合并所有规则。
反模式¶
- 只有一条来源 SQL 就把模式升级为规则。
- 合成数据只做正例，不验证误命中。
- 把规则文本复制进 prompt 或代码，形成多个真相源。
- 匹配阶段直接给出最终优化 SQL。
- 用 AST 相似度单独证明语义等价。
限制¶
PR #3 / #4 与 Issue 已闭环，但看板没有记录 P-003 / P-008 / P-012 的完整端到端报告和抽检阈值。此条目的架构边界已确认，规则质量阈值仍需补证据。