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