未必。
看到 HPFA 那篇论文的时候，我第一个念头不是“这方法多聪明”，而是“为什么之前大家都默认要用反事实测试”。
论文我不复述了，arXiv 上有。核心动作一句话：把一条失败的推理路径和一条成功的路径各自建成超图，对比超边，差异处就是根因候选。就这么简单。
我想说的也不是这篇论文，是这个动作背后被默认了很久的假设——找错误根因，就得“改一改这里，看结果变不变”。反事实测试听起来最严谨。改了 A，结果从错变对，那 A 就是原因。因果上几乎无懈可击。
问题在别处。这个方法随轨迹长度扩展性差到离谱。一条几十步的推理，每一步都可能是根因，组合起来要测多少次，算一下就知道。这不是工程优化能救的，是方法本身的形状不对。
换句话说，多数人把“严谨”和“逐步验证”划了等号。这个等号值得怀疑。
配对对比本来就是我们自己干的事。你 review 同事的代码，发现一个 bug，你不会把每一行都改一遍看测试过不过。你脑子里有一个“正确的写法大概长什么样”，拿它和眼前的代码比，差异跳出来，你直接就怀疑那里。没人管这叫不严谨。没人要求你对每一行做反事实。
那为什么轮到 LLM 推理，我们就突然要求逐步反事实了？
我想是因为轨迹是机器生成的，我们不敢相信自己“看得出来”。对比依赖直觉，反事实不依赖。于是我们选了那个不需要直觉的方法，哪怕它贵到用不起。
这里值得停下来想想。HPFA 的对比也不是人肉直觉，是把“成功路径长什么样”显式建成了结构。超图这个选择有理由——推理步骤之间的依赖不是线性的，扁平序列会丢掉这些依赖，丢了依赖的对比就是瞎比。所以严格说，它不是“用直觉代替验证”，是把直觉里真正起作用的那部分结构化，剩下的扔掉。
这比“人怎么做我就怎么做”要诚实。
你可能会反对说，对比出来的差异未必是原因，可能只是两条路径本来就走的不同。这个反问有道理。差异和根因不是一回事，失败路径和成功路径的差异点可能有一堆，哪个才是真根因，配对本身回答不了。¹ 但换个角度想，反事实测试也没回答这个。它只是把搜索空间全测了一遍，而全测和聪明地缩，得到的是同一种证据，只是一个买得起一个买不起。当准确率没差多少而成本差一个量级时，选择其实不艰难。
真正让我在意的，是论文里顺带提的那半句：归因数据可以规模化合成，拿去训一个轻量的归因模型，测试时还能反过来提升推理准确性。
这半句比 HPFA 本身重要。
因为它暗示的方向是，归因不再是一个分析动作，而是一个可以塞进推理循环里的模块。以前的失败分析是事后的、离线的、人做的。如果归因能被蒸馏成一个便宜的小模型，它就变成在线的——推理走偏的时候当场知道偏在哪，而不是跑完了再解剖。
如果我对，那么接下来值得盯的不是归因准确率再涨几个点，而是谁先把归因模型塞进 agent 的主循环里跑通。那才是这件事的终点形态，HPFA 这类方法只是往那边走的第一步。
开头的说法太绝对了，收紧一点说：反事实测试不是最笨的路，它是最贵的严谨。而工程上，最贵的严谨通常会被“够好的便宜”吃掉。这次大概也不例外。
¹ 严格说 HPFA 是“配对”归因，目标路径和参考路径的选取本身就有自由度。选错了参考，差异点会带偏根因。论文里怎么处理这个自由度，我没细看。这里我可能错了，但暂时这么认为。
² 反事实不是唯一被这个思路威胁的方法。所有“为了严谨所以暴力枚举”的验证类工作，大概都在同一条船上。
³ 逐步反事实在轨迹很短、且每步代价低的场景下仍然完全可行。我质疑的是它作为默认方法的地位，不是它的有效性。