一句话定义：Root-Cause Fixing（根因修复）指修 bug 时改动的是问题产生的真正机制；与之相对的 Symptom Fixing（症状修复）只是把暴露问题的表面现象压下去，让报错暂时不再出现。
打个比方：厨房天花板滴水，症状修复是拿个桶接水、或者把水渍刷一层漆；根因修复是上楼找出哪根管子裂了、把它换掉。桶接满了还会溢，漆干了水渍还会回来。
为什么这成了评价编码智能体的新标准。过去看模型写代码，一个常见指标是“跑完测试全绿”。但绿灯太容易被骗：改断言、把异常用 try/except 吞掉、给测试加 sleep、对特定输入写特判分支——测试确实绿了，程序其实更脆。于是评价口径从“结果绿不绿”转向“它有没有找到真正的因”。
判断治标还是治本，可以看三步：
1. 复现（Reproduction）。它能不能说清触发条件，并在动手前稳定复现？只会在既有的那条失败用例上通过的改动，往往是对着答案写代码。
2. 因果定位（Causal Localization）。改动位置和故障机制对不对得上？它能不能解释“为什么改这里，那里就好了”。典型症状修复特征：改在报错行附近但不解释机制、加空值兜底、调大超时时间、吞掉异常。
3. 回归验证（Regression Verification）。修完后，复现用例转绿，同时相邻功能的用例不被破坏；更硬的一条是反向验证——把根因处的代码还原，故障应当重新出现，说明这条测试真的有鉴别力，而不是被顺手改宽松了。
| 维度 | 根因修复 | 症状修复 |
|---|---|---|
| 改动位置 | 故障机制所在处 | 报错冒出来的地方 |
| 对失败用例 | 让它因正确的原因通过 | 改断言、加特判、吞异常 |
| 可解释性 | 能讲清因果链 | “反正现在不报错了” |
| 后续影响 | 同类问题一起消失 | 换条路径又炸，缺陷后移 |
和相邻概念的区别。加防御性检查、调参数上限本身不等于症状修复，关键判据是：你知不知道自己在绕过什么。知道、并且记下来（留 TODO、开 issue、限定时限），那是合理的临时止血；不知道、还把它当成修好了，那就是治标。同样，重构（Refactoring）改的是结构，根因修复改的是因果，两者常一起发生但不是一回事。
实际意义。对 AI 从业者：评审智能体的产出时，别只看 CI 是否全绿，要看 diff 有没有解释力，是否敢做反向验证；这也是当下区分模型“会写代码”和“会修问题”的实操口径（各类榜单口径不一，以官方页面为准）。对普通职场人：一份报告数字对不上，把差额塞进“其他”是症状修复，找出是哪张表口径不同才是根因修复——“问题不再出现”和“没人再提这个问题”，从来不是同一件事。