什麼是提示工程？優化大型語言模型輸出

提示工程，是一門設計輸入——指令、上下文、示例與輸出契約——使語言模型能夠穩定、可重複、可規模化地產出你所依賴的結果的學科。它常被描述爲「好好跟模型說話」，這種說法既低估了它，更糟的是，讓它聽起來不可度量。做得對的話，它更接近於"爲一個概率系統做接口設計"：你規定任務、約束輸出空間、提供證據，然後用一組用例測試這份規格說明，直到它的行爲變得可預測。

它在商業上重要，是因爲同一個模型，被提問的方式不同，產出質量會有實質性差異。這種方差，正是"在演示中令人印象深刻的試點"與"在真實用戶面前活下來的系統"之間的差別。本文討論提示工程是什麼、哪些技術確有可度量的幫助、如何評估提示而不是靠猜，以及——同樣重要的——提示工程在哪裏不再是合適的工具，而應該由函數調用接手。

到底什麼是提示工程？

提示（prompt）是模型接收到的全部輸入：設定角色與約束的系統指令、用戶的請求、任何檢索到的上下文、任何示例，以及累積的對話。提示工程就是有意地組合這五者的實踐。

• 系統指令。常設的任務簡報：模型是誰、必須始終做什麼、絕不能做什麼。這一層跨請求保持穩定，是策略的棲身之處。
• 任務指令。具體請求，寫成帶明確成功條件的祈使句，而不是寫成一個話題。「總結一下」是話題；「用三條要點總結，每條不超過 20 字，只使用所給文本」纔是任務。
• 上下文。模型必須使用的證據——檢索到的文檔、表結構、客戶記錄。你往這裏放什麼，比你在別處寫什麼更能決定結果的落地性。
• 示例。展示模式的輸入-輸出配對樣例。這是影響格式一致性與語氣的最強槓桿。
• 輸出契約。對答案形態的顯式聲明——JSON schema、markdown 標題、要點數量、單位，或在無法回答時應輸出的字符串。

最有幫助的心智模型是：你不是在說服模型，你是在約束它。你在提示裏留下的每一處歧義，都是模型會通過採樣來解決的一個自由度；而採樣帶來的選擇，正是讓輸出在多次運行之間不一致的原因。

爲什麼提示結構會改變模型輸出？

因爲語言模型不是在檢索答案，而是在延續一種由它面前的文本所條件的模式。由此產生三個推論，每一個都對應一項技術。

順序很重要。模型對上下文窗口開頭與結尾的權重高於中部。請把指令和輸出契約放在最前，把證據放在中部，把具體問題放在最後——並在模型開始生成的位置重複關鍵約束。

示範勝過描述。給出三個正確的樣例，比寫三段描述更能可靠地傳達一種格式。樣例把描述轉化成模型可以延續的模式，這也正是少樣本提示在格式類任務上帶來階躍式提升、而在推理類任務上只帶來邊際改善的原因。

推理受益於被外化。要求模型先分步思考再作答，能提升多步問題的準確率，因爲中間步驟會成爲條件化最終輸出的那段上下文。收益是真實的但有邊界：它在算術、邏輯與多跳問題上幫助最大，在簡單檢索或分類上幫助最小——在那裏它只增加成本，不增加準確率。

還有第四個較少被討論的推論：隨着同時施加的約束數量增加，指令遵循能力會退化。十條規則放在一個提示裏，並不是每條都被執行得和一條規則時一樣好——而是每條都被執行得更差。當一個提示的硬約束超過大約十二條時，請把任務拆成多個階段。

哪些核心技術真正起作用？

按在典型企業任務上的實測效果排序，並附上誠實的保留意見。

檢索增強生成（RAG）。把相關原文放進上下文，是任何依賴"模型未訓練過"或"會隨時間變化"的事實的任務中，最大的單項準確率槓桿。它還讓答案可審計，因爲你可以引用被使用的段落。失效模式在於檢索質量：切分不當或向量匹配太弱，會把錯誤證據放進上下文，而模型會忠實地使用它。

少樣本樣例。兩到五個覆蓋數據變化的樣例，能大幅改善格式遵循與語氣一致性。要精心挑選；隨機採樣的樣例教的是噪聲。

顯式輸出契約。要求一個 schema，並把 schema 提供給它。帶校驗與修復循環的結構化輸出，能把一個散文生成器變成其他系統可以消費的組件。工程價值大部分在這裏。

思維鏈與任務分解。要求先推理再作答，或把複雜任務拆成顯式的子步驟。請有選擇地使用：先度量它是否真的改善了你的任務，再決定是否爲全部流量付出延遲與 token 成本。

受限解碼與護欄。在可能之處限制詞表，按 schema 校驗輸出，並在重試時把校驗錯誤一起放進提示。這能把"通常正確"轉化爲"要麼正確、要麼拒絕"。

提示鏈。把大任務拆成一串更小的調用，每步都有窄指令和自己的輸出契約。鏈式提升可靠性的原因是每一步的自由度更少，而且失敗變得局部、可調試。

自一致性。採樣多個補全結果，取多數或證據最充分的那個。成本高，但對於單次採樣出錯不可接受的高價值決策很有用。

如何寫出一個有效的提示？

一個實操例子。合同審查提示的樸素版本長這樣：

「總結一下這份合同，告訴我有沒有風險。」

它在四個具體方面失敗："總結一下"沒有長度和範圍；"風險"沒有定義，於是模型自行選擇；沒有說明信息缺失時該怎麼辦；輸出是散文，下游無法消費。生產版本是：

• 角色與範圍。「你正在從買方視角審查一份商業供貨協議。只考慮所給文本中的條款。」
• 任務。「識別對買方造成財務或運營敞口的條款。」
• 分類體系。「把每條歸爲以下之一：payment_terms、liability_cap、termination、indemnity、delivery_sla、data_protection、other。」
• 輸出契約。「返回一個 JSON 數組。每項：{clause_ref, category, exposure (high|medium|low), explanation（不超過 30 字）, quoted_text}。若沒有條款造成敞口，返回 []。」
• 落地規則。「引用條款原文。不得推斷文本中不存在的條款。若某條款含義模糊，把 exposure 設爲 medium，並在 explanation 中註明該模糊之處。」
• 示例。給出一條高敞口、一條低敞口的完整樣例，嚴格使用上述輸出 schema。

然後校驗：解析 JSON、檢查枚舉取值、檢查 quoted_text 是否在原文中逐字出現；若校驗失敗，帶着錯誤信息重新提示一次。這個循環，正是"一個提示"與"一個系統"之間的差別。

少樣本提示什麼時候不再划算？

少樣本提示的收益先遞減、後轉負，而轉折點是可預測的。

值得用的情況：輸出格式特殊或嚴格；任務涉及企業風格或領域慣例；分類邊界微妙、示例能澄清它；或者模型必須在幾種都說得通的表述之間做選擇。兩到五個樣例通常就能捕獲大部分收益。

不值得用的情況：任務是有明確 schema 的簡單抽取或分類；樣例太長、佔用了你需要留給證據的上下文；或者樣例不具代表性——此時它們會主動把模型引向錯誤的模式。

有害的情況：樣例取自"手邊方便"而非"有代表性"的樣本，這是少樣本出錯最常見的方式。如果你的樣例聚集在某一個類別上，模型就會過度預測該類別。請拿樣例的標籤分佈去對齊真實分佈。

務實規則是：先用嚴格的輸出契約做零樣本，然後度量。只針對你實際觀察到的失效模式添加樣例，並且每加一次就重新度量一次。沒有度量的提示修改，是迷信。

如何在不靠猜測的前提下評估提示？

這是大多數團隊失敗的地方，也是回報最高的能力建設。四個組成部分：

留出測試集。五十到幾百個真實輸入，帶期望輸出；在無法給出期望輸出時，帶一份顯式評分細則。它必須是留出的：針對你每天都盯着的那幾個用例調優出來的提示，會對它們過擬合。

與任務相稱的指標。抽取用精確匹配；分類用 F1 或分類別精確率與召回率；結構化輸出用 schema 合法率與字段級準確率；RAG 用落地性與引用準確率；散文用人工或模型按細則評分。選定一個主指標和兩個護欄指標，並在開始調優前把它們寫下來。

迴歸紀律。在每次提示變更、每次模型版本變更時，以及按固定週期運行這套測試。模型供應商會靜默更新模型；上個季度得分 94% 的提示，今天可能只有 87%，而你這邊一行未改。

錯誤分析優先於聚合分數。下降 6 個點說明不了任何事；仔細檢查二十個失敗案例，才能準確告訴你該修什麼。按類型把錯誤分桶——格式錯、缺少落地依據、過度拒絕、拒絕不足、分類錯誤——然後修最大的那一桶。大多數提示問題，其實是兩三種失效模式穿着不同的外衣。

爲什麼提示工程不足以支撐企業級的準確性？

因爲提示能讓模型把答案表達得好，卻不能讓答案爲真。有三重限制是結構性的，不是靠更好的措辭能修好的。

事實性。一個被問到它沒有的數字的模型，會編出一個可信的數字。沒有任何指令能消除這一點；只有落地到檢索到的證據，以及——當這個數字重要時——真正做一次計算才能解決。Gartner 被廣泛引用的估算——數據質量低下平均每年給組織造成 1,290 萬美元損失——提醒我們未經覈實的數字在下游會造成什麼代價。

算術與聚合。語言模型是在近似地做算術。讓一個模型在上下文裏把三十個數字加總，等於接受一個你絕不會容忍於電子表格的錯誤率。正確的設計是：讓模型寫查詢或調用函數，由確定性系統來做算術。

時效性與新鮮度。訓練截止之後發生的一切，都在模型知識之外。提示修不了陳舊；檢索與工具調用可以。

正因如此，成熟的模式是「提示工程 + 工具」。提示負責行爲——模型如何拆解問題、引用什麼、如何格式化輸出、何時拒絕；函數調用負責事實。蜂啓諮詢（Beehive Strategy）正是按這個分工落地：受治理的語義層定義有哪些工具可用、它們可以返回什麼；MCP 連接器針對實時系統執行查詢；提示則約束模型只能組合經過認證的度量，而不能發明度量。結果是答案既表達得好、又可驗證——這是唯一能經得起審計的組合。

最常見的提示錯誤有哪些？

成功條件模糊。「寫得簡潔些」不是規格說明。請寫「不超過 120 字」或「三條要點」。

同時施加過多約束。超過約十二條規則之後，每一條的遵循度都會下降。請拆成鏈式步驟。

把指令埋起來。關鍵約束應當放在開頭，並在生成點之前再次重複。

沒有設定拒絕路徑。如果從沒告訴模型答不上來時該做什麼，它就會硬答。請顯式規定兜底行爲。

要求了輸出契約卻不做校驗。要求返回 JSON，不等於拿到合法 JSON。請解析並校驗每一個響應。

樣例不具代表性。順手拿來的樣例，會把模型引向你手上恰好有的那些類別。

沒有測試集就調優。這是根源性的錯誤；其他都還可救，這一條不行。

用提示去繞開數據問題。如果底層數據本身是錯的或過期的，再好的提示也只會產出措辭更好的錯誤答案。

提示與函數調用、智能體是什麼關係？

三者互補，分工穩定。提示負責理解：用戶是什麼意思、如何拆解、引用什麼、如何呈現。函數調用負責執行：跑查詢、取記錄、做計算、寫系統。智能體則增加一個規劃循環，負責編排工具調用、觀察結果，並在落地依據薄弱時重試。

對建設者來說，實操含義是：隨着工具覆蓋面改善，投入重心會從雕琢巧妙的指令，轉向設計好的工具和好的 schema。一個命名清晰、描述精確、參數帶類型的函數，比三段指令更可靠地教會模型。這也正是生產系統的演進方向從提示工程走向工具設計的原因——我們在另一篇關於「爲什麼函數調用正在取代提示工程」的分析中對此有詳細展開。

團隊應該如何把提示工程工業化？

把提示當代碼對待，因爲它們本來就是代碼。

• 對每個提示做版本管理，與調用它的代碼放在一起，並附變更日誌說明每次修改的原因。
• 用參數化而不是字符串拼接。使用帶類型槽位的模板，使用戶輸入無法重構指令。這也是你的提示注入防禦：把不可信內容與指令分離，並把它標記爲數據。
• 固定模型並記錄版本。把模型標識與提示版本隨每次響應一起記錄，以便歸因行爲變化。
• 把評估套件自動化接入 CI，並在發生迴歸時阻斷部署。
• 在生產環境做監控。跟蹤 schema 合法率、拒絕率、延遲、單次請求成本，以及抽樣質量分。任何一項漂移都是你的早期預警。
• 明確歸屬。無人擁有的提示，就是會靜默腐壞的提示。爲每個生產提示及其測試集指定負責團隊。

做到這些，提示工程就不再是發燒友練的手藝，而成爲一門有可度量錯誤率的工程學科——而只有這個版本，才配進入企業系統。