我一向不喜歡把新興現象硬套成舊有世界的類比。不過這次請容我犯同樣的錯：讓我說說為什麼提示詞應該稱為 提示詞設計（prompt design） ，並且可以比擬為網頁設計。

我把提示詞視為與一位時間有限的人類溝通。雖然針對 LLM（大型語言模型）的技巧確實有幫助（最著名的是 chain-of-thought），但我發現要提升表現，最佳的方法之一就是提供極為清晰且高品質的指示；這就像在現實中，清楚且精煉能讓人類更好理解一樣。

把提示詞當作清晰的溝通會讓提示詞聽起來像在寫作。不過，我大多數的提示其實是參數化的：我有多個輸入變數，需要依據它們動態調整我的提示詞。

因此，將提示詞視為一種含動態輸入的清晰溝通可說是最貼切的刻畫。

還有哪個領域講究在面對動態輸入時做到清楚傳達？網頁設計。

讓我們來列出所有相似點。提示詞與網頁設計皆：

1. 要求表達清楚明確，並以溝通為首要目標；
2. 需要回應動態內容，與寫作或雜誌版面配置不同；以及
3. 需要將內容調整以適應不同大小——用於網頁設計的螢幕尺寸，以及用於提示詞的脈絡視窗（context window）。

根據我在提示詞與網頁設計兩方面的實務經驗，我也發現自己在這兩個領域有著相似的開發偏好：

1. 實際查看提示詞 非常重要，就像 實際查看網站的渲染結果 一樣重要。我無法只在腦中模擬 HTML 和 CSS 的渲染過程來設計網站。同樣地，如果不先看過填入所有輸入變數後、該提示詞的實際渲染輸出，要寫出良好且清晰的提示詞確實很難。
   1. 例如，提示詞 "Hi ${username} ${message}" 看起來合理，但實際渲染後你會發現，使用者名稱會和訊息混在一起。
2. 可組合式元件在提示詞撰寫與網頁設計中都很有用。
3. 對兩者來說，宣告式都優於命令式。當網站的所有 HTML 元素都是透過 document.createElement 呼叫建立時，要變更就會變得非常困難。同樣地，閱讀與修改由長串 str += "..." 組成的提示詞也很容易變得難以管理。
4. 在這兩種情境下，我有時都想達到「像素級完美」。當我向能力較弱的模型（GPT-3.5 及更差）提供提示詞時，我會確認沒有多餘的換行或其他格式瑕疵；而在設計網站時，有時每個像素都很關鍵。

對於 LLM 代理而言，我們甚至可以把這個比喻再延伸一步：為代理撰寫提示詞，就像為它們打造一個互動式網站；代理可以透過呼叫函式來「點擊按鈕」，而提示詞會在函式呼叫後重新重繪，就像網站在按下按鈕後會重新渲染一樣。

當然，提示詞設計與網頁設計之間確實有所不同：

1. 目前提示詞僅支援文字（暫時如此！）。
2. 快取有所不同：特別是對於代理，你要確保重新渲染的成本很低，做法是只變更提示詞較後面的部分。雖然可以勉強拿網路作類比（你會想為網站做快取最佳化），但我認為本質上這是相當不同的挑戰。

儘管如此，這些相似之處讓我相信，提示詞應該叫作提示詞設計，而不是提示詞工程。撰寫提示詞感覺就像在設計網站，因此名稱也應該一致。

從提示設計的視角啟發了我，讓我打造了 Priompt，一個類 React、基於 JSX 的提示設計函式庫。

Priompt v0.1：提示詞設計函式庫的初次嘗試

Priompt 是一個受現代網頁設計原則啟發的提示設計程式庫的初步嘗試。我們在 Anysphere 內部使用它，而且非常喜歡。

我認為它在某些抽象層面上可能並非完全精確，但我至少確信，相較於字串樣板，JSX 是更順手的提示詞撰寫方式。就連能輕鬆把提示詞的部分註解掉這種小事，也能讓迭代更快。

Priompt 也附帶一個（臨時拼起來的）預覽網站，讓你可以用真實資料預覽提示詞。在開發應用程式時，你可以在每次請求時記錄進入元件的序列化 props。之後，當出現非預期行為時，你可以前往 Priompt 預覽，查看當下使用的提示詞，並修改原始碼，讓提示詞在沿用與實際請求相同 props 的情況下即時更新。我們發現這能讓提示詞的迭代更輕鬆

如果你試用過，請告訴我你的想法！我很樂於看到更多類似的點子，或者乾脆直說我完全搞錯了，提示詞設計很蠢 :)。

注意事項

模型更新很快，提示詞技巧也得隨之調整。基於此，我認為將其定義為提示詞設計這種說法有幾點需要留意：

1. 對 GPT-4 而言，像素級精準的設計並不重要，而且在 GPT-4.5 或更強的模型出現後很可能就不再必要。
2. 若以近期長脈絡模型的趨勢外推，脈絡視窗的限制或許會消失。不過，我對此並不那麼確定。
3. OpenAI 似乎正朝著讓開發者對提示詞的掌控越來越少的方向邁進；有可能在一年內就不會再有所謂的提示詞，API 呼叫只需提供原始輸入與一條指令即可。這種權限收斂的趨勢自 Chat 格式開始，並延續至近日宣佈的函式呼叫（function calling）。
4. 快取很可能是提示詞設計中最關鍵的面向之一；在這種情況下，這件事聽起來就更像工程而非設計。
5. 或許提示設計屬於過於低層的工作，應交由更高層的框架或編譯器處理（例如 langchain）。我覺得這可能沒錯，但考量到 LLM 發展瞬息萬變，我個人更傾向盡量貼近原始模型。

最後的必要提醒

……因為我很想和你一起工作：在 Anysphere，我們正在打造 Cursor，一款以 AI（人工智慧）為核心的程式碼編輯器。若你對提示設計、用於程式開發的 LLM，或打造優雅的產品感到興奮，請來信至 arvid@anysphere.co 與我聯絡。我們在舊金山共有 5 位成員，我的同事都非常傑出，也希望再找幾位同樣傑出的夥伴——程式開發者與設計師——一起打造程式開發的未來。