小李和小王都在用 ChatGPT 写营销文案。
小李打开对话框,输入:“帮我写个文案。“ChatGPT 回了一段干巴巴的通用文本,像是从教科书里抄的,放在任何产品上都行,也就意味着放在哪里都不出彩。
小王的做法不一样。他输入的是:
ChatGPT 返回了一篇几乎可以直接发布的爆款文案。
用的是同一个模型,结果天差地别。 差距不在 AI 的能力上,而在你怎么 “问”:也就是提示词(Prompt)的质量。
这篇文章要教你的,就是怎么写出好的提示词。
本文要点
- 提示词决定了 AI 输出质量的 80%
- 三大核心设计原则:清晰具体、结构化、角色设定
- 基础技巧:Zero-shot、Few-shot、结构化输出
- 高级技巧:CoT 思维链、ToT 思维树、自洽性采样、ReAct
- System Prompt 设计模式与 User Prompt 的分工
- Prompt Caching 机制与成本优化
- 结构化输出保障:JSON Mode、Tool Use、JSON Schema
- 提示词模板与常见问题排查
一、为什么提示词这么重要?
1.1 回顾:模型的工作方式
在上一篇文章中我们讲过,大模型的核心工作就是一件事:根据输入预测下一个 Token。你给它的输入文本,就是它预测的全部依据。
这意味着什么?你输入的内容越精确、越丰富,模型能 看到 的上下文就越好,预测出的结果也越贴合你的需要。
1.2 提示词就是 面试题目
你可以把每次和 AI 的对话想象成一场面试。模型是候选人,提示词是你出的面试题。
如果你问:“说说你的优点。” 这道题太宽泛了,候选人只能给一个泛泛的回答。
如果你问:“请结合你上一份工作中的三个具体项目,说明你在团队协作和技术难题攻关方面的优势,每个项目用 STAR 方法描述。” 候选人能给出一个清晰、有料、可量化的回答。
题目出得好,答案自然好。提示词也一样。
1.3 提示词的四个作用
一段好的提示词,本质上在帮模型做四件事:
- 设定上下文:告诉模型这是什么场景、背景信息是什么
- 定义角色:让模型以特定的身份和视角来回答
- 提供示例:通过例子展示你期望的输出格式和风格
- 引导推理:通过特定的指令让模型一步步思考,而非直接给答案
二、三大核心设计原则
2.1 原则一:清晰具体
最常见的提示词问题就是 太模糊。模型无法读心,你不说清楚,它只能猜。
差的提示词:
帮我写个邮件。好的提示词:
请帮我写一封工作邮件。收件人:我的直属领导张总。目的:申请下周三(3 月 11 日)在家远程办公一天。原因:家中有维修工人上门,需要有人在场。语气:礼貌、正式,但不要过于生硬。长度:150 字以内。两者的区别一目了然。好的提示词像一张需求文档,包含五个关键要素:
| 要素 | 说明 | 上面例子中的对应 |
|---|---|---|
| 任务 | 你要模型做什么 | 写一封工作邮件 |
| 输入格式 | 给模型的原始材料 | 收件人、原因等背景信息 |
| 输出格式 | 你期望的输出样式 | 150 字以内的邮件 |
| 约束条件 | 限制和要求 | 礼貌正式但不生硬 |
| 示例 | 可选,展示期望的效果 | 此例未提供,但可以加 |
实战建议:写完提示词后,把自己当成模型读一遍。如果你觉得信息不够,模型也一定觉得不够。
2.2 原则二:结构化
人类阅读时喜欢有结构的内容,模型也一样。用分隔符、编号和 Markdown 格式组织你的提示词,模型更容易理解你的意图。
来看一个代码审查的结构化提示词:
## 角色你是一位资深后端工程师,精通 Go 语言和微服务架构。
## 任务请审查以下代码片段,从四个维度给出评价。
## 审查维度1. **正确性**:逻辑是否正确,有无 Bug2. **性能**:有无明显的性能瓶颈3. **可读性**:命名、结构是否清晰4. **安全性**:有无潜在的安全风险
## 输出格式每个维度用以下格式:- 评分:1~5 分- 问题:具体描述- 建议:改进方案(附代码)
## 代码// 这里放你要审查的代码
这段提示词用 Markdown 标题分隔了不同部分,用编号列出了审查维度,用模板定义了输出格式。模型拿到这样的输入,能给出的回答远比 帮我看看这段代码 精确得多。
2.3 原则三:角色设定
角色设定是提示工程中最被低估的技巧之一。
同样问 如何设计一个高并发系统,给模型设定不同的角色,回答会截然不同:
- 你是一位有 10 年经验的架构师:回答会使用专业术语,讨论分布式架构、限流策略、数据库分片,默认读者有技术背景
- 你是一位刚入职的实习生:回答会用大白话解释,会多用类比,避免术语堆砌
角色设定影响三个维度:
| 维度 | 影响 |
|---|---|
| 术语深度 | 专家用术语,新手用大白话 |
| 解释详细度 | 专家跳过基础概念,新手从头解释 |
| 思考视角 | 架构师从全局看,前端工程师从用户体验看 |
角色设定不只是 装装样子。模型在训练数据中见过大量不同身份人群写的文本,设定角色等于告诉模型 从这类文本的风格和深度出发。
三、基础技巧
3.1 Zero-shot:直接给任务
Zero-shot(零样本)是最简单的用法:直接描述任务,不提供任何示例。
将以下英文翻译成中文,保持原文的语气和风格:
"The best way to predict the future is to invent it."对于翻译、摘要、简单问答等模型 本来就会 的任务,Zero-shot 通常就够了。模型在训练阶段已经见过海量的翻译对照数据,不需要你额外示范。
适用场景:模型已经擅长的标准任务。
3.2 Few-shot:用示例教模型
Few-shot(少样本)的核心思想是:给模型 2~5 个示例,让它从示例中学习输出的模式。
来看一个把产品参数转换成营销文案的例子:
请将产品参数转换为面向消费者的营销文案。
示例 1:输入:蓝牙耳机,40mm 驱动单元,主动降噪,续航 30 小时输出:戴上它,世界安静了。40mm 大驱动单元带来录音棚级音质,ANC 主动降噪让你沉浸在自己的世界里。30 小时超长续航,一周只需充一次电。
示例 2:输入:机械键盘,Gasket 结构,PBT 键帽,三模连接,4000mAh输出:每一次敲击都是享受。Gasket 弹性结构带来柔软又扎实的手感,PBT 键帽越用越润。蓝牙、2.4G、有线三模随心切换,4000mAh 电池让你忘记充电这回事。
现在请转换:输入:便携按摩仪,TENS 脉冲技术,6 种模式,Type-C 充电,重量 120g输出:模型会从两个示例中学到:用第二人称、先讲体验再讲参数、语言要有画面感、每个特性对应一句话。然后它会用同样的风格生成新的文案。
Few-shot 的要点:
- 示例数量:2~5 个最佳,太少模式不明显,太多浪费 Token
- 示例质量比数量重要:一个高质量的示例胜过五个平庸的
- 示例要覆盖不同情况:如果任务有多种输入类型,每种都给一个示例
3.3 Many-shot:大量示例
当任务非常复杂或对一致性要求极高时,可以提供 10 个甚至更多的示例。这叫 Many-shot(多样本)。
不过 Many-shot 存在边际效益递减。研究表明,示例从 0 到 3 个时效果提升最明显,从 3 到 10 个时提升变缓,超过 10 个之后提升非常有限。而且更多示例意味着消耗更多 Token,成本更高。
经验法则:先试 3 个示例,效果不够再加到 5 个,5 个还不行再考虑其他策略(如 CoT),而不是无限堆示例。
3.4 结构化输出
让模型输出 JSON、XML 等结构化格式,是提示工程中非常实用的技巧。结构化输出可以直接被程序解析,省去了从自然语言中提取信息的麻烦。
示例提示词:
分析以下用户评论的情感,返回 JSON 格式。
评论:"这个耳机音质不错,但佩戴时间长了耳朵会痛。"
请返回以下格式的 JSON:{ "overall_sentiment":"positive | negative | mixed", "aspects": [ { "aspect":"具体方面 ", "sentiment":"positive | negative", "evidence":"原文依据 " } ]}模型输出:
{ "overall_sentiment":"mixed", "aspects": [ { "aspect":"音质 ", "sentiment":"positive", "evidence":"音质不错 " }, { "aspect":"佩戴舒适度 ", "sentiment":"negative", "evidence":"佩戴时间长了耳朵会痛 " } ]}主流 API 都提供了强制结构化输出的能力。
OpenAI 的 response_format 参数:
from openai import OpenAI
client = OpenAI()response = client.chat.completions.create( model="gpt-4o", messages=[{"role":"user","content":"分析情感..."}], response_format={ "type":"json_schema", "json_schema": { "name":"sentiment_analysis", "schema": { "type":"object", "properties": { "overall_sentiment": { "type":"string", "enum": ["positive","negative","mixed"] }, "aspects": { "type":"array", "items": { "type":"object", "properties": { "aspect": {"type":"string"}, "sentiment": {"type":"string"}, "evidence": {"type":"string"} } } } } } } })Claude 的 Tool Use 强制格式:
import anthropic
client = anthropic.Anthropic()response = client.messages.create( model="claude-sonnet-4-20250514", max_tokens=1024, tools=[{ "name":"sentiment_analysis", "description":"分析文本情感 ", "input_schema": { "type":"object", "properties": { "overall_sentiment": { "type":"string", "enum": ["positive","negative","mixed"] }, "aspects": { "type":"array", "items": { "type":"object", "properties": { "aspect": {"type":"string"}, "sentiment": {"type":"string"}, "evidence": {"type":"string"} }, "required": ["aspect","sentiment","evidence"] } } }, "required": ["overall_sentiment","aspects"] } }], tool_choice={"type":"tool","name":"sentiment_analysis"}, messages=[{"role":"user","content":"分析情感..."}])两种方式的思路相同:通过 Schema 约束模型的输出格式,确保返回的一定是合法的结构化数据。
四、高级技巧
4.1 Chain-of-Thought:让模型 一步步想
Chain-of-Thought(CoT,思维链)是 2022 年 Google 提出的技巧,核心思想极其简单:让模型在给出最终答案之前,先写出推理过程。
为什么有效?回忆一下模型的工作原理:它是逐 Token 生成的。如果你让它直接给答案,它只有一次 “猜” 的机会。如果你让它先写推理步骤,每一步的输出都会成为下一步的输入,模型等于在 草稿纸上演算。
来看一个经典的数学题对比。
不用 CoT:
问:一个商店有 23 个苹果。上午卖了 8 个,下午进货 15 个,又卖了 12 个。现在有多少个苹果?
答:18 个。模型直接给答案,容易算错。
使用 CoT:
问:一个商店有 23 个苹果。上午卖了 8 个,下午进货 15 个,又卖了 12 个。现在有多少个苹果?请一步步推理。
答:让我一步步计算。1. 初始库存:23 个2. 上午卖了 8 个:23 - 8 = 15 个3. 下午进货 15 个:15 + 15 = 30 个4. 又卖了 12 个:30 - 12 = 18 个所以现在有 18 个苹果。这个例子比较简单,结果一样。但当问题变复杂,比如五六步运算或逻辑推理,CoT 的正确率提升非常显著。Google 的论文显示,在 GSM8K(小学数学题集)上,CoT 将 PaLM 540B 的准确率从 17.9% 提升到了 58.1%。
Zero-shot CoT:你甚至不需要手动写推理步骤的示例。只需在提示词末尾加一句 让我们一步步思考(Let’s think step by step),模型就会自动展开推理链。这是目前最简单也最实用的 CoT 用法。
问:如果一条船上有 26 只羊和 10 只山羊,船长多大年纪?请一步步思考。
答:让我分析一下这道题。1. 题目给出的信息:26 只羊和 10 只山羊。2. 题目问的是:船长的年纪。3. 羊的数量和船长的年纪之间没有任何逻辑关系。4. 这是一道经典的 "陷阱题",信息和问题无关。结论:无法根据给出的信息确定船长的年纪。没有 CoT 时,模型可能直接回答 “36 岁”(把 26 + 10 凑了一个答案)。有了 CoT,模型在逐步推理时发现了信息和问题之间没有关联。
4.2 Tree of Thoughts:多路径探索
Tree of Thoughts(ToT,思维树)是 CoT 的升级版。CoT 是一条直线式的推理链,ToT 则是同时探索多条推理路径,评估每条路径的可行性,最终选择最优解。
想象你在迷宫里找出路。CoT 是沿着一条路一直走到底。ToT 是在每个岔路口都探探路,走不通就退回来换一条。
你是一位资深系统架构师。需要为一个日均 1000 万请求的电商平台设计缓存方案。
请用思维树方法分析:1. 列出 3 种可行的缓存方案2. 对每种方案评估优劣(命中率、一致性、运维成本)3. 选择最优方案并说明理由ToT 适合有多种可能解法的开放性问题,比如架构设计、策略规划、创意方案等。对于有唯一正确答案的问题(如数学计算),CoT 通常就够了。
4.3 Self-Consistency:投票选答案
Self-Consistency(自洽性采样)的思路非常直觉:同一道题让模型回答多次,选出现最多的答案。
这就像你对一道数学题没把握,算了五遍。如果三遍答 18、一遍答 16、一遍答 20,你大概率会选 18,因为它出现的次数最多,大概率是对的。
import collections
def self_consistency(prompt, model, n=5, temperature=0.7): answers = [] for _ in range(n): response = model.generate(prompt, temperature=temperature) answer = extract_final_answer(response) answers.append(answer)
counter = collections.Counter(answers) best_answer = counter.most_common(1)[0][0] confidence = counter.most_common(1)[0][1] / n return best_answer, confidence关键参数是 Temperature。Temperature 设为 0 时每次回答一模一样,采样没有意义。设为 0.7~1.0 之间,模型每次走不同的推理路径,更容易在多条路径上 收敛 到正确答案。
研究表明,Self-Consistency 可以将推理任务的准确率提升 10%~30%。代价是多次调用带来的额外成本和延迟。
4.4 ReAct:推理与行动结合
ReAct(Reasoning + Acting)让模型不只是 “想”,还能 “做”。它的工作模式是一个循环:Thought(思考)→ Action(行动)→ Observation(观察)→ Thought → …
来看一个实际的例子。用户问:“2026 年 3 月份人民币对美元汇率是多少?”
Thought: 用户在问实时汇率信息,这是我训练数据截止后的数据, 我需要搜索最新信息。Action: search("2026年3月 人民币 美元 汇率")Observation: 搜索结果显示,2026 年 3 月 2 日, 人民币对美元中间价为 7.1234。Thought: 我找到了所需的信息,可以回答用户了。Answer: 截至 2026 年 3 月 2 日,人民币对美元中间价约为 7.12。 请注意汇率实时波动,建议以银行实际报价为准。ReAct 是构建 AI Agent(智能体)的基础范式。Agent 能调用搜索引擎、执行代码、查询数据库,本质上都是 ReAct 循环的具体实现。后续的 Agent 篇会详细展开。
五、System Prompt 设计模式
5.1 System Prompt 是什么
在 API 调用中,消息分为三种角色:system(系统)、user(用户)、assistant(助手)。其中 System Prompt 是一段 全局指令,它在整个对话过程中持续生效,定义了模型的角色、行为规范和输出格式。
你可以把 System Prompt 理解为公司的 员工手册。User Prompt 是每次具体的工作任务,System Prompt 是贯穿始终的行为准则。
5.2 System Prompt 的三个核心职责
| 职责 | 说明 | 示例 |
|---|---|---|
| 全局角色 | 定义模型是 “谁” | 你是一位资深全栈工程师 |
| 行为规范 | 限定什么该做什么不该做 | 不回答政治敏感话题 |
| 输出格式 | 统一回复的结构 | ”始终用 Markdown 格式回复” |
5.3 好的 System Prompt 模板
## 身份你是 [角色名称],在 [领域] 有 [N] 年经验。
## 核心能力- 能力 1- 能力 2- 能力 3
## 行为准则- 回答之前先确认你理解了用户的需求- 不确定时主动说明,不要编造- 涉及代码时提供可运行的完整示例
## 输出规范- 使用 Markdown 格式- 代码块标注语言类型- 关键结论用粗体标注
## 限制- 不回答与 [领域] 无关的问题- 不提供医疗、法律方面的专业建议5.4 System Prompt 与 User Prompt 的分工
一个常见的误区是把所有信息都塞进 User Prompt。更好的做法是让两者各司其职:
| 内容 | 放在 System Prompt | 放在 User Prompt |
|---|---|---|
| 角色定义 | ||
| 全局行为规范 | ||
| 输出格式模板 | ||
| 具体任务描述 | ||
| 本次输入数据 | ||
| 临时的额外要求 |
System Prompt 写好后通常不变,User Prompt 每次对话都不同。这种分工让提示词更容易维护和复用。
六、Prompt Caching
6.1 重复请求的成本问题
在实际应用中,很多 API 调用共享相同的前缀。比如你有一个客服机器人,每次调用都带着同样的 System Prompt(2,000 Token)和产品文档(10,000 Token),只有用户的提问不同。每次调用都要付这 12,000 个 Token 的输入费用,非常浪费。
6.2 Prompt Caching 机制
Claude 和 GPT 都提供了 Prompt Caching(提示词缓存)功能。核心原理:模型会缓存之前处理过的提示词前缀,当后续请求的前缀与缓存匹配时,跳过重复的计算,直接复用中间结果。
Claude 的缓存用法:
response = client.messages.create( model="claude-sonnet-4-20250514", max_tokens=1024, system=[ { "type":"text", "text":"你是一位专业的客服助手...(很长的系统提示)...", "cache_control": {"type":"ephemeral"} }, { "type":"text", "text":"(很长的产品文档内容)...", "cache_control": {"type":"ephemeral"} } ], messages=[{"role":"user","content":"这款产品支持退货吗?"}])OpenAI 的自动缓存:
GPT-4o 等模型支持自动缓存,只要请求的前缀与之前的请求匹配(至少 1,024 Token),系统自动复用缓存,无需手动标记。
6.3 成本节省
| 场景 | 无缓存 | 有缓存 | 节省比例 |
|---|---|---|---|
| 12K Token 系统提示 + 500 Token 用户问题 | 100% | 10%~40% | 60%~90% |
| 长文档分析(多轮对话) | 100% | 15%~35% | 65%~85% |
缓存在以下场景特别有价值:
- 客服机器人:System Prompt 和知识库文档固定
- 文档问答:同一份文档被反复提问
- 代码助手:代码仓库上下文在多次交互中保持不变
- 批量处理:大量请求共享相同的指令和示例
七、结构化输出保障
在第三节的基础技巧中,演示了如何通过提示词让模型输出 JSON。但仅靠提示词,模型偶尔还是会输出非法 JSON(比如多一个逗号、少一个引号)。在生产环境中,这种 偶尔出错 是不可接受的。
7.1 JSON Mode
OpenAI 提供了 response_format: { type: "json_object" } 参数,强制模型输出合法的 JSON。开启后,模型的输出一定是可解析的 JSON,但不保证符合你期望的结构。
进阶版:JSON Schema 约束。 前面代码示例中用到的 json_schema 类型,不仅保证输出是合法 JSON,还保证它符合你定义的 Schema:字段名、字段类型、枚举值都受约束。
7.2 Tool Use 强制格式
Claude 的 Tool Use(工具使用)机制提供了另一种保障方式。你把期望的输出结构定义为一个 工具 的输入参数,然后强制模型 调用 这个工具。模型返回的工具参数天然就是符合 Schema 的结构化数据。
这种方式的好处是与模型的推理过程解耦:模型可以自由思考,但最终输出必须通过工具调用的结构化接口返回。
7.3 选择建议
| 方案 | 格式保证 | 结构保证 | 适用平台 |
|---|---|---|---|
| 提示词要求 | 弱 | 弱 | 所有平台 |
| JSON Mode | 强 | 弱 | OpenAI |
| JSON Schema | 强 | 强 | OpenAI |
| Tool Use | 强 | 强 | Claude、OpenAI |
生产环境建议:优先使用 JSON Schema 或 Tool Use。仅在原型验证阶段使用纯提示词方式。
八、提示词模板与最佳实践
8.1 通用模板
经过前面的学习,可以总结一个万能的提示词模板:
## 角色设定你是 [身份],擅长 [能力]。
## 任务描述请完成 [具体任务]。
## 输入数据[需要处理的数据或上下文]
## 输出格式请按以下格式输出:[格式示例]
## 约束条件- 约束 1- 约束 2- 约束 3
## 示例(可选)输入:xxx输出:xxx不需要每次都用全五个模块。简单任务可能只需要 任务描述 + 输出格式,复杂任务则建议五个模块都写。
8.2 常见问题与解决
| 问题 | 原因 | 解决方案 |
|---|---|---|
| 输出不稳定,每次结果差异大 | Temperature 过高或提示词太模糊 | 降低 Temperature,增加约束条件和示例 |
| 答案偏离主题 | 上下文中有干扰信息 | 用分隔符明确标注输入数据的边界 |
| 模型 幻觉,编造事实 | 模型在猜测不确定的信息 | 要求模型标注信息来源;接入 RAG |
| 输出太长或太短 | 缺少长度约束 | 明确指定字数或段落数 |
| 忽略部分指令 | 指令太多或优先级不清 | 用编号排列指令,把最重要的放在最前面 |
| 格式不一致 | 缺少格式示例 | 提供完整的输出示例,或使用结构化输出 API |
8.3 迭代优化的流程
写提示词不是一次性的事。好的提示词通常经过多次迭代:
- 写初版:根据需求快速写出第一版提示词
- 测试:用 5~10 个不同的输入测试效果
- 找模式:失败的案例有没有共同特征?
- 调整:针对性地加约束、改角色、加示例
- 回归测试:确保修改后之前正常的案例没有变差
图解
8.1 提示词效果对比
┌─────────────────────────────────────────────────────────┐│ 提示词质量 vs 输出质量 │├─────────────────────────────────────────────────────────┤│ ││ 模糊的提示词 ││ "帮我写个文案" ││ → 通用、空洞、无法直接使用 ││ 质量:██░░░░░░░░ 20% ││ ││ 有角色的提示词 ││ "你是一位新媒体运营专家,帮我写个文案" ││ → 更专业,但缺少细节约束 ││ 质量:█████░░░░░ 50% ││ ││ 有角色+要求的提示词 ││ "...目标人群 25-35 岁白领,轻松风格,300 字" ││ → 方向正确,可用性提升 ││ 质量:███████░░░ 70% ││ ││ 完整的结构化提示词 ││ "角色+任务+人群+风格+结构+字数+示例" ││ → 精准、可直接使用 ││ 质量:█████████░ 90% ││ │└─────────────────────────────────────────────────────────┘8.2 Chain-of-Thought 思维链流程
{{< mermaid >}}
flowchart TD
A[“用户问题
商店有 23 个苹果
卖 8 个,进 15 个,卖 12 个
现在有多少?”] —> B{“使用 CoT?”}
B —>|否:直接回答| C[“模型一步到位
预测最终答案”]
C —> D[“答案:18 个
(简单题碰巧对了)”]
B —>|是:一步步思考| E[“Step 1
初始:23 个”]
E —> F[“Step 2
卖 8 个:23 - 8 = 15”]
F —> G[“Step 3
进 15 个:15 + 15 = 30”]
G —> H[“Step 4
卖 12 个:30 - 12 = 18”]
H —> I[“答案:18 个
(推理过程可验证)”]
style A fill:#e1f5fe style D fill:#fff3e0 style I fill:#e8f5e9 {{< /mermaid >}}
{{< mermaid >}}
flowchart LR
subgraph ReAct[“ReAct 循环”]
direction TB
T1[“Thought
思考:我需要什么信息?”] —> A1[“Action
行动:调用搜索/工具”]
A1 —> O1[“Observation
观察:得到了什么结果?”]
O1 —> T2[“Thought
思考:信息够了吗?”]
T2 —>|不够| A2[“Action
继续查找”]
T2 —>|够了| ANS[生成最终回答]
A2 —> O2[“Observation
新的结果”]
O2 —> T2
end
style T1 fill:#e1f5fe style A1 fill:#fff3e0 style O1 fill:#e8f5e9 style ANS fill:#f3e5f5 {{< /mermaid >}}
常见问题 FAQ
8.1 Q1: 提示词越长越好吗?
不是。精准比冗长更重要。
一段 50 字的提示词如果包含了明确的任务、格式和约束,效果可能远好于一段 500 字但逻辑混乱的提示词。长提示词的风险在于:信息过多时模型可能遗漏关键指令(尤其在上下文中间的信息容易被忽视);Token 越多成本越高、延迟越大。
经验法则:先写最短的有效版本,测试不达标再逐步补充,而不是一开始就堆砌信息。
8.2 Q2: 需要每次都写角色设定吗?
不需要。如果你在调用 API,角色设定通常放在 System Prompt 中,只需设置一次。如果你在 ChatGPT、Claude 等对话界面中使用,简单的日常问答不需要角色设定。
什么时候需要角色设定? 当你对输出的专业度、风格、视角有特定要求时。比如你想要一份医学科普文章的风格而不是学术论文的风格,角色设定就很有用。
8.3 Q3: CoT 对所有任务都有效吗?
不是。CoT 对需要多步推理的任务效果最好,比如数学计算、逻辑推理、代码调试、复杂决策。
对于简单任务(翻译、摘要、情感分析),CoT 反而可能降低效率:模型花时间写了一大段 思考过程,但最终答案和直接回答没有区别。更糟糕的是,对于非常简单的问题,强制 CoT 有时反而会让模型 想多了 而出错。
判断标准:如果一个人类不需要草稿纸就能回答的问题,通常不需要 CoT。
8.4 Q4: 提示词工程会被淘汰吗?
短期内不会,但形态会演变。
随着模型越来越聪明,基础 的提示词技巧(比如 请一步步思考)可能会被模型内化,你不说它也会这样做。但高质量的任务描述、精确的约束条件、好的示例设计永远有价值,因为这本质上是 清晰表达需求 的能力。
类比:编程语言从汇编进化到 Python,编程变简单了,但 把需求转化为清晰指令 的能力依然重要。提示词工程的未来也类似:门槛会降低,但专业能力的天花板会一直存在。
8.5 Q5: 如何系统地测试和优化提示词?
推荐一套简单的流程:
- 构建测试集:收集 20~50 个代表性的输入样本,覆盖正常情况和边界情况
- 定义评估标准:输出的哪些方面是你关心的?准确率、格式一致性、语气、长度?
- 基线测试:用初版提示词跑一遍测试集,记录每个样本的评分
- 对比实验:每次只改一个变量(加角色、改措辞、加示例),观察评分变化
- 回归验证:每次优化后,确保之前表现好的样本没有变差
如果你在生产环境中使用,可以考虑 Promptfoo、LangSmith 等专业的提示词评估工具来自动化这个过程。
小结
回顾本文的核心要点。
提示词是你和大模型之间的 接口协议。写提示词不是在 聊天,而是在精确地传达需求。
三大原则:清晰具体、结构化、角色设定。任何好的提示词都至少满足其中两个。
基础技巧:Zero-shot 适合标准任务;Few-shot 用示例教模型学习模式;结构化输出让程序能直接解析结果。
高级技巧:CoT 让模型 在草稿纸上演算;ToT 探索多条路径选最优;Self-Consistency 多次回答投票;ReAct 让模型能调用外部工具。
工程实践:System Prompt 管全局,User Prompt 管具体任务;Prompt Caching 省成本;JSON Schema 和 Tool Use 保障输出格式。
记住一个核心观点:提示词的本质是需求文档。你越清楚自己要什么,AI 就越能给你想要的。
下篇预告
提示词能引导模型更好地回答,但有一个根本问题它解决不了:模型不知道你的私有数据。
你公司的产品手册、内部知识库、最新的行业报告,这些内容不在模型的训练数据里。你问模型 “我们公司 Q4 的退货政策是什么”,它只能猜测或编造。
怎么办?把你的知识 “喂” 给它。
参考资料
- Wei, J. et al. Chain-of-Thought Prompting Elicits Reasoning in Large Language Models (2022). CoT 的奠基论文。
- Yao, S. et al. Tree of Thoughts: Deliberate Problem Solving with Large Language Models (2023). ToT 思维树论文。
- Wang, X. et al. Self-Consistency Improves Chain of Thought Reasoning in Language Models (2022). 自洽性采样论文。
- Yao, S. et al. ReAct: Synergizing Reasoning and Acting in Language Models (2022). ReAct 框架论文。
- OpenAI. Prompt Engineering Guide. OpenAI 官方提示工程指南。
- Anthropic. Prompt Engineering Overview. Claude 官方提示工程文档。
- Kojima, T. et al. Large Language Models are Zero-Shot Reasoners (2022). Zero-shot CoT 论文。
- Brown, T. et al. Language Models are Few-Shot Learners (GPT-3, 2020). Few-shot 学习的开创性工作。
支持与分享
如果这篇文章对你有帮助,欢迎支持作者或分享给更多人
部分信息可能已经过时






