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