为什么 AI 做的重构经常编译不过？这周看到一篇论文，作者没猜原因，是手动一条条数出来的。
拿 10 个开源 Java 项目，让 LLM 去做重构，跑原生测试套件。失败的案例一个个看过去，归类。这种笨办法我喜欢。
数出来的东西挺有意思。失败原因排第一的是上下文误解或幻觉，占 24.3%。第二是重命名改得不一致，15.3%。第三是它顺手加了新功能或新变量，13.7%。
这三个加起来超过一半。记住这个比例，下面还要用到。
RefactorAssist：论文自己提的修法
论文提出了个方法，叫 RefactorAssist。思路不复杂，分两步。
第一步是静态修复。缺的 import、不平衡的括号、编译错误，先不用 LLM，直接用静态手段修掉。这一步很老实。能不用 AI 的地方就不用 AI。
第二步才是 agent 出场。错误日志加代码 diff 喂给它，测试引导着修。剩下那些失败案例，这一步最高修掉 70.8%。最优配置下累计测试通过率 94.2%。
点评：数字好看，但我更在意的是那张失败原因清单。工具会迭代，清单不会过时。
那张清单比 94.2% 值钱
简单说，排前面的三个失败原因，每一个都对应一个普通人今天就能用的动作。
幻觉占四分之一，意思是喂给它的上下文不够或者太乱。解法是把要动的文件、不要动的文件说清楚。这就是 prompt 里“具体、分步”那条老建议。只不过这次有人数了个数，证明这条建议值多少。
重命名不一致 15.3%，是它改了一处忘了另一处。这种活，事后跑一遍全局搜索，比自己肉眼盯靠谱。
顺手加功能 13.3% 那条，最像人。你让同事改个方法名，他顺手“优化”了三行，你也想骂。解法一样：改完看 diff，不认识的改动就问。
所以这份清单可以理解为一份“AI 改完代码后你该检查什么”的清单。不用等 RefactorAssist 出工具版，今天就能照着查。
先静态修，再让 agent 动手
这个顺序值得单独说。我之前收过类似思路的，不是第一次出现。能不用模型的地方用确定性工具，把 LLM 留给真正需要判断的部分。
括号不平衡这种事交给 LLM 修，属于杀鸡用牛刀，而且牛刀还偶尔砍偏。静态检查一秒出结果，永远不幻觉。
普通人版本：让 AI 改代码之前，先把自己项目里能跑的 lint 和测试跑通。不是废话。很多人是在测试本来就红着的仓库里让 AI 改代码，改完红了也分不清是新伤还是旧伤。
94.2% 这个数，补一句
通过率是 94.2%，不是 100%。剩下那 5.8% 论文里没细说怎么失败的。这条我其实只看懂了一半，先放在这里，回头把论文再翻一遍，懂了补上。
还有一点想说清楚。这是 10 个 Java 项目的测试通过率，不是“AI 重构可以放心裸交”的意思。测试过了不代表行为没变。这个老规矩在 AI 时代只会更重要，不会更松。
这周真正想留给你的一句话
那 24.3% 的幻觉失败，翻译成白话就是：AI 改错代码，四分之一的锅在提问的人。
这话可能说重了。但方向是对的。与其换更贵的模型，先把上下文喂干净。后者免费。
本周就这些。
上面有任何一条你试过、或者觉得我讲错了，欢迎告诉我。讲错的我补，没讲清的我改。
下周见。