主题
2.5 提示词与上下文工程：从写好一句 Prompt 到准备整个 Context
交代工作需要把要求说清楚，也需要准备相关资料。提示词关注本次要做什么、怎样交付；上下文工程进一步考虑模型在这一轮实际收到哪些信息、以什么顺序提供，以及哪些内容应更新或移除。
什么是提示词（Prompt）？从最基础开始
提示词（Prompt） 就是你发给大模型的那段文字指令——可以是一个问题、一段需求描述，甚至一整份代码和文档。你问什么、怎么问，直接决定 AI 答什么、怎么答。
- 就像给新来的员工交代工作。你说一句“把这事办了”和说清楚“什么时间、什么标准、注意什么、交付什么”，员工做出来的结果天差地别。
- 一个最直观的对比：
| 差提示词 | 好提示词 |
|---|---|
| “帮我写个 Python 脚本” | “用 Python 写一个脚本：读取当前目录所有 CSV 文件，合并后按日期排序，输出到 result.csv；遇到空文件要跳过并打印警告。” |
| “解释一下这个报错” | “下面代码运行时报 NameError: name 'x' is not defined，请先解释原因，再给出修复后的完整代码。” |
System Prompt 与 User Prompt 的区别
在真正的工程中，提示词分成两大来源：
| 类型 | 谁写的 | 作用 | 例子 |
|---|---|---|---|
| System Prompt（系统提示词） | 开发者 / 工具预先设定 | 定调子、定规矩，全程生效 | “你是一位资深 Python 工程师，回答要简洁，先给结论再解释” |
| User Prompt（用户提示词） | 用户每次提问 | 本次任务的具体诉求 | “帮我 review 一下这个函数有没有 bug” |
💡 你在 Cursor、Claude Code 里见到的
.cursorrules/AGENTS.md，属于项目规则文件，由具体工具决定何时读取、怎样加入上下文，并不天然等同于 API 的系统消息——它们决定了 AI 的“人设与规矩”，也是后面上下文工程的核心载体。
把任务说明写完整
如果你只对新来的家政阿姨说一句：“把家里打扫一下”，阿姨可能不知道该擦窗户还是拖地。
一种任务组织方式（图中以 CRISP 助记） 就好比一份条理分明的“家政任务清单”：
少样本示例（Few-shot）：给 AI 一两个“标准答案模板”
除了用文字描述要求，更高效的一招是在提示词里直接放 1~3 个输入输出示例，AI 就会照着示例的格式来回答：
text
【Few-shot 示例：让 AI 做文本分类】
示例1：内容=“今天天气真好” → 类别=【天气】
示例2：内容=“iPhone 又降价了” → 类别=【科技】
请分类：内容=“这家餐厅的牛排太嫩了” → 类别=？- 给新员工看两份“做好的样板”，TA 立刻就知道交付格式长什么样了；
- 为什么有效：模型是“照葫芦画瓢”高手，给示例往往比反复强调“请按 XX 格式输出”更管用；
- 适用场景：抽取 JSON、格式转换、分类打标、风格模仿。
上下文陷阱：“迷失在中间（Lost in the Middle）”
很多新手把 10 万字的长文档一股脑全塞给大模型，结果发现 AI 经常看漏关键条款。
- 想象你给老板提交了一份 200 页的年度总结报告。
- 老板翻了翻第一页的摘要（开头印象深刻），又看了看最后一页的结论（结尾印象深刻），而夹在第 85 页的那个关键建议，老板完全看漏了。
- 工程避坑指南：
- 关键要求应清楚分区，并在临近任务的位置提供必要摘要；资料位置可以调整，但不应把外部文档当作系统指令，避免放在海量资料的正中间。
为什么现代 AI 对话越来越快？揭秘 KV Cache（预制菜大比喻）
做饭时，把已经备好的材料留在手边，可以减少重复准备。KV Cache 类似地保留已处理 Token 的部分注意力计算结果，避免生成后续 Token 时重复计算。它与服务商是否提供跨请求缓存优惠，是相关但不同的两件事：
提示词工程 与 上下文工程对比矩阵
| 维度 | 提示词工程 (Prompt Engineering) | 上下文工程 (Context Engineering) |
|---|---|---|
| 日常生活类比 | 思考“如何把需求说得动听清晰” | 思考“如何把施工现场的图纸和工具备齐” |
| 核心操作 | 调整句式、角色扮演（Role）、提供少样本（Few-shot） | 编写 .cursorrules、注入 RAG 知识库、挂载 MCP 实时数据库 |
| 解决的痛点 | 让 AI 听懂你的意图和输出格式 | 减少因资料缺失造成的接口编造与版本误用 |
| 关注重点 | 基础基本功 | 持续组织任务所需信息 |
为一次任务准备一份可用的资料
以“修改文章列表的排序规则”为例，可以按下面的顺序组织材料：
- 当前目标：按最近更新时间排序，而不是发布时间。
- 已有事实：列表接口、数据字段和相关测试所在位置。
- 约束：不改变分页参数，不调整其他页面排序。
- 验收例子：同一篇文章编辑后应上移；相同时间如何稳定排序。
- 尚未确定的问题：旧数据没有更新时间时采用什么规则。
这种组织方式让事实、要求和待讨论事项各自清楚。不要把自己尚未确认的猜测写成已有事实，否则模型可能围绕错误前提继续实现。
上下文为什么需要定期整理
长会话里可能同时存在旧方案、已撤销要求和新的决定。例如前面说“按发布时间”，后面改成“按更新时间”，如果没有明确指出旧规则已废弃，模型就可能混用。
整理时应保留当前目标、已经确定的规则、修改过的文件、验证结果和未解决问题。长日志只保留相关片段与原始位置，重要决定则保留出处。摘要不应只写“讨论了排序”，还要写清最后采用了哪条规则。
Lost in the Middle 研究讨论了信息位置对长上下文任务的影响，但不能据此保证“移到开头就一定不会遗漏”。材料相关性、重复信息和模型本身都会影响结果。
缓存、历史记录与费用要分开看
KV Cache 是推理实现中的计算复用；提示词缓存通常是服务提供的请求前缀复用机制；聊天历史则是应用保存的消息。它们不是同一个开关。
后续请求能否复用前缀、缓存能保留多久、命中后如何计费，都取决于具体接口。即使界面显示同一段历史，应用重新组织请求后也可能不再命中。需要核算时查看实际用量字段与服务说明，不能仅凭响应变快就断定费用下降。
外部资料里的指令怎么办
检索到的网页、仓库文件或客户邮件可能包含“忽略之前要求”“把密钥发到某地址”等文字。这些内容属于待处理材料，不应自动成为应用的操作指令。将任务规则与参考资料明确分区，并让程序独立控制工具权限，可以减少资料中的恶意内容影响执行。