待确认知识候选¶

从 issue/PR 沉淀下来的候选知识，等待双周 review 后转正到知识库或拒绝。

候选列表¶

[候选] sql-distributed 4 处 skill 缺陷的硬约束补丁（环境/分片键/索引参数/超时降级）¶

来源 issue: IK37HX（issue 仍 open，PR 已合入待回归）
来源 PR: PR #5（2026-07-28 merged → develop）
沉淀时间: 2026-07-28
状态: pending（待 IK37HX 回归验证后转正）
拟归主题: agent-边界设计或 sql-优化技术

背景：

opencode + GLM 执行 sql-distributed 跑 gcsdb_0005 / gcsdb_0019，Skill 遵循度 ~50%。复盘定位 4 处 skill 真实缺陷（非 LLM 执行偏差）： - P-1：步骤 3 环境初始化假设系统 python3 可用，无 venv fallback 指引 - P-2：分片键推断值未强制暴露 source 字段，被下游当成 DBA 确认值用 - P-3：空索引场景下 execute.py 省略 --index-ddl / --rollback-index，审计字段空值 - P-4：baseline.py 无大表超时降级路径，>300s 直接终止整条流程

当前方案（PR #5 已合入 + 跟进补丁 8aab330）：

按 reviewer buaazyp 2026-07-27 评论给出的硬约束实现： - P-1：python3 写死改 $PYTHON_BIN，加边界控制（不新增脚本/依赖、不联网 pip、不改 pyvenv.cfg/软链；fallback 失败立即停止并输出诊断） - P-2：分片键缺失时显式标明缺失并提供给 LLM，不把推断值当 ground truth - P-3：无推荐索引时 --index-ddl / --rollback-index 必须传 '[]'，缺参数视为有问题 - P-4：>300s 直接输出运行超时，走人工单独处理（不强行降级 EXPLAIN）

跟进补丁（commit 8aab330，2026-07-29 合 develop）—— 服务器部署反馈后进一步收紧： - env_check 契约：只保留两段探测 python3 → $SQL_OPT_PYTHON；删除自动扫本地 scripts/venv / venv_pythonhome 路径；失败输出极简 JSON + README 修复指引；总控步骤 3.5 交互询问，不自动降级为「模型优化-未验证」 - 超时：固定 --timeout 300，超时 → 运行超时-人工处理，跳过步骤 5–11；移除 --fallback-to-explain / explain_only 降级路径 - pending_rules 路径：pending_rules_1.md → skills/rule-match/rules/pending_rules_1.md，同步 rule-match / sql-distributed 步骤 5.5 / sql-synth / 相关 docs - 措辞：点名 → 点明、臆造 → 伪造

待确认点：

P-2 的 source 字段 schema（dba_confirmed / inferred_from_partition / ddl_explicit / missing）是否要写进 generation.md 的硬约束？
P-4 的 300s 阈值是否需要按表大小动态调整？
env_check 契约是否要抽成跨 skill 通用约束（其他依赖 Python 环境的 skill 是否复用同一探测流程）？
规则库目录路径已变 2 次（根 → skills/rule-match/ → skills/rule-match/rules/），是否要作为契约固化避免未来再漂移？

[候选] rule-match skill：把已有规则库当外挂 md 模型做命中匹配¶

来源 issue: IK1CK3（仍 open，端到端验证未完成）
来源 PR: PR #4（2026-07-27 merged → develop）
沉淀时间: 2026-07-28
状态: pending（待 IK1CK3-PR4 端到端验证 3 条规则后转正）
拟归主题: agent-边界设计

背景：

skills/rule-match/rules/pending_rules_1.md 堆积 P-001~P-012 共 12 条 AI 自动发现的 SQL 改写规则草案，审核靠人工逐条对照 rewrite-rules.md + feature_matcher.py，触发命中精确性 / 改写语义等价性都缺自动化校验通路。

当前方案（PR #4 已合入）：

rule-match skill 骨架 + P-003 验证 + 规则非原子化问题登记。核心思路：已有规则库 rewrite-rules.md 作为「外挂 md 模型」做命中匹配——待验证规则 + 合成 SQL 喂给 LLM，LLM 通过检索/对照外挂规则库判定 (a) 本规则是否命中、(b) 是否会被已有规则误命中。同时附 P-003 正确性报告 + 1 条规则非原子化问题的分析记录。

待确认点：

外挂规则库的检索方式选型（整库灌入 / RAG / 分段加载）尚未敲定
语义等价判定是否要补 AST 结构比对 + 列引用图作为辅助证据
规则非原子化问题登记是否要单独立 issue 推进修订

[候选] sql-synth 数据合成骨架（脚本 + 提示词 + jsonl schema）¶

来源 issue: IK1CK3（仍 open）
来源 PR: PR #3（2026-07-23 merged → develop）
沉淀时间: 2026-07-28
状态: pending（待 IK1CK3-PR2 人工验证首批样本后转正）
拟归主题: sql-优化技术

背景：

每条 pending 规则只有 1 条来源 SQL 对，证据单薄，触发特征是否在其他 SQL 形态下仍精确无法证明。需要把 1 条来源 SQL 对扩展为 N 条同语义、不同形态的 SQL 对（覆盖 format / alias / ident / predicate / nesting / constant / negative 负例）。

当前方案（PR #3 已合入）：

三段式：脚本（调用 LLM + sqlglot 语法校验 + 落盘 jsonl）+ 提示词（版本化管理）+ 人工抽检
产物 schema 与工作 2（rule-match）对齐，可被直接消费
首批 P-003 样本已生成

待确认点：

人工抽检通过率阈值（PR-2 阶段定）
是否值得把脚本沉淀为独立 sql-synth skill（目前仅脚本 + 提示词，未沉淀为 skill）

[候选] 主模型失败时自动降级到备用模型（代理层 fallback 设计）¶

来源 issue: IJZKZE（已闭环）
沉淀时间: 2026-07-21
状态: pending
拟归主题: sql-优化技术或 agent-边界设计

背景：

Claude Code 通过 anthropic-to-openai-proxy.py 转发模型请求。主模型不可用会直接中断调用方，影响所有依赖代理的 skill。

当前方案（PR #2 已合入 develop，2026-07-19）：

保留硬编码 primary / fallback 模型配置（不引入额外配置改造）
主模型出现以下情况时触发降级：连接失败 / 请求超时 / 非 200 / 异常响应
fallback 成功 → 对调用方返回正常 Anthropic 格式响应（透明）
primary + fallback 双失败 → 返回清晰错误
增加必要日志，能看出失败原因与是否发生降级

待确认点：

硬编码模型配置何时迁移到配置文件（已登记为技术债）
触发降级的超时阈值是否需要可调（当前硬编码）
是否需要在 fallback 也失败时做第三级兜底（如返回缓存结果）

[候选] Skill 不应手写最终结果 JSON¶

来源 issue: IJYC7V（已闭环）
沉淀时间: 2026-07-13
状态: pending
拟归主题: agent-边界设计

背景：

SQL 优化 skill 在生成 {case}_result.json 时，由模型手写 status 字段。出现 execute_result.result_identical=false 时仍被写成「正优化」，错误结论进一步进入 summary。

当前方案（PR #1 已合入）：

禁止 skill 手写最终结果 JSON
引入统一结果生成脚本，依据 baseline.json + execute_result.json 判定状态
强制包含 schema_version、result_identical、comparison_detail 等审计字段
collect_results.py 只接受标准格式结果

待确认点：

该规则是否要升级为「所有 skill 输出」的通用约束（即所有结构化输出都必须由脚本生成）？
schema_version=sqlopt-result/v1 是否需要进文档作为团队约定？

[候选] SQLite 存储设计方案（v2 最终版）¶

来源: sql_opt/docs/sqlite_storage_proposal.md（681 行）
沉淀时间: 2026-07-13
状态: pending（设计中，未实施）
拟归主题: sql-优化技术

背景：

SQL 优化结果当前以 JSON 文件形式落盘，跨 case 检索、聚合统计困难。需要在 v1 提案基础上结合 DBD 设计与 bda_cli_v101 分支数据结构，沉淀为 SQLite 落地方案。

当前方案（设计稿）：

表结构按 pi_optimization_tables.md 规范
与 core/dataprocess_v3/ 现有能力对齐
所有进一步变更需走 SSD 流程更新本文件 + todo.md

待确认点：

落地时机（与现有 JSON 落盘并存还是替换？）
迁移路径（历史 JSON 数据是否要回灌 SQLite？）

[候选] 审查未通过后保持优化轨多轮累加¶

来源: sql_opt/docs/optimizer-history-through-review.md（445 行）
沉淀时间: 2026-07-13
状态: pending（设计中，未实施）
拟归主题: sql-优化技术

背景：

V3 工作流审查未通过时，当前直接重置进入新一轮优化。希望支持「保持当前优化轨，多轮累加细调」的路径，避免丢失已积累的 prompt context。

主要触达文件：

core/llm_opt_v3/v3_state.py、core/llm_opt_v3/v3_nodes.py、core/llm_opt_v3/prompting.py

待确认点：

累加上限多少轮？（与 max_rounds 关系）
审查失败后是「保留 context 累加」还是「剥离失败部分后累加」？

[候选] SQL 模板与参数变体验证方案¶

来源: sql_opt/docs/spec-sql-template-variant.md（371 行）
沉淀时间: 2026-07-13
状态: pending（设计中，未实施）
拟归主题: sql-优化技术

背景：

当前系统对每条具体 SQL（带字面量值）独立优化，生成的索引和 SQL 改写可能只对该参数值有效。

典型场景：WHERE status = 'PENDING'（1% 数据）建的索引，换成 WHERE status = 'COMPLETED'（99% 数据）后执行计划可能退化。核心矛盾：具体 SQL 的优化 ≠ 通用 SQL 模板的优化。

当前方案（设计稿）：

优化阶段：输入具体 SQL + EXPLAIN（现有流程不变）+ 额外告知 LLM 该 SQL 的参数化模板与当前值的选择性 → LLM 输出时标注是否参数敏感
验证阶段：拿优化后方案，对多个具体变体 SQL 跑 EXPLAIN + 计时 → 确认通用有效 or 参数敏感

待确认点：

参数变体由谁提供（用户 / 自动枚举 / LLM 生成）？
验证不通过时，是回退方案还是降级标注「参数敏感」？

候选格式¶

### [候选] 标题

- 来源 issue: IJZKZE
- 沉淀时间: YYYY-MM-DD
- 状态: pending

**背景：**
（issue 描述）

**当前方案：**
（解法）

**待确认点：**
（人工 review 时要看的疑问）

转正规则¶

通过 → 移到 knowledge/<对应主题>/
拒绝 → 删除并在 01-sync-ledger.md 记录原因