Prompt 本质上不是“随便问一句话”，而是你和大模型协作时下达的一份任务说明。
如果写得好，模型会更容易理解你的目标、边界和输出要求；如果写得模糊，模型就很容易“自己发挥”，最后产出看起来像对了、但其实不太能用的内容。
自己在日常使用 Prompt 时，到底该注意什么，以及有哪些真正实用的技巧。
一、什么是 Prompt
Prompt，中文通常叫“提示词”，但如果只把它理解成“提示”，会低估它的作用。
更准确地说：
Prompt 是你给大模型的一份任务指令。
它至少在做四件事：
- 告诉模型它现在要扮演什么角色
- 告诉模型这次具体要完成什么任务
- 告诉模型当前问题的背景和约束
- 告诉模型最后要输出成什么样子
可以把一个好 Prompt 理解成下面这个结构：
- Role（角色）：你是谁
- Task（任务）：你要做什么
- Context（上下文）：你要基于什么信息做
- Format（输出格式）：你要按什么形式输出
例如下面这个例子：
你现在是一位有 10 年经验的资深 Java 架构师，擅长性能优化与代码评审。
请评审以下 Java 接口代码的性能问题。代码功能是用户订单查询，当前线上 QPS 2000 时响应时间超过 500ms。
输出时请包含以下 3 部分：
1. 性能瓶颈点（标注问题位置和原因）
2. 优化方案（附修改建议）
3. 优化后的预期收益（响应时间、资源占用变化）
这段 Prompt 的价值就在于：它把角色、任务、上下文和输出结构都交代清楚了。
模型不会再只给你一个泛泛而谈的“可以优化 SQL、加缓存、加索引”，而是更有机会输出一份可落地的结果。
二、Prompt 不是越长越好
这是很多人刚开始使用 Prompt 时最容易踩的坑。
不少人会觉得：
我把背景写得越多、要求写得越细，模型就越聪明。
但实际情况通常不是这样。
过长、过杂、没有层次的 Prompt，反而容易带来几个问题：
- 模型抓不住重点
- 任务边界变模糊
- 前后要求互相冲突
- 输出时顾此失彼
所以真正有效的原则不是“越长越好”，而是：
用尽可能简洁的方式，把最关键的信息说清楚。
怎么判断该长还是该短？
可以用一个很实用的判断标准：
简单任务：一句话往往就够
比如：
- 翻译一句话
- 解释一个概念
- 查询某个 API 的用法
- 帮你润色一段文案
这类任务没必要堆很多背景。
复杂任务：要结构化，但不要堆砌
比如：
- 代码评审
- 架构设计
- 面试题生成
- PRD 拆解
- 长文档总结
这类任务确实需要补充上下文，但更推荐按结构写，而不是一股脑全塞进去。
最常用的做法就是按照下面这个模板来组织：
角色
任务
上下文
约束条件
输出格式
这样既完整，也不容易失焦。
三、写 Prompt 时最该注意的 7 件事
下面这 7 条，是日常使用里最值得长期记住的。
1. 角色要具体，不要空泛
很多人会写：
你是一个 AI 助手，请帮我分析一下...
这种角色几乎没提供任何有效信息。
更好的方式是给出一个具体、贴近任务的角色。
例如：
- 你是一位资深 Java 后端工程师
- 你是一位有多年经验的技术面试官
- 你是一位擅长 B 端产品设计的产品经理
- 你是一位熟悉 SQL 优化的数据开发工程师
角色越贴近任务，模型越容易进入你期望的回答风格。
注意：角色不是越夸张越好，而是越贴题越好。
比如“世界顶级宇宙级专家”这种描述，大多数时候并不会比“资深 Java 架构师”更有效。
2. 任务要单一，不要混在一起
一个 Prompt 里最怕的不是信息少，而是目标太多。
例如：
请先帮我总结这篇文章，再提炼成 PPT 大纲，再改写成公众号风格，最后帮我给出 10 个标题。
这类 Prompt 不是不能做，而是很容易输出质量一般，因为模型同时在处理多个目标。
更好的方式是拆开：
- 先总结文章
- 再基于总结生成 PPT 大纲
- 再改写成公众号文章
- 最后生成标题
这就是很典型的 任务分解 思路。
3. 上下文要补“关键事实”，不要补一堆废话
上下文的作用不是把所有东西都塞给模型，而是提供那些会影响答案质量的关键事实。
例如在代码评审场景里，这些信息通常是有价值的：
- 语言和框架
- 当前业务场景
- 线上性能现状
- 你最关心的指标
- 不能突破的限制条件
而“项目从 2018 年开始做”“团队有 15 个人”这种内容，如果和问题无关，通常不需要写进去。
4. 输出格式一定要提前说清楚
如果你不说输出格式，模型就会默认按“自然语言自由发挥”。
但很多真实场景里，你要的不是“自由发挥”，而是“可直接复用”。
例如：
- 要求表格输出
- 要求分点输出
- 要求 JSON 输出
- 要求固定包含 3 个部分
- 要求每个问题后带追问
输出格式一旦讲清楚，结果可用性会提升很多。
5. 约束条件别怕写，但要写得明确
好的 Prompt 往往不是只告诉模型“做什么”，还会告诉它“不要做什么”。
例如：
- 严禁脱离提供的简历内容自由扩展
- 只保留核心观点，不要复述全文
- 不要输出代码块，只输出 JSON
- 如果信息不足，请明确说明，不要编造
这些限制条件，能显著降低模型“脑补”的概率。
6. 不要默认模型理解你的隐含意图
这是一个很容易忽略的问题。
你心里知道“我要一个更偏实战的答案”，但如果你没写出来，模型并不一定知道。
所以像下面这些要求，最好显式写出来：
- 请优先从工程实战角度回答
- 请用通俗易懂的方式解释
- 请避免过于学术化的表述
- 请给出可执行的建议，而不是抽象概念
7. 把模型当成“能力强但需要明确说明的协作者”
你不能把模型当成“读心术高手”，但也没必要把它当成“死板脚本”。
最好的方式是：
- 对任务说明清楚
- 对边界约束清楚
- 对输出结构清楚
- 给它必要的上下文
- 给它适度的发挥空间
Prompt 写作的本质，不是“控制模型说每一个字”，而是把目标和边界设计清楚。
四、最常用的 Prompt 技巧
如果只选几种最值得掌握的技巧，我会优先推荐下面这几个。
1. 角色扮演（Role-Playing）
这是最常见、也最容易立刻见效的方法。
比如同样是问 JVM：
普通写法
解释一下什么是 JVM。
加角色后的写法
你是一位拥有 10 年经验的资深 Java 架构师，请用通俗易懂的语言向初学者解释 JVM 的核心原理。
后者通常更容易得到：
- 更专业的角度
- 更稳定的表达风格
- 更贴近目标读者的回答
适用场景：
- 代码评审
- 架构设计
- 技术选型
- 面试模拟
- 文案改写
2. 分步思考（Step-by-Step）
对于需要推理、分析、诊断的复杂任务，最有效的方式之一，就是要求模型先分析，再输出结论。
例如：
请先分析问题可能的原因，再给出最终结论和建议。
或者：
请分步骤完成：
1. 识别问题
2. 分析原因
3. 给出解决方案
为什么这招有效？
因为很多复杂任务如果直接让模型“给结论”，它容易跳步骤。
而一旦你要求它按步骤走，答案通常会更稳定、更像推理出来的结果。
实践里，建议把重点放在“先分析、再回答”的过程约束上，而不是一味追求非常冗长的显式推理链。
3. 少样本示例（Few-Shot）
当任务对格式、风格、分类标准要求比较严格时，最好的方式往往不是再解释一遍，而是直接给示例。
例如你要做信息提取：
请从下面文本中提取姓名、岗位和工作年限。
示例输入：
张三，5 年 Java 开发经验，目前应聘后端工程师。
示例输出：
{
"name": "张三",
"role": "后端工程师",
"years": 5
}
当模型看到样例之后，它更容易理解：
- 你希望抽哪些字段
- 输出格式长什么样
- 你的抽取标准是什么
适用场景：
- 信息提取
- 文本分类
- 风格改写
- 固定格式输出
4. 任务分解（Task Decomposition）
如果任务很复杂，不要总想着“一次问完”。
复杂任务更适合拆成多个子问题。
例如“长文档总结”这个场景，可以拆成：
- 先提炼每一章重点
- 再汇总成完整摘要
- 最后生成面向不同读者的版本
这种方式的好处是：
- 每一步更聚焦
- 更容易排查哪一步出了问题
- 结果更稳定
这和软件工程里的“分治思想”很像。
5. 结构化输出（Structured Output）
如果你希望模型输出能直接被程序消费，或者你想减少人工整理成本，结构化输出非常重要。
比如：
请以 JSON 格式输出，字段包括：
- title: string
- summary: string
- score: int，范围 0-100
- tags: string[]
这比只说“请输出 JSON”稳定得多。
因为后者太模糊，而前者明确了：
- 字段名称
- 字段类型
- 数值范围
- 数组结构
结构化输出的几个实践建议
提供 Schema 或模板
不要只说“返回 JSON”，最好把字段结构写出来。
降低温度
如果任务重点是“稳定输出格式”，一般更适合低温参数。
把模型输出当成外部不可靠输入
即使你要求“只输出 JSON”，也仍然可能出现：
- 字段缺失
- 类型错误
- JSON 前后夹带解释文字
- 输出被截断
所以工程上要有：
- 解析失败重试
- 修复阶段
- 字段二次校验
- 默认值或降级策略
这类思路尤其适合需要把模型输出接入系统流程的场景。
五、System Prompt 和 User Prompt 有什么区别
这是很多人会混淆的一个点。
1. System Prompt
System Prompt 主要用来定义：
- 模型的角色
- 行为边界
- 语气风格
- 长期约束
它更像是“全局规则”。
例如：
你是一位资深技术面试官，回答应保持专业、简洁，并严格基于用户提供的简历内容，不得编造未提供的信息。
2. User Prompt
User Prompt 主要是当前这一轮的具体任务。
例如：
请基于以下简历生成 8 个面试问题，每个问题都需要附带一个追问。
简单理解
- System Prompt：定义你长期“怎么做事”
- User Prompt：定义你这次“具体做什么”
如果你是普通用户在用聊天产品，不一定能严格区分这两层；但如果你在做自己的 AI 应用，这个区别会非常重要。
六、一个顺手就能用的 Prompt 模板
如果你平时不知道怎么起手，可以直接套下面这个通用模板。
你现在的角色是：{角色}
你需要完成的任务是：{任务}
相关上下文如下：
{上下文}
请遵守以下约束：
1. {约束 1}
2. {约束 2}
3. {约束 3}
请按以下格式输出：
{输出格式}
示例：代码评审场景
你现在是一位资深 Java 后端架构师，擅长性能优化与代码评审。
你需要完成的任务是：评审下面这段订单查询接口代码，并指出性能问题与改进方案。
相关上下文如下：
- 当前接口用于用户订单查询
- 线上 QPS 约为 2000
- 平均响应时间超过 500ms
- 当前使用 Spring Boot + MySQL
请遵守以下约束：
1. 优先分析影响性能的核心问题
2. 结论要结合给定场景，不要泛泛而谈
3. 如果信息不足，请明确指出
请按以下格式输出：
1. 性能瓶颈
2. 原因分析
3. 优化方案
4. 预期收益
这个模板的优点是：
- 好上手
- 可复用
- 对大部分任务都适用
- 很容易扩展成更复杂的版本
七、几个最常见的 Prompt 误区
最后再专门总结几个高频误区。
误区 1：把 Prompt 写成情绪表达，而不是任务说明
比如：
你认真一点，别乱说，好好帮我分析。
这种表达不是完全没用，但作用很有限。
相比之下，真正有效的是把任务和标准讲清楚。
误区 2：只提要求，不给上下文
你说“帮我优化这段代码”，和你说“这是一个高并发下的订单查询接口，当前慢查询严重”，结果通常完全不是一个质量等级。
误区 3：只给上下文，不说输出要什么
如果你给了一大段背景，但不告诉模型最后要输出什么，它往往只能自由发挥，导致结果难以直接使用。
误区 4：一次塞太多目标
任务越多，结果越容易散。
复杂任务优先拆解，而不是一次打包。
误区 5：把模型输出当成绝对可靠结果
尤其是结构化输出、事实性任务、规则判断类任务，最好始终保留二次检查的意识。
八、如果只记住 5 条，记这 5 条就够了
如果你不想看太多理论，至少记住下面这 5 条：
- 先说角色，再说任务
- 补关键上下文，不要堆无关信息
- 明确输出格式，不要让模型自由发挥
- 复杂任务拆开做，别一次塞太多目标
- 把 Prompt 写成任务说明书，而不是聊天吐槽
这 5 条，已经能解决大多数“为什么模型回答不稳定”的问题。
