Problem

一次 CVE 复盘，真正耗人的不是「会不会写 QL」

CodeQL 本身很强：库、数据流、SARIF 都是成熟工具链。问题出在研究过程被拆成互不相通的片段——每段都能单独做，但拼起来靠人脑粘合，上下文一换班就丢。

1. 从补丁直觉到可编译查询，迭代太贵

研究员通常先有：

• GHSA / NVD 描述
• 一两个 commit / patch
• 「大概从哪进、在哪炸」的直觉

要把这变成能编译、能跑、有信号的 CodeQL 查询，往往要多轮：模板套错、类型写飘、import pack 不对、DB 版本和补丁版本对不上。每轮失败都要重读错误、改 QL、再 codeql query run。LLM 能写草稿，但没有流水线时，草稿和 DB / SARIF 仍是两套世界。

2. 工具链按阶段断裂

一次完整复盘经常跨这些目录和工具：

片段	常见落点	丢上下文的方式
情报	浏览器、本地 JSON、笔记	描述和补丁版本对不上
源码与补丁	某个 clone / zip	和 DB 不是同一棵树
CodeQL DB	codeql database create	Java / Python / C++ 参数各异
查询	手写 .ql	和 sink/source 假设脱节
结果	SARIF / IDE	路径上百条，不知道先看哪条
纪要	Markdown / 聊天	二次审计找不到当时依据

没有共享的 case 工作区 时，每个工具都「对了一截」，整条链却对不齐。

3. 语言差异被当成三套产品

研究问题本身是同构的：危险 sink、可控 source、中间是否有 sanitizer、路径是否可信。

但落地差异很大：

• Python：解释型，建库相对直接
• Java：常用 --build-mode=none，不追编译，但 classpath / 源根仍会坑人
• C/C++：必须有可重复的 build command；本地两步走失败还可能要 Docker 兜底

如果没有统一 case 布局和导入策略，换语言就像重开一局：目录约定、DB 路径、查询 pack、失败日志全要重新记。

4. 只有「讲得通」的聊天，没有可复查产物

LLM 可以直接讲一条利用链，听起来很完整。二次审计时你会发现缺：

• 原始 SARIF（工具链可复现）
• 未筛选路径 vs 精选路径的对照
• 各阶段中间结论（CVE 摘要、sink/source 假设、生成的 QL）

没有落盘，就无法把「模型当时为什么这么选」交给另一人或下周的自己。

5. 路径爆炸：有结果不等于有优先级

CodeQL 一旦命中，data flow 路径可能是几十上百条。人肉打开 SARIF 时：

• 不知道哪条对齐当前 CVE 叙事
• 容易被无关重载 / 测试代码带偏
• 缺乏「为什么选这三条」的元数据

需要的是可解释的路径精选，而不是再堆一个更大的结果文件。

目标（问题侧）

把「情报 → sink/source → 查询草稿与修复 → 执行 → 路径精选」收成可跑、可存、可复查的管道：

• LLM 加速草稿与解释
• CodeQL 给出可核对的求值结果
• 研究员保留最终利用判断

下一页写我们怎么拆阶段、以及为什么会有两层「path」。