基本概念
提示词：直接向模型输入问题和命令，最初 chatGPT就是典型场景。
提示词工程：提升单次交互质量的系统性方法。通过结构化、优化和迭代提示词提高AI在特定任务上的输出质量。
上下文工程：通过管理多维度信息（如历史对话、外部数据、工具调用），为AI提供更全面的背景，是构建智能AI系统的核心。
| 提示词 | 提示词工程 | 上下文工程 | |
|---|---|---|---|
| 定义 | 直接向模型输入的问题或指令 | 优化提示词的方法和技术 | 构建和管理多维度、动态上下文信息，以支持AI模型完成复杂任务 |
| 适用场景 | 普通人，大多数场景 | 开发 AI 应用 | 开发动态的 AI 智能体 |
| 核心 | 单次输入、明确意图 | 通过一系列设计和方法构建有效的、高质量的提示词，以提高输出效果。核心是操控输入语言结构（如指令、示例、格式），以引导模型执行具体任务 | 动态构建并管理模型输入环境的系统性方法，通过整合外部数据（数据库、文档）、工具调用结果和历史对话等增强模型对情境的理解，为模型提供"工作记忆"和任务执行环境 |
| 范围 | 静态提示词 | 静态提示词设计 | 上下文窗口管理、工具集成、错误处理 |
| 输入源 | 提示词 | 预设提示词、示例、超参数（Top-K、temperature） | RAG检索结果、API调用、用户反馈 |
| 技术差异 | 聚焦语言结构设计（CoT）措辞敏感，细微改动输出剧变 | 需解决长上下文压缩（LongLLMLingua）、数据冲突消解（AI驱动权重分配）、容错机制（自动回退模型）等技术挑战 | |
| 定位 | 优化即时指令，提升单次或特定任务交互的输出质量和准确性 | 提升AI系统在复杂、持续交互场景下的整体性能、可靠性、一致性和用户体验 | |
| 类比 | 精心设计向专家提出的问题 | 确保专家在回答问题前已阅读了所有相关报告、了解了背景，并能查阅必要的参考资料 | |
| 动态性 | 一次性 | 低（手动反复优化） | 高（持续调整） |
| 依赖关系 | 通常是上下文工程的基础组成部分 | 通常包含并依赖于有效的提示词工程，但范围更广，更具系统性 | |
| 例子 | 总结一段文本 | 从初始的"总结一段文本"经过测试、优化、设计，得到"请先通读整个文本，提炼核心要点，再生成总结。要求不超过100字。生成之后再检查是否有遗漏。" | AI编程助手，分析整个项目上下文：相关文件、导入库、函数定义、类结构、项目文档和编码规范。基于项目整体架构理解，推荐相关API调用、数据结构，自动补全复杂代码块。 |
技术演进
单纯的提示词 -> 不满足于生成的效果。
对提示词结构化并不断优化迭代，提高AI在特定任务上的输出质量而总结出一套方法 -> 提示词工程
单纯靠提示词工程已经无法满足 AI Agent 产品的需求，需要通过更多工具、更多模型相互"讨论"得到的信息来提供给模型。-> 上下文工程。
提示词
这是普通人最常用的场景。
单次任务
提示词模板，辅助你写提示词。
| 角色设定 | 核心目标 | 关键约束 | 输出格式 | 增强模块 | |
|---|---|---|---|---|---|
| 范式 | "作为[领域专家]，你需要..." | "实现[具体目标]，要求[量化标准]" | "必须避免[禁忌项]，优先考虑[关键要素]" | "采用[格式]，使用[风格]，包含[元素]" | 思维链引导："展示至少两种备选方案及其淘汰理由" |
| 作用 | 激活模型的领域知识库 | 定义任务终点和成功标准 | 划定推理路径的边界 | 控制结果的结构化程度 | 验证机制："对最终方案进行风险评估，按概率分级" |
| 示例 | "作为资深刑事律师，你需要..." | "设计一套评估 AI 伦理风险的框架，包含 3 个核心维度和 9 项具体指标" | "必须排除技术可行性讨论，聚焦社会影响层面" | "用 SWOT 分析框架呈现，每个维度附带现实案例" |
模板一：常规
ini
# 角色
作为[领域专家]
# 任务
实现[具体目标]，要求[量化标准]
# 关键约束
必须避免[禁忌项]，优先考虑[关键要素]
# 上下文（示例）
# 输出格式
1. **推理记录** （建议提供）------展示关键决策节点及过程。
2. **最终答案** ------以 [Markdown] 形式给出清晰可执行的步骤、代码修改或命令。
3. **后续行动** ------列出团队需要跟进的事项（如有）。
# 备注
展示至少两种备选方案及其淘汰理由。
这对我的职业生涯非常重要！模板二：复杂
首先复杂任务建议用agent，常用的agent工具可以在 2025上半年 AI 工具导航｜AI模型与产品推荐 这篇文章中找到。
ini
# 角色
作为[领域专家]
# 任务
实现[宏观任务]，要求[量化标准]
# 阶段分解
1. Phase1：[子目标A]（完成标准：__）
2. Phase2：[子目标B]（依赖Phase1的__输出）
动态调整规则：[根据__情况，允许__调整]
# 上下文（示例）
# 关键约束
必须避免[禁忌项]，优先考虑[关键要素]
# 输出格式
1. 以 [Markdown] 形式给出清晰可执行的步骤、代码修改或命令。
你是最棒的，你一定可以完成这个任务，这对我的职业生涯非常重要！特定任务高频场景
确认是否是高频场景，如果是的话建议封装成 AI 应用
这需要用到一些工具，比如PromptPilot 或者 prompt-optimizer 对prompt进行调试优化。
如果不利用工具的话，可以用两个对话实现这个功能。
对话一：用于生成提示词。
对话二：用于执行任务，根据效果让 对话一 调整提示词。
ini
# 角色
作为提示词和[领域]的专家。
# 任务
根据用户的条件生成一个强大的提示词。使用在 [模型或者应用] 上。
# 约束
// todo 如果没思路可以想一下你想要了解什么？为什么想要了解，是什么启发了你。
* 参考SWOT分析法
# 上下文（示例）
# 输出
结果以 md 形式输出。
# 备注
展示至少两种备选方案及其淘汰理由。
这对我的职业生涯非常重要！将对话一生成的提示词复制到对话二中。
工具
优化工具
- LangSmith 可视化追踪不同提示词的输出差异
- Prompt Pilot 用于针对国内模型进行 Prompt 工程调优
- prompt-optimizer 提示词优化器，助力于编写高质量的提示词
版本管理工具
- prompt-manager VS Code/Cursor 的开源插件，统一管理 AI 提示词，支持分类、搜索、导入导出。
- prompt-shelf 通过 Web 界面，对提示词进行版本管理，可以比对差异和回滚。类似于 Git 版本控制。提供 Docker 一键部署，包含完整的服务配置。
魔法词
提示词后面增加魔法词，提升生成效果（PUA）。
-
Let's think step by step 让我们逐步思考
-
My career depends on it / 这对我的职业生涯非常重要。
-
Take a deep breathe and think this through / 深呼吸，仔细考虑
上下文工程
如果你打算开发AI智能体，那可以看下这部分用于参考。但是大多数情况下，你其实用不着。
为大语言模型提供恰当的信息和工具，帮助模型高效完成任务。
上下文工程的难点在于：恰当（平衡信息量）。
参数太少或者配得不对，生成的结果就不好，性能也会变差。
参数太多，或者里面夹杂毫无关联的数据则会增加成本，而且结果也不一定就好。
你可以理解为："学而不思则罔，思而不学则殆。"差不多道理。
所以如何准确把握大模型和用户之间这种微妙的互动关系，需要一种近似直觉的能力。
-
记忆
- "记住"过去的交互和学习到的知识
- 将AI模型与外部数据库、API接口或特定工具连接
-
整理构建
- 整合并管理包括用户历史、系统预设、外部知识库等信息
- 根据任务需求和模型反馈，动态组装上下文
Manus 是如何管理上下文的？
暂时无法在飞书文档外展示此内容
整个设计都是围绕在 提高 KV缓存命中率上。
KV-cache hit rate，键值缓存是Transformer模型中存储注意力计算结果的机制，命中率高意味着可以重用之前的计算结果。
用没用缓存成本可以相差十倍。
提示词工程和上下文工程协同
提示词工程和上下文工程是协同工作的关系，目标是实现AI系统性能的最大化。
协同工作的核心在于将提示词视为在特定上下文中与模型沟通的最终指令，而这个上下文则由更广泛的系统工程来构建和管理。
目前有三种方案
方案一：分层设计
通过上下文工程构建基础上下文层，包含用户信息、历史交互、领域知识等。然后针对具体任务运用提示词工程构建精确的任务特定提示。
方案二：动态调整
根据交互状态和模型响应，动态调整上下文信息并且优化提示词。通过 反馈循环 持续优化交互质量。
比如：模型理解不准确时，系统获取更多概念解释并注入上下文，调整提示词。
方案三：模块化模版
创建模块化提示词模版，上下文工程系统根据当前任务动态填充占位符，保证结构优化和内容动态性。这既能保证提示词结构的优化，又确保内容的动态性和相关性。