Prompt 本質(zhì)上不是“隨便問一句話”，而是你和大模型協(xié)作時下達的一份任務說明。
如果寫得好，模型會更容易理解你的目標、邊界和輸出要求；如果寫得模糊，模型就很容易“自己發(fā)揮”，最后產(chǎn)出看起來像對了、但其實不太能用的內(nèi)容。
自己在日常使用 Prompt 時，到底該注意什么，以及有哪些真正實用的技巧。
一、什么是 Prompt
Prompt，中文通常叫“提示詞”，但如果只把它理解成“提示”，會低估它的作用。
更準確地說：
Prompt 是你給大模型的一份任務指令。
它至少在做四件事：
- 告訴模型它現(xiàn)在要扮演什么角色
- 告訴模型這次具體要完成什么任務
- 告訴模型當前問題的背景和約束
- 告訴模型最后要輸出成什么樣子
可以把一個好 Prompt 理解成下面這個結構：
- Role（角色）：你是誰
- Task（任務）：你要做什么
- Context（上下文）：你要基于什么信息做
- Format（輸出格式）：你要按什么形式輸出
例如下面這個例子：
你現(xiàn)在是一位有 10 年經(jīng)驗的資深 Java 架構師，擅長性能優(yōu)化與代碼評審。
請評審以下 Java 接口代碼的性能問題。代碼功能是用戶訂單查詢，當前線上 QPS 2000 時響應時間超過 500ms。
輸出時請包含以下 3 部分：
1. 性能瓶頸點（標注問題位置和原因）
2. 優(yōu)化方案（附修改建議）
3. 優(yōu)化后的預期收益（響應時間、資源占用變化）
這段 Prompt 的價值就在于：它把角色、任務、上下文和輸出結構都交代清楚了。
模型不會再只給你一個泛泛而談的“可以優(yōu)化 SQL、加緩存、加索引”，而是更有機會輸出一份可落地的結果。
二、Prompt 不是越長越好
這是很多人剛開始使用 Prompt 時最容易踩的坑。
不少人會覺得：
我把背景寫得越多、要求寫得越細，模型就越聰明。
但實際情況通常不是這樣。
過長、過雜、沒有層次的 Prompt，反而容易帶來幾個問題：
- 模型抓不住重點
- 任務邊界變模糊
- 前后要求互相沖突
- 輸出時顧此失彼
所以真正有效的原則不是“越長越好”，而是：
用盡可能簡潔的方式，把最關鍵的信息說清楚。
怎么判斷該長還是該短？
可以用一個很實用的判斷標準：
簡單任務：一句話往往就夠
比如：
- 翻譯一句話
- 解釋一個概念
- 查詢某個 API 的用法
- 幫你潤色一段文案
這類任務沒必要堆很多背景。
復雜任務：要結構化，但不要堆砌
比如：
- 代碼評審
- 架構設計
- 面試題生成
- PRD 拆解
- 長文檔總結
這類任務確實需要補充上下文，但更推薦按結構寫，而不是一股腦全塞進去。
最常用的做法就是按照下面這個模板來組織：
角色
任務
上下文
約束條件
輸出格式
這樣既完整，也不容易失焦。
三、寫 Prompt 時最該注意的 7 件事
下面這 7 條，是日常使用里最值得長期記住的。
1. 角色要具體，不要空泛
很多人會寫：
你是一個 AI 助手，請幫我分析一下...
這種角色幾乎沒提供任何有效信息。
更好的方式是給出一個具體、貼近任務的角色。
例如：
- 你是一位資深 Java 后端工程師
- 你是一位有多年經(jīng)驗的技術面試官
- 你是一位擅長 B 端產(chǎn)品設計的產(chǎn)品經(jīng)理
- 你是一位熟悉 SQL 優(yōu)化的數(shù)據(jù)開發(fā)工程師
角色越貼近任務，模型越容易進入你期望的回答風格。
注意：角色不是越夸張越好，而是越貼題越好。
比如“世界頂級宇宙級專家”這種描述，大多數(shù)時候并不會比“資深 Java 架構師”更有效。
2. 任務要單一，不要混在一起
一個 Prompt 里最怕的不是信息少，而是目標太多。
例如：
請先幫我總結這篇文章，再提煉成 PPT 大綱，再改寫成公眾號風格，最后幫我給出 10 個標題。
這類 Prompt 不是不能做，而是很容易輸出質(zhì)量一般，因為模型同時在處理多個目標。
更好的方式是拆開：
- 先總結文章
- 再基于總結生成 PPT 大綱
- 再改寫成公眾號文章
- 最后生成標題
這就是很典型的 任務分解 思路。
3. 上下文要補“關鍵事實”，不要補一堆廢話
上下文的作用不是把所有東西都塞給模型，而是提供那些會影響答案質(zhì)量的關鍵事實。
例如在代碼評審場景里，這些信息通常是有價值的：
- 語言和框架
- 當前業(yè)務場景
- 線上性能現(xiàn)狀
- 你最關心的指標
- 不能突破的限制條件
而“項目從 2018 年開始做”“團隊有 15 個人”這種內(nèi)容，如果和問題無關，通常不需要寫進去。
4. 輸出格式一定要提前說清楚
如果你不說輸出格式，模型就會默認按“自然語言自由發(fā)揮”。
但很多真實場景里，你要的不是“自由發(fā)揮”，而是“可直接復用”。
例如：
- 要求表格輸出
- 要求分點輸出
- 要求 JSON 輸出
- 要求固定包含 3 個部分
- 要求每個問題后帶追問
輸出格式一旦講清楚，結果可用性會提升很多。
5. 約束條件別怕寫，但要寫得明確
好的 Prompt 往往不是只告訴模型“做什么”，還會告訴它“不要做什么”。
例如：
- 嚴禁脫離提供的簡歷內(nèi)容自由擴展
- 只保留核心觀點，不要復述全文
- 不要輸出代碼塊，只輸出 JSON
- 如果信息不足，請明確說明，不要編造
這些限制條件，能顯著降低模型“腦補”的概率。
6. 不要默認模型理解你的隱含意圖
這是一個很容易忽略的問題。
你心里知道“我要一個更偏實戰(zhàn)的答案”，但如果你沒寫出來，模型并不一定知道。
所以像下面這些要求，最好顯式寫出來：
- 請優(yōu)先從工程實戰(zhàn)角度回答
- 請用通俗易懂的方式解釋
- 請避免過于學術化的表述
- 請給出可執(zhí)行的建議，而不是抽象概念
7. 把模型當成“能力強但需要明確說明的協(xié)作者”
你不能把模型當成“讀心術高手”，但也沒必要把它當成“死板腳本”。
最好的方式是：
- 對任務說明清楚
- 對邊界約束清楚
- 對輸出結構清楚
- 給它必要的上下文
- 給它適度的發(fā)揮空間
Prompt 寫作的本質(zhì)，不是“控制模型說每一個字”，而是把目標和邊界設計清楚。
四、最常用的 Prompt 技巧
如果只選幾種最值得掌握的技巧，我會優(yōu)先推薦下面這幾個。
1. 角色扮演（Role-Playing）
這是最常見、也最容易立刻見效的方法。
比如同樣是問 JVM：
普通寫法
解釋一下什么是 JVM。
加角色后的寫法
你是一位擁有 10 年經(jīng)驗的資深 Java 架構師，請用通俗易懂的語言向初學者解釋 JVM 的核心原理。
后者通常更容易得到：
- 更專業(yè)的角度
- 更穩(wěn)定的表達風格
- 更貼近目標讀者的回答
適用場景：
- 代碼評審
- 架構設計
- 技術選型
- 面試模擬
- 文案改寫
2. 分步思考（Step-by-Step）
對于需要推理、分析、診斷的復雜任務，最有效的方式之一，就是要求模型先分析，再輸出結論。
例如：
請先分析問題可能的原因，再給出最終結論和建議。
或者：
請分步驟完成：
1. 識別問題
2. 分析原因
3. 給出解決方案
為什么這招有效？
因為很多復雜任務如果直接讓模型“給結論”，它容易跳步驟。
而一旦你要求它按步驟走，答案通常會更穩(wěn)定、更像推理出來的結果。
實踐里，建議把重點放在“先分析、再回答”的過程約束上，而不是一味追求非常冗長的顯式推理鏈。
3. 少樣本示例（Few-Shot）
當任務對格式、風格、分類標準要求比較嚴格時，最好的方式往往不是再解釋一遍，而是直接給示例。
例如你要做信息提?。?/p>
請從下面文本中提取姓名、崗位和工作年限。
示例輸入：
張三，5 年 Java 開發(fā)經(jīng)驗，目前應聘后端工程師。
示例輸出：
{
"name": "張三",
"role": "后端工程師",
"years": 5
}
當模型看到樣例之后，它更容易理解：
- 你希望抽哪些字段
- 輸出格式長什么樣
- 你的抽取標準是什么
適用場景：
- 信息提取
- 文本分類
- 風格改寫
- 固定格式輸出
4. 任務分解（Task Decomposition）
如果任務很復雜，不要總想著“一次問完”。
復雜任務更適合拆成多個子問題。
例如“長文檔總結”這個場景，可以拆成：
- 先提煉每一章重點
- 再匯總成完整摘要
- 最后生成面向不同讀者的版本
這種方式的好處是：
- 每一步更聚焦
- 更容易排查哪一步出了問題
- 結果更穩(wěn)定
這和軟件工程里的“分治思想”很像。
5. 結構化輸出（Structured Output）
如果你希望模型輸出能直接被程序消費，或者你想減少人工整理成本，結構化輸出非常重要。
比如：
請以 JSON 格式輸出，字段包括：
- title: string
- summary: string
- score: int，范圍 0-100
- tags: string[]
這比只說“請輸出 JSON”穩(wěn)定得多。
因為后者太模糊，而前者明確了：
- 字段名稱
- 字段類型
- 數(shù)值范圍
- 數(shù)組結構
結構化輸出的幾個實踐建議
提供 Schema 或模板
不要只說“返回 JSON”，最好把字段結構寫出來。
降低溫度
如果任務重點是“穩(wěn)定輸出格式”，一般更適合低溫參數(shù)。
把模型輸出當成外部不可靠輸入
即使你要求“只輸出 JSON”，也仍然可能出現(xiàn)：
- 字段缺失
- 類型錯誤
- JSON 前后夾帶解釋文字
- 輸出被截斷
所以工程上要有：
- 解析失敗重試
- 修復階段
- 字段二次校驗
- 默認值或降級策略
這類思路尤其適合需要把模型輸出接入系統(tǒng)流程的場景。
五、System Prompt 和 User Prompt 有什么區(qū)別
這是很多人會混淆的一個點。
1. System Prompt
System Prompt 主要用來定義：
- 模型的角色
- 行為邊界
- 語氣風格
- 長期約束
它更像是“全局規(guī)則”。
例如：
你是一位資深技術面試官，回答應保持專業(yè)、簡潔，并嚴格基于用戶提供的簡歷內(nèi)容，不得編造未提供的信息。
2. User Prompt
User Prompt 主要是當前這一輪的具體任務。
例如：
請基于以下簡歷生成 8 個面試問題，每個問題都需要附帶一個追問。
簡單理解
- System Prompt：定義你長期“怎么做事”
- User Prompt：定義你這次“具體做什么”
如果你是普通用戶在用聊天產(chǎn)品，不一定能嚴格區(qū)分這兩層；但如果你在做自己的 AI 應用，這個區(qū)別會非常重要。
六、一個順手就能用的 Prompt 模板
如果你平時不知道怎么起手，可以直接套下面這個通用模板。
你現(xiàn)在的角色是：{角色}
你需要完成的任務是：{任務}
相關上下文如下：
{上下文}
請遵守以下約束：
1. {約束 1}
2. {約束 2}
3. {約束 3}
請按以下格式輸出：
{輸出格式}
示例：代碼評審場景
你現(xiàn)在是一位資深 Java 后端架構師，擅長性能優(yōu)化與代碼評審。
你需要完成的任務是：評審下面這段訂單查詢接口代碼，并指出性能問題與改進方案。
相關上下文如下：
- 當前接口用于用戶訂單查詢
- 線上 QPS 約為 2000
- 平均響應時間超過 500ms
- 當前使用 Spring Boot + MySQL
請遵守以下約束：
1. 優(yōu)先分析影響性能的核心問題
2. 結論要結合給定場景，不要泛泛而談
3. 如果信息不足，請明確指出
請按以下格式輸出：
1. 性能瓶頸
2. 原因分析
3. 優(yōu)化方案
4. 預期收益
這個模板的優(yōu)點是：
- 好上手
- 可復用
- 對大部分任務都適用
- 很容易擴展成更復雜的版本
七、幾個最常見的 Prompt 誤區(qū)
最后再專門總結幾個高頻誤區(qū)。
誤區(qū) 1：把 Prompt 寫成情緒表達，而不是任務說明
比如：
你認真一點，別亂說，好好幫我分析。
這種表達不是完全沒用，但作用很有限。
相比之下，真正有效的是把任務和標準講清楚。
誤區(qū) 2：只提要求，不給上下文
你說“幫我優(yōu)化這段代碼”，和你說“這是一個高并發(fā)下的訂單查詢接口，當前慢查詢嚴重”，結果通常完全不是一個質(zhì)量等級。
誤區(qū) 3：只給上下文，不說輸出要什么
如果你給了一大段背景，但不告訴模型最后要輸出什么，它往往只能自由發(fā)揮，導致結果難以直接使用。
誤區(qū) 4：一次塞太多目標
任務越多，結果越容易散。
復雜任務優(yōu)先拆解，而不是一次打包。
誤區(qū) 5：把模型輸出當成絕對可靠結果
尤其是結構化輸出、事實性任務、規(guī)則判斷類任務，最好始終保留二次檢查的意識。
八、如果只記住 5 條，記這 5 條就夠了
如果你不想看太多理論，至少記住下面這 5 條：
- 先說角色，再說任務
- 補關鍵上下文，不要堆無關信息
- 明確輸出格式，不要讓模型自由發(fā)揮
- 復雜任務拆開做，別一次塞太多目標
- 把 Prompt 寫成任務說明書，而不是聊天吐槽
這 5 條，已經(jīng)能解決大多數(shù)“為什么模型回答不穩(wěn)定”的問題。
