防止编程智能体把补丁改到别处

AI 编程助手可能写出了正确的修复，却把它放进了另一个 Bug 的分支。原文讨论的就是这种错位：症状相似、代码结构相近，再加上不断追求测试通过，容易让一次修复扩散到无关位置。

作者给出的结论是：先确认一个根因和具体位置，再逐块审查改动是否服务于它。对日常让 Agent 修 Bug 的程序员，这篇短文提供了一套约束修改范围的办法，但没有实验数据证明它能降低多少出错率。

为什么修复思路对了，修改位置却错了

典型场景是一个会话里堆着多个问题：两个失败案例、几份堆栈，以及几个长得很像的文件。Agent 如果从症状直接跳到修改，就可能把「看起来相关」当成「已经确认」。

例如，两个函数结构相似，或者同一句错误信息出现在两条执行路径中，原本适用于 Bug A 的修改，就可能落到 Bug B 所在的分支。缺失的环节是定位：究竟哪个文件、哪个符号、哪条分支产生了错误值？

另一种偏移发生在第一次修改之后。作者认为，Agent 对构建成功和检查通过的追求，会促使它在原修改无效时继续调整相邻代码。最后，真正的修复和无关修改混进同一份 diff，测试变绿又让后者更容易被忽略。

这里讨论的是一种行为解释。原文没有交代具体模型、提示词或实验过程，也没有证明所有 Agent 都会以相同方式扩展修改。

哪些看似顺手的修改，最容易让修复越界

作者列出了三类常见形态。

第一类是复制防御逻辑。发现某处需要空值检查或超时处理，就给所有相似位置都加一遍。问题在于，其他调用点可能根本不会接收到触发故障的输入。代码长得像，不足以成为同时修改的理由。

第二类是全局重命名或替换。目标标识符改对了，另一个原本合法的用法也被改掉。替换操作覆盖了哪些位置，和故障实际经过哪些位置，是两件需要分别确认的事。

第三类是顺手夹带重构、格式化或依赖升级。这些改动可能各有价值，但如果与当前故障没有关系，就会增加审查负担，也让后续回退更难判断。

测试通过，只能证明被检查的路径通过了，不能证明每一处修改都有必要。

因此，审查不能停在「现在能跑了」。还要追问：这个修改位置能否接收到失败输入？这一块 diff 是否确实在处理同一个根因？

怎样把一个 Bug 收紧成一次可审查的修改

作者建议先定位，再编辑。让 Agent 指出文件、符号，以及错误值产生的具体行或分支，并用一句话说明根因。如果这句话还不能明确指向一个原因，就不宜开始修改。

接着补一个能复现问题的测试：修复前失败，修复后通过，同时确认相关的无关行为没有变化。前者说明修复命中了故障，后者用于检查它有没有影响旁边的正常路径。

最后逐块检查 diff。这里的 hunk，就是 diff 中一段连续的修改。每一块都要回答同一个问题：它是否服务于已经确认的根因？答不上来的，拆出去或删除。

提交也应保持单一目的。同一根因对应一次原子提交，无关改动另行处理，才能独立审查和回退。原文还提到 Powerduck 的 changes-only 视图与 revision anchors 可以辅助这项检查，但没有展示操作过程或效果对比。

多个 Bug 能否一起修，也遵循同一标准：只有确认它们共享一个根因，才适合合并处理。症状相似并不够。

我的判断

我认同作者把「修改是否必要」单独列为审查目标。测试回答的是已有断言是否满足，diff 审查还要回答修改范围是否合理，两者承担的任务不同。

但「一个根因」不能机械理解为「只准改一个文件」。一个原因可能需要调整多个位置，关键是能否解释它们与失败输入之间的关系。反过来，即使只改了一行，也可能改错分支。

这套方法也依赖定位能力。如果团队没有稳定的复现输入，或现有测试覆盖很薄，让 Agent 写出一句根因，并不会自动让判断变可靠。那句话应当能由输入、堆栈和执行路径支撑。

与单纯要求 Agent「多跑测试」相比，作者补上了修改必要性的检查；与完全依靠人工审查相比，失败测试又提供了可重复验证的依据。不过，原文没有对照数据，也没有具体失败案例，应把它看作一套有道理的工程经验，而非经过量化验证的方案。

能拿来做什么

• 给 Agent 修前端或 Node 故障时，先提供失败输入和堆栈，要求它在编辑前指出文件、函数或符号、出错分支，以及一句话根因。
• 遇到批量添加空值检查、超时或全局替换时，逐个要求解释：失败输入如何到达这个位置。无法建立路径的修改应当拆出或删除。
• 验收时同时检查失败测试和 diff。测试需要经历修复前失败、修复后通过，每一块修改也都应能对应到同一个根因。
• 同一会话里有多个问题时，先判断是否共享已确认的根因；如果只是报错相似，就分别准备测试和提交。