Prompt 設計入門:把模型當同事而不是搜尋引擎

工程師第一次寫 prompt,常常沿用查搜尋引擎的習慣:丟幾個關鍵字,期待 系統自己猜出你要什麼。這個心智模型對搜尋引擎有效,對 LLM 卻常常失敗 ——因為模型不是在「查找」答案,而是在「推理並生成」答案。真正好用的 類比,是把模型當成一位剛加入專案、聰明但完全不了解背景的新同事。

搜尋引擎心智 vs. 同事心智

對搜尋引擎,你會輸入「React useEffect 無限迴圈」,期待它從既有索引裡 撈出最相關的頁面。對一位新同事,你不會只丟這幾個字——你會說清楚: 現在遇到什麼情境、已經試過什麼、期待的結果長什麼樣。prompt 設計的 第一課,就是把這種「交接工作」的完整度,搬到你和模型的對話裡。

三個把「查詢」變成「交接」的具體做法

1. 給角色,但給的是責任,不是頭銜。 與其寫「你是一位資深工程師」,不如寫「你要對這段程式碼的正確性負責, 發現任何邊界情況都要主動提出,不要假設輸入永遠合法」。頭銜是裝飾, 責任範圍才會真正影響模型的行為。

2. 交代「為什麼」,不只是「做什麼」。 新同事拿到一張只寫「把這個函式改成非同步」的票,很容易改壞介面;如果 多一句「因為呼叫端已經在等待其他非同步操作,同步呼叫會卡住整個佇列」, 他改的方式會完全不同。模型也一樣,理由能約束它挑選解法的空間。

3. 明確定義「完成」的樣子。 「幫我優化這段程式碼」是模糊指令;「幫我優化這段程式碼,目標是把時間 複雜度從 O(n²) 降到 O(n log n),並保留原本的公開介面」才是可驗收的 任務。輸出格式、驗收標準寫得越清楚,模型的產出離題的機率就越低。

上下文不是越多越好

心智模型轉過來之後,常見的下一個誤區是「既然要交代背景,那就把所有 資料都塞進去」。但同事心智的重點是相關的背景,不是全部背景。 把整份程式碼庫貼進 prompt,和完全不給背景一樣,都會讓模型難以聚焦—— 差別只是前者看起來比較「用心」。

實務上比較有效的做法,是像簡報一樣分層:先給結論性的任務描述,再給 必要的程式片段或資料,最後才附上「如果需要更多細節,可以要求我提供 某個檔案」這類的延伸選項。這樣模型可以先用最精簡的資訊嘗試作答,只在 真正需要時才「回頭問你要更多」。

把 prompt 當成活文件維護

同事會成長,你交接工作的方式也會跟著調整;prompt 也一樣。與其把 prompt 寫死在程式碼裡的一個字串常數,不如把它當成一份會被回顧、會 被版本控管、會因為觀察到新的失敗案例而修訂的文件。每一次模型答錯, 與其怪模型「不夠聰明」,不如先問:如果這是交給新同事的工單,哪一句 交代得不夠清楚?

把這個習慣建立起來之後,你會發現多數所謂的「prompt engineering 技巧」,其實都只是「把話說清楚」這件事的具體化——只是說話的對象, 換成了一位讀得極快、但完全沒有共同記憶的同事。