提示設計 · Cursor

我通常不太喜歡那種用舊世界的事物去類比新世界現象的習慣。所以請容我犯一次同樣的錯：讓我來說明為什麼提示應該被稱為 提示設計（prompt design） ，並類比為網頁設計。

我把提示視為在和一個時間受限的人類溝通。雖然確實有一些針對 LLM 的特定技巧（最顯著的是 chain-of-thought）很有幫助，但我發現，提升效能最好的方法之一，就是提供極度清楚且高品質的指示，就像清楚與精簡能幫助真實的人類更好理解一樣。

把提示視為清晰溝通（prompting-as-clear-communication） 會讓提示聽起來很像寫作。不過，我實際上大多數在做的提示工作是參數化的：我有許多輸入變數，必須依照這些變數動態調整我的提示。

因此，把提示視為帶有動態輸入的清晰溝通（prompting-as-clear-communication-with-dynamic-input） 感覺是最貼切的描述。

還有哪個領域是在針對動態輸入做清楚的溝通？網頁設計。

我們來列出所有相似之處。提示與網頁設計都：

需要清楚，而溝通是主要目標；
必須回應動態內容，不像寫作或雜誌排版；以及
需要讓內容適應不同的大小——網頁設計是螢幕大小，提示則是上下文視窗（context window）。

根據我同時做提示和網頁設計的經驗，我也發現自己在這兩個領域有類似的開發偏好：

看到實際的提示內容 極其重要，就像 看到實際渲染後的網站 一樣重要。如果我必須在腦中模擬 HTML 與 CSS 的渲染過程，我就沒辦法設計網站。同樣地，如果不看填入所有輸入變數後渲染出的提示結果，要寫出良好且清楚的提示會非常困難。
例如，提示 "Hi ${username} ${message}" 表面看起來合理，但等你渲染後才發現，使用者名稱會和訊息混在一起。
可組合的元件在提示與網頁設計中都很有用。
在兩者中，宣告式都比指令式更好。當所有 HTML 元素都是用 document.createElement 呼叫建立時，要修改網站會變得非常困難。同樣地，閱讀與修改一個由長串 str += "..." 組成的提示，也會很快變得難以掌控。
在兩者裡，我有時都想追求「像素級完美」。在對能力較弱的模型（GPT-3.5 以及更差的模型）下提示時，我會想確保沒有多餘的換行或其他不完美的格式；而在設計網站時，有時每一個像素都很重要。

對於 LLM 代理來說，這個類比甚至可以更進一步延伸：代理提示可以被視為替代理建立一個互動式網站，在那裡它們可以透過呼叫函式來「點擊按鈕」，而且提示會在函式呼叫後重新渲染，就像網站會在按鈕被點擊後重新渲染一樣。

當然，提示設計與網頁設計之間也有差異：

提示目前只處理文字（至少目前是這樣！）。
快取機制也不同：特別是對代理來說，你會希望重新渲染是便宜的，因此只改變提示後半段的內容。這在網頁世界中有個有點牽強的類比（你也會希望為網站做快取最佳化），但我認為本質上是相當不同的挑戰。

儘管如此，這些相似性讓我相信，提示應該被稱為 提示設計（prompt design），而不是 提示工程（prompt engineering）。寫提示 感覺就像在設計一個網站，因此名稱也應該以相同的方式來命名。

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

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

Priompt 是一個受現代網頁設計原則啟發、首次嘗試打造的提示設計函式庫。我們已經在 Cursor 內部使用，而且非常喜歡。

我認為它在一些抽象設計上可能還不完全正確，但我至少可以確信，用 JSX 編寫提示比用字串樣板順手得多。就連像可以輕鬆把提示的一部分註解掉這種小事，都能讓迭代循環快上許多。

Priompt 也附帶了一個（非常匆忙組起來的）預覽網站，你可以在上面用真實資料預覽你的提示。在開發應用程式時，你可以在每次請求時記錄傳入某個元件的序列化後 props。接著，當你看到非預期行為時，就可以前往 Priompt 預覽頁，查看精確的提示內容，並修改原始碼，讓提示在與實際請求相同的 props 下即時更新。我們發現這讓提示的迭代變得容易許多。

如果你試用過，請告訴我你的想法！我很樂於看到更多同路線的點子，或是被直接告知我完全搞錯了、提示設計根本就是個蠢主意 :)。

注意事項

模型變化很快，提示技巧也必須隨之調整。基於此，我認為把這一切統稱為「提示設計」有幾點必須保留的看法：

對 GPT-4 而言，像素級完美的設計並不重要，而且很可能在 GPT-4.5 或更好的模型出現後就會變得過時。
如果依照最近長上下文模型的發展趨勢做外推，上下文視窗的限制可能會消失。不過，我對此並不完全信服。
OpenAI 似乎正朝著讓開發者對提示掌控權愈來愈少的方向前進；有可能一年之後，根本不會再有「提示」這種東西，API 呼叫只需要我們提供原始輸入再加上一段說明即可。這種降低控制權的趨勢，從對話格式（chat format）就開始了，並在最近宣布的函式呼叫（function calling）中延續下去。
有可能快取是提示中最重要的面向之一，在那種情況下，這件事聽起來就更像工程而不是設計。
或許提示設計的層級太低，應該交給更高階的框架或編譯器處理（例如 langchain）。我認為這可能是對的，但考量到 LLM 本身變化速度極快，我個人還是偏好盡量貼近原始模型。

最後不得不說的一點

……因為我真的很想和你一起工作：在 Cursor，我們正在打造 Cursor，一款以 AI 為核心的程式碼編輯器。如果你對 prompt 設計、將 LLM 應用在程式開發上，或是打造優雅的產品感到興奮，請寫信到 arvid@cursor.com 給我。我們目前是位於舊金山的 5 人團隊，我的每一位同事都非常傑出，也希望再找幾位同樣優秀的人——工程師與設計師——一起打造程式開發的未來。

因此，把提示視為帶有動態輸入的清晰溝通（prompting-as-clear-communication-with-dynamic-input） 感覺是最貼切的描述。

還有哪個領域是在針對動態輸入做清楚的溝通？網頁設計。

我們來列出所有相似之處。提示與網頁設計都：

需要清楚，而溝通是主要目標；
必須回應動態內容，不像寫作或雜誌排版；以及
需要讓內容適應不同的大小——網頁設計是螢幕大小，提示則是上下文視窗（context window）。

根據我同時做提示和網頁設計的經驗，我也發現自己在這兩個領域有類似的開發偏好：

看到實際的提示內容 極其重要，就像 看到實際渲染後的網站 一樣重要。如果我必須在腦中模擬 HTML 與 CSS 的渲染過程，我就沒辦法設計網站。同樣地，如果不看填入所有輸入變數後渲染出的提示結果，要寫出良好且清楚的提示會非常困難。
例如，提示 "Hi ${username} ${message}" 表面看起來合理，但等你渲染後才發現，使用者名稱會和訊息混在一起。
可組合的元件在提示與網頁設計中都很有用。
在兩者中，宣告式都比指令式更好。當所有 HTML 元素都是用 document.createElement 呼叫建立時，要修改網站會變得非常困難。同樣地，閱讀與修改一個由長串 str += "..." 組成的提示，也會很快變得難以掌控。
在兩者裡，我有時都想追求「像素級完美」。在對能力較弱的模型（GPT-3.5 以及更差的模型）下提示時，我會想確保沒有多餘的換行或其他不完美的格式；而在設計網站時，有時每一個像素都很重要。

當然，提示設計與網頁設計之間也有差異：

提示目前只處理文字（至少目前是這樣！）。
快取機制也不同：特別是對代理來說，你會希望重新渲染是便宜的，因此只改變提示後半段的內容。這在網頁世界中有個有點牽強的類比（你也會希望為網站做快取最佳化），但我認為本質上是相當不同的挑戰。

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

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

Priompt 是一個受現代網頁設計原則啟發、首次嘗試打造的提示設計函式庫。我們已經在 Cursor 內部使用，而且非常喜歡。

如果你試用過，請告訴我你的想法！我很樂於看到更多同路線的點子，或是被直接告知我完全搞錯了、提示設計根本就是個蠢主意 :)。

注意事項

模型變化很快，提示技巧也必須隨之調整。基於此，我認為把這一切統稱為「提示設計」有幾點必須保留的看法：

對 GPT-4 而言，像素級完美的設計並不重要，而且很可能在 GPT-4.5 或更好的模型出現後就會變得過時。
如果依照最近長上下文模型的發展趨勢做外推，上下文視窗的限制可能會消失。不過，我對此並不完全信服。
OpenAI 似乎正朝著讓開發者對提示掌控權愈來愈少的方向前進；有可能一年之後，根本不會再有「提示」這種東西，API 呼叫只需要我們提供原始輸入再加上一段說明即可。這種降低控制權的趨勢，從對話格式（chat format）就開始了，並在最近宣布的函式呼叫（function calling）中延續下去。
有可能快取是提示中最重要的面向之一，在那種情況下，這件事聽起來就更像工程而不是設計。
或許提示設計的層級太低，應該交給更高階的框架或編譯器處理（例如 langchain）。我認為這可能是對的，但考量到 LLM 本身變化速度極快，我個人還是偏好盡量貼近原始模型。

最後不得不說的一點

因此，把提示視為帶有動態輸入的清晰溝通（prompting-as-clear-communication-with-dynamic-input） 感覺是最貼切的描述。

還有哪個領域是在針對動態輸入做清楚的溝通？網頁設計。

我們來列出所有相似之處。提示與網頁設計都：

需要清楚，而溝通是主要目標；
必須回應動態內容，不像寫作或雜誌排版；以及
需要讓內容適應不同的大小——網頁設計是螢幕大小，提示則是上下文視窗（context window）。

根據我同時做提示和網頁設計的經驗，我也發現自己在這兩個領域有類似的開發偏好：

看到實際的提示內容 極其重要，就像 看到實際渲染後的網站 一樣重要。如果我必須在腦中模擬 HTML 與 CSS 的渲染過程，我就沒辦法設計網站。同樣地，如果不看填入所有輸入變數後渲染出的提示結果，要寫出良好且清楚的提示會非常困難。
例如，提示 "Hi ${username} ${message}" 表面看起來合理，但等你渲染後才發現，使用者名稱會和訊息混在一起。
可組合的元件在提示與網頁設計中都很有用。
在兩者中，宣告式都比指令式更好。當所有 HTML 元素都是用 document.createElement 呼叫建立時，要修改網站會變得非常困難。同樣地，閱讀與修改一個由長串 str += "..." 組成的提示，也會很快變得難以掌控。
在兩者裡，我有時都想追求「像素級完美」。在對能力較弱的模型（GPT-3.5 以及更差的模型）下提示時，我會想確保沒有多餘的換行或其他不完美的格式；而在設計網站時，有時每一個像素都很重要。

當然，提示設計與網頁設計之間也有差異：

提示目前只處理文字（至少目前是這樣！）。
快取機制也不同：特別是對代理來說，你會希望重新渲染是便宜的，因此只改變提示後半段的內容。這在網頁世界中有個有點牽強的類比（你也會希望為網站做快取最佳化），但我認為本質上是相當不同的挑戰。

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

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

Priompt 是一個受現代網頁設計原則啟發、首次嘗試打造的提示設計函式庫。我們已經在 Cursor 內部使用，而且非常喜歡。

如果你試用過，請告訴我你的想法！我很樂於看到更多同路線的點子，或是被直接告知我完全搞錯了、提示設計根本就是個蠢主意 :)。

注意事項

模型變化很快，提示技巧也必須隨之調整。基於此，我認為把這一切統稱為「提示設計」有幾點必須保留的看法：

對 GPT-4 而言，像素級完美的設計並不重要，而且很可能在 GPT-4.5 或更好的模型出現後就會變得過時。
如果依照最近長上下文模型的發展趨勢做外推，上下文視窗的限制可能會消失。不過，我對此並不完全信服。
OpenAI 似乎正朝著讓開發者對提示掌控權愈來愈少的方向前進；有可能一年之後，根本不會再有「提示」這種東西，API 呼叫只需要我們提供原始輸入再加上一段說明即可。這種降低控制權的趨勢，從對話格式（chat format）就開始了，並在最近宣布的函式呼叫（function calling）中延續下去。
有可能快取是提示中最重要的面向之一，在那種情況下，這件事聽起來就更像工程而不是設計。
或許提示設計的層級太低，應該交給更高階的框架或編譯器處理（例如 langchain）。我認為這可能是對的，但考量到 LLM 本身變化速度極快，我個人還是偏好盡量貼近原始模型。