提示词很好理解，就是给AI模型的输入文本，就是你直接向模型输入的问题或指令。比如你让ChatGPT总结一段文本、调用模型API传入提示词去翻译一篇文章等等。
提示词是一段文本，有点像代码中的指令，它直接决定了模型的输出方向。
### 2. 什么是提示词工程（Prompt Engineering）？提示词工程是一个过程，系统化地设计、测试、优化提示词的过程。
就像软件工程，我们为了完成某个需求，要有一套科学的方法来帮助完成软件开发的过程，有方法论（比如敏捷开发），要使用工具，要保证质量，不断迭代，最终交付软件，或者说代码。
> **小提示**：提示词工程的核心思维是“实验验证”。每次修改提示词后，都要用测试集来评估效果，而不是凭感觉随意改动。 ### 3. 什么是上下文工程（Context Engineering）？要理解上下文工程，先得搞清楚什么是“上下文”（Context）？
“上下文”不仅仅是发给大语言模型的一句提示词，而是模型生成回答之前所看到的一切信息，这些信息包括系统提示词、用户输入的问题、当前对话的历史消息、系统对你的历史记忆、工具返回的信息等等。
另外上下文窗口不是无限的，每个模型都对上下文的长度有限制，通常上下文内容多了会影响性能，所以控制好发送给AI的上下文很重要，既不能遗漏，又不能什么都放进去要控制体积。
上下文工程（Context Engineering），就是一门为AI设计和构建动态上下文的学科，为大语言模型提供恰当的信息和工具，帮助模型高效完成任务。
## 二、方法论对比：提示词工程vs上下文工程的实践差异 ### 1. 提示词工程的工作流程 提示词工程的核心是围绕提示词本身进行优化，包括： - 设计指令的措辞 - 添加角色设定 - 引入思维链（CoT）等方法 - 进行A/B测试验证效果 ### 2. 上下文工程的工作流程 上下文工程则关注整个信息环境的构建： - 设计可调用的工具集 - 定义工具与模型的交互格式 - 有效组织历史会话信息 - 控制上下文窗口大小 - 实现动态信息补充 ### 3. 两者的核心区别上下文工程的概念是在AI Agent爆发的背景下诞生的。原来单纯靠提示词工程已经无法满足AI Agent产品的需求了，AI Agent需要的更多的是为系统设计好工具、定义好工具和模型之间交互的数据格式、有效组织上下文信息提供给模型（内容长了要不要压缩、怎么压缩）等等。
## 三、实战案例：翻译场景下的完整优化路径演示 ### 阶段一：普通提示词 普通人都可以写：“请把下面的英文内容翻译为中文：”
这就是一段提示词。
### 阶段二：引入角色设定但是你会发现虽然能翻译，但是似乎翻译效果不够好，于是你开始想办法优化，让AI扮演一个英文翻译到中文的专家，发现似乎有点效果。
### 阶段三：引入思维链（CoT）但还是翻译有点生硬，然后你看有人介绍了CoT（思维链，Chain of Thought），于是尝试在提示词中让AI去先直译再意译，但你也不知道这样的改动是不是真的有用，于是你找了10篇文章，分别用加了CoT和没加CoT的文章，去用相同的模型去翻译，然后找了几个人，在不告诉他们使用什么方法翻译的情况下让他们评估好坏，结果绝大部分都认为加了CoT的效果更好，那么你就明白了，原来加了CoT对翻译是有效果的。
> **常见问题**：为什么CoT对翻译有效果？> **回答**：因为CoT让模型分步骤思考，先直译保留原意，再意译优化表达，这样能减少直接意译可能产生的信息偏差。但要注意，CoT步骤并非越多越好，过多的步骤会增加Token消耗、延长响应时间，还可能导致原意偏离。 ### 阶段四：多步骤优化与评估
于是你受到鼓舞，既然CoT有效果，那么我在直译、意译的基础上，继续增加一个AI对直译结果的评估，再去意译，甚至再多加几步是不是效果更好？再继续改进提示词，拿着之前的测试集去评估测试，果然测试效果更好，但是也带来新的问题，Token消耗更多，时间更长，还可能偏离原意。CoT也并不见得步骤越多越好。
### 阶段五：适配新模型精简优化再后来推理模型发布了，你发现模型自己会CoT了，语言能力也更强了，原来繁琐的一步步翻译似乎没有必要，于是进一步优化，发现只要在提示词中让模型“用中文重写”就可以达到很好的翻译效果，测试集评估结果也是正面的。
这整个对翻译提示词“设计”、“测试”、“优化”的过程就是提示工程。最终通过这样的过程，产生出一个版本一个版本的提示词。
再精炼浓缩一下：提示词工程是产生提示词的过程。
## 四、上下文工程的完整工作流程演示 ### 示例：询问AI新闻你跟ChatGPT说：
“今天都有什么重要的AI新闻？”
看起来只是一句话，但是对于大模型来说，初始的上下文有这些：
- • 系统提示词：“你是个有用的助手，总是帮用户解决问题”
- • 用户输入：“今天都有什么重要的AI新闻？”
- • 可用工具：“日期工具、搜索工具、网页抓取工具”
- • 长期记忆：“用户主要使用中文”
- • 历史会话消息：无
- • 工具返回信息：无
这些上下文不足以让AI回答你的问题，于是它需要自己去调用工具找齐上下文：
- • 根据日期工具获取到今天的日期（大模型自己不知道今天是几号）
- • 根据今天的日期去调用搜索工具检索AI新闻
调用完工具后，现在AI的信息完整了：
- • 系统提示词：“你是个有用的助手，总是帮用户解决问题”
- • 用户输入：“今天都有什么重要的AI新闻？”
- • 可用工具：“日期工具、搜索工具、网页抓取工具”
- • 长期记忆：“用户主要使用中文”
- • 历史会话消息：无
- • 工具返回信息：
- • 2025-7-1
- • Hollywood Confronts AI Copyright Chaos in Washington, Courts
- • Mark Zuckerberg Announces New Meta ‘Superintelligence Labs’ Unit
现在信息够了，考虑用户偏好中文，最后返回的内容如下：
今天的AI新闻有：
- • 好莱坞在华盛顿和法院直面人工智能版权混乱
- • 马克·扎克伯格宣布成立新的“超级智能实验室”部门
假如用户再追问一句：
“帮我返回第二条新闻的详情”
那么模型要从历史会话里面，找到第二条新闻的链接，再去调用网页抓取工具，把新闻内容抓取下来，根据用户的偏好翻译成中文，最后返回用户中文的新闻内容。
注意看这个构建上下文的过程是完全动态的，并不是按照设计好的工作流去收集上下文，而是模型自己根据当前上下文状态去自主动态的调用工具收集上下文，并且不同的任务需要调用的工具也不一样。
这其实也就是现在AI Agent的工作原理：能分辨是否已经收集够了完成任务必要的上下文，能自主决定是不是需要借助工具或者对话来补齐上下文。
> **回答**：主要挑战有三个：1）如何平衡信息充分性和上下文窗口限制；2）如何设计工具使模型能够正确调用；3）如何动态判断何时该补充上下文、何时该压缩已有内容。这需要精细的设计和反复测试。 ### 上下文工程的本质
“上下文工程”指的是一种精妙而复杂的技术：你要精准地将上下文窗口填充上恰到好处的信息，让模型能准确地迈出下一步。
这是一门科学，也是门艺术。
说它是科学，因为你要把任务描述、说明、少量样例（few-shot examples）、检索增强生成（RAG）、各种相关数据（甚至可能是多模态数据）、工具、状态、历史信息等全部巧妙地组合在一起，同时还要考虑如何压缩信息。这就像烹饪一道精致的菜肴，配料太少或搭配不对，模型无法获得足够的信息，性能会变差；配料太多或毫无关联，则会增加成本甚至降低表现。要做好这件事，需要的不仅仅是简单堆叠，更是高度专业化的技巧。
说它是艺术，则是因为操作者还要掌握一种近似“心理学”的直觉，敏锐地洞察LLM和人类用户心理之间的微妙互动。
> **常见问题**：初学者如何开始学习上下文工程？——Andrej Karpathy
> **回答**：建议从简单的AI Agent项目开始，例如构建一个能联网搜索的问答助手。先理解工具定义、系统提示词、历史会话管理的基础概念，再逐步尝试更复杂的多工具协作场景。推荐从LangChain或AutoGPT这类框架入手，它们提供了很多现成的上下文管理组件。 ## 五、核心要点总结
- • 提示词：发送给AI的问题或者指令文本
- • 提示词工程：系统化地设计、测试、优化提示词的过程。
- • 上下文工程：为大语言模型提供恰当的上下文、帮助模型高效完成任务的科学和艺术。
如果没理解这些概念也没关系，对于普通人来说，能写提示词就够了，要开发AI应用才需要考虑提示词工程去不断优化提示词，要开发动态的AI智能体才需要去搞上下文工程为AI的上下文窗口填充恰好的信息。