【編者按】如今生成式 AI 逐漸融入軟件開發流程，越來越多 AI 生成的代碼出現在實際工程中——但你有沒有想過，這些由 AI 寫出來的代碼，從一開始就可能被視為“遺留代碼”？本文作者從工程經驗出發，結合 AI 的生成機制，提出一個頗具啟發性的觀點：AI 生成的代碼缺乏上下文記憶和維護連續性，因此一誕生就處于“他人舊作”的狀態。這不僅是對當前 AI 編碼能力的冷靜觀察，也為我們理解未來軟件開發形態提供了一種新視角。

原文鏈接：https://text-incubation.com/AI+code+is+legacy+code+from+day+one

翻譯 | 鄭麗媛

出品 | CSDN（ID：CSDNnews）

在軟件開發中，代碼的“可改進性”往往取決于其所處的生命周期階段。通常可以分為以下幾類情況：

• 當某段代碼是你自己剛寫的：“哦，確實可以改成那種寫法，應該不難。”

• 當某段代碼是別人剛寫的：“可能是出于最近的一些臨時情況才這么寫的吧。如果真有需要，我可以考慮調整一下。”

• 當某段代碼是你以前寫的：“嗯，其實當時應該那樣寫。如果有必要，等忙完手頭工作了我再優先處理吧。”

• 當某段代碼是別人以前寫的：“他為什么要這么寫呢？不過應該沒必要動，等真的出問題再說。”

總的來看，代碼的演進速度，通常取決于離它的編寫時間有多近、維護者是不是原作者。

其實，這種狀態是合理的：對于一個運行穩定、經過驗證的軟件系統而言，貿然進行“改進”往往帶來額外風險，尤其是當你對系統的整體脈絡不甚了解時，原作者通常才最清楚其潛在邏輯和開發背景。

AI 生成的代碼，處在什么階段？

那么換個角度看，AI 生成的代碼具體處在什么階段呢？在我看來，它有幾個關鍵的特點：

（1）即使AI擁有上下文窗口，它也是“無狀態”的（stateless）。也就是說，AI 可以推測一段代碼為什么這樣寫，但它無法真正“知道”作者當時的具體意圖，也無法像人類維護者那樣擁有真實的時間點記憶。

（2）每一次 AI生成的代碼，其實都是“由別人寫的”。AI 就像一個第一次閱讀你代碼的新人，從零構建對上下文的理解，它不會真的“記得”當初的輸入是如何經過某種“電路”轉化為某個輸出。

（3）AI 生成的代碼，一出生就已經“變老”了。它跳過了“新代碼”的階段，直接進入了“別人寫的舊代碼”的模式——沒有時間上的“新鮮感”，也沒有原作者持續維護的加成。這種代碼，從一開始就可以被視作“遺留代碼（legacy code）”。

當然，也有熟練 AI 的開發者在嘗試解決這個問題。比如通過精心構造的提示（prompts）、設計合理的上下文窗口、詳細注釋等手段，來彌補 AI 缺乏狀態記憶的問題。但總體上，這些做法更像是順應慣性、朝著某一個方向在緩慢優化。

不過我個人的猜測是——或許這根本不算大問題，因為代碼本身就是一種“靜態狀態”。隨著提示工程（prompting）和上下文窗口的能力增強，代碼會被越來越多地“提示生成”，而非長期維護。未來“復雜軟件”的代碼量可能會更少，更多的邏輯會依賴于模型推理、提示而非靜態結構。

在此背景下，AI 提示生成的代碼，更像是一個短期/中期的“過渡橋梁”。

一些值得細品的高贊評論

我把以上的觀點整理成稿并發布后，在Hacker News 上引發了熱烈討論。以下是幾條高贊評論，我覺得都值得細品：

（1）@dang：文章的開頭實際上可以追溯到 Peter Naur 在 1985 年發表的經典論文《Programming as Theory Building》。順帶補充一下，Naur 正是 ALGOL 語言和 BNF 語法的核心人物之一。

Naur 的觀點是，復雜的軟件系統，本質上是開發者集體心智中構建起來的“理論”。源碼和文檔只是這種理論的低保真表達（lossy representation）——因為你永遠無法僅憑代碼和注釋，完整還原構建這個系統時的全部思維脈絡。

在這種意義下，遺留代碼（legacy code）指的是：雖然你還保留著代碼和文檔這些“文物”，但支撐它們的那套“理論”已經隨著原作者的離開而失傳了。這也就意味著，你不再有權限對系統進行“深層改進”，只能做些修補和維護。

那么，這種思想對于大語言模型（LLM）時代意味著什么呢？

從 Naur 的角度來看，LLM 是否也必然缺乏“程序背后的理論”？這并不是一個有定論的問題，可能存在以下幾種可能性：

• LLM 在生成代碼時，其實已經隱含某種“理論”，只是我們還沒看懂；

• 也許 LLM 可以從已有代碼中逐步構建這種理論，或者未來能做到；

• 或許 LLM 根本不需要人類工程團隊那樣的“理論”；

• 如果代碼是由 AI 生成的，那么或許 AI 才是唯一掌握了理論的存在，而不再是人類；

• 又或者，這套“理論”其實是掌握在寫 prompt 的人手中，而不是寫代碼的人手中。

（2）@mrweasel：我和老板總會對新來的年輕同事“辯解”說：“這就是我們那時的寫法”——多數情況下，這只是用來掩飾一些寫得不咋地的代碼的接口，而“那時”可能也就是兩周前。

不過有時候我們也確實沒錯。因為有些奇怪的寫法，是為了適配一些極端邊界場景，或者是為了集成一些老舊系統——它們本來就是那個時代的產物。所幸我們還在團隊里，所以能判斷哪些代碼可以刪、或者至少可以試著刪。

我認為，如果 LLM 輔助編程可以記錄下 Prompt，并與生成的代碼一起保存，那它或許比人類更能管理技術債。舉個例子：

如果你能知道某段代碼是由這樣一個 Prompt 生成的——“確保處理客戶端運行 AIX 6 時的邊界情況”，這就能回答很多問題。雖然你依然不知道當初是誰在用 AIX，但你至少知道為什么這段代碼存在，也能判斷是否還能刪。

（3）@TZubiri：原文中提到，“即使 AI 擁有上下文窗口，它也是“無狀態”的（stateless）。也就是說，AI 可以推測一段代碼為什么這樣寫，但它無法真正“知道”作者當時的具體意圖，也無法像人類維護者那樣擁有真實的時間點記憶。”

對于這句話，我想說：Chain of Thought（思維鏈）技術能搞定這個問題。

甚至就算是沒有 CoT 的模型，也能通過“閱讀”原有代碼重新激活上下文。其實這一點跟人類工程師很像——我們也不是永遠都能記得所有的代碼背景，但重新看一遍代碼，通常就能想起當時的上下文。