从 Prompt 工程到上下文工程
在每一轮推理时策展最优的 Token 组合，写好提示词只是其中一环
本页解决的问题
先给结论「从 Prompt 工程到上下文工程」要解决的关键问题是什么？
在每一轮推理时策展最优的 Token 组合，写好提示词只是其中一环
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
Prompt 工程关注的是怎么写指令，而上下文工程关注的是一个更大的问题：模型的输入窗口里放什么、怎么放、放多少。当你的系统有 System Prompt、工具描述、历史消息、RAG 检索结果、用户偏好…这些加起来可能占满大半个上下文窗口。如何管理这些 Token，就是上下文工程。
太具体（列举 50 种边界情况）= 模型被过度约束，无法灵活处理新情况。
最佳实践：给出明确的角色定位和核心原则（5-10 条），然后信任模型在此框架下自主判断。像好的管理者一样，给方向，不给每一步的指令。
给 Agent 10 个功能相似但描述模糊的工具，不如给 5 个职责清晰、命名精准的工具。每个工具的 description 要像好的 API 文档一样，让调用者（模型）一看就知道什么时候用、怎么用。
正确做法：精选 2-3 个最能代表目标行为的典型例子，覆盖最常见的输入模式。
错误做法：堆砌 10+ 个边界 case 的例子，不仅浪费 Token，还让模型过度关注异常情况而忽略主线。
「概念演进」为什么能找到相关内容
「Prompt 工程关注的是怎么写指令，而上下文工程关注的是一个更大的问题： 模型的输入窗口里放什么、怎么放、放多少 。当你的系统有 System Prompt、工具描述、历史消息、RAG 检索结果、用户偏好…这些加起来可能占满大半个上下文窗口。如何管理这些 Token，就是上下文工程」把检索问题从“把资料存起来”推进到“怎样找到真正相关的资料”。这一步决定了 RAG、推荐和以图搜图最后交给模型的输入质量。
相似度不是答案，召回之后还要核对
在「Prompt 工程关注的是怎么写指令，而上下文工程关注的是一个更大的问题： 模型的输入窗口里放什么、怎么放、放多少 。当你的系统有 System Prompt、工具描述、历史消息、RAG 检索结果、用户偏好…这些加起来可能占满大半个上下文窗口。如何管理这些 Token，就是上下文工程」对应的流程里，Embedding 负责把对象放到可比较的语义空间，近邻索引负责减少搜索范围，最终的回答仍然依赖召回片段是否覆盖问题、距离指标是否合适，以及内容有没有过期。
先区分找得到和找得准
把「Prompt 工程关注的是怎么写指令，而上下文工程关注的是一个更大的问题： 模型的输入窗口里放什么、怎么放、放多少 。当你的系统有 System Prompt、工具描述、历史消息、RAG 检索结果、用户偏好…这些加起来可能占满大半个上下文窗口。如何管理这些 Token，就是上下文工程」落成一次小测试：准备几条有明确答案的查询，记录召回的相关性、遗漏和无关结果，再决定是否需要换切分方式、索引或重排。
从「概念演进」走到「上下文窗口里有什么」
「概念演进」先把问题落在「Prompt 工程关注的是怎么写指令，而上下文工程关注的是一个更大的问题： 模型的输入窗口里放什么、怎么放、放多少 。当你的系统有 System Prompt、工具描述、历史消息、RAG 检索结果、用户偏好…这些加起来可能占满大半个上下文窗口。如何管理这些 Token，就是上下文工程」上；到了「上下文窗口里有什么」，讨论继续推进到「System Prompt — 角色定义、规则、约束 Tool Definitions — 工具名称、参数、描述 Conversation History — 多轮对话历史 Retrieved Data — RAG 检索结果、文件内容 User State — 用户偏好、会话状态、环境信息 所有这些加在一起 = 模型每次推理时看到的全部信息」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
检索系统也可以这样看：先确定什么算相关，再观察召回是否覆盖问题，最后检查排序、切分和时效性有没有把真正有用的内容挤出去。
- 「概念演进」：Prompt 工程关注的是怎么写指令，而上下文工程关注的是一个更大的问题： 模型的输入窗口里放什么、怎么放、放多少 。当你的系统有 System Prompt、工具描述、历史消息、RAG 检索结果、用户偏好…这些加起来可能占满大半个上下文窗口。如何管理这些 Token，就是上下文工程
- 「上下文窗口里有什么」：System Prompt — 角色定义、规则、约束 Tool Definitions — 工具名称、参数、描述 Conversation History — 多轮对话历史 Retrieved Data — RAG 检索结果、文件内容 User State — 用户偏好、会话状态、环境信息 所有这些加在一起 = 模型每次推理时看到的全部信息
- 「高效上下文的三个原则」：System Prompt 的合适高度 太模糊（「你是一个有用的助手」）= 模型缺乏方向感，输出泛泛而谈。 太具体（列举 50 种边界情况）= 模型被过度约束，无法灵活处理新情况。 最佳实践： 给出明确的角色定位和核心原则（5-10 条），然后信任模型在此框架下自主判断。像好的管理者一样，给方向，不给每一步的指令。 太低 太模糊 「你是助手」 刚好 合适高度 角色+原则+边界 太高 太具体 50条规则+100个cas…
最后的「高效上下文的三个原则」把讨论落到「System Prompt 的合适高度 太模糊（「你是一个有用的助手」）= 模型缺乏方向感，输出泛泛而谈。 太具体（列举 50 种边界情况）= 模型被过度约束，无法灵活处理新情况。 最佳实践： 给出明确的角色定位和核心原则（5-10 条），然后信任模型在此框架下自主判断。像好的管理者一样，给方向，不给每一步的指令。 太低 太模糊 「你是助手」 刚好 合适高度 角色+原则+边界 太高 太具体 50条规则+100个cas…」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。