【CSDN 編者按】現(xiàn)在生成式 AI 軟件開(kāi)發(fā)過(guò)程逐步融入，越來(lái)越多 AI 生成的代碼出現(xiàn)在實(shí)際工程中——但是你有沒(méi)有想過(guò)這些原因？ AI 編寫(xiě)的代碼可能從一開(kāi)始就被視為“遺留代碼”？本文作者從工程經(jīng)驗(yàn)出發(fā)，結(jié)合 AI 生成機(jī)制，提出了一種極具啟發(fā)性的觀點(diǎn)：AI 由此產(chǎn)生的代碼缺乏前后文記憶和維護(hù)的連續(xù)性，所以一出生就處于“他人舊作”的狀態(tài)。。這樣做不只是為了現(xiàn)在 AI 對(duì)編碼能力的理性觀察，也為我們對(duì)未來(lái)軟件開(kāi)發(fā)形式的理解提供了一個(gè)新的視角。

代碼的“可改進(jìn)性”在軟件開(kāi)發(fā)中往往取決于其生命周期階段。一般可分為以下幾種情況：

• 你剛剛寫(xiě)了一段代碼：哦，的確可以改成那種寫(xiě)法，應(yīng)該不難。
• 別人剛剛寫(xiě)了一段代碼：也許是因?yàn)樽罱囊恍簳r(shí)的情況才寫(xiě)出來(lái)的。要是真的需要，我可以選擇調(diào)整一下。
• 在你之前寫(xiě)的某一段代碼："嗯，事實(shí)上，那時(shí)候應(yīng)該這樣寫(xiě)。如有必要，等忙完手頭的工作，我再優(yōu)先考慮。"
• 在某一段代碼是別人之前寫(xiě)的："他為什么要這樣寫(xiě)？但是應(yīng)該沒(méi)有必要?jiǎng)樱日娴某隽藛?wèn)題再說(shuō)。"

總的來(lái)看，代碼的演變速度，一般取決于它的編寫(xiě)時(shí)間有多近，維護(hù)者是否是原作者。

其實(shí)這種狀態(tài)是合理的:對(duì)于一個(gè)性能穩(wěn)定、經(jīng)過(guò)驗(yàn)證的軟件系統(tǒng)來(lái)說(shuō)，貿(mào)然“改進(jìn)”通常會(huì)帶來(lái)額外的風(fēng)險(xiǎn)，尤其是當(dāng)你對(duì)系統(tǒng)的整體脈絡(luò)了解不多的時(shí)候，原作者一般最了解它的潛在邏輯和發(fā)展背景。

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

所以換個(gè)角度看，AI 生成的代碼具體處于什么階段？在我看來(lái)，它有幾個(gè)關(guān)鍵特征：

（1）即使AI有前后文窗口，它也是“無(wú)狀態(tài)”的。（stateless）。換句話說(shuō)，AI可以猜測(cè)為什么一個(gè)代碼是這樣寫(xiě)的，但它不能真正“知道”作者當(dāng)時(shí)的具體意圖，也不能像人類維護(hù)者那樣有真實(shí)的時(shí)間記憶。

（2）每一次 AI生成的代碼，實(shí)際上是“別人寫(xiě)的”。AI就像第一次閱讀你的代碼的新人。它不會(huì)真正“記住”當(dāng)時(shí)的輸入是如何通過(guò)某個(gè)“電路”轉(zhuǎn)化為某個(gè)導(dǎo)出的。

（3）AI 生成的代碼，一出生就已“變老”。它跳過(guò)了“新代碼”的時(shí)期，直接進(jìn)入了“別人寫(xiě)的舊代碼”的方式——沒(méi)有時(shí)間上的“新鮮感”，也沒(méi)有原作者持續(xù)維護(hù)的加成。這類代碼，從一開(kāi)始就可以被視為“遺留代碼”（legacy code）”。

自然，也有熟練程度 AI 開(kāi)發(fā)者正試圖解決這個(gè)問(wèn)題。例如，通過(guò)精心的結(jié)構(gòu)提示（prompts）、前后文窗設(shè)計(jì)合理，詳細(xì)說(shuō)明等方法，以彌補(bǔ)。 AI 缺少狀態(tài)記憶的問(wèn)題。但是，總的來(lái)說(shuō)，這些做法更像是適合慣性，在某個(gè)方向上緩慢提高。

但我個(gè)人的猜測(cè)是——也許這根本不是什么大問(wèn)題，因?yàn)榇a本身就是一種“靜態(tài)狀態(tài)”。提醒項(xiàng)目（prompting）隨著前后窗口能力的增強(qiáng)，代碼會(huì)被越來(lái)越多的“提醒生成”，而不是長(zhǎng)期維護(hù)。未來(lái)“復(fù)雜軟件”的代碼量可能會(huì)更少，更多的邏輯將取決于模型推理和提醒，而不是靜態(tài)結(jié)構(gòu)。

在這種背景下，AI 提示產(chǎn)生的代碼，更像是一座短期/中期的“過(guò)渡橋梁”。

一些值得細(xì)品的高贊評(píng)論

在Hacker之后，我整理出上述觀點(diǎn)并發(fā)表。 News 上面引起了熱烈的討論。下面是一些好評(píng)如潮的評(píng)論，我覺(jué)得都值得精品：

（1）@dang：事實(shí)上，文章的開(kāi)頭可以追溯到 Peter Naur 在 1985 2008年發(fā)表的經(jīng)典論文《Programming as Theory Building》。順便補(bǔ)充一下，Naur 正是 ALGOL 語(yǔ)言和 BNF 其中一個(gè)是語(yǔ)法核心人物。

Naur 其觀點(diǎn)是，復(fù)雜的軟件系統(tǒng)，本質(zhì)上是開(kāi)發(fā)者集體思想所構(gòu)建的“理論”。源代碼和文檔只是這一理論的低保真表達(dá)。（lossy representation）——由于你永遠(yuǎn)不能僅僅依靠代碼和注釋來(lái)完全恢復(fù)構(gòu)建這個(gè)系統(tǒng)時(shí)的所有思維脈絡(luò)。。

從這個(gè)意義上說(shuō)，遺留代碼（legacy code）這意味著：雖然你仍然保留著代碼和文檔這些“文物”，但是隨著原作者的離開(kāi)，支持它們的“理論”已經(jīng)失傳。也就是說(shuō)，你不再有權(quán)對(duì)系統(tǒng)進(jìn)行“深度改進(jìn)”，只能進(jìn)行一些修復(fù)和維護(hù)。

所以，這種思想對(duì)大語(yǔ)言模型來(lái)說(shuō)是正確的。（LLM）時(shí)代意味著什么？

從 Naur 從角度看，LLM “程序背后的理論”也必須缺乏嗎？這個(gè)問(wèn)題并非有定論的問(wèn)題，這些概率可能會(huì)出現(xiàn)：

LLM 實(shí)際上，在生成代碼的時(shí)候，已經(jīng)隱含了一些“理論”，只是我們還沒(méi)有理解；

或許 LLM 這一理論可以從現(xiàn)有代碼中逐步構(gòu)建，也可以在未來(lái)實(shí)現(xiàn)；

也許 LLM 沒(méi)有人類工程團(tuán)隊(duì)那樣的“理論”。；

假如代碼是由的 AI 產(chǎn)生的，那么也許 AI 只有掌握了理論的出現(xiàn)，才不再是人類；

或者，這套“理論”實(shí)際上是掌握在寫(xiě)作中的。 prompt 人手中，而非敲代碼的人手中。

（2）@mrweasel：我和老板總是“為新來(lái)的年輕同事辯護(hù)”，說(shuō)“這是我們當(dāng)時(shí)的寫(xiě)作方式”——大多數(shù)情況下，這只是用來(lái)掩蓋一些代碼寫(xiě)得不好的界面，而“當(dāng)時(shí)”可能是兩周前。

但是有時(shí)候我們是對(duì)的。因?yàn)橛行┢婀值膶?xiě)作方式是為了適應(yīng)一些極端的界限場(chǎng)景，或者是為了整合一些舊系統(tǒng)——它們本身就是那個(gè)時(shí)代的產(chǎn)物。幸運(yùn)的是，我們還在團(tuán)隊(duì)中，所以我們可以判斷哪些代碼可以被刪除，或者至少我們可以嘗試刪除。

我覺(jué)得，如果 LLM 幫助編程記錄下來(lái) Prompt，并且與生成的代碼一起存儲(chǔ)，那么它可能比人類更能管理技術(shù)債務(wù)。舉個(gè)例子：

假如你能夠知道某個(gè)代碼就是這樣一個(gè) Prompt 產(chǎn)生-“確保處理客戶端的運(yùn)行 AIX 6 時(shí)間的界限”，這樣可以回答很多問(wèn)題。雖然你還不清楚當(dāng)時(shí)誰(shuí)在用。 AIX，但是你至少知道為什么這個(gè)代碼存在，也可以判斷是否還可以刪除。

（3）@TZubiri：即便如此，原文中提到 AI 有了前后文窗，它也是“無(wú)狀態(tài)”的。（stateless）。換句話說(shuō)，AI 我們可以猜測(cè)為什么一個(gè)代碼是這樣寫(xiě)的，但是它不能真正“知道”作者當(dāng)時(shí)的具體意圖，也不能像人類維護(hù)者那樣有真實(shí)的時(shí)間記憶。"

關(guān)于這個(gè)句子，我想說(shuō)：Chain of Thought(思維鏈)技術(shù)可以解決這個(gè)問(wèn)題。

即使沒(méi)有 CoT 模型也可以通過(guò)“閱讀”原始代碼重新激活前后文本。其實(shí)這和人類工程師很像——我們并不總是記住所有的代碼背景，但是如果我們?cè)倏匆槐榇a，我們通?？梢杂涀‘?dāng)時(shí)的前后文本。

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

本文來(lái)自微信微信官方賬號(hào)“CSDN"，翻譯：鄭麗媛，36氪經(jīng)授權(quán)發(fā)布。

本文僅代表作者觀點(diǎn)，版權(quán)歸原創(chuàng)者所有，如需轉(zhuǎn)載請(qǐng)?jiān)谖闹凶⒚鱽?lái)源及作者名字。

免責(zé)聲明：本文系轉(zhuǎn)載編輯文章，僅作分享之用。如分享內(nèi)容、圖片侵犯到您的版權(quán)或非授權(quán)發(fā)布，請(qǐng)及時(shí)與我們聯(lián)系進(jìn)行審核處理或刪除，您可以發(fā)送材料至郵箱：service@tojoy.com