敲打旧代码：LLM改的对不对，得看它怕不怕砸

1问题

科学家们现在喜欢用大语言模型（LLM）来给老旧的科学软件“换皮”。比如，他们把几十年前的 Fortran 代码，让 LLM 改写成现代的 Python 或 C++，好让这些老古董跑得更快、更稳。这事儿听着挺美，但有个大坑：我们怎么知道 LLM 改出来的新代码，真的继承了老代码的“脾气”？

以前的验证方法太简单了，就像你修好了汽车，只试了它能不能发动，没试它撞墙会不会散架。老代码里藏着很多细节，比如某个位（bit）突然翻转了，或者精度稍微低一点，老代码可能只是抖一下就过去了，但 LLM 改的新代码可能直接崩溃，或者算出完全错误的结果。如果不把这些“坏情况”测出来，直接上线生产，那就是在埋雷。作者发现，光看“正常运行”是不够的，必须得给代码制造点人为的“故障”，看看它能不能扛得住。这就是他们要做的——给 LLM 改的代码做一场“暴力测试”。

2翻译

为了验证 LLM 改的代码到底行不行，作者想了个绝招：差分故障注入。这就像是给两个医生（原始代码和 LLM 改的代码）做同一场手术，但手术过程中，作者故意在同一个位置搞点小破坏，看看两个医生处理坏结果的能力是不是一样。

这个方法的核心组件，是一个叫 SCF 的驱动程序。它是整个科学计算软件的“心脏”，负责指挥计算。作者在这个心脏上选了 12 个关键位置，人为地制造故障。这里的类比是：这就像给汽车刹车系统做测试，你不仅看车能不能开，还要看在急刹车时，刹车片会不会过热失效。

他们一共跑了 2200 多次实验，数据非常漂亮：1. 瞬态故障吸收成本：当故障发生时，代码需要多少次迭代才能“自我修复”。预测值和实测值几乎完全吻合，比如预测每增加一位故障需要 0.74 次迭代，实测是 0.82 次。2. 持续扰动：如果故障没被修复，最终算出来的能量误差会怎么样。结果发现，每增加一位故障，最终能量误差就会减半。3. 匹配率：在 200 组对比测试中，原始代码和 LLM 改的代码对故障的反应完全一致。

除了验证成功，他们还发现了一个反直觉的副发现：在精度降低的情况下，LLM 改的代码反而比老代码更不容易出现“假收敛”。老代码在精度不够时容易骗自己说“算完了”，而 LLM 改的代码虽然慢点，但更诚实。

3核心概念

1. 差分故障注入：这是主角手里的武器。它不是简单地把代码跑一遍，而是人为地在代码里制造错误（比如把 0 变成 1），然后对比原始代码和 LLM 改的代码在出错时的表现。如果表现不一样，说明 LLM 没改好。2. SCF 驱动程序：这是被测试的“靶子”。它是科学软件中负责迭代求解的核心组件，非常复杂且关键。作者选择它作为测试对象，是因为它是整个软件的“大脑”，如果它坏了，整个计算就废了。3. 位翻转：这是故障的具体形式。在计算机里，数据都是 0 和 1 组成的。作者人为地把某个 0 变成 1，或者把 1 变成 0，模拟硬件老化或干扰带来的错误。这就像给电路板通了个高压电，看看会不会短路。

4洞见

代码不仅仅是“运行正确”，它还有“性格”。老代码经过几十年的打磨，对错误有特定的容忍度和处理机制。验证 LLM 改的代码，不能只看它能不能算出正确答案，更要看它在面对错误（故障、精度下降）时，是不是继承了老代码的“性格”。

5博导审稿

“选题眼光不错，直击痛点。”

“方法设计很扎实。把故障注入和 LLM 验证结合，这个思路很聪明。特别是那个 12 个测试点的选择，既覆盖了关键路径，又控制了实验规模，很务实。”

“实验诚意很足。2200 次运行，数据对比清晰，还有那个‘假收敛’的发现，说明你们真的在深入挖掘代码的行为，而不是只看表面数字。”

“不过，有一点隐忧。你们只测了 SCF 驱动程序这一个组件。虽然它是核心，但整个软件还有其他模块。如果其他模块和 SCF 交互时出了问题，你们的方法可能就测不到了。另外，那个 12 个点是不是有点少？万一漏掉了某个关键位置呢？”

“总体来说，这是一篇非常有说服力的验证论文。虽然方法本身不算颠覆性创新，但它是工程实践中的刚需。”

判决：Strong Accept。

6启发

这意味着你可以：1. 迁移：把这套“故障注入”的测试方法，移植到你手头维护的任何老旧系统上，用来评估新换的组件是否靠谱。2. 混搭：把“差分测试”和“LLM 代码审查”混在一起。先用 LLM 改代码，再用故障注入测代码，形成一套完整的自动化验证流水线。3. 反转：不要总想着让 LLM 改代码变得“完美无缺”。如果 LLM 改的代码在出错时表现不如老代码，那也许我们可以反过来，利用 LLM 来“修复”老代码的错误处理机制，而不是仅仅翻译逻辑。