作者：默思編輯部 發布：2026-10-20
如果你最近關注程式開發圈的新聞，會發現一個清楚的模式正在成形：GitHub用14.5週、一名工程師搭配AI代理，把Copilot執行環境從TypeScript遷移到Rust；開發者Theo Browne花2.4萬美元，用Claude Opus 5.5把整個TypeScript編譯器重寫成Rust版本，聲稱通過全部18萬多項移植測試。這些案例背後有一個共同的問題值得認真討論：當程式碼的規模大到沒有人能逐行審查，我們要用什麼標準來判斷這次重寫「做對了」？
這波實驗最直接的吸引力在於數字對比過於懸殊。過去規模類似的語言遷移專案，通常需要整個團隊投入一到兩年；而GitHub這次只用一名工程師與約12萬美元token成本，14.5週就完成。Theo Browne的案例更誇張——他用Claude Opus 5.5只花約2.4萬美元就達成的效果，是他先前用OpenAI Codex模型嘗試、花費超過40萬美元卻只做到約84%相容度的十幾倍效率。對資源有限的團隊而言，這種成本結構的改變，確實可能讓過去「不划算、不敢做」的大型重構專案變得可行。
但支持這套做法的人很少正面回答一個問題：**沒有人讀過程式碼，要怎麼確定它是對的？**Theo Browne自己就坦承「我從來沒有讀過生成出來的程式碼」，這句話之所以引發討論，是因為它精準點出了整個模式的風險所在——傳統的程式碼審查流程，本質上是靠人類工程師理解邏輯來把關正確性；但當重寫規模大到18萬項測試、130萬行程式碼，唯一可行的把關機制只剩下「測試是否通過」。有後續討論指出，針對Browne的專案做過的覆核發現了70項失敗測試與比官方版慢2.6到3.4倍的建置速度——這個覆核結果本身的來源尚待進一步查證，但光是「存在這種質疑的空間」，就足以說明測試通過率不等於程式碼品質已被完整驗證。
值得注意的是，這兩個案例的風險等級其實不一樣。GitHub採用的是漸進式切換策略——用N-API互通層讓新舊程式碼並存、逐步替換，期間系統持續對外服務，就算某個元件出問題也能快速定位、不影響整體；而且GitHub自己承認重寫過程中確實出現了數十個迴歸問題，只是形容為「數量不多、很快修復」。相較之下，Theo Browne的專案更接近一次性的實驗性賭注，沒有漸進上線的安全網，正確性幾乎完全壓在測試覆蓋率上。
如果你的團隊也在考慮讓AI代理承接類似規模的重構任務，這兩個案例給出的借鏡其實很一致：真正能讓這類專案安全落地的關鍵，從來不是「AI模型有多強」，而是既有的測試覆蓋率夠不夠完整、能不能做到漸進式切換、以及是否保留足夠的回滾空間。把這些工程紀律準備好，AI代理帶來的速度與成本優勢才能真正轉化成團隊的生產力，而不是埋下日後難以追查的風險。
持續打磨看懂程式碼邏輯、而不只是依賴工具輸出結果的硬實力，歡迎參考Python課程。
參考資料