Original 李建忠 李建忠研思

最近ChatGPT及基于大語言模型（Large Language Model，以下簡(jiǎn)寫為L(zhǎng)LM）的Github Copilot等工具出來之后，在軟件開發(fā)領(lǐng)域也帶來了非常大的震撼。著名的觀點(diǎn)有Fixie創(chuàng)始人、前Google工程總監(jiān)Matt Welsh在ACM通訊上發(fā)表的《The End of Programming:編程的終結(jié)》，以及OpenAI網(wǎng)紅研究科學(xué)家Andrej Karpathy的“The hottest new programming language is English”，這些言論在海外也是非常有爭(zhēng)議性的。比如我和C++之父Bjarne Stroustrup的交流，他老人家對(duì)LLM能替代程序員就相當(dāng)不以為然。這些專家觀點(diǎn)，很多時(shí)候不是簡(jiǎn)單的Yes or No的結(jié)論，因?yàn)長(zhǎng)LM沖擊的范圍太大，而且很多時(shí)候大家談的都不是同一件事情。

以Andrej Karpathy為代表談的“The hottest new programming language is English”，是對(duì)其2017年發(fā)表的著名文章《Software 2.0》的延續(xù)。其主要觀點(diǎn)是未來用“神經(jīng)網(wǎng)絡(luò)計(jì)算替代傳統(tǒng)計(jì)算”，那么這時(shí)候?qū)Α吧窠?jīng)網(wǎng)絡(luò)”的編程就是自然語言。而傳統(tǒng)程序員使用高級(jí)語言來編程的方式，會(huì)逐漸式微。這一觀點(diǎn)足以顛覆整個(gè)自1944年馮諾伊曼以來的計(jì)算機(jī)體系架構(gòu)、包括程序理論、編譯原理、操作系統(tǒng)等等整個(gè)計(jì)算機(jī)科學(xué)體系。這個(gè)觀點(diǎn)，雖然驚世駭俗，我覺得也足夠深刻，但它的影響不是短時(shí)間能顯現(xiàn)的，需要整個(gè)AGI產(chǎn)業(yè)相當(dāng)?shù)某墒旌头睒s，同時(shí)需要解決巨大的能源和算力需求。因篇幅有限，這個(gè)我會(huì)放到下一篇文章中談。

而以Matt Wels為代表的，談的其實(shí)是使用LLM來生成代碼、需求文檔、設(shè)計(jì)文檔、測(cè)試代碼等一系列活動(dòng)，它是對(duì)傳統(tǒng)程序員工作方式的變革，仍然建立在馮諾伊曼體系架構(gòu)上，遵從現(xiàn)有計(jì)算機(jī)科學(xué)體系。它也是目前正在我們眼前就發(fā)生的事情。

但這些專家觀點(diǎn)，加上技術(shù)社區(qū)一些極端言論的鼓噪，在程序員群體造成了一種某名奇妙的“被提示工程師淘汰”的恐慌感，甚至最近在某些高考家長(zhǎng)群體中也造成了一些誤導(dǎo)——“聽說程序員將來也要被ChatGPT給替代了，所以建議不要報(bào)計(jì)算機(jī)相關(guān)學(xué)科”。

作為一個(gè)還算資深的計(jì)算機(jī)專業(yè)人士，我深感有責(zé)任說點(diǎn)什么。先說我的觀點(diǎn)，我認(rèn)為在LLM生成代碼的語境下，Prompt不等于編程，所謂的LLM“提示工程師”淘汰程序員也是一個(gè)偽命題。我分以下七個(gè)部分來闡述我的觀點(diǎn)。

一、確定性計(jì)算 VS. 概率計(jì)算

在前面《AGI時(shí)代的產(chǎn)品版圖和范式》的文章中，我曾提出【計(jì)算1.0 和 計(jì)算2.0】的范疇和重要特征。其中提到神經(jīng)網(wǎng)絡(luò)的概率計(jì)算特點(diǎn)，如果拿它和傳統(tǒng)計(jì)算機(jī)的確定性計(jì)算來對(duì)比的話，可以看下圖（該圖來自于我今年4月份在上海的SDCon 2023全球軟件研發(fā)技術(shù)大會(huì)上的演講稿）：

對(duì)于計(jì)算1.0時(shí)代的數(shù)字邏輯電路來講，做的都是確定性計(jì)算（左圖），即給定一個(gè)結(jié)構(gòu)化輸入X，那么結(jié)果Y則是確定的。但對(duì)于計(jì)算2.0時(shí)代的數(shù)字神經(jīng)網(wǎng)絡(luò)（也就是LLM的原理），做的都是概率性計(jì)算（右圖），即給定一個(gè)自然語言輸入u（也就是所謂的提示詞Prompt），那么結(jié)果是一個(gè)概率分布：Y1, Y2, Y3, Y4, Y5……可以有很多。

概率計(jì)算是計(jì)算2.0時(shí)代，也就是LLM非常重要的基本特征。

二、LLM 生成代碼的基礎(chǔ)原理

不僅自然語言，計(jì)算機(jī)編程語言也是人類知識(shí)的載體，而且是邏輯性更強(qiáng)的語言載體。如果借用OpenAI 首席科學(xué)家Ilya Sutskever的話“LLM（大語言模型）是對(duì)人類知識(shí)的壓縮”，那么我們可以說計(jì)算機(jī)編程語言是對(duì)人類邏輯的壓縮。

無論ChatGPT，還是Github Copilot等代碼生成工具，其原理都是通過海量代碼數(shù)據(jù)學(xué)習(xí)（主要來自Github開源代碼），從而使模型掌握壓縮后的編程知識(shí)和邏輯。實(shí)際上很多研究都表明，在訓(xùn)練了代碼數(shù)據(jù)之后，LLM的泛化能力使得它的邏輯推理顯著增強(qiáng)——這和一個(gè)人學(xué)習(xí)了編程語言后，邏輯能力大為提升是一個(gè)道理。

然后，通過Prompt的方式，就可以讓LLM自動(dòng)生成包含一定知識(shí)和邏輯的代碼。這種代碼生成，仍然具有LLM的“概率計(jì)算”特點(diǎn)。下面和“傳統(tǒng)編程”做一個(gè)對(duì)比。

在傳統(tǒng)編程下，高級(jí)語言（即program） 通過編譯器（計(jì)算1.0時(shí)代的確定性邏輯）轉(zhuǎn)換為匯編語言。而在LLM代碼生成下，自然語言（即prompt） 通過LLM （計(jì)算2.0 時(shí)代的概率性邏輯） 轉(zhuǎn)換為高級(jí)語言。

這里面有兩階段的概率性：第一層 自然語言prompt階段，大家都知道自然語言表述有巨大的隨意性，雖然當(dāng)前各種 prompt技巧甚至prompt patterns發(fā)展的如火如荼，但它本質(zhì)上還是自然語言，不可能再走回到結(jié)構(gòu)化編程語言的老路上，所以只要是自然語言prompt，它的隨機(jī)屬性就永遠(yuǎn)存在；第二層 LLM經(jīng)過神經(jīng)網(wǎng)絡(luò)推理生成代碼，這個(gè)階段前面談過，LLM是個(gè)計(jì)算2.0時(shí)代的概率性邏輯，它的輸出當(dāng)然是概率性的。

這兩階段的概率性，使得LLM生成的高級(jí)語言代碼，具有相當(dāng)?shù)牟淮_定性。這也是為什么很多程序員朋友使用了Copilot等工具后，并不能得到預(yù)期穩(wěn)定的代碼輸出。

三、只做提示詞工程，LLM是否能完成軟件編寫？

有些朋友可能會(huì)說，程序員編寫代碼，也是生物神經(jīng)網(wǎng)絡(luò)計(jì)算，也有很大不確定性啊？同樣一個(gè)任務(wù)，A程序員和B程序員編寫的代碼肯定不一樣，即使A程序員放不同的時(shí)間，編寫的代碼也不同啊？

其實(shí)程序員“生成”代碼之后，還有一個(gè)不斷通過“邏輯校驗(yàn)”、“編譯器校驗(yàn)”、“ 各種測(cè)試校驗(yàn)”的過程，這是一個(gè)從概率性邏輯向確定性邏輯的逐步收斂過程。這樣一個(gè)收斂過程，通常伴隨著語義正確性推演、內(nèi)存和資源使用正確性確認(rèn)、設(shè)計(jì)符合良好耦合原則確認(rèn)、單元測(cè)試結(jié)果正確性確認(rèn)等一系列過程。不是“生成完代碼”就大功告成了。

用一個(gè)簡(jiǎn)單的公式表示：編碼 = “代碼生成”+“確定性收斂過程”

其實(shí)整個(gè)編碼活動(dòng)中，這個(gè)“確定性收斂過程”常常是比“生成代碼”更為重要、耗時(shí)更長(zhǎng)、也更有價(jià)值的活動(dòng)。當(dāng)然，這些也可以讓LLM來輔助（比如LLM幫助debug、生成單元測(cè)試等）。但是注意我用的詞是“輔助”，而不是“完成”，因?yàn)長(zhǎng)LM本質(zhì)是概率性計(jì)算，而這些“收斂活動(dòng)”最后都要求“確定性計(jì)算”。最終的收斂點(diǎn)如果沒有程序員“介入矯正”和“最終裁決”，是無法徹底完成的。

因此僅在“編碼”這一環(huán)節(jié)，提示詞工程師都是完全不夠的。必須程序員不斷介入。如果說一個(gè)“提示詞工程師”完全不懂某一門編程語言和技術(shù)棧，所謂 Prompt就大概只是花拳繡腿，想獨(dú)立完成該語言下的軟件開發(fā)工作，就有點(diǎn)異想天開了，匡論“淘汰”程序員？

四、LLM的劣勢(shì)，程序員的技能優(yōu)勢(shì)——“抽象”

很多軟件項(xiàng)目實(shí)踐都表明LLM在細(xì)顆粒度、抽象層次較低的任務(wù)上，表現(xiàn)非常好；但在大顆粒度、抽象層次較高的任務(wù)上，表現(xiàn)比較差。而大顆粒度、高抽象的設(shè)計(jì)才是軟件開發(fā)中核心的核心——抵抗軟件的復(fù)雜性。

正如面向?qū)ο蟠髱烥rady Booch在回復(fù)Andrej Karpathy的“The hottest new programming language is English”爭(zhēng)論時(shí)，也鮮明地指出“整個(gè)軟件工程的歷史就是不斷提升抽象層次”。

而這一點(diǎn)和LLM將人類知識(shí)“不斷壓縮、進(jìn)而抽象”的發(fā)展路徑不謀而合。

所以在即將到來的AGI時(shí)代，軟件開發(fā)中比較難被LLM替代的部分主要包括以下抽象層次較高的任務(wù)：需求分析、領(lǐng)域建模、架構(gòu)設(shè)計(jì)、詳細(xì)設(shè)計(jì)、模塊耦合性設(shè)計(jì)、接口設(shè)計(jì)、開發(fā)者測(cè)試設(shè)計(jì)等。而具體的類型實(shí)現(xiàn)、函數(shù)實(shí)現(xiàn)、算法實(shí)現(xiàn)、單元測(cè)試實(shí)現(xiàn)等這些抽象層次較低的任務(wù)則是LLM特別勝任的。所以，AGI時(shí)代，程序員最重要的技能要聚焦在上述抽象層次較高的任務(wù)，才有號(hào)令LLM的資本。

同樣用一個(gè)簡(jiǎn)單的公式表示：軟件開發(fā)=抽象層次較高的任務(wù) + 抽象層次較低的任務(wù)（編碼）

如果套用上面的編碼公式，可以推演如下：軟件開發(fā)= 抽象層次較高的任務(wù) + “代碼生成”+“確定性收斂過程”

其中代碼生成是目前LLM最為擅長(zhǎng)的，而抽象層次較高的任務(wù) 和 “確定性收斂過程”都是離不開程序員的。

不過，對(duì)于抽象層次高的任務(wù)，LLM未來一定無能為力嗎？理論上來講，人類大腦的生物神經(jīng)網(wǎng)絡(luò)可以掌握的，基于LLM的數(shù)字神經(jīng)網(wǎng)絡(luò)一定也可以。能不能實(shí)現(xiàn)主要看LLM訓(xùn)練數(shù)據(jù)的質(zhì)量、RLHF中的人類反饋、FineTune、Prompt等環(huán)節(jié)是否能將軟件行業(yè)積累這么多年的各種“抽象”的優(yōu)秀實(shí)踐都學(xué)習(xí)掌握到？至少目前以GitHub開源代碼為主要訓(xùn)練數(shù)據(jù)來源的LLM在這方面表現(xiàn)還有相當(dāng)大的距離。

我相信這也將是軟件領(lǐng)域今后長(zhǎng)期活躍的研究方向。但這一定是一個(gè)漸進(jìn)、漫長(zhǎng)的過程。

五、LLM沒有改變什么？

有些朋友因?yàn)槊襟w的各種鼓噪產(chǎn)生了對(duì)AGI（通用人工智能）強(qiáng)大的幻想癥，覺得LLM無所不能，LLM會(huì)改變世界的一切規(guī)則。甚至覺得有一天LLM會(huì)不會(huì)發(fā)展到不需要生成高級(jí)語言、不需要編譯器，給Prompt就能直接生成計(jì)算機(jī)程序？

這要看大家在什么前提下談，如果不拋棄馮諾伊曼體系架構(gòu)，那么這種設(shè)想就不可能。

因?yàn)長(zhǎng)LM本質(zhì)上是一個(gè)大語言模型，它接受的是語言輸入，輸出的也是語言。在馮諾伊曼體系架構(gòu)下，它不會(huì)改變數(shù)字電路“與或非”的原理、不會(huì)改變計(jì)算機(jī)程序的基本邏輯、不會(huì)改變編譯原理、不會(huì)改變操作系統(tǒng)的規(guī)則、也不會(huì)改變算法、數(shù)據(jù)結(jié)構(gòu)、網(wǎng)絡(luò)協(xié)議……等等自圖靈、馮諾伊曼以來計(jì)算機(jī)科學(xué)近八十年所積累的所有的“Law”。

六、LLM將會(huì)改變什么？

那么LLM在軟件開發(fā)領(lǐng)域到底會(huì)改變什么？它改變的是，以“語言”為載體，由人參與的“經(jīng)驗(yàn)性活動(dòng)”，大量需要“各種語言載體”進(jìn)行溝通、協(xié)調(diào)、對(duì)接、傳授的部分。比如：需求分析、軟件設(shè)計(jì)、代碼編寫、開發(fā)者測(cè)試、代碼評(píng)審、重構(gòu)、整潔代碼、缺陷調(diào)試等等。

說到“各種語言載體”，其實(shí)除了自然語言和編程語言外，軟件活動(dòng)中還有很多種“語言”，例如：各種 結(jié)構(gòu)化文檔、數(shù)據(jù)文件、圖表（Diagram） 、XML、Schema、Table…… 這些都是LLM可以大力發(fā)揮“大語言模型”神力的地方。

這些“經(jīng)驗(yàn)性活動(dòng)”組成了我們通常所說的軟件工程，都是LLM會(huì)引起劇烈變革的地方。比如我的朋友、來自同濟(jì)大學(xué)的朱少民教授就提出軟件工程3.0，對(duì)這方面有很多闡述。

七、LLM是程序員的效能倍增器

站在軟件工程的角度，LLM會(huì)大幅提升原來軟件開發(fā)過程中的每一個(gè)環(huán)節(jié)。因此學(xué)習(xí)掌握一定的Prompt技巧是有必要的，但前提是首先要掌握好“編程語言”和相關(guān)技術(shù)棧本身——這也是做好Prompt的前提。沒有“編程語言”和技術(shù)棧本身的掌握，再多的Prompt技巧只是緣木求魚。實(shí)際上有些朋友在軟件項(xiàng)目中已經(jīng)發(fā)現(xiàn)，花費(fèi)在反復(fù)Prompt和調(diào)錯(cuò)上的時(shí)間代價(jià)有時(shí)候比手工編程還要高很多。

但我也反對(duì)一些老派程序員“致命的自負(fù)”，總是認(rèn)為自己手搓代碼比LLM生成代碼快、質(zhì)量好，面對(duì)LLM對(duì)軟件開發(fā)的變革而無動(dòng)于衷。就像有了社交網(wǎng)絡(luò)之后，一個(gè)人能夠管理朋友的數(shù)量，是沒有社交網(wǎng)絡(luò)之前的好多倍。同樣，有了 LLM 之后，一個(gè)程序員的效能提升，也會(huì)成倍增長(zhǎng)。

有些朋友可能會(huì)從“結(jié)果”的角度來推演，LLM既然讓程序員效能提升了數(shù)倍之后，那原來需要30個(gè)程序員，現(xiàn)在是不是只需要5個(gè)程序員就可以了，其他程序員不會(huì)被淘汰嗎？

這是站在“總需求量固定”的思維定勢(shì)下的結(jié)論。實(shí)際上我認(rèn)為，假如有了LLM對(duì)程序員的賦能之后，整個(gè)社會(huì)對(duì)軟件的數(shù)量、復(fù)雜度、規(guī)模的需求都會(huì)出現(xiàn)井噴效應(yīng)，從而會(huì)更大程度上創(chuàng)造出更多程序員崗位。比如飛行技術(shù)的發(fā)展，迎來了航空業(yè)的大發(fā)展，促進(jìn)了更多飛行員的需求，而不是相反。

總結(jié)我的結(jié)論，在不拋棄馮諾伊曼體系架構(gòu)前提下。

在AGI時(shí)代，掌握編程語言和其背后抽象層次較高的部分、以及相關(guān)技術(shù)棧，仍然是優(yōu)秀程序員的基本功?！癙rompt Engineering提示工程”對(duì)軟件開發(fā)可以起到效率倍增的作用，但它不是軟件開發(fā)的全部，“提示詞工程師”也替代不了程序員的作用。