AI 改文件的三种流派：为什么换个编辑工具，同一个模型就变笨了

Sun, 20 Sep 2026 08:00:00 +0800

📄 本文综合改写自 Paul Pham 发布在 DEV Community 的《Deep Dive into Editing Tools in AI Coding Harnesses》，并补充了 Codex V4A 补丁格式的技术分析资料，原文链接见文末。

同一个模型，在 Claude Code 里改代码顺顺当当，换到另一个 harness 上就开始频繁报错，错误信息还都长一个样：「String to replace was not found」。

把模型换掉再试，换两三个，还是一样。

但这不是模型变笨了。问题出在更下面一层：Agent 究竟是怎么把「我要改这里」这个意图，变成磁盘上真实发生的变动。

这一层有个不太出名的名字，叫编辑原语（edit primitive）。它平时完全不露面，可一旦它不合格，再强的模型也会在「把 print("hello") 改成 print("hello world")」这种级别的活上翻车。

一、模型其实碰不到你的文件

先说一个容易被忘记的事实：大语言模型不能直接操作文件系统。

它唯一的输出通道是文本。所以它必须先把改动「描述」出来，再由外面的 harness 解析这段描述，落到真实文件上。描述格式设计得好不好，直接决定了落地的成功率。

这件事有两个无法回避的设计张力。

第一，行号不可信。模型会幻觉行号，尤其是在前面几轮编辑已经让内容整体位移之后。任何依赖绝对行号的格式，早晚都会崩。

第二，整文件重写太贵。为了改一行代码而吐出整个文件，token 成本高，出错概率也不低，文件越大越明显。

所以主流 harness 最后都收敛到了同一条路：用周围代码作为锚点，而不是用行号定位。方向一致，但格式细节上分岔得很厉害。而那些分岔的地方，恰好就是失败的来源。

Claude Code 走的是最直白的一条。它的结构化 Edit 工具接受一对参数：old_string 和 new_string。harness 拿着 old_string 在文件里找，找到唯一匹配就替换。

好处是心智模型极简。没有格式要学，模型不需要背任何语法，读起来也一目了然。

代价藏在「唯一」和「逐字符」这两个词里。锚点必须在文件中唯一出现，而且必须完全一致。多一个空格、缩进从四个空格变成 tab、行尾多一个尾随空格、文件被 formatter 重排过一次，匹配立刻失败。

这类失败在 Claude 自家模型上相对少见，因为这套 harness 是围着它们调优的，模型很熟悉这个工作流。可一旦换成通过 OpenRouter 接进来的其他模型，尤其是参数量较小的开源模型，失败率就明显上来了。