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

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

作者 | Ayush Thakur@Potpie

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

編譯 | 岳揚

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

01 提供詳細的上下文

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

上下文需要包含的關鍵要素有：

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

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

? 欠佳的提示詞：創建一個用戶身份驗證系統。

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

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

02 將問題分解為多個步驟

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

• 從明確的功能需求出發
• 分析目錄結構和代碼組織方式
• 引導 LLM 按照邏輯步驟實現目標功能，同時遵循既定的架構邊界和設計模式。

例如，在實現一個數據處理 pipeline 時，首先需明確輸入的數據結構、轉換邏輯、錯誤處理的相關要求及預期的輸出格式。隨后分析目錄結構，并確定新功能的實現位置。

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

03 選擇合適的模型完成任務

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

• 上下文窗口大小（處理大型代碼庫時至關重要）
• 對編程語言/技術框架的掌握程度
• 特定領域的專業知識
• 多輪交互的穩定性

對比示例：

任務類型	模型選擇考量因素
復雜的企業級架構	更大的上下文窗口大小有助于在大型代碼庫中保持多輪交互的穩定性
機器學習 pipeline	數學基礎扎實且經過數據科學專項訓練的模型更具優勢
前端組件	采用新近框架數據訓練的模型，可輸出符合業界最新標準的代碼模式

04 具體參照現有的代碼實現模式

在提示詞中明確具體細節能大大提升代碼生成的質量。 技術細節需明確指向代碼庫中的既有實現范式，而非籠統要求通用方案。例如：

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

? 更優的提示詞：“在 UserProcessor 類 (src/services/UserProcessor.js) 中創建一個新方法，沿用 transformPaymentData 方法的函數式編程風格實現用戶數據的轉換。因采用異步機制，實現時應以可讀性為第一準則，性能次之。”

該方法也同樣適用于命名規范、編碼標準和架構模式。需明確說明采用函數式或面向對象范式，指定設計模式類型，并澄清性能與代碼可讀性的優先級。

05 請重新生成而非回滾

當生成的代碼出現問題時，重新生成有問題的模塊通常比逐步去修復代碼中的問題效果更好。 此方法源于大語言模型理解上下文和生成模型響應的機制。

為何重新生成效果更好？

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

這種方法對解決一些算法難題或實現復雜的代碼邏輯特別有效，因為在這些場景下一點細微的錯誤都可能影響整體解決方案。

示例：

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

06 決策前請生成多套方案進行對比

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

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

示例：

“請為 API 響應緩存系統（caching system for our API responses）提供三套實現方案：

1. 基于自定義數據結構的 LRU 內存緩存方案

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

3. 支持 TTL 的本地文件系統緩存

請分別分析各方案的時間復雜度、內存占用、多服務器擴展能力和實現復雜度”

07 實施自我審查機制

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

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

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

08 為模型賦予技術人設或給出參考框架

為大語言模型分配技術人設，可確保其代碼生成保持統一的專業視角。當要求模型以"精通分布式系統的高級后端工程師"的思維模式運作時，其生成的代碼會優先考慮可擴展性、容錯性和性能優化。同理，若賦予"安全專家"人設，其生成的代碼會重點強化內容輸入區的驗證、規范認證流程，并預先規避潛在的漏洞風險。

技術參考框架需與任務需求相匹配。

根據不同任務選擇不同的專業人設：

• 后端系統：“具備分布式系統專業知識的高級后端工程師”
• 安全模塊：“熟悉 OWASP 規范的安全架構師”
• 基礎設施：“專攻云原生解決方案的 DevOps 工程師”
• 前端開發：“關注用戶體驗且具有無障礙化開發經驗的前端工程師”

這種方法利用模型模仿領域專家的能力，使生成的代碼更精準體現特定技術領域的行業最佳實踐。

示例：

“扮演高級安全工程師進行代碼審查。用 Python/Django 創建用戶注冊系統，需實現合規的密碼處理、輸入驗證功能，并防御常見 Web 漏洞。”

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

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

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

示例：

“請使用以下技術棧開發 REST API 接口：

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

10 實施思維鏈這一提示詞工程技術

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

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

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

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

與側重任務分解的"分步執行"方法不同，思維鏈技術著重于顯性化模型的推理路徑，確保在確認最終方案前保持邏輯的嚴謹性。

11 針對不同大語言模型（LLM）的特長設計專屬的提示詞策略，以最大化發揮其優勢

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

提示詞策略如下：

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

了解模型在訓練過程中接觸的數據集特點是優化提示詞的關鍵。 不同的模型因其訓練數據分布不同，往往只對特定編程范式或語言有更強的理解力。例如，若某模型在訓練中接觸了大量函數式編程內容，那么當問題本身適合使用函數式編程解決時，用函數式編程術語構建提示詞，將獲得更精準的響應。

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

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

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

示例：

“實現一個能處理以下情況的文件處理函數：

• 空文件（返回空結果）
• 超過 1GB 的文件（分塊讀取處理）
• 格式錯誤的 CSV 數據（記錄錯誤并跳過錯誤行，繼續處理后續有效行）
• 多進程/線程同時操作同一文件（需加鎖（如文件鎖、數據庫鎖）避免數據競爭）
• 網絡中斷（需支持斷點續傳）”

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

About the author

Ayush Thakur

Developer Advocate | Community Manager | Technical Writer

END

本期互動內容 ??

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

本文經原作者授權，由 Baihai IDP 編譯。如需轉載譯文，請聯系獲取授權。

原文鏈接：

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