仓库级别的程序修复不仅需要正确的补丁，还需要可检查的记录来说明需求是如何转化为代码修改以及后编辑证据的。我们提出了 THEMIS，这是一种阶段感知的修复工作流，能够通过语义解释、运行时需求‑代码图、图衍生的开发者指导、保留的修复理由与补丁以及后编辑审计记录，将需求到修复的过程外部化。
THEMIS 的核心包括：① 语义解释层，将自然语言需求映射到代码语义；② 运行时需求‑代码图，捕获需求实体与代码符号之间的关联；③ 基于图的开发者指导，向修复模型提供上下文提示；④ 保留的修复理由和补丁，形成可追溯的审计链；⑤ 后编辑审计记录，用于跨阶段的对应性检查。
我们对 300 条 SWE‑bench Lite 案例进行回顾性审计，发现 288 条（96%）提供了完整的开发者理由，214 条（71.3%）保留了完整的审计字段集合，能够连接所选的各个阶段。目标符号在开发者理由中出现的比例为 62.6%，在补丁中为 62.8%，若计入相关符号则提升至 75.8%。
在配对的 100 案例对比实验中，使用关系型工作流解决了 19 案例，而直接同输入条件下仅解决 9 案例。由于两组条件在 Analyzer 输出、图衍生的蒸馏信息以及 Judge 记录上也存在差异，我们将此结果报告为工作流层面的初步证据，而非图组件的因果效应。
总体来看，THEMIS 将原本隐式的需求‑修复转换显式化，使得修复决策在各阶段的持久性、对齐性和演化过程能够系统化检查。
点评