編者按： 如何有效利用大語言模型（LLMs）生成高質(zhì)量代碼？這是當(dāng)下開發(fā)者們比較關(guān)心的一個問題。在生成代碼的過程中，提示詞的設(shè)計是否精確，直接決定了模型輸出的質(zhì)量。

本文深入探討了提示詞優(yōu)化的 12 條策略，給出了清晰的操作指南和示范案例，讀者可以了解到如何通過精準(zhǔn)編寫提示詞引導(dǎo)模型生成性能優(yōu)越、符合實際需求的代碼。

作者 | Ayush Thakur@Potpie

(https://github.com/potpie-ai/potpie)

編譯 | 岳揚

大語言模型（LLMs）已經(jīng)徹底改變了代碼生成領(lǐng)域，但要想獲得高質(zhì)量、有用的輸出結(jié)果，編寫有效的提示詞至關(guān)重要。LLMs 生成代碼的質(zhì)量高度依賴于所提供提示詞的質(zhì)量。一句表述不當(dāng)?shù)奶崾驹~可能導(dǎo)致不完整、不正確或雖然正確但不具備針對性的響應(yīng)，而邏輯性、完整性和易讀性良好的提示詞則能最大化發(fā)揮模型的潛力。 本文將探討編寫有效提示詞的高級策略，以便使用 LLMs 生成高質(zhì)量的代碼。

01 提供詳細(xì)的上下文

在與 LLMs 進(jìn)行交互生成代碼時，所提供上下文的深度和質(zhì)量直接影響模型輸出的相關(guān)程度和準(zhǔn)確程度。

上下文需要包含的關(guān)鍵要素有：

• Specific problem domain（譯者注：指的是你試圖解決的問題所在的特定專業(yè)或技術(shù)領(lǐng)域。例如，如果你正在開發(fā)一個系統(tǒng)來處理金融交易，那么你的問題領(lǐng)域就是金融科技（FinTech）。）
• Existing codebase characteristics（譯者注：指的是當(dāng)前項目中已有代碼的特點、風(fēng)格和結(jié)構(gòu)等信息。）
• Implementation constraints（譯者注：在實現(xiàn)解決方案時必須遵守的各種限制條件，如只能使用某些技術(shù)棧等。）
• Performance requirements（譯者注：指的是系統(tǒng)或應(yīng)用程序需要達(dá)到的性能標(biāo)準(zhǔn)。）
• Architectural patterns already in use（譯者注：指的是在當(dāng)前項目或組織中已經(jīng)采用的軟件架構(gòu)模式。架構(gòu)模式是一種通用的、可重復(fù)的設(shè)計模板，用于解決軟件架構(gòu)中的常見問題。例如，微服務(wù)架構(gòu)、分層架構(gòu)（n-tier architecture）或是事件驅(qū)動架構(gòu)等。）

此外，你可以使用 @references 指向特定文件或函數(shù)（譯者注：大部分“對話式編程” Apps 都支持該功能），使你的請求更加精準(zhǔn)。與其用文字描述某個函數(shù)，不如直接引用它。

? 欠佳的提示詞：創(chuàng)建一個用戶身份驗證系統(tǒng)。

? 更好的提示詞：為我們的 Node.js Express API 創(chuàng)建一個基于 JWT 的身份驗證系統(tǒng)，該系統(tǒng)需要與 MongoDB 的 user 集合集成。該系統(tǒng)應(yīng)使用 bcrypt 處理密碼哈希，簽發(fā)有效期為 24 小時的令牌，并實現(xiàn)刷新令牌（refresh token）輪換機(jī)制增強(qiáng)安全性?，F(xiàn)有的中間件模式采用 async/await 語法。請參考 @authMiddleware.js 的中間件結(jié)構(gòu)和 @userModel.js 的 user 集合結(jié)構(gòu)。

通過使用 @authMiddleware.js 和 @userModel.js，可以確保生成的代碼與現(xiàn)有架構(gòu)保持一致，減少一些集成問題和手動調(diào)整工作量。

02 將問題分解為多個步驟

復(fù)雜的編碼任務(wù)需要系統(tǒng)性地拆解為可管理單元。該方法論的實施路徑如下：

• 從明確的功能需求出發(fā)
• 分析目錄結(jié)構(gòu)和代碼組織方式
• 引導(dǎo) LLM 按照邏輯步驟實現(xiàn)目標(biāo)功能，同時遵循既定的架構(gòu)邊界和設(shè)計模式。

例如，在實現(xiàn)一個數(shù)據(jù)處理 pipeline 時，首先需明確輸入的數(shù)據(jù)結(jié)構(gòu)、轉(zhuǎn)換邏輯、錯誤處理的相關(guān)要求及預(yù)期的輸出格式。隨后分析目錄結(jié)構(gòu)，并確定新功能的實現(xiàn)位置。

需要綜合考量代碼之間的依賴關(guān)系（dependency relationships）、模塊的職責(zé)劃分與隔離（module boundaries）以及代碼的目錄結(jié)構(gòu)與命名規(guī)范（code organization principles）。這一步驟可確保生成的代碼能無縫集成到現(xiàn)有代碼庫中。

03 選擇合適的模型完成任務(wù)

不同 LLM 在代碼生成任務(wù)中展現(xiàn)出的優(yōu)勢不同。某模型可能擅長理解復(fù)雜需求并生成邏輯一致性強(qiáng)的代碼，而另一模型可能在特定編程語言或框架上具有優(yōu)勢。 在評估使用哪種 LLM 時，需著重關(guān)注以下技術(shù)因素：

• 上下文窗口大?。ㄌ幚泶笮痛a庫時至關(guān)重要）
• 對編程語言/技術(shù)框架的掌握程度
• 特定領(lǐng)域的專業(yè)知識
• 多輪交互的穩(wěn)定性

對比示例：

04 具體參照現(xiàn)有的代碼實現(xiàn)模式

在提示詞中明確具體細(xì)節(jié)能大大提升代碼生成的質(zhì)量。 技術(shù)細(xì)節(jié)需明確指向代碼庫中的既有實現(xiàn)范式，而非籠統(tǒng)要求通用方案。例如：

? 欠佳的提示詞： “寫一個處理用戶數(shù)據(jù)的函數(shù)”

? 更優(yōu)的提示詞：“在 UserProcessor 類 (src/services/UserProcessor.js) 中創(chuàng)建一個新方法，沿用 transformPaymentData 方法的函數(shù)式編程風(fēng)格實現(xiàn)用戶數(shù)據(jù)的轉(zhuǎn)換。因采用異步機(jī)制，實現(xiàn)時應(yīng)以可讀性為第一準(zhǔn)則，性能次之?！?/p>

該方法也同樣適用于命名規(guī)范、編碼標(biāo)準(zhǔn)和架構(gòu)模式。需明確說明采用函數(shù)式或面向?qū)ο蠓妒剑付ㄔO(shè)計模式類型，并澄清性能與代碼可讀性的優(yōu)先級。

05 請重新生成而非回滾

當(dāng)生成的代碼出現(xiàn)問題時，重新生成有問題的模塊通常比逐步去修復(fù)代碼中的問題效果更好。 此方法源于大語言模型理解上下文和生成模型響應(yīng)的機(jī)制。

為何重新生成效果更好？

• 脫離原有錯誤實現(xiàn)方式的思維定式
• 防止舊代碼中的錯誤代碼邏輯污染新的代碼實現(xiàn)
• 支持加入新的約束條件

這種方法對解決一些算法難題或?qū)崿F(xiàn)復(fù)雜的代碼邏輯特別有效，因為在這些場景下一點細(xì)微的錯誤都可能影響整體解決方案。

示例：

“請嘗試用不同的方法實現(xiàn)排序算法。當(dāng)前版本的時間復(fù)雜度為 O(n2)，無法滿足數(shù)據(jù)集規(guī)模要求，請基于我們其他的數(shù)據(jù)處理函數(shù)使用的歸并排序模式，重新生成 O(n log n) 時間復(fù)雜度的解決方案”

06 決策前請生成多套方案進(jìn)行對比

利用大語言模型能夠生成多套解決方案的能力，通過對比分析提升代碼質(zhì)量。首先，要求模型生成 2-3 種不同的實現(xiàn)策略，每種策略需包含對該方案優(yōu)缺點的分析。

生成多套方案后，引導(dǎo)模型分析時間復(fù)雜度、空間復(fù)雜度、代碼可讀性和可維護(hù)性等因素，并分析如何權(quán)衡這些因素。這一反思（reflection）過程使模型能根據(jù)具體需求選擇并完善最合適的解決方案。

示例：

“請為 API 響應(yīng)緩存系統(tǒng)（caching system for our API responses）提供三套實現(xiàn)方案：

1. 基于自定義數(shù)據(jù)結(jié)構(gòu)的 LRU 內(nèi)存緩存方案

2. 基于 Redis 的分布式緩存方案

3. 支持 TTL 的本地文件系統(tǒng)緩存

請分別分析各方案的時間復(fù)雜度、內(nèi)存占用、多服務(wù)器擴(kuò)展能力和實現(xiàn)復(fù)雜度”

07 實施自我審查機(jī)制

Self-review prompting 可通過引導(dǎo)大語言模型對其生成的代碼進(jìn)行系統(tǒng)化評估來提升代碼質(zhì)量。具體實施時需明確要求模型在完成代碼生成后交叉檢查其生成的代碼。自我審查（Self-review）應(yīng)評估以下這幾個方面：

• 代碼正確性（是否有邏輯錯誤）
• 效率（是否存在性能問題）
• 邊界情況的處理情況
• 安全漏洞
• 是否嚴(yán)格滿足需求

在自我審查過程中，模型可識別潛在問題，例如并發(fā)代碼中的競態(tài)條件漏洞（譯者注：一種常見安全漏洞，源于系統(tǒng)或程序在處理并發(fā)操作時因時序問題導(dǎo)致的邏輯錯誤。）、資源管理中的內(nèi)存泄漏，或直接影響系統(tǒng)安全的核心邏輯中的漏洞風(fēng)險點。發(fā)現(xiàn)問題后，模型可立即優(yōu)化代碼實現(xiàn)來解決問題。此方法對應(yīng)成熟的軟件工程實踐（如代碼審查和靜態(tài)分析），但將其置于同一 prompt-response 周期內(nèi)執(zhí)行，大大提升了初始的代碼生成質(zhì)量。

08 為模型賦予技術(shù)人設(shè)或給出參考框架

為大語言模型分配技術(shù)人設(shè)，可確保其代碼生成保持統(tǒng)一的專業(yè)視角。當(dāng)要求模型以"精通分布式系統(tǒng)的高級后端工程師"的思維模式運作時，其生成的代碼會優(yōu)先考慮可擴(kuò)展性、容錯性和性能優(yōu)化。同理，若賦予"安全專家"人設(shè)，其生成的代碼會重點強(qiáng)化內(nèi)容輸入?yún)^(qū)的驗證、規(guī)范認(rèn)證流程，并預(yù)先規(guī)避潛在的漏洞風(fēng)險。

技術(shù)參考框架需與任務(wù)需求相匹配。

根據(jù)不同任務(wù)選擇不同的專業(yè)人設(shè)：

• 后端系統(tǒng)：“具備分布式系統(tǒng)專業(yè)知識的高級后端工程師”
• 安全模塊：“熟悉 OWASP 規(guī)范的安全架構(gòu)師”
• 基礎(chǔ)設(shè)施：“專攻云原生解決方案的 DevOps 工程師”
• 前端開發(fā)：“關(guān)注用戶體驗且具有無障礙化開發(fā)經(jīng)驗的前端工程師”

這種方法利用模型模仿領(lǐng)域?qū)＜业哪芰?，使生成的代碼更精準(zhǔn)體現(xiàn)特定技術(shù)領(lǐng)域的行業(yè)最佳實踐。

示例：

“扮演高級安全工程師進(jìn)行代碼審查。用 Python/Django 創(chuàng)建用戶注冊系統(tǒng)，需實現(xiàn)合規(guī)的密碼處理、輸入驗證功能，并防御常見 Web 漏洞?！?/p>

09 明確編程語言、開發(fā)框架或第三方庫的限制條件

明確說明技術(shù)限制條件，才能確保代碼與運行環(huán)境完美兼容。首先應(yīng)清晰說明編程語言版本（例如 Python 3.9、TypeScript 4.5），確保生成的代碼所使用的語言特性在生產(chǎn)環(huán)境中可用。同時需指定框架版本及其特定規(guī)范，例如"使用 Pydantic v2 模型的 FastAPI 0.95 進(jìn)行數(shù)據(jù)驗證"。

此外，還要交代清楚：用哪些第三方庫、具體怎么接入。例如，在請求生成數(shù)據(jù)庫交互代碼時，應(yīng)指定使用 SQLAlchemy 等 ORM 還是原始的 SQL queries，并明確數(shù)據(jù)庫連接的處理要求。摳到這種細(xì)節(jié)程度，才可以避免生成依賴了不可用的組件或版本不兼容的代碼。

示例：

“請使用以下技術(shù)棧開發(fā) REST API 接口：

• Python 3.9
• 搭載 Pydantic v2 模型的 FastAPI 0.95 框架
• 使用 SQLAlchemy 2.0 執(zhí)行數(shù)據(jù)庫操作
• 通過 auth_utils.py 文件中現(xiàn)有 AuthManager 實現(xiàn) JWT 身份認(rèn)證
• 必須兼容 PostgreSQL 13 數(shù)據(jù)庫”

10 實施思維鏈這一提示詞工程技術(shù)

思維鏈（Chain of thought prompting）通過引導(dǎo)大語言模型進(jìn)行邏輯推理，可以大大提升代碼生成質(zhì)量。這個方法的精髓是：讓 AI 先拆解問題再寫代碼。

要求模型按這個順序分步思考：

• 用大白話解釋實現(xiàn)思路
• 搭建解決方案的偽代碼框架
• 每個模塊的具體實現(xiàn)邏輯
• 最終完整可運行的代碼成品

思維鏈技術(shù)對于包含復(fù)雜邏輯或數(shù)據(jù)轉(zhuǎn)換的算法特別有效。這種方法可以減少邏輯錯誤，提高代碼的一致性，并可視化模型的推理過程，便于在最終代碼生成前進(jìn)行修正。

與側(cè)重任務(wù)分解的"分步執(zhí)行"方法不同，思維鏈技術(shù)著重于顯性化模型的推理路徑，確保在確認(rèn)最終方案前保持邏輯的嚴(yán)謹(jǐn)性。

11 針對不同大語言模型（LLM）的特長設(shè)計專屬的提示詞策略，以最大化發(fā)揮其優(yōu)勢

不同的大語言模型具備各自獨特的優(yōu)勢，通過針對性的提示詞技巧可以充分發(fā)揮它們的潛能。

提示詞策略如下：

• 針對上下文窗口有限的模型：聚焦分步算法指導(dǎo)
• 針對擅長函數(shù)式編程的模型：使用函數(shù)式思維提問
• 針對精通某一特定開發(fā)框架的模型：直接使用該框架的核心 API、類名或設(shè)計模式等特定術(shù)語提問，減少解釋成本。

了解模型在訓(xùn)練過程中接觸的數(shù)據(jù)集特點是優(yōu)化提示詞的關(guān)鍵。 不同的模型因其訓(xùn)練數(shù)據(jù)分布不同，往往只對特定編程范式或語言有更強(qiáng)的理解力。例如，若某模型在訓(xùn)練中接觸了大量函數(shù)式編程內(nèi)容，那么當(dāng)問題本身適合使用函數(shù)式編程解決時，用函數(shù)式編程術(shù)語構(gòu)建提示詞，將獲得更精準(zhǔn)的響應(yīng)。

12 指定邊界情況和約束條件

全面覆蓋邊界場景能大幅提升代碼健壯性 ?。技術(shù)領(lǐng)域的邊界情況因場景而異，但通常包含臨界值（譯者注：如數(shù)值溢出、空輸入）、資源限制（譯者注：如內(nèi)存耗盡、超時）和異常狀態(tài)（譯者注：如網(wǎng)絡(luò)中斷、并發(fā)沖突）。在向模型發(fā)送請求生成代碼時，應(yīng)明確列出這些要素，例如說明數(shù)據(jù)處理函數(shù)應(yīng)如何處理空輸入、格式錯誤的數(shù)據(jù)或超出預(yù)期范圍的值。

通過預(yù)先考慮這些約束條件，生成的代碼可包含與指定限制條件相匹配的驗證邏輯、錯誤處理機(jī)制和性能優(yōu)化方案。

示例：

“實現(xiàn)一個能處理以下情況的文件處理函數(shù)：

• 空文件（返回空結(jié)果）
• 超過 1GB 的文件（分塊讀取處理）
• 格式錯誤的 CSV 數(shù)據(jù)（記錄錯誤并跳過錯誤行，繼續(xù)處理后續(xù)有效行）
• 多進(jìn)程/線程同時操作同一文件（需加鎖（如文件鎖、數(shù)據(jù)庫鎖）避免數(shù)據(jù)競爭）
• 網(wǎng)絡(luò)中斷（需支持?jǐn)帱c續(xù)傳）”

掌握代碼生成的提示詞工程既是一門藝術(shù)，也是一門科學(xué)，它能大幅提升開發(fā)效率。通過運用這些策略方法，開發(fā)者可以將大語言模型（LLM）從簡單的代碼生成工具升級為智能開發(fā)助手，從而打造出更健壯、高效且易于維護(hù)的軟件系統(tǒng)。

About the author

Ayush Thakur

Developer Advocate | Community Manager | Technical Writer

END

本期互動內(nèi)容 ??

?文中提到「重新生成代碼優(yōu)于修復(fù) Bugs」，你在實際使用“對話式編程”時有這種感受嗎？ 歡迎在評論區(qū)分享~

本文經(jīng)原作者授權(quán)，由 Baihai IDP 編譯。如需轉(zhuǎn)載譯文，請聯(lián)系獲取授權(quán)。

原文鏈接：

https://github.com/potpie-ai/potpie/wiki/How-to-write-good-prompts-for-generating-code-from-LLMs