内容
Can Bölük 的《Harness 问题》表明，对于编程智能体，hashline 风格的编辑 (以行号为锚点，例如 4#WB) 优于传统的 replace 模式编辑 (通过 old_string/new_string 匹配)。
我一直在尝试构建自己的 harness (tau)，想验证这一结果，看看是否应该考虑将 hashline 设为默认编辑策略。
于是，我构建了 edit-bench，亲自在多种语言和模型上进行测试。
测试设置
edit-bench 从现有代码库中生成基于变异的测试。 只需让脚本指向一个目录，它就会生成删除语句、翻转布尔值、交换参数等变异。
- 语言：Python (来自 hive)、TypeScript (来自 oh-my-pi)、Rust (来自 irradiate)
- 模型：
gpt-4.1-mini、google/gemini-3-flash-preview、qwen/qwen3.5-397b-a17b - 编辑模式：replace (old_string/new_string) 与 hashline (以行号为锚点)
- 每种语言 20 个任务，单次尝试、一次性运行
- 我最近还为
tau添加了模糊匹配 (逐级去除空白：trim_end → trim_both → unicode normalization)，想看看这是否有帮助
结果
Replace 模式：
| 模型 | Python | TypeScript | Rust |
|---|---|---|---|
| gemini-3-flash | 95% | 80% | 95% |
| qwen3.5-397b | 90% | 85% | 85% |
| gpt-4.1-mini | 65% | 75% | 45% |
Hashline 模式 (来自此前的运行结果)：
| 模型 | Python | TypeScript | Rust |
|---|---|---|---|
| gemini-3-flash | 70% | 85% | 90% |
| qwen3.5-397b | 85% | 85% | 90% |
| gpt-4.1-mini | 50% | 70% | 55% |
Hashline 明显降低了 Python 上的表现，而对 TypeScript 和 Rust 似乎大致没有影响。 这种与语言相关的差异很有意思——Python 的空白字符具有语法意义，这可能会让以行为锚点的编辑更容易出错。
模糊匹配有帮助吗？
看来没有。
我添加了执行轨迹收集功能，想看看在 replace 模式的运行中，tau 的模糊匹配逐级去空白机制是否会触发。在 114 次成功编辑和 20 次失败编辑中 (3 个模型 × 3 种语言)，模糊匹配触发了 0 次。
在这 20 次失败编辑中：
- 1 次存在行尾空白 (理论上可以修复)
- 约 8 次在
old_string中包含了行号 (模型错误) - 约 11 次的内容完全是凭空编造的
当模型能正确生成 old_string 时，空白字符也能处理正确。
而当模型出错时，往往错得离谱——逐级去除空白也无济于事。
(执行轨迹分析详情)
心得
-
Hashline 与 replace 之间没有明确的赢家。 效果因语言和模型而异。Python 上 hashline 表现更差；TypeScript 上没有明显差异；Rust 上则难分高下。
-
Can 的结果很难推广。 react-edit-benchmark 只测试 JavaScript，并使用 LSP 提供验证反馈。我们的测试设置 (没有 LSP，涵盖多种语言) 呈现了不同的结果。尤其是 LSP 反馈循环，很可能构成了混杂因素。向模型提供类型错误信息，让它据此重试，能带来实质性的提升，而这种提升又与编辑格式相互影响。
-
对于当前模型，模糊匹配要解决的问题并不存在。 大语言模型要么精确复现源文本，要么凭空编造出完全不同的内容。模糊匹配所针对的那种仅在空白字符上略有偏差的情况，实际中基本不会发生。
-
对于在当下 harness 中运行的当前一代模型，编辑格式并不是瓶颈。 模型之间的差距 (gemini-3-flash 达到 90%+，而 gpt-4.1-mini 为 55-65%) 远大于编辑格式之间的差距。在纠结编辑格式之前，先把精力投入模型选择和提示工程。
照例声明：样本量小，统计上不够严谨，请据此看待结果。
全部数据：nwyin/edit-bench，议题 #13 和 #14。