引言
2023 年初，Anthropic 发布了一个令人瞠目的招聘信息：提示工程师（Prompt Engineer），年薪 $300K。一个不需要写代码、不需要 PhD、只需要「会跟 AI 说话」的职位，薪资竟然比很多资深工程师还高。
社交媒体瞬间炸锅了。「提示工程是未来的核心技能！」「提示工程师是新世纪的程序员！」一时间，无数的提示工程课程、电子书、付费社群如雨后春笋般出现。
但叙事很快就变了。早在 2022 年，OpenAI 的 Sam Altman 在 Greylock 播客采访中就说了一句广为流传的话：「我认为五年后我们不会再做提示工程了。」
到底谁是对的？提示工程是未来还是泡沫？
AK1986-
Andrej Karpathy
OpenAI 联合创始人、前特斯拉 AI 总监
"我更倾向于用「上下文工程」而非「提示工程」——它是一门精细的艺术，把恰到好处的信息填入上下文窗口。"
提示词能做到什么？
做得很好的事
✓ 控制输出风格和格式
"用莎士比亚风格重写这段话"
"输出 JSON 格式，包含 name 和 age 两个字段"
✓ 设定角色和行为框架
"你是一个资深的 Python 开发者"
"你是一个只会用比喻来解释概念的老师"
✓ 引导推理过程
"Let's think step by step"
"先分析问题，再给出方案"
✓ 分类和提取任务
"判断这段文本的情感倾向"
"从以下文本中提取所有人名"
✓ 翻译和改写
"将以下文本翻译成英文"
"用简单的话解释量子力学"做得不好的事
✗ 可靠的格式保证
你说「只输出 JSON」→ 模型有时还是会加上 "Here is the JSON: ..."
你说「不要输出多余内容」→ 模型有时还是会加解释
✗ 工具使用
"帮我查一下今天北京天气" → "我无法访问实时信息"
"帮我算 1234 × 5678" → 可能算错
✗ 实时信息
"今天新闻里有什么大事？" → 模型的知识有截止日期
"这支股票现在多少钱？" → 模型不知道
✗ 长期一致性
第 1 轮："记住我的名字是张三" → "好的"
第 20 轮："我叫什么名字？" → 可能忘记
✗ 精确的事实性
"某某论文的引用次数是多少？" → 可能编造数字「提示工程已死」的争论
正方：提示工程在退化
支持「提示工程已死」的论据：
1. 模型越来越聪明，Zero-Shot 就够
GPT-4 不需要复杂提示就能理解意图
早期需要 Few-Shot 的任务现在 Zero-Shot 就行
2. 结构化输出取代了格式控制提示词
Structured Outputs 保证合法 JSON
不需要说「请只输出 JSON」
3. 工具调用取代了手工指令
Function Calling 让模型自动使用工具
不需要在 prompt 里写「如果你想搜索...」
4. Fine-tuning 取代了复杂提示词
微调可以把行为刻进模型权重
比 system prompt 更可靠反方：提示工程在进化
反对「提示工程已死」的论据：
1. System Prompt 仍然是核心
每个生产级应用都需要精心设计的 system prompt
Copilot、Cursor、Devin 都有几千字的 system prompt
2. 从「写提示词」到「设计上下文」
提示工程没有死，它进化成了「上下文工程」
工程师需要设计完整的上下文：prompt + 示例 + 文档 + 工具
3. 模型越强大，上下文设计越重要
强模型可以做更多事 → 需要更精细的上下文控制
就像：越强大的编程语言越需要好的架构设计
4. 成本优化需要提示工程
好的提示词 = 更少的 token = 更低的成本
好的提示词 = 更少的重试 = 更快的响应真相：两者都对
正在死去的是： 正在成长的是：
「魔法提示词」 「上下文工程」
"请扮演一个..." System prompt 设计
「提示词模板库」 Few-shot 策略选择
「万能提示词公式」 工具定义与编排
社交媒体上的「AI 技巧」 RAG 管线设计
成本优化策略
提示工程 ≠ 找到正确的魔法咒语
提示工程 = 设计模型完成任务所需的完整信息环境从提示工程到上下文工程
上下文工程的定义
提示工程（Prompt Engineering）：
设计一段文本输入来引导模型行为
上下文工程（Context Engineering）：
设计模型完成任务所需的完整信息环境
包含：
├── System Prompt（角色和行为规则）
├── Few-Shot 示例（格式和行为示范）
├── 检索内容（RAG - 外部知识）
├── 工具定义（Tool Calling - 外部能力）
├── 对话历史（多轮上下文管理）
└── 输出格式（Structured Outputs）为什么需要上下文工程？
一个真实的客服场景：
仅靠 Prompt：
"你是客服，回答用户问题"
→ 模型不知道产品详情，可能编造信息
Prompt + RAG：
"你是客服" + 检索产品文档
→ 模型有知识，但不知道用户历史
Prompt + RAG + 对话历史：
"你是客服" + 产品文档 + 之前的对话
→ 模型有知识有上下文，但只能说话不能做事
Prompt + RAG + 对话 + Tool Call：
"你是客服" + 产品文档 + 对话 + 查订单工具
→ 完整的上下文环境，模型可以查信息、回答、操作
这就是上下文工程的全部——设计这个完整的环境。本课程接下来的路线
我们已经学了：
Stage 1: API 基础（messages、token、上下文窗口）
Stage 2: 提示工程（system prompt、few-shot、边界）
接下来要学：
Stage 3: 结构化输出 → 保证输出格式可靠
Stage 4: Tool Calling → 给模型动手的能力
Stage 5: RAG → 给模型外挂知识
Stage 6: 上下文管理 → 多轮对话和成本优化
Stage 7: 未来方向 → 记忆系统、未解之谜本节小结
| 概念 | 要点 |
|---|---|
| 提示词的能力 | 控制风格、设定角色、引导推理——对于简单任务足够 |
| 提示词的局限 | 格式不可靠、无法使用工具、缺乏实时信息、长期一致性差 |
| 「提示工程已死」 | 魔法提示词确实在消亡，但上下文工程正在兴起 |
| 上下文工程 | 设计完整的上下文环境：prompt + RAG + tools + history |
| $300K 提示工程师 | 真正的高薪岗位需要的是系统设计能力，不是写提示词 |
思考题
- 在你的工作中，有哪些任务纯靠提示词就能解决？哪些需要更复杂的上下文工程？
- 如果模型变得足够智能，能够完全理解用户的意图，我们还需要 system prompt 吗？
- 「上下文工程」这个概念和传统软件工程中的「接口设计」有什么相似之处？