Skip to content

第一章:提示词基础 ​

学习目标:理解提示词工程的核心概念,掌握提示词的基本要素和设计原则

预计时间:60-90 分钟

难度:⭐⭐

1.1 什么是提示词? ​

定义 ​

**提示词(Prompt)**是用户向 AI 模型提供的输入信息,用于引导模型生成期望的输出。它可以是一个问题、一条指令、一段上下文,或者它们的组合。

**提示词工程(Prompt Engineering)**是指设计、优化和管理提示词的过程,让 AI 模型产生更准确、更有用、更符合预期的输出[^1]。

一个简单的类比 ​

把提示词想象成给聪明但缺乏背景知识的新员工下达工作指令:

❌ 差的提示词(像模糊的指令):
"帮我处理这个数据"

✅ 好的提示词(像清晰的工作指示):
"你是一名数据分析师。请分析附件中的销售数据(2024年Q1),
找出销售额top3的产品,并计算它们占总销售额的百分比。
最后用markdown表格呈现结果。"

两个前提(2026 年) ​

前提一:模型分为推理模型和非推理模型。 推理模型会在内部完成多步思考,官方建议不要再用「一步步思考」「展示推理过程」这类提示,而是把目标、约束和验收标准写清楚[^2]。非推理模型(以及小模型、低延迟场景)仍然从显式的步骤引导中受益。同一个提示词模板不应该无差别地套到所有模型上。

前提二:提示词只是上下文的一部分。 系统指令、工具定义、检索文档、对话历史和记忆共同决定输出。Anthropic 把这种整体设计称为「上下文工程」,并指出上下文越长、模型对其中信息的召回越容易衰减[^3]。因此,与其反复雕琢一句话,不如先问:该给模型看的信息是否都在、是否足够精简。

为什么提示词工程如此重要? ​

  1. 模型能力的"激活器": 大语言模型能力很强,但需要正确的提示词来激活
  2. 决定输出稳定性: 同一模型在不同提示词下的成功率差异明显,且只能用你自己的任务集测出来,不能靠通用数字推断
  3. 成本控制: 精准的提示词减少不必要的 token 消耗和重复调用
  4. 可靠性保障: 结构化的提示词让模型输出更稳定、可预测

1.2 提示词的核心要素 ​

一个优秀的提示词通常包含以下要素:

1. 角色设定(Role) ​

告诉 AI 它应该扮演什么角色:

markdown
你是一位有10年经验的Python开发工程师...
你是一位专业的医学编辑...
你是一位友善的数学辅导老师...

放在哪一层? 角色、语气和全局规则应放在 system / developer 消息里;具体任务、输入数据和示例放在 user 消息里。OpenAI 的 instructions 参数优先级高于 input,把长期设定和单次任务混在一起会让提示词难以复用[^4]。

为什么有效? 角色设定帮助模型:

  • 选择合适的语言风格和专业术语
  • 应用领域知识
  • 采用恰当的沟通方式

2. 任务描述(Task) ​

清晰说明你希望 AI 完成什么任务:

markdown
请分析这段代码的性能瓶颈...
请为这篇文章写一个200字的摘要...
请将这段文字翻译成商务英语...

最佳实践:

  • 使用动词开头(分析、总结、翻译、创建...)
  • 明确输出形式(报告、表格、代码、图表...)
  • 说明任务的具体要求

3. 上下文信息(Context) ​

提供完成任务所需的背景信息:

markdown
背景:我们是一家B2B SaaS公司,目标客户是中小企业的HR部门...
数据:以下是我们2024年的用户调查结果(5000份样本)...
约束:需要遵守GDPR隐私保护要求...

重要提示:

  • 只提供相关的上下文
  • 过多无关信息会分散注意力
  • 过少信息会导致幻觉或错误理解

4. 示例(Examples) ​

通过示例展示你期望的输出格式和质量:

markdown
示例:
输入:"产品很好用"
输出:{"sentiment": "positive", "confidence": 0.8}

输入:"产品质量一般,价格偏贵"
输出:{"sentiment": "neutral", "confidence": 0.6}

提示: 在 Few-shot 学习中,示例是最关键的因素之一

5. 格式要求(Format) ​

明确指定输出格式:

markdown
请用JSON格式返回结果:
{
  "title": "文章标题",
  "summary": "摘要",
  "keywords": ["关键词1", "关键词2"]
}

或使用markdown表格:
| 产品 | 销售额 | 增长率 |
|------|--------|--------|
| ...  | ...    | ...    |

更可靠的做法: 如果 API 支持 Structured Outputs(JSON Schema),优先用它约束返回结构,而不是只在提示词里写「请返回 JSON」。OpenAI 的 text.format 和 Anthropic 的结构化输出都会在解码阶段强制符合 schema,能消除大部分「模型返回了坏 JSON」的问题。


1.3 提示词设计的基本原则 ​

原则1:清晰具体(Clarity & Specificity) ​

❌ 模糊的提示词:

"帮我写一篇文章"

✅ 清晰的提示词:

"你是一位科技博客作者。请写一篇关于'大语言模型在医疗领域应用'的文章,
目标读者是医疗行业从业者。文章应包含:
1. 引言(150字)
2. 三个主要应用场景(各300字)
3. 挑战与展望(200字)
总字数控制在1200字以内。"

原则2:提供上下文(Provide Context) ​

❌ 缺乏上下文:

"这段代码有什么问题?"

✅ 提供上下文:

"以下是一个用于处理用户登录验证的Python函数。
系统运行环境:Django 4.0, PostgreSQL数据库。
问题:在高并发情况下(1000+请求/秒),偶尔会出现认证延迟。
请分析可能的原因并提供优化建议。"

原则3:使用结构化格式(Use Structure) ​

使用清晰的标记来组织提示词:

markdown
## 角色设定
你是一位资深的产品经理...

## 任务
分析以下用户反馈并...

## 输入数据
[用户反馈内容]

## 输出要求
1. 按功能模块分类
2. 标注优先级(高/中/低)
3. 提供改进建议

推荐的分隔符:

  • --- 或 *** 用于分隔不同部分
  • """ 或 ``` 用于引用文本或代码
  • XML标签如 <context>...</context> 用于标记数据

原则4:明确约束条件(Specify Constraints) ​

markdown
请优化以下代码:
约束条件:
- 不可使用外部库
- 时间复杂度需保持在 O(n)
- 保持代码可读性(添加注释)
- 内存使用不超过 100MB

原则5:迭代优化(Iterate) ​

第一次尝试不完美很正常!

迭代流程:

  1. 设计初始提示词
  2. 测试并记录结果
  3. 识别问题(不准确、格式错误、遗漏要求...)
  4. 优化提示词(补充说明、调整示例、明确约束...)
  5. 重复测试,直到满意

1.4 常见的提示词结构模板 ​

模板1:简单任务 ​

markdown
[角色设定]

[任务描述]
[输入内容]

[输出格式要求]

示例:

markdown
你是一位英语老师。

请将以下中文翻译成地道的商务英语。
"我们公司计划在下个季度推出新产品,希望能与贵公司建立合作关系。"

请提供3种不同正式程度的翻译选项。

模板2:复杂分析任务 ​

markdown
## 角色设定
[专家身份]

## 任务目标
[明确的目标]

## 背景信息
[相关上下文]

## 分析步骤
1. [步骤1]
2. [步骤2]
3. [步骤3]

## 输出格式
[具体的格式要求]

## 注意事项
- [约束1]
- [约束2]

模板3:带示例的学习任务(Few-shot) ​

markdown
[任务描述]

以下是几个示例:

示例1:
输入: [输入1]
输出: [输出1]

示例2:
输入: [输入2]
输出: [输出2]

现在请处理:
输入: [新输入]
输出:

1.5 提示词的常见误区 ​

误区1:提示词越短越好 ​

真相: 过于简短的提示词往往缺乏必要的上下文和指导。

markdown
❌ "总结这个"

✅ "请将以下文章总结为3个要点,每个要点不超过50字,
重点保留关键数据和结论。[文章内容]"

误区2:模型能理解隐含意图 ​

真相: AI 模型不会"读心术",必须明确表达需求。

markdown
❌ "看看这个代码有什么问题"  (隐含:性能问题?安全问题?可读性问题?)

✅ "请检查以下Python代码是否存在潜在的安全漏洞,
重点关注SQL注入和XSS攻击风险。"

误区3:一次就能得到完美提示词 ​

真相: 优秀的提示词是迭代出来的。

建议的平均迭代次数:3-5次

误区4:对推理模型仍然要求「一步步思考」 ​

真相: 推理模型已经在内部完成推理,再要求它展示步骤通常不会提升效果,还可能增加 token 消耗。对这类模型,直接给出目标、约束和成功标准更有效;需要可解释性时,再单独要求它在最终答案中说明关键依据。

误区5:忽略输出格式 ​

真相: 明确的格式要求能大幅减少后续处理工作。

markdown
❌ "分析这些数据"

✅ "请分析这些数据,并以JSON格式返回:
{
  'trend': '上升/下降/平稳',
  'key_insights': ['洞察1', '洞察2'],
  'recommendation': '建议'
}"

1.6 实战练习 ​

练习1:基础提示词设计 ​

任务:设计一个提示词,让 AI 帮你撰写邮件

点击查看参考答案
markdown
你是一位专业的商务沟通专家。

请帮我写一封邮件给客户,说明产品交付延迟的情况。

具体信息:
- 客户名称:ABC科技公司
- 原定交付日期:2026年11月1日
- 新交付日期:2026年11月15日
- 延迟原因:供应链问题
- 补偿措施:延长3个月免费服务期

要求:
1. 语气专业诚恳
2. 清晰说明情况
3. 强调我们的歉意和补偿方案
4. 控制在200字以内

练习2:添加约束条件 ​

任务:在上面的邮件提示词基础上,添加以下约束:

  • 使用正式商务英语
  • 避免过于技术化的术语
  • 包含行动号召(CTA)
点击查看参考答案

在原提示词后添加:

markdown
额外要求:
- 使用正式商务英语(类似哈佛商业评论风格)
- 避免使用技术术语,用通俗语言解释供应链问题
- 结尾包含明确的下一步行动号召,邀请客户确认新时间表

练习3:迭代优化 ​

任务:测试你设计的提示词,根据 AI 输出质量进行优化

点击查看优化思路

如果输出不够好,可以尝试:

  1. 太正式? → 添加"语气要专业但不刻板,体现合作伙伴关系"
  2. 缺少关键信息? → 在"具体信息"部分补充更多细节
  3. 太长/太短? → 调整字数要求
  4. 结构不清晰? → 添加"使用以下结构:道歉说明-原因解释-补偿方案-后续安排"

1.7 本章小结 ​

核心要点 ​

  1. 提示词是与 AI 交互的"编程语言"
  2. 五大核心要素:角色、任务、上下文、示例、格式
  3. 五大设计原则:清晰具体、提供上下文、使用结构、明确约束、迭代优化
  4. 两个时代前提:推理模型不需要「一步步思考」;提示词之外还要管理整个上下文
  5. 避免常见误区:提示词并非越短越好,模型不能理解隐含意图

下一步 ​

掌握基础后,下一章我们将学习经典的提示词模式(Zero-shot、Few-shot、CoT、ReAct 等),这些模式能让你应对更复杂的任务。


思考题 ​

  1. 为什么说"提示词是与 AI 交互的编程语言"?请结合你的理解举例说明。

  2. 尝试分析一个你最近使用过的提示词,它是否包含了五大核心要素?哪些可以改进?

  3. 在什么情况下应该提供更多上下文?什么情况下应该保持简洁?

  4. 为什么需要迭代优化提示词?你有什么实际经验或想法?


← 返回模块三 | 继续学习:提示词模式 →


💡 实践建议: 在进入下一章之前,建议你选择一个日常任务(写邮件、总结文档、分析数据等),尝试按照本章学到的要素和原则设计一个提示词,并实际测试效果。


参考来源:

[^1]: Anthropic, "Prompt engineering overview", https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/overview [^2]: OpenAI, "Reasoning best practices", https://developers.openai.com/api/docs/guides/reasoning-best-practices [^3]: Anthropic, "Effective context engineering for AI agents", https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents [^4]: OpenAI, "Prompt engineering", https://developers.openai.com/api/docs/guides/prompt-engineering

最近更新

基于 MIT LICENSE 许可发布