內容
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 項任務，每次執行皆採單次嘗試、one-shot 方式
- 我最近也為
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 的空白字元具有語法意義，可能讓以行號定位的編輯更容易出錯。
模糊比對有幫助嗎？
看來沒有。
我加入了執行追蹤資料的蒐集功能，想看看 tau 逐級去除空白的模糊比對機制，是否曾在 replace 模式執行過程中觸發。在總計 114 次成功編輯和 20 次失敗編輯中（3 種模型 × 3 種語言），模糊比對的觸發次數是 零次。
這 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。