提示工程基礎和最佳做法
在本單元中，我們將討論：
- 什麼是提示工程？
- 提示工程的基礎
- 提示工程的最佳做法
- Copilot 如何從您的提示中學習
什麼是提示工程？
提示工程是一種制定清楚指令來引導 AI 系統 (例如 GitHub Copilot) 的程序，以產生適合您的專案特定需求的內容相關的程式碼。 這可確保程式碼在語法、功能和內容上都是正確的。
既然您知道什麼是提示工程，那麼讓我們來了解一下它的一些原則。
提示工程的原則
在探討具體的策略之前，讓我們先了解提示工程的基本原則，總結為以下 4 個 S。 這些核心規則是建立有效提示的基礎。
- 單一：始終將您的提示集中在一個單一明確定義的工作或問題上。 這種清楚性對於從 Copilot 獲得準確且有用的回應是很重要的。
- 具體：確保您的指示明確且詳細。 具體性可帶來更適用且更精確的程式碼建議。
- 簡短：在保持具體的同時，也要讓提示能夠簡潔、扼要。 這種平衡可確保清楚性，而不會使 Copilot 負荷過重或使互動複雜化。
- 圍繞物：利用描述性的檔名並讓相關的檔案保持開啟。 這可為 Copilot 提供豐富的內容背景，進而產生更量身定制的程式碼建議。
這些核心原則為制定效率高且有效的提示奠定了基礎。 請記住這 4 個 S，讓我們深入探討進一步的最佳做法，以確保與 GitHub Copilot 的每次互動都得到最佳化。
提示工程的最佳做法
以下基於這 4 個 S 的進階做法可優化並增強您與 Copilot 的互動，進而確保產生的程式碼不僅準確，而且完全符合您專案的特定需求和內容。
提供足夠的清楚性
基於「單一」和「具體」原則，始終以您的提示的明確性為目標。 例如，像「撰寫一個 Python 函式來篩選並傳回指定清單中的偶數」這樣的提示既是單一聚焦又是具體的。
提供足夠的內容與詳細資料
遵循「圍繞物」原則，以豐富 Copilot 對內容的理解。 提供的內容資訊越多，產生的程式碼建議就越合適。 例如，藉由在程式碼頂端新增一些註解來提供您想要的更多詳細資料，您可以為 Copilot 提供更多的內容來理解您的提示並提供更好的程式碼建議。
在上面的範例中，我們使用步驟來提供更多的細節，同時保持簡短。 這種做法遵循「簡短」的原則，平衡細節與簡潔以確保溝通的清楚性和正確性。
注意
Copilot 也會在您的程式碼編輯器中使用平行開啟的索引標籤，以取得程式碼需求的更多內容。
提供學習的範例
使用範例可以釐清您的需求和期望，說明抽象概念並使提示對 Copilot 更加具體。 精心設計的範例可協助 Copilot 快速理解模式，從而提供更準確的初始建議，而需要更少的修訂週期。 這種方法對於產生樣板程式碼、測試範本和構成更大功能基礎的重複實作特別有效。
判斷提示並逐一查看
釋放 GitHub Copilot 全部潛力並加速開發工作流程的關鍵之一是策略迭代的實踐。 您的第一個提示可能並不總是產生生產就緒的程式碼，這完全沒問題。 與其花時間手動完善輸出，不如將其視為與 Copilot 高效對話的開始。
如果第一個輸出不完全符合您的需求，請不要從頭開始。 相反，請刪除建議的程式碼，使用新增的詳細資訊和範例來豐富您的初始評論，然後再次提示 Copilot。 這種迭代方法通常可以讓您比傳統開發方法更快地獲得高品質、部署就緒的程式碼，因為每次迭代都建立在 Copilot 對您特定需求的理解之上。
既然您已了解改善提示技能的最佳做法，讓我們進一步了解如何提供 Copilot 可從中學習的範例。
Copilot 如何從您的提示中學習
GitHub Copilot 是根據經過大量資料訓練的 AI 模型來運作的。 為了增強其對特定程式碼內容的理解，工程師經常會為其提供許多範例。 這種做法 (在機器學習中很常見) 會導致不同的訓練方法，例如：
零樣本學習
在這裡，GitHub Copilot 是在沒有任何具體範例的情況下 (僅依靠其基礎訓練) 來產生程式碼。 這種方法非常適合快速實現通用模式和標準功能。 例如，假設您要建立一個函式以在攝氏和華氏之間轉換溫度。 您可以先只撰寫描述您想要的內容的註解，Copilot 也許能夠根據其先前的訓練為您產生生產就緒的程式碼，而無需任何其他範例。
一個樣本學習
透過這種方法，會提供一個範例，幫助模型產生更多具上下文敏感度並遵循您特定模式和慣例的回應。 這對於在程式碼庫中建立一致的實作、加速功能開發同時維持程式碼標準特別有效。 基於前面的零樣本範例，您可能會提供一個溫度轉換函式的範例，然後要求 Copilot 建立另一個類似的函式。 它看起來可能像這樣：
少樣本學習
在此方法中，Copilot 會給出了幾個範例，以在零樣本不可預測性與微調精確度之間取得平衡。 這種方法擅長產生處理多種場景和邊緣情況的複雜實現，從而減少手動測試和改進所花費的時間。 假設您想要產生根據一天中的時間來向您傳送問候語的程式碼。 以下是該提示的幾個樣本的版本：
鏈結提示和管理聊天記錄
處理需要多個步驟的複雜功能時，您可能會與 GitHub Copilot Chat 進行延伸交談。 雖然詳細的上下文有助於 Copilot 了解您的需求，但維護較長的對話歷史記錄可能會變得低效且處理成本高昂。
例如，您可以從基本實作開始，然後反覆新增錯誤處理、測試、文件和最佳化。 每個回合都建立在先前的上下文之上，但完整的歷史會變得更長：
第 1 回合：「建立使用者驗證函式」回合 2：「新增無效憑證的錯誤處理」
第 3 回合： 「新增驗證函式的單元測試」 第 4 回合：「 新增 JSDoc 註解以記錄函式」 第 5 回合：「 最佳化函式以獲得更好的效能」
注意
具有完整對話歷史記錄的長提示每回合可能會消耗 2-3 個 PRU。 摘要內容或重設對話可以讓每次要求的資源消耗更接近 1 個 PRU。
若要有效管理此問題：
- 當對話變得冗長時總結上下文：「根據我們之前關於使用者身份驗證的討論，接著增加頻率限制以防止暴力攻擊」
- 重設並提供新功能的重點內容：從必要的詳細資料重新開始，而不是沿用整個對話內容
- 使用對先前工作的簡潔引用，而不是重複完整的實現
針對特定工作的角色提示
角色提示涉及指示 GitHub Copilot 充當特定類型的專家，這可以顯著提高專門領域生成代碼的質量和相關性。 這種方法有助於在第一次嘗試時獲得更有針對性的解決方案來加速開發。
安全性專家角色
在處理安全關鍵功能時，提示 Copilot 像安全專家一樣思考：
“充當網絡安全專家。 創建一個密碼驗證功能，檢查常見漏洞並遵循 OWASP 指南。
這種方法通常會產生包含以下內容的程式碼：
- 輸入清理
- 防範常見攻擊
- 業界標準驗證模式
- 安全性最佳做法
效能最佳化角色
對於效能關鍵程式碼，請使用效能專家角色：
“充當性能優化專家。 重構這種排序演算法以有效地處理大型資料集。
這通常會導致：
- 優化的演算法和資料結構
- 記憶體效率高的實作
- 延展性考慮
- 效能監控建議
測試專員角色
建立全面的測試套件時，請利用測試專家的觀點：
“充當測試專家。 為此支付處理模組建立全面的單元測試，包括邊緣情況和錯誤場景。」
這通常會產生：
- 完整的測試覆蓋範圍
- 邊緣案例處理
- 模擬實作
- 錯誤條件測試
角色提示透過將領域專業知識納入初始實作，幫助您更快地取得生產就緒程式碼，從而減少多個修訂週期的需求。
現在您已經了解了 Copilot 如何使用您的提示來學習，讓我們深入了解它實際上如何使用您的提示來為您提供程式碼建議。