description: “一次真实的 AI 辅助科研实践：围绕动态运行信息在 LLM 缺陷检测、定位与复现中的作用，完成论文筛选、原文核查、统一 RQ 分析、九维分类和可导航研究成果包。”
tags:

• Codex
• AI辅助科研
• 大语言模型
• 软件缺陷检测
• 动态信息
• 文献调研
  categories:
• 科研实践
  draft: false

我用 Codex 做了两天文献调研：从 42 篇论文筛选到动态信息九维分类

过去两天，我尝试把 Codex 真正放进一次科研工作流，而不是只让它总结几篇论文或润色文字。

我的研究主题是：

程序真实执行产生的动态信息，能否帮助大语言模型更好地完成缺陷检测、故障定位和缺陷复现？如果有效，它在什么条件下有效，又应该如何选择和获取？

这里的动态信息包括测试通过或失败、错误日志、Stack Trace、覆盖率、执行路径、运行时变量、GUI 状态和历史动作等。它们与源码、Issue 文本等静态信息不同：动态信息必须来自一次真实的程序、测试、设备或工具执行。

这两天的目标也不是让 AI 替我“读完论文”，而是把一批零散资料推进成一套能够继续研究、能够回到原文核查、也能够交给别人复用的研究资产。

最终，我完成了这样一条工作链：

42 篇泛读报告 ↓ 统一筛选 28 篇核心论文 ↓ 原文与 PDF 一一核查 27 篇严格纳入语料 ↓ 110 条动态信息使用路径 统一五个 RQ + 九维分类 ↓ 可检索、可导航、可回到原文的成果包

本文记录这两天具体做了什么、得到了哪些研究发现，以及我对“怎样让 Codex 真正服务科研”的一些认识。

一、研究真正困难的地方，不是“找到使用了动态信息的论文”

刚开始时，我的问题看起来很直接：搜索那些将执行结果、Trace、Coverage 或 Debugger 信息提供给 LLM 的论文，然后比较它们的效果。

但很快我就发现，论文中只要出现execution、runtime或feedback，并不意味着它真的证明了动态信息对 LLM 有帮助。

至少要区分以下几种情况：

• 动态信息直接进入 LLM 的 Prompt；
• Agent 调用测试或调试工具，工具结果返回给 LLM；
• 动态信息只被外部控制器用于选择 Seed、算子或候选；
• 执行结果只用于过滤和排序生成物；
• 信息仅在最后充当成功判定的 Oracle；
• 动态数据只用于论文的事后评测，根本没有影响系统决策。

例如，一个系统生成测试后运行它们，并不代表执行结果参与了下一轮推理。如果运行结果只负责判断测试是否成功，那么它证明的是“系统能够被执行验证”，而不是“动态信息改善了 LLM 的决策”。

因此，我给整个调研设置了三条边界：

1. 使用动态信息，不等于证明动态信息有效。
2. 完整系统优于基线，不等于系统中的每种动态信息都有独立贡献。
3. 报告时间、Token 或 API 费用，不等于系统已经具备 Cost-aware 的信息选择能力。

这三条边界后来贯穿了所有筛选、分类和 RQ 分析。

二、第一天：把 42 篇泛读结果变成统一的筛选矩阵

第一天的输入是 42 份已经形成的论文泛读报告。每份报告都包含Overall Relevance，但如果逐个打开、凭印象比较，很容易出现三个问题：

• 不同批次的判断尺度不一致；
• 星级高不等于能够回答核心研究问题；
• 有价值的对照论文容易与核心证据混在一起。

我让 Codex 批量读取 42 份报告，抽取论文 ID、所属任务、标题、星级、相关性判断、使用限制和源报告位置，生成一张可排序、可筛选的统一表格。

初步结果如下：

这里的“核心纳入”“对照保留”和“边界保留”承担不同作用：

• 核心纳入：动态信息确实进入了 LLM、Agent 或控制流程，与缺陷治理任务直接相关；
• 对照保留：可以作为静态 LLM、传统动态方法或 Oracle-only 方法的参照，但不能作为核心效力证据；
• 边界保留：主题接近，却存在“是否为真实动态信息”“是否真的影响模型决策”等定义争议。

按照“四星或五星 + 核心纳入”的规则，42 篇论文被压缩为 28 篇核心论文，其中五星 19 篇、四星 9 篇。对应的 28 份泛读报告和 28 份原文 PDF 也被整理成独立成果包，而原始 42 篇资料保持不变。

这一步让我第一次感受到 Codex 在科研中的高价值场景：它不是替研究者决定标准，而是把已经明确的标准稳定地应用到大量文件上，并把结果变成可检查的结构化数据。

三、第二天：回到原文后，28 篇变成了 27 篇

如果工作停在“已经得到 28 篇高相关论文”，这次调研看起来已经很顺利。但第二天继续进行原文核查时，最重要的问题恰恰出现了。

其中一条记录LOC0002的泛读报告对应 SoapFL，但成果包里的 PDF 实际是另一篇论文 BugCerberus。也就是说，报告、论文 ID 和原文没有形成可靠的一一对应关系。

面对这种情况，最危险的做法是根据已有摘要继续推断，或者临时把另一篇论文的结论补进来。我的处理是直接排除该记录，并把排除原因写入编码手册和最终报告。

最终的严格语料变为：

这个从 28 到 27 的变化，比“又多整理了一篇论文”更有价值。它提醒我：

AI 可以大幅提高阅读和整理速度，但证据链是否闭合，仍然必须靠原文、文件映射和可追溯锚点来保证。

从这一步开始，每个关键判断都要求保留论文原文中的 Section、Algorithm、Table、Figure 或 PDF 页码。泛读报告可以帮助定位，但原文 PDF 才是最终证据源。

四、从“27 篇论文”转向“110 条动态信息使用路径”

只把论文分成“用了动态信息”和“没用动态信息”，信息损失太大。

同一篇论文可能同时：

• 把错误日志直接提供给 LLM；
• 用覆盖率控制外部搜索；
• 用测试结果过滤候选；
• 再用 Fail-to-Pass 作为最终评价指标。

这些路径的消费者、时机和作用完全不同，不能只给整篇论文贴一个标签。

因此，我把主要分析单位从“论文”下沉为“动态信息使用路径”：某种由真实执行产生的信息，以某种表示，在某个位置被某个组件消费，并发挥特定作用。

27 篇论文最终被拆解为110 条动态信息使用路径。一篇论文可以对应多条路径，每条路径分别记录其类型、接入机制、闭环位置、证据强度和效应方向。

这一步使研究从“论文名单整理”变成了真正可以比较机制的证据结构。

五、用同一套五个 RQ 审查三类任务

为了避免缺陷检测、故障定位和缺陷复现各说各话，我为全部 27 篇论文使用同一套 Research Questions。

27 篇论文对应 27 × 5，共形成135 条论文—RQ 记录。

这套 RQ 的核心不是统计“多少篇论文用了 Stack Trace”，而是进一步追问：

• Stack Trace 是否做过有无对照？
• 系统提升是否同时来自新的 Prompt、工具和迭代预算？
• 信息更多时是否一定更好？
• Agent 是在选择下一步动作，还是在选择下一条信息？
• 停止是因为已经获得足够证据，还是因为时间用完了？

当问题被这样定义后，许多看似相近的论文开始呈现出明显不同的证据结构。

六、九维分类：不只看“信息是什么”，还看它如何发挥作用

在统一 RQ 之外，我又把 110 条信息路径整理为九个分类维度。

其中，信息类型本身又被统一为 11 个信息族，包括：

• 结果与进展信号；
• 错误与诊断信息；
• 栈与调用上下文；
• 覆盖、频谱与控制流；
• 路径与约束；
• 运行值与程序状态；
• 协议、设备与物理状态；
• GUI 与多模态环境状态；
• 交易与经济执行状态；
• 执行验证后的工件；
• 历史、记忆与新颖度。

当前语料中出现最多的是结果与进展信号，共 25 条；随后是覆盖与控制流 16 条、错误与诊断 13 条、历史与新颖度 11 条、执行验证工件 10 条。

但这里必须再次强调：

出现频率高，只能说明某类信息常被使用，不能说明它的效力更强。

七、这 27 篇论文真正告诉了我什么？

1. 动态信息被广泛使用，但独立因果证据没有想象中充分

在 27 篇论文中，25 篇至少有一条动态信息路径会影响后续决策；13 篇还包含只用于后置评价的动态路径。

按照每篇论文的最高可归因强度，RQ1 的分布是：

这意味着，文献已经能够说明动态信息在一些限定任务和路径上有帮助，但还不能把所有完整系统的提升都归因于动态信息。

有些论文在加入执行反馈的同时，还更换了 Prompt、工具集、搜索方式、候选数量或预算。此时能得到的结论只能是“整个复合方案有效”，而不是“某一种动态信息贡献了多少”。

2. Context Factors 大量出现，但真正经过验证的很少

关于哪些因素会调节信息价值，27 篇论文中只有 3 篇达到Validated，其余 24 篇主要是Observed。

这些论文确实暴露了许多可能的重要条件：故障是否出现在栈中、执行环境是否可靠、覆盖率是否停滞、GUI 状态是否具有历史依赖、日志是否过长、已有信息是否重复、剩余预算是否充足等。

但“在案例中观察到”与“能够在线预测信息价值”仍然相距很远。这也意味着，未来的系统不能简单地把这些因素写进规则，而需要真正验证Context × Information的交互效应。

3. 多数系统固定信息设计，然后自适应选择动作

RQ3 中，12 篇论文比较了不同信息设计，15 篇仍采用固定设计。

当前常见做法是：系统预先规定每一轮都收集测试结果、日志、覆盖率或 GUI 状态，然后让 Agent 根据这些观测选择下一步动作。

这当然已经形成反馈闭环，但它仍不等于“动态信息选择”。

Agent 选择下一条测试、下一个断点、下一个 Seed 或下一个 GUI 操作，回答的是“接下来做什么”；只有当它能够选择是否再执行、查询哪一种信息、采用什么粒度以及是否停止时，才真正回答“接下来获取什么信息”。

4. 成功停止和预算停止，都不等于信息已经充分

RQ4 的主状态分布为：自适应 7 篇、启发式 5 篇、固定 11 篇、开环 4 篇。

很多系统会在复现出目标 Bug 时停止，也会在达到固定轮数、时间或 Token 上限时停止。但这两类机制分别回答“目标是否达成”和“预算是否耗尽”，并没有回答：

如果再获得一条动态信息，它的预期收益是否仍高于获取成本？

覆盖率 Plateau、重复历史、连续无新发现等启发式已经开始接近这个问题，但针对停止策略的校准、Regret 分析和净效用比较仍然很少。

5. 最明显的研究缺口，是完整的 Context + Cost-aware 信息选择

RQ5 的结果最直接：

在这 27 篇封闭语料中，我没有发现达到 L4 的完整系统：它应当能够根据当前上下文与增量成本，在多个动态信息源之间决定获取什么、获取多少、按什么顺序获取，以及何时停止。

这不是说整个研究领域一定不存在这样的工作，而是说明在当前严格纳入的语料中，这一能力仍然是空白。

它也直接指向了我下一步最感兴趣的研究方向：

让 Agent 不只是使用动态信息，而是学习选择最值得获取的动态信息。

八、我没有把结果停留在一份长报告里

文献调研最容易出现的另一个问题，是最终得到一份很长的 Word 或 Markdown，但几周以后自己都很难回到原文。

因此，这次我把研究结果继续加工成了可导航成果包：

• 一份保持原有章节、说明和统计的 Markdown；
• 18 个分类与综合表格；
• 27 个唯一论文 ID；
• 27 篇一一对应的原文 PDF；
• 1115 处论文 ID 导航链接；
• 一个用于 Windows + VS Code 的轻量 WPS PDF 打开器；
• 一份自动生成的链接与打包检查报告。

在 VS Code 中查看 Markdown 时，点击表格里的论文 ID，就能定位对应 PDF 并调用外部 WPS 打开。这样做的意义不是“多做了一个小工具”，而是把每个分类结论重新连接到证据源。

最终验收结果为：

打开器还通过了 22 项 Node 测试和 3 项 Python 测试，并抽样验证了检测、定位与复现三类论文的外部打开链路。

到这一步，成果才从“阅读笔记”变成了可以继续研究、复核和迁移的资料基础。

九、Codex 在这次科研流程中最有价值的地方

经过两天实践，我认为 Codex 最适合承担以下工作：

1. 把明确规则应用到大量异构文件

只要研究者先定义好筛选标准、证据等级和边界，Codex 很适合批量抽取字段、统一格式、检查缺失项并生成结构化表格。

2. 把自然语言研究标准变成可执行检查

例如，“每个论文 ID 必须唯一对应一个 PDF”“Markdown 中不能出现本机绝对路径”“Word 与 Markdown 的 ID 次数必须一致”，都可以被转换为自动化检查，而不只是人工肉眼确认。

3. 维持跨文档的一致性

当同一批论文同时存在泛读报告、分类表、RQ 矩阵、Word、Markdown 和压缩包时，人工修改很容易造成数字漂移。Codex 可以反复核对 27 篇、110 条实例、135 条 RQ 记录和 1115 个链接是否一致。

4. 把科研产物工程化

研究结论不仅需要写出来，还需要可追溯、可导航、可复核。脚本、测试、映射报告和打包流程让一次性的分析能够变成可重复运行的研究管线。

十、Codex 不能替我做什么

效率提升并不意味着可以把研究判断交给模型。

这次工作中，以下任务仍然必须由研究者主导：

• 定义什么才算“真实动态信息”；
• 判断外部控制器反馈与 LLM 直接观测的区别；
• 区分系统整体提升与单一信息的因果贡献；
• 决定哪些跨论文指标不可合并；
• 对原文错配、缺失证据和不确定结论做保守处理；
• 解释研究缺口，而不是根据标签数量自动生成结论。

尤其值得警惕的是，LLM 很容易把“论文使用了某种机制”写成“论文证明了该机制有效”。如果没有明确的反事实检查和证据等级，这种表述在几十篇论文的汇总中会被不断放大。

所以，我现在更愿意把 Codex 看成一个可以执行规则、维护证据结构和构建研究工具的协作者，而不是论文结论的最终裁判。

十一、我总结出的一套可复用工作流

如果以后继续用 Codex 做文献调研，我会复用下面这套流程：

1. 先定义研究边界。明确纳入对象、排除对象以及关键术语的操作性定义。
2. 保留原始资料。筛选时建立副本和排除清单，不直接破坏原成果包。
3. 先建矩阵，再写长文。让每篇论文以统一字段和状态进入结构化表格。
4. 把原文作为最终证据源。摘要和泛读只负责定位，不能替代 PDF 证据。
5. 允许“未证明”和“无证据”。不用推断填补论文没有研究的问题。
6. 把使用路径而非整篇论文作为分析单位。同一论文中的 Prompt、控制器、Oracle 和评价路径应分别编码。
7. 自动检查数量与映射。对 ID、文件、链接、表格和压缩包做机器可执行的质量控制。
8. 最后再做跨论文综合。只比较证据结构，不强行平均不可比的原始指标。

这套流程的关键不是“让 AI 多做一点”，而是让每一个由 AI 加速的步骤都有明确输入、输出和验收标准。

十二、下一步：从“使用动态信息”走向“选择动态信息”

这两天的结果让我把未来方向进一步收敛到一个更具体的问题：

给定当前任务状态、已有证据、可用工具与剩余预算，Agent 应该获取哪一种动态信息？应该获取到什么粒度？何时停止最合算？

一个理想的 Dynamic Information Selection Agent 不应每轮固定收集所有日志、覆盖率和运行状态，而应该估计每项信息的条件价值：

候选动态信息 ↓ 结合当前 Context 预测边际收益 ↓ 估计执行、Token、时间与人工成本 ↓ 选择信息源、粒度、组合和顺序 ↓ 判断继续获取或停止

这将把现有系统中常见的“反馈驱动动作选择”，推进为真正的“价值驱动信息选择”。

它也可能让动态信息的研究从“加上 Trace 是否更好”转向更实用的问题：

• 什么 Bug 值得运行程序获取证据？
• 什么情况下一个 Stack Trace 已经足够？
• Coverage、Runtime State 和历史轨迹何时互补，何时只是噪声？
• 多获取一条信息带来的收益，是否值得它的执行与上下文成本？

这些问题目前还没有被统一回答，也正是这次文献调研留下的最清晰研究空间。

结语

两天时间当然不足以“完成一个领域的 Survey”。我真正完成的，是把一批论文从零散资料推进成了一个边界清楚、证据可追溯、结构可比较的封闭研究语料。

从 42 篇泛读报告，到 28 篇核心候选，再到 27 篇严格纳入论文；从整篇论文标签，到 110 条动态信息使用路径；从五个统一 RQ，到九维分类和可导航成果包——Codex 带来的最大帮助不是替我得出结论，而是压缩了资料整理、规则执行和质量检查的成本。

但研究可信度的来源没有改变：它仍然来自清楚的定义、保守的证据判断、对原文的回查，以及敢于在发现错配时把 28 改成 27。

这大概也是我这两天最大的收获：

AI 辅助科研真正有价值的方式，不是让模型替代研究者，而是让研究者有能力建立更细、更稳、更可复核的证据链。