從語法流暢到架構(gòu)理解的范式轉(zhuǎn)移
編者按：大模型的文生文能力正在引發(fā)軟件開發(fā)的范式轉(zhuǎn)移，下一代的軟件開發(fā)將由提示驅(qū)動(dòng)，開發(fā)者不會(huì)消失，但溝通能力與戰(zhàn)略思維會(huì)變得更加重要。
我在感恩節(jié)期間開發(fā)了一個(gè)應(yīng)用，很快就收獲了1000名用戶，并在圣誕節(jié)前實(shí)現(xiàn)盈利。
但最瘋狂的是……我本人一行代碼都沒寫。那都是我一步步指導(dǎo)大模型（LLM）寫的，我們一起開發(fā)了一個(gè)全棧的NodeJS/React應(yīng)用，這個(gè)應(yīng)用帶有PostgreSQL數(shù)據(jù)庫(kù)，實(shí)現(xiàn)了與Stripe的集成，托管在Heroku上，用SendGrid發(fā)送電子郵件，用CloudFlare進(jìn)行DNS處理。
此后我一直都在思考提示驅(qū)動(dòng)開發(fā)的事情，琢磨著該怎么做才好，思考其對(duì)行業(yè)發(fā)展的意義。以下就是我的想法。
▋概要
什么是提示驅(qū)動(dòng)開發(fā)（PDD）？
工具與工作流
成功的心智模式
行業(yè)影響
▋什么是提示驅(qū)動(dòng)開發(fā)（PDD）？
從本質(zhì)上講，PDD是一種開發(fā)工作流程，開發(fā)人員主要促使LLM生成所有必要的代碼。讓我們將其與傳統(tǒng)開發(fā)進(jìn)行對(duì)比。
PDD本質(zhì)上是這么一種開發(fā)范式：開發(fā)者主要通過向LLM提供提示（prompt）來生成所有的必要代碼。我們來跟傳統(tǒng)開發(fā)模式對(duì)比一下。
傳統(tǒng)軟件開發(fā)的高階流程通常是這樣的：
1.開發(fā)者收到需求
2.開發(fā)人員在IDE本地迭代代碼變更
3.開發(fā)者提交代碼變更以供審查
4.另一位開發(fā)者審查并合并變更
傳統(tǒng)開發(fā)的高階流程
相比之下，PDD有幾個(gè)關(guān)鍵區(qū)別。首先，LLM會(huì)參與并編寫主要（甚至全部）代碼。其次，開發(fā)者專注于提示工程和代碼審查，而不是自己編寫代碼。除此之外，其余流程大致是相同的。
高階提示驅(qū)動(dòng)開發(fā)流程：
1.開發(fā)者收到需求
2.開發(fā)者將需求分解為一系列提示*
3.LLM針對(duì)每個(gè)提示生成代碼
4.開發(fā)者審查L(zhǎng)LM生成的代碼*
5.開發(fā)者提交所有變更以供審核
6.另一位開發(fā)者審查并合并變更
提示驅(qū)動(dòng)開發(fā)高階流程
*我想強(qiáng)調(diào)幾個(gè)步驟。
1.“將需求分解為提示”是一項(xiàng)新技能，需要學(xué)習(xí)和練習(xí)。我會(huì)在“思維模式”章節(jié)討論怎么做。
2.“審查L(zhǎng)LM生成的代碼”至關(guān)重要。你不會(huì)不假思索就合并進(jìn)人工編寫的代碼，所以對(duì)LLM編寫的代碼也別這樣做！
▋給誰用？
簡(jiǎn)而言之，每個(gè)人。
我曾經(jīng)跟一位資深工程師交流過，他們正在用這種做法開發(fā)極具創(chuàng)新性的技術(shù)。我的一位朋友甚至用PDD從頭開始做出了自己的編程語言。我也接觸過一些非技術(shù)人員，這些人能開發(fā)出功能完備的原型，甚至有人還部署到生產(chǎn)環(huán)境并吸引到用戶了。LLM最驚人的特性之一就是大幅降低了編程門檻，讓零技術(shù)經(jīng)驗(yàn)的人也能生成可運(yùn)行的代碼。
但我認(rèn)為有類人群特別適合這種技術(shù)：那就是具有技術(shù)背景但轉(zhuǎn)型從事產(chǎn)品、戰(zhàn)略或設(shè)計(jì)工作的人。這當(dāng)中包括技術(shù)產(chǎn)品經(jīng)理、技術(shù)設(shè)計(jì)師以及工程經(jīng)理等。由于我的個(gè)人背景與此類似（開發(fā)者→用戶體驗(yàn)→產(chǎn)品經(jīng)理），所以我對(duì)PDD的熱情可能有些偏頗。
這種技能組合之所以能夠從PDD獲益，是因?yàn)檫@些人可能對(duì)軟件工作原理具備了架構(gòu)上的理解，但對(duì)編程語法卻不太熟悉。由于LLM可以幫忙處理語法，因此語法不熟練不再是制約因素。通過PDD，他們可以高效、無拘束地進(jìn)行開發(fā)。
▋工具和工作流
基礎(chǔ)模型
以下是可編寫代碼的一些LLM。隨著新模型不斷被訓(xùn)練并部署到市場(chǎng)上，這個(gè)領(lǐng)域會(huì)非常活躍，充滿活力。就PDD而言，需關(guān)注：
·我通常用Claude 3.5 Sonnet、GPT 4o和GPT o1
·對(duì)各種模型的編碼能力進(jìn)行測(cè)試的基準(zhǔn)測(cè)試有很多。選擇模型時(shí)請(qǐng)參考最新的基準(zhǔn)測(cè)試
這些基準(zhǔn)數(shù)據(jù)可能已過時(shí)
聊天工具
ChatGPT，Claude，Gemini
常規(guī)聊天工具可作為PDD的一個(gè)選項(xiàng)。就我個(gè)人而言，我更喜歡大模型原生IDE，但我訪談過的幾位開發(fā)者都用了聊天工具，因?yàn)楸容^簡(jiǎn)單。因?yàn)橐oLLM提供一切適當(dāng)?shù)纳舷挛?，然后還要將輸出粘貼到代碼庫(kù)中，這種做法的人工操作更多，但用起來是沒問題的。
其工作流如下：
1.給LLM寫提示
2.從代碼庫(kù)中復(fù)制所有必要的代碼上下文，并將其作為提示的一部分
3.復(fù)制LLM生成的代碼
4.將代碼輸出粘貼到代碼庫(kù)中的正確位置
雖然我的主要工作流不是這樣，但PDD過程中也會(huì)偶爾使用。如果要嘗試這種方式，強(qiáng)烈推薦使用Claude Projects或ChatGPT Projects功能，你可用來組織文件和聊天記錄，極大提升上下文管理效率。
ChatGPT Project
LLM原生IDE
Cursor、Windsurf、Bolt、v0、Replit工具
這些工具徹底改變了游戲規(guī)則。它們將LLM集成到IDE中，相比聊天模式有兩大優(yōu)勢(shì)：
1.為L(zhǎng)LM提供代碼上下文非常容易
2.LLM能夠直接在IDE中編輯你的文件
這顯著加快了代碼生成反饋循環(huán)，無需反復(fù)復(fù)制粘貼到IDE內(nèi)。
此類工具層出不窮，我個(gè)人用的是Cursor。說實(shí)話，這些工具大同小異：Replit可自動(dòng)部署代碼庫(kù)，Windsurf與GitHub集成等，但核心價(jià)值都在于簡(jiǎn)化PDD的用戶體驗(yàn)。
我強(qiáng)烈建議選擇個(gè)LLM原生的IDE然后堅(jiān)持用下去。在各種選項(xiàng)之間切換的成本非常低。關(guān)鍵要培養(yǎng)如何編寫出色提示的技能，而不是記住特定IDE的所有功能。所以選好一個(gè)，堅(jiān)持用下去，聚焦在提示上。
Cursor，注意右側(cè)的“Composer”窗口
我的工作流
我在工作流結(jié)合了ChatGPT與Cursor的使用。大致分解如下：
·80%時(shí)間與Cursor交互：通過Composer功能向Claude發(fā)送提示，審查接受/拒絕修改。重復(fù)此過程。如有錯(cuò)誤，我們會(huì)一起解決。
·15%時(shí)間把GPT4o當(dāng)作技術(shù)思考伙伴：處理復(fù)雜變更或新功能開發(fā)時(shí)，要求其提供技術(shù)方案并創(chuàng)建任務(wù)工單，以此作為提示輸入給Cursor，然后進(jìn)入Cursor工作流
·5%的時(shí)間使用GPTo1進(jìn)行深度規(guī)劃：?jiǎn)?dòng)新項(xiàng)目或?qū)嵤┫盗袕?fù)雜變更時(shí)，GPTo1可生成更高質(zhì)量、更長(zhǎng)篇幅的輸出（例如一次性生成十余個(gè)任務(wù)工單）
我對(duì)PDD工具使用的大致分布情況
▋成功的心智模式
更好的提示==LLM生成更好的代碼。垃圾進(jìn)，垃圾出，對(duì)吧？每個(gè)人的目標(biāo)、環(huán)境和技能組合都不一樣。所以這里不會(huì)告訴你究竟該怎么寫提示，而是會(huì)提供一些思維模式，這些思維模式可提高提示質(zhì)量，進(jìn)而提高生成代碼的質(zhì)量。
LLM是剛加入本項(xiàng)目的初級(jí)開發(fā)者
LLM擁有令人難以置信的編碼能力。但是，如果你是PDD新手，我強(qiáng)烈建議你先想到這一點(diǎn)。告訴自己，LLM是剛接觸該項(xiàng)目的初級(jí)開發(fā)者。在編寫提示時(shí)，要考慮到如何指導(dǎo)這類人。錯(cuò)誤示范：“給我寫個(gè)可以讓朋友們發(fā)布照片并互相關(guān)注的app?！边@樣絕對(duì)行不通。
別這樣，你得給出很小、非常具體的變更。你可能還要提供各種相關(guān)的文件，并說明關(guān)于產(chǎn)品是什么以及別人會(huì)怎么用的一大堆信息。這是思考如何給LLM提示來生成代碼的正確方法。這樣不僅會(huì)生成更好的結(jié)果，還會(huì)迫使你更好地給出提示，你的關(guān)注點(diǎn)應(yīng)該在這里。
更好的提示==LLM生成更好的代碼。垃圾進(jìn)，垃圾出，對(duì)吧？
表現(xiàn)得像自己就是一整支產(chǎn)品團(tuán)隊(duì)一樣
給LLM提供的東西不用局限在技術(shù)背景上。不妨設(shè)想自己是產(chǎn)品經(jīng)理、設(shè)計(jì)師、開發(fā)主管以及QA工程師，你可以就工作范圍提供意見。你要盡可能地模仿角色，但也不要用力過度。
除了技術(shù)指導(dǎo)之外，你還應(yīng)提供：
·用戶故事
·業(yè)務(wù)目標(biāo)
·UI描述
·UX流程描述
·測(cè)試計(jì)劃
把這些類型的附注添加到提示中可以給LLM提供更全面的上下文，也能提高其實(shí)現(xiàn)預(yù)期目標(biāo)的能力。
上下文、具體性及范圍
這是調(diào)整提示時(shí)需要考慮的三個(gè)變量。這些變量跟代碼質(zhì)量的關(guān)系很簡(jiǎn)單。為了提高LLM生成代碼的質(zhì)量，你需要：
·增加提供的上下文的信息量
·提高請(qǐng)求的具體性
·縮小變更范圍
為了獲得最佳輸出，你需要上下文豐富、特別具體，范圍很窄
以下是我對(duì)這些術(shù)語的定義……
上下文是提示提供的代碼庫(kù)片段或文件。
·上下文不充分：“在后端進(jìn)行這些變更”
·上下文豐富：“調(diào)整backend/routes/user.js文件的getMarker函數(shù)。文件在這兒，它一般會(huì)進(jìn)行交互的另外3個(gè)文件在這兒......”
具體性是指請(qǐng)求定義得有多明確、多精確。
·不夠具體：“當(dāng)用戶單擊提交時(shí)，將其提交添加到feed中?！?/p>
·非常具體：“當(dāng)用戶單擊提交時(shí)，調(diào)用saveSubmission端點(diǎn)將提交存儲(chǔ)到數(shù)據(jù)庫(kù)內(nèi)。保存后，自動(dòng)調(diào)用loadFeed函數(shù)刷新前端的feed，讓用戶能夠立即看到自己的提交，而無需重新加載頁面。”
范圍是要求LLM一次性變更多少東西。
范圍很廣：“添加一個(gè)設(shè)置頁面，用戶可以在該頁面管理和更新賬號(hào)。”
范圍很窄：“在設(shè)置頁面上添加一個(gè)切換按鈕，用戶可以將自己的帳戶設(shè)置為私密或公開?！?/p>
請(qǐng)記住，要想得到最佳輸出，上下文得豐富、請(qǐng)求要足夠具體，范圍不要太寬。是，寫成這樣需要時(shí)間，但寫代碼也一樣。提示成什么樣你得根據(jù)自己的技能組合來權(quán)衡。
LLM寫代碼也會(huì)有bug（就像人類一樣）
知道不，LLM并不完美。我和曾經(jīng)嘗試過PDD的人聊過，“因?yàn)锳I產(chǎn)生了一個(gè)bug，所以我就放棄了。”我建議你不要期望過高，只需知道LLM會(huì)時(shí)不時(shí)產(chǎn)生bug就行了。這是正常開發(fā)過程的一部分，那怕是人類寫代碼也會(huì)出錯(cuò)。
這也是為什么在接受LLM代碼之前對(duì)其進(jìn)行審查和測(cè)試如此重要的原因。不要盲目地合并它所做的變更。人寫的代碼你不會(huì)無腦合并，那為什么LLM寫的代碼你就會(huì)無腦合并呢？如果你遇到bug的概率超過5%，請(qǐng)使用上述建議重新審視你的提示技術(shù)。
人寫的代碼你不會(huì)無腦合并，那為什么LLM寫的代碼你就會(huì)無腦合并呢？
▋行業(yè)影響
門檻提高了
常見誤區(qū)認(rèn)為L(zhǎng)LM將取代開發(fā)者。更準(zhǔn)確的認(rèn)知是：對(duì)所有從業(yè)來說門檻提高了。
對(duì)于技術(shù)人員來說，熟練掌握一門編程語言已不再足夠。因?yàn)檫@項(xiàng)技能可以100%外包給LLM。現(xiàn)在，開發(fā)者需要對(duì)所用的代碼庫(kù)有深入的架構(gòu)理解，并且需要具備強(qiáng)大的寫作技能，以便能夠準(zhǔn)確地向LLM表達(dá)所需做出的變更。
對(duì)于非技術(shù)人員來說，能夠給開發(fā)團(tuán)隊(duì)編寫需求已經(jīng)不夠了。相反，他們還得會(huì)開發(fā)可在本地運(yùn)行的功能齊全的原型。為此，他們需要具備足夠的技術(shù)知識(shí)，好向LLM描述所需的內(nèi)容，還得知道如何啟動(dòng)本地Web服務(wù)器。
低階工作不會(huì)消失，但工作性質(zhì)會(huì)改變
最近有很多關(guān)于入門級(jí)（甚至中級(jí)）開發(fā)者角色被AI取代的討論。我知道他們想說什么，但我認(rèn)為那是不對(duì)的。其實(shí)他們是想說LLM現(xiàn)在已經(jīng)能做我們目前認(rèn)為需要入門級(jí)或中級(jí)開發(fā)者才能完成的工作了。這一點(diǎn)我大抵是同意的。但認(rèn)為這些角色會(huì)消失的想法是只見樹木不見森林。
消滅初級(jí)和中級(jí)崗位會(huì)導(dǎo)致開發(fā)者的人才斷代?，F(xiàn)在那些高級(jí)開發(fā)者總有一天會(huì)退休的，而由于沒有人才儲(chǔ)備，我們沒法用足夠快的速度去替換他們。
中級(jí)開發(fā)者的定義肯定會(huì)發(fā)生變化。他們需要完成的任務(wù)類型會(huì)變得更加復(fù)雜。他們可能會(huì)使用LLM來生成大量代碼。而且，他們還需要對(duì)產(chǎn)品有深入的架構(gòu)理解，并具備強(qiáng)大的書面溝通能力。
軟件開發(fā)的學(xué)法不一樣了
2010年代我剛開始學(xué)習(xí)軟件開發(fā)時(shí)，概念學(xué)習(xí)的順序大致是像下面這樣的：
1.基本概念（變量、數(shù)據(jù)結(jié)構(gòu)等）
2.語言語法和特性（我學(xué)過C++、Java、LISP、Ruby、JavaScript）
3.協(xié)作（Git）
4.架構(gòu)模式（前端/后端、MVC）
5.之后我轉(zhuǎn)行去做產(chǎn)品了
我預(yù)計(jì)現(xiàn)在對(duì)于學(xué)軟件的人來說會(huì)發(fā)生一些變化了。首先，他們不會(huì)像我一樣去學(xué)5種編程語言。沒有理由去做這樣的事情了。他們可能會(huì)學(xué)習(xí)一種語言，然后靠LLM去學(xué)習(xí)其他語言和框架。其次，他們會(huì)學(xué)習(xí)架構(gòu)模式的時(shí)間會(huì)提前，可能學(xué)習(xí)基本概念的同時(shí)就開始學(xué)了。這是因?yàn)槟惚仨氄莆者@些知識(shí)才能編寫出高質(zhì)量的提示。第三，他們從第一天開始就會(huì)學(xué)習(xí)使用LLM，逐步練就非常強(qiáng)大的書面溝通技巧，從而寫出高質(zhì)量的提示。
整個(gè)過程大概是這樣的：
1.學(xué)基本概念+架構(gòu)模式
2.學(xué)一種編程語言+提示寫作（語言可能是python或Javascript，會(huì)通過提示來學(xué)習(xí)）
3.合作
4. ......等等
小一點(diǎn)、新一點(diǎn)的公司會(huì)率先采用提示驅(qū)動(dòng)開發(fā)
改變很難，組織慣性會(huì)妨礙成熟的大型科技公司大規(guī)模采用這些做法。他們需要更長(zhǎng)的時(shí)間才能共同建立起對(duì)LLM代碼質(zhì)量的信任感，才能理解提示質(zhì)量才是更重要的因素，才不會(huì)感到受到LLM的威脅，并最終接受這些工具。
小一點(diǎn)、新一點(diǎn)的公司有充分的理由從第一天開始就成為AI原生企業(yè)，沒有理由不這樣做。他們沒有歷史負(fù)擔(dān)，很快就能學(xué)會(huì)如何將其融入自己的獨(dú)特文化，并以業(yè)內(nèi)前所未有的速度交付產(chǎn)品。這種情況正在上演，Headstart等公司就是典范。
▋結(jié)論
提示驅(qū)動(dòng)開發(fā)(PDD)是一場(chǎng)軟件開發(fā)變革，強(qiáng)調(diào)的是對(duì)架構(gòu)的理解而非語法流暢。通過利用LLM，開發(fā)者和非開發(fā)者都可以更快、更高效地開發(fā)出產(chǎn)品。不過，LLM生成代碼的質(zhì)量在很大程度上要取決于提示夠不夠清晰，夠不夠具體，因此，溝通能力與戰(zhàn)略思維至關(guān)重要。
本文來源：36氪
文章轉(zhuǎn)載于其他網(wǎng)絡(luò)，如有侵權(quán)請(qǐng)聯(lián)系我們及時(shí)刪除
