NEE's Blog

Harness 问题：为什么你的 AI 编程助手总在改代码时翻车

February 12, 2026

本文翻译自 The Harness Problem，原载于 Hacker News。

0x0: 问错了问题

现在关于 AI 编程的讨论几乎全都聚焦在”哪个模型最擅长写代码”——GPT-5.3 还是 Opus？Gemini 还是这周刚发布的新模型？

这种框架越来越具有误导性，因为它把模型当作唯一重要的变量。但实际上，瓶颈往往出在一个更 mundane 的地方：Harness（工具链/框架层）。

Harness 不仅决定了用户的第一印象（是疯狂滚动还是丝滑流畅），还是所有输入 token 的来源，也是模型输出与你工作区变更之间的接口。

我维护了一个”业余爱好级”的 harness——oh-my-pi，它是 Pi 的一个 fork（由 Mario Zechner 开发的优秀开源编程代理）。目前我已经提交了约 1300 个 commit，主要是玩票性质的改进，哪里有痛点就修哪里。

为什么折腾这个？Opus 确实是个好模型，但 Claude Code 到今天仍然会从子代理输出中泄露原始 JSONL，浪费数十万 token。我可以说”去他的，子代理现在输出结构化数据”。

Tool schema、错误消息、状态管理——从”模型知道要改什么”到”问题解决”之间的所有东西。这正是实际使用中大多数失败发生的地方。

由于模型无关，这是一个很好的测试场，因为模型只是一个参数。真正的变量是 harness，你对它有着难以想象的掌控力。

让我告诉你我昨天改的这个 变量。

0x1: 编辑工具的现状

在我解释自己做了什么之前，先了解一下业界现状。

Codex 使用 apply_patch：它接收一个字符串，本质上是 OpenAI 风格的 diff。它不依赖结构化 schema，harness 只是期望这个文本块遵循一套严格的规则。由于 OpenAI 的工程师肯定很聪明，我确信在 LLM 网关层，Codex 变体的 token 选择过程会被引导以适应这种结构——类似于 JSON schema 或必需的 tool call 等其他约束。

但把这个交给任何其他对此一无所知的模型？Patch 失败率飙升。在我的基准测试中，Grok 4 的 patch 失败率是 50.7%，GLM-4.7 是 46.2%。这些不是差模型——它们只是不”说”这门语言。

Claude Code（以及大多数其他工具）使用 str_replace：找到 完全匹配 的旧文本，替换为新文本。理解起来很简单。但模型必须完美复现每个字符，包括空白和缩进。多个匹配？拒绝。错误提示 “String to replace not found in file” 太常见了，甚至有自己的 GitHub issues 长帖（+27 个相关 issue）。不太理想。Gemini 本质上做同样的事情，外加一些模糊的空白匹配。

Cursor 训练了一个独立的神经网络：一个微调过的 70B 模型，唯一的工作就是接收草稿编辑并正确合并到文件中。Harness 问题太难了，以至于最有钱的 AI 公司之一决定再扔一个模型来解决它，即便如此，他们在自己的博客文章中也承认”对于 400 行以下的文件，完全重写整个文件优于 aider 风格的 diff”。

Aider 自己的基准测试 显示，仅格式选择一项就能让 GPT-4 Turbo 从 26% 提升到 59%，但 GPT-3.5 用同样的格式只得了 19%，因为它无法可靠地生成有效 diff。格式和模型一样重要。

JetBrains 的 Diff-XYZ 基准测试系统地证实了：没有单一的编辑格式能在所有模型和用例中占主导地位。EDIT-Bench 发现只有一个模型在现实编辑任务上达到超过 60% 的 pass@1。

如你所见，对于简单的”如何修改东西”这个问题，没有真正的”最佳方案”共识。我的 5 分钱观点：这些工具都没有给模型一个稳定、可验证的标识符来指明它想修改的行，而不浪费大量上下文或依赖完美回忆。 它们都依赖模型复现已看过的内容。当它做不到时——经常做不到——用户就会怪模型。

0x2: Hashline！

现在请耐心听我说。如果当模型读取文件或 grep 搜索时，返回的每一行都带有一个 2-3 字符的内容哈希标签：

11:a3|function hello() {
22:f1| return "world";
33:0e|}

当模型编辑时，它引用这些标签——”替换行 2:f1，替换范围 1:a3 到 3:0e，在 3:0e 后插入”。如果文件自上次读取后已更改，哈希（乐观地）将不匹配，编辑会在任何内容被破坏之前被拒绝。

如果它们能回忆起一个伪随机标签，很可能它们知道自己正在编辑什么。模型不需要复现旧内容，或者天哪空白字符，来表达一个可信的”锚点”来基于此表达更改。

0x3: 基准测试

由于我主要关心实际性能，测试用例生成方式如下：

  1. 从 React 代码库中随机取一个文件
  2. 通过可逆编辑引入突变，表述为 bug（例如运算符交换、布尔值翻转、差一错误、可选链移除、标识符重命名）
  3. 用纯英语生成问题描述

典型的任务描述看起来像这样：

# 修复 `useCommitFilteringAndNavigation.js` 中的 bug
一个守卫子句（早期返回）被移除了。
问题出在 `useCommitFilteringAndNavigation` 函数中。
恢复缺失的守卫子句（带早期返回的 if 语句）。

当然，我们不期望 100% 成功率，因为模型可能想出独特的解决方案，不一定是完全相同的文件。但这些 bug 是足够机械化的，大多数情况下，修复就是我们的突变被还原。

每个任务 3 次运行，每次运行 180 个任务。每次都是新的代理会话，四个工具（read、edit、write）。我们只需给它一个临时工作区，传递提示，一旦代理停止，我们就与原始文件进行比较（格式化前后）。

16 个模型，3 种编辑工具，结果清晰明了：

排名 模型 Patch Replace Hashline Δ Patch Δ Replace Tokens
1 Gemini 3 Flash 73.3% 70.0% 78.3% +5.0 +8.3 -21%
2 Kimi K2.5 66.7% 71.7% 76.7% +10.0 +5.0 -26%
3 GLM-4.7 51.7% 66.7% 71.7% +20.0 +5.0 -32%
6 Grok Code Fast 1 6.7% 66.7% 68.3% +61.6 +1.6 -49%
12 GPT-5.2 Codex 76.7% 81.7% 76.7% ±0.0 -5.0 –

Patch 是几乎所有模型最差的格式，Hashline 对大多数模型匹配或超越 Replace，最弱的模型获益最大。

Grok Code Fast 1 从 6.7% 到 68.3%，十倍改进，因为 patch 失败得太惨烈，模型的实际编码能力几乎完全被机械编辑失败掩盖了。MiniMax 翻了一倍多。Grok 4 Fast 的输出 token 下降了 61%，因为它不再在重试循环中浪费 token。

0x4: 所以呢？

Gemini 成功率提高 8%，比大多数模型升级带来的提升还大，而且零训练成本。 只是一点实验（和约 300 美元的基准测试费用）。

通常模型不是在理解任务上出问题。它是在表达自己时出问题。你在怪飞行员，但问题是起落架。

0x5: 关于厂商的一点话

Anthropic 最近封锁了 OpenCode——一个广受欢迎的开源编程代理——通过 Claude Code 订阅访问 Claude。

Anthropic 的立场”OpenCode 逆向工程了私有 API”表面上没问题。他们的基础设施，他们的规则。但看看这个行动传递的信号：

不要构建 harness。用我们的。

不只是 Anthropic。在写这篇文章时，Google 直接把我的 Gemini 账号禁了：

不是限速。不是警告。禁用。就因为运行了一个基准测试——同一个显示 Gemini 3 Flash 用新技术达到 78.3% 比他们最好的尝试高 5.0 pp 的基准测试。我甚至不知道因为什么。

这就是为什么这种做法是倒退的。我刚展示了不同的编辑格式可以提升 他们自己的模型 5 到 14 个百分点，同时减少约 20% 的输出 token。这不是威胁。这是免费的 R&D。

没有厂商会为竞争对手的模型做 harness 优化。Anthropic 不会为 Grok 调优。xAI 不会为 Gemini 调优。OpenAI 不会为 Claude 调优。但开源 harness 为所有模型调优，因为贡献者使用不同的模型并修复他们个人遇到的失败。

模型是护城河。Harness 是桥梁。烧掉桥梁只会让更少人愿意过河。

把 harness 视为已解决，甚至无关紧要，是非常短视的。

我来自游戏安全背景。作弊者对生态系统有巨大破坏性。当然，他们会被封禁、追杀、起诉，但一个众所周知的秘密是，最终安全团队会问，”酷！想告诉我们你是怎么绕过的吗？”然后他们加入防御。

当有人弄你的 API，并设法用他们的工具聚集了大量用户时，正确的回应是”告诉我们更多”，而不是”让我们批量封禁数千人；如果想解封请私信乞求。”

Harness 问题是真实存在的、可衡量的，也是现在创新杠杆最高的地方。

从”酷炫演示”到”可靠工具”的差距不是模型魔法。是工具边界上仔细、相当无聊的经验工程。

Harness 问题会被解决。问题是它会被一家公司私下为一种模型解决，还是由一个社区公开为所有模型解决。

基准测试结果不言自明。

所有代码、基准测试和每次运行报告： oh-my-pi

关键要点

  1. Harness 问题被严重低估：很多人把 AI 编程助手的问题归咎于模型，但实际上编辑工具的设计可能才是真正的瓶颈。

  2. 编辑格式影响巨大：仅改变编辑格式（从 patch 到 hashline），某些模型的成功率提升了最高 61 个百分点，这比大多数模型升级带来的提升还大。

  3. Hashline 是个好思路：通过给每行附加内容哈希作为稳定标识符，避免了模型需要完美复现原始内容（包括空白）的问题。

  4. 开源 harness 有独特价值：厂商只会为自己的模型优化 harness，但开源社区会为所有模型优化。

  5. 零成本获得显著提升：这个改进不需要任何训练计算，只是重新思考工具设计。

comments powered by Disqus