AI编程代理为何总犯低级错误

上周我让Claude Code重构一个模块。它读代码、分析依赖、生成新版本——一切看似顺利。可跑测试时直接崩了。翻遍日志才发现：它调用了一个早已废弃的API，而这个API的警告就写在它读过的文件注释里。它看了，却当没看见。

这不是第一次。每次AI编程代理出错，我都问同一个问题：它明明‘知道’，为何还犯？最近一篇arXiv论文给了我答案。

论文叫ToolFailBench，来自软件工程研究团队。他们系统分析大语言模型调用工具时的失败模式——不只看测试是否通过，而是深挖每一步操作哪里出了岔。结果惊人：整体分数常掩盖了工具调用的真实失败率。

结合论文与我的经验，我总结出五大典型错误。第一种：该用工具时不用。模型遇到需外部工具解决的问题，却误以为仅靠内部知识就能搞定，给出看似合理实则错误的答案。这在编程中极常见——比如该读文件A最新内容，它却凭记忆编了个版本。

第二种：用了工具但无视结果。这就是我开头的状况——模型读了文件，却完全忽略其中警告。它‘看了’，但没‘看见’。这不是能力不足，是注意力错配。

第三种：工具或参数选错。模型知道要用工具，却挑错工具或填错参数。比如该用grep却用了find，或关键字拼错。这类错误在多步任务中高发——连续调七八个工具，一步错，全盘乱。

第四种：工具执行成功，但理解错误。比如grep返回20行，模型只看前5行就下结论，后15行其实藏着关键信息。这与第二类相似，但区别在于：第二类是忽略结果，第四类是误读结果。

第五种：竞争冲突。当多个AI Agent同时操作同一代码库，会互相覆盖修改。有意思的是，同期另一篇arXiv论文专门研究AI Agent的PR冲突率，数据清晰：多个AI同时提PR，merge conflict率显著飙升，因它们不自觉改了同一文件。

这篇论文让我深受触动。我们常凭benchmark评分评判AI编程工具——SWE-bench、HumanEval，全是冷冰冰的数字。但ToolFailBench提醒我们：一个模型可能分数很高，却在实际中频繁栽在‘低智商’错误上——读文件马虎、用错工具、无视警告。这些才是最耗开发者耐心的。

作为日常使用AI编程的开发者，我能从中学到什么？

第一，必须手动验证。现在我养成习惯：AI说改好了，我先自己看一遍改动。不是不信任，而是它的注意力机制注定有盲区。关键修改后的显式检查，能省下大量调试时间。

第二，拆分大任务。多步骤任务的失败率呈指数上升。与其让AI一次做十步，不如拆成三个三步小任务，每步后都验证。尤其在AI Agent PR场景中，多个Agent协同几乎必然冲突。

第三，别迷信benchmark。选AI工具时，多看开发者论坛反馈、GitHub issue抱怨、社区踩坑记录。benchmark告诉你上限，论坛告诉你中位数。对日常开发，中位数才真实。

回到最初的问题：AI明明知道，为何还犯错？因为‘知道’和‘用对’之间隔着一道深沟。ToolFailBench把沟里的坑一个个标了出来。它不是颠覆性发现，却把模糊直觉转化成了可排查的清单。下次AI再翻车，你就知道是哪一种翻法了。

—— 老田