背景：三週、四千美元、三十萬行程式碼
CodeScene 近日公布一份案例研究，內容是讓 coding agent 對一個約 30 萬行的 C 語言程式碼庫進行大規模重構。整個過程歷時三週，token 成本約 4,000 美元，產出 2,903 次提交，涉及 726 個檔案，改動 252,055 行。用來衡量內部品質的 Code Health 分數，從 5.6 升到 10.0。這個程式碼庫是《Street Fighter III: 3rd Strike》的反編譯開源專案，也就是把遊戲的原始機器碼還原成可讀、可重新編譯的原始碼。CodeScene 創辦人 Adam Tornhill，同時是《Your Code as a Crime Scene》的作者，他寫道，在處理大型系統三十年之後，這是他第一次在規模化場景看到他所謂的「超人類 AI 表現」。這份案例由 InfoQ 記者 Steef-Jan Wiggers 報導。
核心機制：一個可優化的分數，加上逐幀比對的正確性檢查
這項工作能成立，靠的是兩個機制。第一個是品質訊號：CodeHealth MCP Server 提供一個確定性的分數，讓代理知道自己該優化什麼，也能判斷某次改造究竟有沒有幫助。第二個是正確性：一套 replay-trace 測試框架，逐幀比較 rollback state hash，因此每次變更之後都能檢查行為是否保持一致。這種做法的關鍵在於「oracle」，也就是一個能自動判斷新舊版本行為是否等價的裁判。對反編譯後的格鬥遊戲而言，相同的輸入會產生相同的畫面與狀態，因此可以逐幀重播並比對；這讓代理在沒有人逐行審查的情況下，仍有一個客觀依據判斷改動是否安全。
代理自己長出的重構手冊
比數字更值得注意的是代理在過程中累積出來的東西。它們並沒有套用一份固定的重構目錄，而是逐步累積出一本重構手冊（playbook），最後包含 22 條 recipe 與 82 則輔助筆記。裡面有些是熟悉的手法，例如 Extract Function 與 Guard Clauses；也有一些是針對這個程式碼庫長出來的專門手法。Shared Index Range 用來捕捉那些只有起始與結束範圍不同、其餘部分重複的迴圈；Action Parameter 處理的是控制結構重複、主要差異只在於呼叫哪個函式的狀況；Uniform Step Table 則把異質的呼叫轉換成表驅動分派。失敗的嘗試同樣被記錄下來，包括那些讓 Code Health 反而變差的轉換。這一點相當重要：它意味著代理不只產出程式碼，也產出了一份可累積的經驗文件，而這份文件本身可能就是後續自動化的資產。
模型選擇與工具鏈的影響
模型選擇在這項工作中占有一席之地。團隊最後以 Claude Opus 承擔大部分工作，並表示 Claude Code 搭配 Opus，在捕捉與記錄這些新興模式上，明顯優於 Codex 搭配 Sol。當較小的模型執行同一任務時，檔案的 Code Health 經常停在某個水準就上不去，看似達到了一個無法跨越的局部最佳解。三週專案中每日非合併提交數依模型分佈，也被用來佐證這個差異。
從業者的分歧：不是數字，而是產生數字的條件
在 LinkedIn 上，實務工作者對這份案例的反應明顯分裂，而分歧點在於「它證明了什麼」，而不是「它有沒有發生」。支持者 Paolo Perrone 指出，多數重構宣稱建立在測試套件維持綠燈之上，那只告訴你測試還活著；把重播軌跡拿去比對一款格鬥遊戲，標準高得多。Omda Response 技術長 Mats Iremark 則說自己做過類似的事，CodeScene 的 MCP 加上當前的代理，幾乎像是作弊。
懷疑的一方集中在範圍與適用性。技術主管與顧問 Konrad Otrębski 追問：這些改動有沒有被合併？是變成一個巨大的合併，還是多個合併？這是不是在開源程式碼上做的實驗，而不是在真正賺錢的生產程式碼上？NeoSee 技術長 Daniel Webb 是實際執行這項工作的兩位工程師之一，他回應說，程式碼已透過 54 個 pull request 合併到 fork 的 main 分支。Otrębski 接著把標準拉高：他認為真正檢驗 AI 能力的方式，是把這種重構提供給知名開源專案，例如 Grafana，而完成的定義當然是合併進 master。
也有針對方法與定義的質疑。軟體架構師與研究者 Tracy Bannon 反對的是論述框架，而非方法本身，她認為把結果描述成「完美」相當大膽。Denis Baltor 則質疑那些被發現的 recipe：DRY 關注的是知識與意圖的重複，而不是相同的程式碼行；用「只有範圍不同的迴圈」或「只有呼叫函式不同的控制結構」來定義 recipe，可能把這兩件事混為一談。Asko Nõmm 提出的則是方法論問題：Claude Code 與 Codex 各自針對自家模型調校，因此很難判斷結果有多少來自模型、多少來自測試框架，成本也會以同樣方式變動。他補充說，架構層面仍未受到衡量，程式碼可能看起來健康，但根本問題日後才浮現。
作者自己留下的未答問題
幾個沒有答案的問題來自團隊成員本身。Marc Bouvier 問到非功能行為是否改善，因為對一款遊戲而言，幀率、記憶體用量與輸入延遲都很重要；Webb 說團隊正準備引入一位效能專家。被問到測試框架是否能捕捉細微的幀時序回歸時，他坦言可能沒有定論，因為它是作為 pre-commit hook 執行，有些失敗在被觀察到之前就已經修掉了。至於 diff 大小，他的回答同樣直接：如果你不熟悉這份程式碼，而且不再逐行審查，那麼一個 diff 可以有多大？他沒有給出斷言，只留下問題。
沒有 oracle 的現實：為什麼多數遺留系統難以複製
如果這些反應具有代表性，那麼爭論的核心不在數字，而在產生這些數字的條件。replay-trace 之所以可行，是因為反編譯後的遊戲提供了確定性的逐幀重播；大多數遺留系統並沒有等價的裁判機制，而這也正是重構它們本身就有風險的原因。Tornhill 寫道，自動化測試與等價性檢查是絕對必要的保障，這等於把責任放在不健康程式碼庫往往最欠缺的那一點上。團隊自己的選擇過程也說明了這件事：Webb 表示他們曾考慮他參與過的英國政府 marine licensing 程式碼庫，但它太健康了，對後續研究沒有用處；他們選擇這款遊戲，部分原因是他們自己就在玩，因此是它的使用者。
後續研究與被外推的數字
這項提升帶來了兩個功能等價的系統版本，一個 Code Health 為 5.6，另一個為 10.0，將用於與 Lund University 合作的研究：學生會用前沿模型在兩個版本上實作功能，並比較成本與品質。有兩個標題數字屬於這項未來工作，而不是本次案例：CodeScene 預估這次提升可讓 AI 引發的缺陷減少約 70%、token 浪費減少約 45%，兩者都是從早先研究外推而來，並非本案例的實測結果。4,000 美元與三週，則是實測數字。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。