mobile wallpaper 1mobile wallpaper 2mobile wallpaper 3mobile wallpaper 4
6359 字
17 分钟
提示工程:与 AI 高效对话的艺术
2025-08-02

小李和小王都在用 ChatGPT 写营销文案。

小李打开对话框,输入:“帮我写个文案。“ChatGPT 回了一段干巴巴的通用文本,像是从教科书里抄的,放在任何产品上都行,也就意味着放在哪里都不出彩。

小王的做法不一样。他输入的是:

flowchart TD N0["结构:痛点引入"] N1["产品亮点(3 个)"] N0 --> N1 N1["产品亮点(3 个)"] N2["使用场景"] N1 --> N2 N2["使用场景"] N3["号召行动。"] N2 --> N3

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 提示词的四个作用#

一段好的提示词,本质上在帮模型做四件事:

  1. 设定上下文:告诉模型这是什么场景、背景信息是什么
  2. 定义角色:让模型以特定的身份和视角来回答
  3. 提供示例:通过例子展示你期望的输出格式和风格
  4. 引导推理:通过特定的指令让模型一步步思考,而非直接给答案

二、三大核心设计原则#

2.1 原则一:清晰具体#

最常见的提示词问题就是 太模糊。模型无法读心,你不说清楚,它只能猜。

差的提示词:

帮我写个邮件。

好的提示词:

请帮我写一封工作邮件。
收件人:我的直属领导张总。
目的:申请下周三(3 月 11 日)在家远程办公一天。
原因:家中有维修工人上门,需要有人在场。
语气:礼貌、正式,但不要过于生硬。
长度:150 字以内。

两者的区别一目了然。好的提示词像一张需求文档,包含五个关键要素:

要素说明上面例子中的对应
任务你要模型做什么写一封工作邮件
输入格式给模型的原始材料收件人、原因等背景信息
输出格式你期望的输出样式150 字以内的邮件
约束条件限制和要求礼貌正式但不生硬
示例可选,展示期望的效果此例未提供,但可以加

实战建议:写完提示词后,把自己当成模型读一遍。如果你觉得信息不够,模型也一定觉得不够。

2.2 原则二:结构化#

人类阅读时喜欢有结构的内容,模型也一样。用分隔符、编号和 Markdown 格式组织你的提示词,模型更容易理解你的意图。

来看一个代码审查的结构化提示词:

## 角色
你是一位资深后端工程师,精通 Go 语言和微服务架构。
## 任务
请审查以下代码片段,从四个维度给出评价。
## 审查维度
1. **正确性**:逻辑是否正确,有无 Bug
2. **性能**:有无明显的性能瓶颈
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 ModeOpenAI
JSON SchemaOpenAI
Tool UseClaude、OpenAI

生产环境建议:优先使用 JSON Schema 或 Tool Use。仅在原型验证阶段使用纯提示词方式。


八、提示词模板与最佳实践#

8.1 通用模板#

经过前面的学习,可以总结一个万能的提示词模板:

## 角色设定
你是 [身份],擅长 [能力]。
## 任务描述
请完成 [具体任务]。
## 输入数据
[需要处理的数据或上下文]
## 输出格式
请按以下格式输出:
[格式示例]
## 约束条件
- 约束 1
- 约束 2
- 约束 3
## 示例(可选)
输入:xxx
输出:xxx

不需要每次都用全五个模块。简单任务可能只需要 任务描述 + 输出格式,复杂任务则建议五个模块都写。

8.2 常见问题与解决#

问题原因解决方案
输出不稳定,每次结果差异大Temperature 过高或提示词太模糊降低 Temperature,增加约束条件和示例
答案偏离主题上下文中有干扰信息用分隔符明确标注输入数据的边界
模型 幻觉,编造事实模型在猜测不确定的信息要求模型标注信息来源;接入 RAG
输出太长或太短缺少长度约束明确指定字数或段落数
忽略部分指令指令太多或优先级不清用编号排列指令,把最重要的放在最前面
格式不一致缺少格式示例提供完整的输出示例,或使用结构化输出 API

8.3 迭代优化的流程#

写提示词不是一次性的事。好的提示词通常经过多次迭代:

  1. 写初版:根据需求快速写出第一版提示词
  2. 测试:用 5~10 个不同的输入测试效果
  3. 找模式:失败的案例有没有共同特征?
  4. 调整:针对性地加约束、改角色、加示例
  5. 回归测试:确保修改后之前正常的案例没有变差

图解#

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: 如何系统地测试和优化提示词?#

推荐一套简单的流程:

  1. 构建测试集:收集 20~50 个代表性的输入样本,覆盖正常情况和边界情况
  2. 定义评估标准:输出的哪些方面是你关心的?准确率、格式一致性、语气、长度?
  3. 基线测试:用初版提示词跑一遍测试集,记录每个样本的评分
  4. 对比实验:每次只改一个变量(加角色、改措辞、加示例),观察评分变化
  5. 回归验证:每次优化后,确保之前表现好的样本没有变差

如果你在生产环境中使用,可以考虑 Promptfoo、LangSmith 等专业的提示词评估工具来自动化这个过程。


小结#

回顾本文的核心要点。

提示词是你和大模型之间的 接口协议。写提示词不是在 聊天,而是在精确地传达需求

三大原则:清晰具体、结构化、角色设定。任何好的提示词都至少满足其中两个。

基础技巧:Zero-shot 适合标准任务;Few-shot 用示例教模型学习模式;结构化输出让程序能直接解析结果。

高级技巧:CoT 让模型 在草稿纸上演算;ToT 探索多条路径选最优;Self-Consistency 多次回答投票;ReAct 让模型能调用外部工具。

工程实践:System Prompt 管全局,User Prompt 管具体任务;Prompt Caching 省成本;JSON Schema 和 Tool Use 保障输出格式。

记住一个核心观点:提示词的本质是需求文档。你越清楚自己要什么,AI 就越能给你想要的。


下篇预告#

提示词能引导模型更好地回答,但有一个根本问题它解决不了:模型不知道你的私有数据

你公司的产品手册、内部知识库、最新的行业报告,这些内容不在模型的训练数据里。你问模型 “我们公司 Q4 的退货政策是什么”,它只能猜测或编造。

怎么办?把你的知识 “喂” 给它。


参考资料#

  1. Wei, J. et al. Chain-of-Thought Prompting Elicits Reasoning in Large Language Models (2022). CoT 的奠基论文。
  2. Yao, S. et al. Tree of Thoughts: Deliberate Problem Solving with Large Language Models (2023). ToT 思维树论文。
  3. Wang, X. et al. Self-Consistency Improves Chain of Thought Reasoning in Language Models (2022). 自洽性采样论文。
  4. Yao, S. et al. ReAct: Synergizing Reasoning and Acting in Language Models (2022). ReAct 框架论文。
  5. OpenAI. Prompt Engineering Guide. OpenAI 官方提示工程指南。
  6. Anthropic. Prompt Engineering Overview. Claude 官方提示工程文档。
  7. Kojima, T. et al. Large Language Models are Zero-Shot Reasoners (2022). Zero-shot CoT 论文。
  8. Brown, T. et al. Language Models are Few-Shot Learners (GPT-3, 2020). Few-shot 学习的开创性工作。

支持与分享

如果这篇文章对你有帮助,欢迎支持作者或分享给更多人

提示工程:与 AI 高效对话的艺术
https://blog.souloss.com/posts/machine-learning/llm-guide/machine-learning-llm-guide-prompt-engineering/
作者
Souloss
发布于
2025-08-02
许可协议
CC BY-NC-SA 4.0

部分信息可能已经过时