LLM 對(duì)軟件研發(fā)的單點(diǎn)提效，我之前錄制過(guò)一段視頻，大家可以直接觀看，里面有詳細(xì)的演示，我在這里就不再贅述了。

除此以外，我這里羅列一些更多的可能用途：

智能代碼提示

代碼片段智能生成

SQL 語(yǔ)句的智能生成與調(diào)優(yōu)

更高效更精準(zhǔn)的靜態(tài)代碼檢查與自動(dòng)修復(fù)（非 rule-based）

智能輔助的代碼評(píng)審與代碼重構(gòu)

單元測(cè)試和接口測(cè)試代碼的自動(dòng)生成

更高級(jí)的重復(fù)代碼檢查（語(yǔ)義重復(fù)檢查）

失敗用例的自動(dòng)分析與歸因

看到這里，你有可能會(huì)得出一個(gè)結(jié)論：完蛋了，程序員要大面積失業(yè)了。真的是這樣嗎？要回答這個(gè)問(wèn)題，我們需要從全局來(lái)看問(wèn)題，首先我們要搞清楚，LLM 對(duì)于軟件研發(fā)，什么變了？什么沒(méi)有變？

2LLM 對(duì)于軟件研發(fā)，什么變了？

看了上面的案例，你應(yīng)該已經(jīng)能夠體會(huì)到 LLM 對(duì)于軟件研發(fā)單點(diǎn)效率提升的各種可能性，這些能力讓我們看到了軟件研發(fā)的變化，我把這些變化總結(jié)為：基礎(chǔ)編碼能力的知識(shí)平權(quán)，進(jìn)而帶來(lái)局部效率的提升。

以前工程師個(gè)體學(xué)習(xí)掌握一門(mén)計(jì)算機(jī)語(yǔ)言以及相應(yīng)的數(shù)據(jù)結(jié)構(gòu)和算法，需要較長(zhǎng)的學(xué)習(xí)周期，很多經(jīng)驗(yàn)和模式還需要工程師個(gè)體在大量實(shí)踐中進(jìn)行總結(jié)，每個(gè)工程師個(gè)體都在重復(fù)著這個(gè)過(guò)程，現(xiàn)在 LLM 讓一個(gè)沒(méi)有接受過(guò)系統(tǒng)培訓(xùn)的個(gè)體也能擁有同樣的能力，個(gè)體和個(gè)體之間的能力差異被 LLM 拉平了，這就是知識(shí)平權(quán)。

如果說(shuō) ChatGPT 實(shí)現(xiàn)了數(shù)字時(shí)代知識(shí)的平權(quán)，codex 類(lèi)的代碼語(yǔ)言大模型實(shí)現(xiàn)了基礎(chǔ)編碼能力的知識(shí)平權(quán)，進(jìn)而帶來(lái)軟件研發(fā)的局部效率提升。

可以說(shuō)，LLM 降低了軟件開(kāi)發(fā)的門(mén)檻，可以讓更多對(duì)軟件開(kāi)發(fā)感興趣的人更加輕松地參與到軟件開(kāi)發(fā)工作中，同時(shí)，LLM 提高了編程的效率和質(zhì)量，使我們可以在更短的時(shí)間內(nèi)完成更多的工作，因而能留出更多的時(shí)間讓我們思考。

前段時(shí)間，前哈佛大學(xué)計(jì)算機(jī)科學(xué)教授，曾在 Google 和 Apple 擔(dān)任高級(jí)工程職位的 Matt Welsh 發(fā)表了一個(gè)視頻，其中的主要觀點(diǎn)是“LLM 將會(huì)代表著編程的終結(jié)”，他認(rèn)為程序員會(huì)被淘汰，未來(lái)只有產(chǎn)品經(jīng)理和代碼審查員。我不知道大家對(duì)這個(gè)怎么看？

我的觀點(diǎn)是，在抱有敬畏之心的同時(shí)，我們不要輕易下結(jié)論。為什么，因?yàn)檐浖邪l(fā)還有很多東西是沒(méi)有變的，而這些沒(méi)有變的才是軟件工程中的核心問(wèn)題和主要矛盾。

3LLM 對(duì)于軟件研發(fā)，什么沒(méi)有變？

我們面對(duì)的是軟件工程的問(wèn)題，編程不等于軟件工程，編程只是軟件工程的一部分。軟件工程的四大內(nèi)在特性（復(fù)雜度、不一致性、可變性、不可見(jiàn)性）并沒(méi)有因?yàn)?LLM 的出現(xiàn)而發(fā)生本質(zhì)上的變化，這才是軟件工程面臨的主要矛盾。

從復(fù)雜度的角度來(lái)看，問(wèn)題域本身的復(fù)雜度并沒(méi)有變，本質(zhì)復(fù)雜度也沒(méi)有變，變的可能只是一部分的隨機(jī)復(fù)雜度。雖然說(shuō)局部編碼變簡(jiǎn)單，或者說(shuō)更高效了，但是需求分析和軟件設(shè)計(jì)并沒(méi)有因?yàn)?LLM 而變得簡(jiǎn)單，這個(gè)稍后我們來(lái)詳聊。

從一致性的角度來(lái)看，由于軟件研發(fā)的本質(zhì)依然是“知識(shí)手工業(yè)者的大規(guī)模協(xié)作”，所以我們非常需要一致性。如果系統(tǒng)是一致的，則意味著相似的事情以相似的方式完成，錯(cuò)并不可怕，怕的是錯(cuò)的千變?nèi)f化。LLM 的出現(xiàn)并沒(méi)有提升軟件研發(fā)的一致性，甚至由于 LLM 本身的概率屬性，使用 LLM 實(shí)現(xiàn)代碼生成的不一致性問(wèn)題反而是被放大了，這點(diǎn)我們后面展開(kāi)講。

從可變性的角度來(lái)看，軟件會(huì)隨著需求不斷演進(jìn)和變化，所以架構(gòu)設(shè)計(jì)和模塊抽象只能面向當(dāng)下，它天然是短視的，或者說(shuō)是有局限性的，這種局限性即使是最優(yōu)秀的架構(gòu)師也是不可逾越的。

在敏捷開(kāi)發(fā)模式下這個(gè)問(wèn)題更被凸顯了出來(lái)，而且需求本身就是零散的，目標(biāo)也是模糊的，在沒(méi)有全局視圖的情況下，架構(gòu)自然就是有局限性，所以需要不斷迭代變更。每個(gè)迭代，你能拿到的信息僅僅是宏大視圖中的小小一角，根本沒(méi)有全貌，LLM 對(duì)此也是無(wú)能為力的。

從不可見(jiàn)性的角度來(lái)看，軟件的客觀存在不具有空間的形體特征，不同的關(guān)注點(diǎn)，會(huì)有不同的圖。綜合疊加這些圖是困難的，而且強(qiáng)行可視化的效果會(huì)造成圖的異常復(fù)雜，反而失去了可視化的價(jià)值。設(shè)計(jì)無(wú)法可視化就限制了有效的溝通和交流。

如果以上四點(diǎn)再疊加上大型軟件的規(guī)模效應(yīng)，其中包含軟件系統(tǒng)本身的規(guī)模和軟件研發(fā)團(tuán)隊(duì)的規(guī)模，問(wèn)題就更嚴(yán)重了，即會(huì)顯著提升軟件研發(fā)過(guò)程中的溝通成本、決策成本、認(rèn)知成本和試錯(cuò)成本，而這些才是軟件工程問(wèn)題的本質(zhì)，這些本質(zhì)問(wèn)題自始至終都沒(méi)有變過(guò)，LLM 對(duì)此也基本無(wú)能為力。

基于上述的分析，我們可以看到，軟件工程的核心矛盾并沒(méi)有改變，現(xiàn)代軟件工程應(yīng)對(duì)的是規(guī)模化場(chǎng)景下的各種問(wèn)題，基于 LLM 實(shí)現(xiàn)的編程提效只是其中的一小部分，而其中最重要的需求和代碼演進(jìn)模式都沒(méi)有發(fā)生本質(zhì)變化，我們接下里分別展開(kāi)討論一下。

4需求的重要性沒(méi)有變，在 LLM 時(shí)代還被放大了

只有我們的需求足夠的清楚，那么生成的代碼才會(huì)準(zhǔn)確。如何準(zhǔn)確全面描述需求成為了關(guān)鍵。面向自然語(yǔ)言編程，首先你要有能力把話(huà)講清楚。但是問(wèn)題是：你能講清楚嗎？

我們通過(guò)一些實(shí)踐發(fā)現(xiàn)，要把需求描述到讓它能正確寫(xiě)出來(lái)代碼，需要的工作量似乎已經(jīng)接近甚至超過(guò)編碼了。為什么會(huì)這樣，有兩個(gè)方面的原因。

一是因?yàn)榇蠖鄶?shù)的代碼實(shí)現(xiàn)是 imperative 的，而需求描述是 declarative 的，這兩者對(duì)人的要求完全不一樣。我們程序員群體接受的教育是編程，而不是需求描述，也就是說(shuō)程序員本來(lái)更擅長(zhǎng)寫(xiě)代碼，而不是描述需求。

二是因?yàn)樵诋?dāng)前的開(kāi)發(fā)模式下，程序員直接用代碼默認(rèn)幫需求（產(chǎn)品經(jīng)理）做了很多代償。很多在需求中沒(méi)有明確提及的內(nèi)容被程序員用代碼直接實(shí)現(xiàn)了（代償）。而現(xiàn)在要倒過(guò)來(lái)先把需求的細(xì)節(jié)完全理清楚這個(gè)可能不是程序員當(dāng)前的工作習(xí)慣。而且代碼的信息熵其實(shí)要大于自然語(yǔ)言，程序員更善于用代碼而非自然語(yǔ)言來(lái)描述事務(wù)。

舉個(gè)例子：如何清楚地描述一個(gè)排序函數(shù) sort 的需求？sort 輸出的數(shù)字必須是從小到大排列的，這樣描述需求就夠了嗎？其實(shí)遠(yuǎn)遠(yuǎn)不夠，重復(fù)數(shù)字怎么處理？排序數(shù)據(jù)的數(shù)量有沒(méi)有上限？有的話(huà)如何提示？排序時(shí)長(zhǎng)需要有超時(shí)設(shè)計(jì)嗎？是預(yù)先判定還是中途判斷？算法復(fù)雜度有明確的要求嗎？算法需要應(yīng)對(duì)并發(fā)嗎？并發(fā)的規(guī)模怎么樣？等等。

一個(gè)軟件的需求，不僅僅是功能性的，還有很多非功能的需求，這些都是需要描述清楚的。另外代碼實(shí)現(xiàn)的時(shí)候，還要考慮為可測(cè)試而設(shè)計(jì)，為可擴(kuò)展而設(shè)計(jì)，為可運(yùn)維而設(shè)計(jì)，為可觀測(cè)而設(shè)計(jì)等等。原本這些很多是開(kāi)發(fā)代償了，現(xiàn)在要從需求生成代碼，你必須要提前講清楚。

所以，我們的總結(jié)是：“軟件從業(yè)者高估了編程的復(fù)雜度，但是卻低估了功能和設(shè)計(jì)的深刻度”。

5代碼是持續(xù)“生長(zhǎng)”出來(lái)的，需要持續(xù)更新

對(duì)于現(xiàn)行的軟件開(kāi)發(fā)范式，當(dāng)需求發(fā)生變動(dòng)后，一般是會(huì)在原有代碼基礎(chǔ)上改動(dòng)，而不是直接從頭全量生成全部代碼，這個(gè)時(shí)候，LLM 本質(zhì)上做的是局部編程的輔助（pair programming）。局部編程輔助過(guò)程中，經(jīng)常需要對(duì)代碼做局部修改，而這個(gè)往往并不容易。

我們知道，代碼的信息熵大于自然語(yǔ)言，用信息熵更低的自然語(yǔ)言去描述代碼，尤其是準(zhǔn)確描述大段代碼中的若干個(gè)位置往往是困難的。想象一下，如果只用在線(xiàn)聊天的方式跟別人講在代碼的什么地方做修改的效率是何其低下，相比指著屏幕，或者使用專(zhuān)門(mén)的 CR 工具，效率的差距是巨大的。

如果需要進(jìn)一步描述如何修改就會(huì)更困難，因?yàn)榇蟾怕市枰玫胶芏啻a上下文的相關(guān)描述，所以對(duì)于 prompt 的表述要求以及長(zhǎng)度要求都很高。

另外，LLM 接納修改意見(jiàn)（prompt）后的輸出本身也是不穩(wěn)定和不收斂的，同時(shí)也具有不可解釋性，LLM 本質(zhì)上不是基于修改意見(jiàn)（prompt）進(jìn)行改寫(xiě)，而是基于修改意見(jiàn)（prompt）重新寫(xiě)了一份。輸出的代碼需要人重復(fù)的閱讀和理解，使得認(rèn)知成本變高了。

同時(shí)，LLM 的原理決定了其會(huì)“一本正經(jīng)的胡說(shuō)八道”的本質(zhì)，會(huì)混合捏造一些不存在的東西，可以說(shuō)人工智能的混合捏造是人工智能在無(wú)知情況下的“自信”反應(yīng)，而這個(gè)點(diǎn)在代碼生成上是災(zāi)難性的，比如會(huì)將不同類(lèi)型的 SQL 語(yǔ)句混在一起使用，會(huì)分不清 Go 語(yǔ)言的 os.Kill 和 Python 語(yǔ)言的 os.kill()。這個(gè)問(wèn)題可能需要使用 AI 審計(jì) AI 的方式來(lái)緩解了。

剛才提到，要在原有代碼基礎(chǔ)上修改，就需要利用已有的代碼上下文，而不是從 0 開(kāi)始。要實(shí)現(xiàn)這一點(diǎn)，一個(gè)最樸素的做法就是把整個(gè)項(xiàng)目的代碼都貼到 prompt 里，但這樣并不現(xiàn)實(shí)。因?yàn)?GPT-3.5 限制最多只能 4096 個(gè) tokens，GPT-4 最多 8192 個(gè)，除非項(xiàng)目非常小，否則根本放不下。這個(gè)問(wèn)題可能需要用 langchain 來(lái)解決了。

LangChain 是一個(gè)鏈接面向用戶(hù)程序和 LLM 之間的一個(gè)中間層，通過(guò)輸入自己的知識(shí)庫(kù)來(lái)“定制化”自己的 LLM。langchain 使用 embedding 建立基于項(xiàng)目特定的向量知識(shí)庫(kù)，實(shí)現(xiàn)“基于特定文檔的問(wèn)答”。

6LLM 時(shí)代，對(duì)軟件研發(fā)更多的思考 思考 1：替代的是碼農(nóng)，共生的是工程師

在軟件開(kāi)發(fā)過(guò)程中，當(dāng)偽代碼級(jí)別的設(shè)計(jì)完成后，最后一公里的編碼實(shí)現(xiàn)會(huì)被 LLM 替代，因?yàn)榛谟洃浀暮?jiǎn)單重復(fù)編碼不是人的優(yōu)勢(shì)，而是機(jī)器的優(yōu)勢(shì)。

這部分工作現(xiàn)在屬于碼農(nóng)，也就是我們俗稱(chēng)的 CRUD 仔和 API Boy，所以很多不涉及設(shè)計(jì)的碼農(nóng)可能會(huì)被大模型替代。

而工程師需要關(guān)注業(yè)務(wù)理解、需求拆分、架構(gòu)設(shè)計(jì)、設(shè)計(jì)取舍，并在此基礎(chǔ)上通過(guò) prompt 學(xué)會(huì)與 AI 合作，從而實(shí)現(xiàn)“工程師 + LLM”形成 1+1 >2 的效果。這就是共生。

需要注意的是，這種共生必須始終保持人的主觀能動(dòng)性，機(jī)器必須是 Copilot，也就是智能副駕駛，主駕駛位置必須是人，這樣的人 - 機(jī)關(guān)系才能長(zhǎng)期健康發(fā)展。這也就是為什么說(shuō)微軟現(xiàn)任 CEO 薩提亞強(qiáng)調(diào) Copilot（智能副駕駛）是比 Autopilot（自動(dòng)駕駛）還先進(jìn)的根本原因。

另外，特別要提的是：短期內(nèi)率先學(xué)會(huì)使用 LLM 的工程師必將獲益，但是很快大家都會(huì)掌握，這個(gè)時(shí)候能力水平就再次被拉平了，這個(gè)很像之前“外賣(mài)騎手困在系統(tǒng)里”那篇文章中的觀點(diǎn)，所以作為共生的工程師，我們更需要從以下三個(gè)方面來(lái)強(qiáng)化自己的能力：

需求理解、需求分析、需求拆解的能力

架構(gòu)設(shè)計(jì)、架構(gòu)分析、設(shè)計(jì)取舍的能力，并推動(dòng)設(shè)計(jì)的文檔化和規(guī)范化

理解問(wèn)題本質(zhì)，而不是單純學(xué)習(xí)應(yīng)用（授人以魚(yú)不如授人以漁）

思考 2：有利于控制研發(fā)團(tuán)隊(duì)規(guī)模，保持小團(tuán)隊(duì)的優(yōu)勢(shì)

隨著一個(gè)軟件規(guī)模的擴(kuò)展，軟件項(xiàng)目參與的人越來(lái)越多，分工越來(lái)越細(xì)，人和人之間需要的溝通量，也指數(shù)增長(zhǎng)。很快你會(huì)發(fā)現(xiàn)，溝通花費(fèi)的時(shí)間，漸漸地就比分工省下來(lái)的時(shí)間還要多。說(shuō)白了，過(guò)了一個(gè)臨界點(diǎn)，人越多不是越幫忙，而是人越多越添亂。一個(gè)人 12 個(gè)月能完成的事，不見(jiàn)得上 12 個(gè)人 1 個(gè)月就能完成，甚至 12 個(gè)月也未必能完成。

《人月神話(huà)》里建議了一種組織方式，叫“外科手術(shù)式的隊(duì)伍”。就像一臺(tái)外科手術(shù)一樣，有一個(gè)主刀大夫，軟件項(xiàng)目也應(yīng)該有一個(gè)首席程序員，其他人都是給他提供支持的。這樣，就既能獲得由少數(shù)頭腦產(chǎn)生的產(chǎn)品完整性，又能得到多位協(xié)助人員的總體生產(chǎn)率，還徹底地減少了溝通的工作量。

但是軟件規(guī)模大了之后，需要的程序員數(shù)量必然會(huì)更多，團(tuán)隊(duì)規(guī)模一定會(huì)加速擴(kuò)展。但是 LLM 的出現(xiàn)，讓基礎(chǔ)編程工作一定程度上實(shí)現(xiàn)了自動(dòng)化，這樣非常有利于控制研發(fā)團(tuán)隊(duì)規(guī)模，保持小團(tuán)隊(duì)的效率優(yōu)勢(shì)。

思考 3：暗知識(shí)

大模型的成功很大程度上來(lái)自于對(duì)已有的互聯(lián)網(wǎng)文本語(yǔ)料和專(zhuān)業(yè)書(shū)籍等資料的學(xué)習(xí)。相對(duì)應(yīng)，在軟件工程領(lǐng)域，需要學(xué)習(xí)的不僅僅是代碼，還應(yīng)該包括需求，設(shè)計(jì)。

但是，很多需求和設(shè)計(jì)并不以文檔的形式存在，往往會(huì)存在于程序員和架構(gòu)師的腦子里，或者在討論的過(guò)程中。就算有文檔，文檔和代碼大概率不同步。就算文檔同步，文檔（需求和設(shè)計(jì)）背后經(jīng)常有大量的方案對(duì)比和推敲，甚至有很多要在原有債務(wù)基礎(chǔ)上的設(shè)計(jì)妥協(xié)，這些決策過(guò)程一般都不會(huì)明確地被記錄下來(lái)。這些沒(méi)有被文檔化下來(lái)的知識(shí)，我們稱(chēng)其為“暗知識(shí)”。

雖然我們說(shuō)只要有足夠的數(shù)據(jù)，大模型就可以學(xué)到需求和設(shè)計(jì)知識(shí)。但這些“暗知識(shí)”本身就很難被捕捉到，“足夠的數(shù)據(jù)”這一前提在需求分析和軟件設(shè)計(jì)可能難以滿(mǎn)足。

另外，在實(shí)際軟件開(kāi)發(fā)中，需求可能一次不能表達(dá)得很清楚，需要一邊開(kāi)發(fā)一邊逐步寫(xiě)清楚需求。尤其是敏捷開(kāi)發(fā)更是如此。所以一些通用的，不需要特定領(lǐng)域知識(shí)的問(wèn)題，LLM 的表現(xiàn)會(huì)比較好，但是那些專(zhuān)用的，需要特定領(lǐng)域知識(shí)（私域知識(shí)）的問(wèn)題，LLM 就可能不是很擅長(zhǎng)。

總結(jié)來(lái)看：“你能想到的多過(guò)你能說(shuō)出來(lái)的，你能說(shuō)出來(lái)的多過(guò)你能寫(xiě)下來(lái)的?！彼赃@就天然限制了 LLM 能力的上限。

思考 4：Prompt 即代碼，代碼不再是代碼

讓我們做個(gè)大膽的設(shè)想，如果當(dāng)軟件需求發(fā)生變化的時(shí)候，我們不再是去改代碼，而是直接修改需求對(duì)應(yīng)的 prompt，然后基于 prompt 直接生成完整的代碼，這個(gè)將是軟件開(kāi)發(fā)范式的改變。

在這種范式下，我們需要確保代碼不能有人為修改，必須都是由 prompt 直接生成，此時(shí)我們還需要對(duì) prompt 做版本管理，或許會(huì)出現(xiàn)類(lèi)似今天 git 的 prompt 版本管理的新物種。

此時(shí)，從本質(zhì)上來(lái)看 prompt 即是代碼，而原本的代碼不再是代碼了，這就真正實(shí)現(xiàn)了基于自然語(yǔ)言（prompt）的編程，此時(shí)的編程范式將從 prompt to code 轉(zhuǎn)變?yōu)?prompt as code。

更進(jìn)一步思考，當(dāng)實(shí)現(xiàn)了 prompt as code，我們是否還需要 code，關(guān)于代碼的很多工程化實(shí)踐還重要嗎？現(xiàn)在我們之所以認(rèn)為代碼工程化很重要，因?yàn)榇a是人來(lái)編寫(xiě)，代碼是人來(lái)維護(hù)的。而當(dāng)代碼由 LLM 來(lái)編寫(xiě)，由 LLM 來(lái)維護(hù)的話(huà)，那么現(xiàn)有的軟件架構(gòu)體系還適用嗎？這個(gè)時(shí)候或許才真正實(shí)現(xiàn)了軟件研發(fā)范式的進(jìn)化。

思考 5：直接可運(yùn)行，prompt to executable 軟件開(kāi)發(fā)范式的可能性

在深入一步思考，直接可運(yùn)行，prompt to executable 的基礎(chǔ)設(shè)施會(huì)出現(xiàn)嗎？

代碼只是軟件工程中的一部分，遠(yuǎn)遠(yuǎn)不是軟件工程的全部，你想想你有多少時(shí)間占比是在編碼的。一般來(lái)講，編碼完成后往往要經(jīng)歷 CI 和 CD 等一些列的工程實(shí)踐才能向終端用戶(hù)交付價(jià)值。

所以全新的軟件范式是否可以實(shí)現(xiàn)從 prompt 直接到可運(yùn)行的程序?qū)嵗?？目前?lái)看，或許 Serverless 是可能的架構(gòu)之一。

思考 6：計(jì)算機(jī)教育的反思

LLM 出現(xiàn)后，關(guān)于對(duì)計(jì)算機(jī)教育的反思我認(rèn)為有兩個(gè)層面的思考：

首先是，計(jì)算機(jī)學(xué)科研究方向的變化，之前 NLP、知識(shí)圖譜、代碼理解，代碼缺陷發(fā)現(xiàn)、test oracle 生成等都是獨(dú)立的研究方向，但是 LLM 表現(xiàn)出的 AGI 能力似乎讓這些垂直領(lǐng)域的研究失去的意義，因?yàn)?LLM 的 AGI 能力都能解決，或許效果還更好。

所以這些研究方向?qū)⒑稳ズ螐氖切枰覀兯伎嫉摹Ｓ腥苏f(shuō) LLM 是 NLP 的新里程碑，但也有人認(rèn)為其更像是 NLP 的墓志銘，這句話(huà)很好的表達(dá)了我的觀點(diǎn)。

其次，LLM 一次次地證明了通過(guò)“死記硬背 + 簡(jiǎn)單推理”就能通過(guò)大多數(shù)人類(lèi)的考試和技術(shù)面試。那教育的終極目標(biāo)又是什么？先進(jìn)的人工智能?chē)L試把機(jī)器培養(yǎng)成人，而落后的教育試圖把人培養(yǎng)成機(jī)器。計(jì)算機(jī)教育，其實(shí)我們整個(gè)教育到了需要徹底反思的時(shí)刻了。

或者我們都錯(cuò)了？！

彼得德魯克說(shuō)過(guò)“動(dòng)蕩時(shí)代的最大風(fēng)險(xiǎn)不是動(dòng)蕩本身，而是企圖以昨天的邏輯來(lái)應(yīng)對(duì)動(dòng)蕩”，今天 LLM 對(duì)軟件工程的影響，我還是在以以往的邏輯在做分析，這個(gè)基礎(chǔ)可能本來(lái)就是錯(cuò)誤，全新的時(shí)代需要全新的思維模式，然后我們拭目以待。

審核編輯：劉清