AI生成的程式碼難以維護分支

如果你曾經維護過一個專案的分支，或者提交過一個長期未能合併的拉取請求，你很可能對這種情況感同身受：上游程式碼不斷更新，當你執行 git rebase 或 git merge 時，原本獨立且整潔的變更突然被合併衝突覆蓋。有時這還可以應付——鄰近的函式改變、檔案移動、型別重新命名，花幾分鐘修復並重新執行測試即可。但有時情況遠沒有那麼簡單。維護者可能對整個專案進行了格式化，或者重新組織了所有模組，甚至重寫了你的變更所依賴的內部結構。這時你的分支不再是一個分支，而變成了一個考古專案。

這種痛苦由來已久。它不僅涉及枯燥的機械性工作，還伴隨著風險。你最初編寫的版本是基於特定的上游狀態進行測試的，你對周圍的程式碼瞭如指掌，每一行都有合理的原因。但經過三次痛苦的變基後，目標悄然改變——你不再試圖保留原始變更的質量，而只是想讓程式碼重新編譯透過，讓測試透過，在解決相同概念衝突於五個略有不同的檔案時保持理智。於是，原本不存在的錯誤和安全漏洞被引入，分支的質量在每一次變基後逐漸下降。

令人煩惱的是，過去這種情況相對罕見。大規模、影響廣泛的上游變更確實存在，但它們需要付出真正的人力成本。維護者必須判斷一次大規模重構是否值得付出痛苦，並且必須親自動手完成。因此，大多數專案存在某種自然的阻力。然而，人工智慧消除了大量這種阻力。雖然廉價實驗很有用，但它也改變了提交的形態。在“氛圍編碼”的專案中，提交往往變得非常龐大，以至於成為一種模式。一個提示詞產生了一個影響廣泛的差異（diff），維護者檢視結果、執行測試、認可方向，然後提交。一次提交，大量更改。生成那個差異的成本微乎其微，但其他人整合它的成本卻很高。

一次大型的AI生成重構對於按下回車鍵的人來說可能很便宜，但對於任何維護本地更改、下游補丁集或長期執行的拉取請求的人來說，代價可能極其高昂。專案不僅改變了行為，還改變了形態。而分支依賴於形態。分支不僅僅是程式碼的副本，它是一系列關於程式碼位置、函式劃分、哪些內部邊界足夠穩定可以構建其上、哪些檔案可以在不影響其他部分的前提下更改的假設。當每一次上游提交都重新洗牌這種形態時，分支就失去了錨點。

對於那些重要但無法立即合併的改動來說，這尤其糟糕。維護者可能同意想法但希望採用不同的API；改動可能需要更多測試；可能對某個部署有用但對上游來說太特殊；或者專案審查進度緩慢因為大家都很忙。如果上游專案不斷被提示詞重寫，那麼理智合併的視窗就會大大縮小。要麼你的工作迅速合併，要麼立刻開始腐化——不是因為邏輯錯誤，而是因為周圍的程式碼被攪成了另一種形態。一段時間後，維護分支變得幾乎不可能。你可以停止從上游更新，這意味著分支慢慢變成獨立專案；你可以繼續變基，這意味著花費越來越多的時間修復無關全域性編輯造成的損害；或者你可以放棄，讓AI從零生成你自己的競爭版本。

最後一個選項很糟糕，但恰恰是激勵導向所在。如果上游將程式碼視為可隨意根據心情全域性重寫的可丟棄文本，那麼下游使用者最終也會以同樣的方式對待上游。為什麼還要費心維護一個拒絕保持穩定形態的專案的分支呢？

故意的大規模變更和隨意的變動之間存在區別。人類的重構通常會留下一些“傷疤”。你可以看到維護者試圖最小化損害：差異有邊界，提交訊息解釋原因，出現相容層，舊路徑存活一段時間，審閱者詢問這是否會傷害下游使用者。而AI生成的程式碼自然不會關心這些。它最佳化的是滿足當前工作區中的提示詞，不知道某人的分支中存在哪些補丁系列，不關心一個小函式重新命名會在十個未合併的拉取請求中造成衝突，也感受不到讓其他人重做工作的社會成本。可分支性曾經是專案的一個品質，而AI使得摧毀它比以往任何時候都更容易。