使用LLM重寫過時的開源項目

大型語言模型（LLM）正在從根本上改變軟件開發的成本結構，特別是對於重寫現有開源項目這一任務。在過去，重寫一個成熟的、經過長期打磨的開源項目可能需要數年時間，因為需要處理數十年積累的邊緣情況、平台兼容性和隱含的設計決策。但如今，這些障礙正在被消除。

本文的作者來自一家名為Architect的公司，他們正在經歷一場這樣的重寫。由於使用了LLM的幫助，他們預測對關鍵工具CRIU（Checkpoint/Restore In Userspace）的重寫將在幾個月內完成，而不是通常需要的幾年。CRIU是Linux上唯一能夠實現進程檢查點/恢復的工具，它被集成在runc、podman和整個Kubernetes生態系統中。然而，這個擁有十多年曆史的項目正在變得陳舊：其代碼庫是C語言，主頁仍然運行着過時的MediaWiki實例，並且維護者面臨AI生成的大量補丁和錯誤報告，這些報告看似正確卻需要耗費大量精力審查。

文章深入分析了開源項目為什麼會過時。首先，維護者是人，他們的熱情會消退。一個項目在初期充滿活力，但隨着時間推移，維護工作變得乏味，導致核心開發者逐漸離開。其次，世界在變化：Go、Rust、Zig等新語言出現，eBPF和io_uring等新功能被引入內核，但成熟的代碼庫很難適應這些變化。第三，大型項目往往停止創新，因為穩定性和向後兼容性成為了首要目標，任何大的改動都難以被合併。作者將這種情況與大型公司類比：它們不創新，而是收購創新成果。但開源項目沒有這種機制，因此創新必須來自外部。

AI如何改變這種局面？關鍵在於LLM不僅能夠生成代碼，更重要的是，現有項目本身成為了一個可用的參考規範。數十年來積累的決策、邊緣情況和平台細節，曾經是重寫的最大障礙，而現在它們成為了驗證新實現的規範。開發者可以利用LLM快速生成符合這些規範的新代碼，而無需從頭摸索所有細節。AI不能替代架構設計和判斷力，但能夠顯著減少乏味的工作：編寫樣板代碼、處理平台特性、構建測試矩陣等。這使得重寫從“不可能”變為“在有限時間內可行”。

回到具體案例。Architect的核心業務是實時遷移工作負載，他們需要一個快速、可預測、能隨時修復的檢查點/恢復工具。CRIU雖然功能強大，但它的C語言代碼庫使得集成和優化變得困難。因此，他們決定用Zig重寫CRIU。選擇Zig的原因包括其現代特性、更好的內存安全性以及與現有C代碼的互操作性。利用LLM，他們能夠以原始CRIU為參考，快速生成新代碼，並針對自己的特定用例進行優化，擺脱了CRIU為了服務於所有可能場景而積累的複雜性。

當然，這並非沒有挑戰。Kernel接口、精確的進程狀態捕獲等核心難點仍然需要人工處理。但LLM極大地加快了開發速度。團隊計劃在幾個月內完成重寫，而不是通常的幾年。這篇文章提供了一個清晰的視角：AI並沒有使軟件開發變得簡單，但它使許多原本代價高昂的任務變得廉價，從而改變了重寫舊項目的經濟學。