夜雨聆风副标题：为什么 AI 的回答质量，很大程度上取决于它这一次“看见了什么”
图注：Prompt 只是入口，上下文才是模型这一次看见的任务现场。
引言：为什么同一个 AI，表现差异会这么大？
如果你经常使用 AI，应该会有过一种很熟悉的体验。
有时候，你只是随手问一句：
帮我写一个产品方案。
AI 很快给你一份结构完整的回答：背景、目标、功能、流程、风险，一个不少。
但你读完以后会发现，它说得并不算错，就是很空。它像一篇任何项目都能套用的方案，放到你的业务里，没有多少真正能用的细节。
然后你换一种方式，把业务背景、目标用户、当前问题、已有材料、输出要求都补进去。它的回答突然明显变好了：更贴近场景，更知道轻重缓急，也更像一个真的参与过这个项目的人写出来的东西。
这时候，我们很容易得出一个结论：
看来我终于写对 Prompt 了。
这个结论当然没错。Prompt 确实重要。
但我觉得，如果只停留在“提示词写对了”这一层，还是有点浅了。更准确地说，是模型终于看见了足够多的任务现场。
前几篇文章里，我们一直在建立一个关于 LLM 的底层直觉：它不是数据库，不是在答案库里查答案；它的回答是一枚 token 接一枚 token 生成出来的；语言上顺滑，也不代表事实上一定正确。
到了第四篇《重新理解 AI 系列04：Prompt 不是咒语，而是任务说明书》，我们讨论了 Prompt Engineering：好 Prompt 的关键，不是神秘句式，而是把任务目标、角色、背景、约束和输出标准交代清楚。
现在，一个很自然的问题就出现了：
如果 Prompt 是任务说明书，那么模型完成任务时，除了这份说明书，还应该看见什么？
所以这一篇，我们继续往前走。
不只是问：
我该怎么写 Prompt？
还要问：
我到底把 AI 放进了一个怎样的上下文里？
我希望通过这篇文章，先和你建立一个更进一步的直觉：
Prompt 只是你对 AI 说的话，上下文才是 AI 这一次真正置身其中的世界。
一、先把上下文说清楚：它不是聊天记录那么简单
我们平时说“上下文”，很容易想到聊天记录。
比如前面聊过什么，刚刚问了什么，这一轮对话应该怎么接住上一轮回答。
这些当然是上下文的一部分。
但在 LLM 的使用里，上下文比“聊天记录”要大得多。
一个更准确、也更实用的理解是：
上下文，就是模型这一次生成回答时能够读取到的全部信息。
这里的“全部信息”，可能包括你刚刚输入的问题，也包括前面几轮对话。
它还可能包括系统提示词里写的角色、规则和限制，你上传的文件、复制进来的资料、引用的文章片段。
如果这是一个 AI 应用，它还可能在后台注入用户偏好、任务状态、项目背景；如果接入了检索或工具，它还可能看到知识库片段、工具说明、函数参数和执行结果。
这些东西加在一起，才构成了模型这一次回答时真正“看见”的世界。
这里有一个很关键的差别：
对模型来说，真正起作用的不是现实世界里有什么，而是这一次上下文里有什么。
现实世界里可能有一份完整的项目文档，但如果它没有进入上下文，模型就不能稳定地依赖它。
你脑子里可能很清楚这个业务的来龙去脉，但如果你没有告诉模型，它并不会自动知道。
公司内部可能有一套最新制度，但如果 AI 没有读到，它也不能可靠地基于这套制度回答。
你可以把模型想象成一个能力很强的临时协作者。
你把它叫进会议室，它能基于会议室里的白板、材料、历史讨论和你刚刚交代的任务，很快给出方案。但会议室外面的档案柜里有什么，它不一定知道。你没有带进来的资料，它就只能猜。
这也是很多 AI 使用问题的根源。
我们经常以为自己是在和一个“知道很多东西的智能体”对话。但在一次具体任务里，它更像是在和你搭出来的这个临时世界互动。
这个世界越清楚，模型越容易生成有用回答。
这个世界越模糊，模型就越容易用常见模式去补空。
图注：聊天记录只是上下文的一部分，完整上下文还包括文件、规则、检索结果、工具结果和任务状态。
二、为什么 Prompt 有用，但 Prompt 不是全部？
说到这里，我并不是要否定 Prompt。
Prompt 当然有用。
它能告诉模型任务目标：是写方案、做总结、改代码，还是帮你检查逻辑。
它能规定输出形式：要列表、表格、邮件、文章、小红书笔记，还是 PRD。
它能指定角色和口吻：像产品经理、技术顾问、编辑、老师，还是严格的代码审查者。
它也能设置边界：只根据材料回答，不确定就说不知道，不要扩展无关内容。
这些都很重要。
但 Prompt 更多是在告诉模型“应该怎么做”，它不会自动补齐“做这件事所需要的事实材料”。
我们看一个简单对比。
如果你只说：
帮我写一个产品方案，要专业一点。
模型可以写。
它会按照产品方案常见结构生成：背景、目标、用户、功能、流程、收益、风险。
但它不知道你的产品是什么，不知道用户是谁，不知道业务痛点来自哪里，也不知道这个方案是给老板看、给研发看，还是给客户看。
于是它只能写出一篇“像产品方案的文本”。
如果你换成这样：
我们要给连锁门店做一个会员运营工具，目标用户是区域运营经理。当前痛点是活动配置复杂、门店执行不可控、复盘数据分散。请基于这些背景，写一篇 1500 字左右的产品方案，重点说明目标、核心流程、关键功能和风险。语气要适合发给业务负责人，不要堆技术术语。
这时候，模型能用的信息就多了很多。
它不只是知道“要写产品方案”，还知道这个方案发生在什么业务里、给谁看、要解决什么问题、重点在哪里、哪些表达方式不合适。
这就是 Prompt 和上下文的区别。
Prompt 更像任务说明书。
上下文则是任务说明书、参考材料、现场状态、边界条件和验收标准的组合。
所以，很多时候我们说“这个 Prompt 好”，并不是因为里面有什么神秘咒语，而是因为它把任务现场交代得更清楚。
反过来，如果上下文缺失严重，再漂亮的 Prompt 也很难凭空变出可靠答案。
你让模型“请严谨地总结这篇报告”，但不给报告正文，它没法真正总结这篇报告。
你让模型“请准确分析这条政策对我们公司的影响”，但不给政策原文，也不给公司业务信息，它只能生成一份通用分析。
你让模型“请基于最新文档写代码”，但不给最新文档，它可能会按训练中见过的旧版本模式回答。
所以，会写 Prompt 的下一步，不是背更多模板，而是学会问：
这个任务要做好，模型到底需要看见哪些信息？
三、上下文窗口是什么？为什么它不是越大越好？
既然上下文这么重要，那我们自然会想到另一个词：上下文窗口。
你可以先把上下文窗口理解为：
模型一次调用中最多能够读取的 token 容量。
这里不需要马上陷入 token 数字和模型参数细节。直觉上说，上下文窗口越大，模型一次能看见的内容越多。
这当然很有价值。
窗口小的时候，你只能给它很短的问题、很少的历史对话、很少的材料。
窗口变大以后，你可以让它读更长的文档，理解更完整的项目背景，处理更复杂的多轮任务。
所以，长上下文不是坏事。它确实让很多过去很难做的事情变得容易了。
但这里有一个很容易被误解的地方：
上下文窗口变大，不等于上下文自动变好。
能装更多东西，不代表装进去的东西都重要。
能看更长材料，不代表模型一定能稳定抓住关键。
能保留更多历史对话，不代表每一句历史对话都应该继续影响当前任务。
研究者也观察到过类似现象。比如 Nelson F. Liu 等人在论文《Lost in the Middle: How Language Models Use Long Contexts》中，在多文档问答和键值检索任务里发现：模型使用长上下文时，相关信息放在开头或结尾，效果往往更好；当关键信息出现在长上下文中间，性能可能明显下降。
这不是说长上下文没用，而是提醒我们：能放进去，不等于能被稳定、准确地用起来。
我觉得可以把上下文窗口想象成会议室。
会议室变大了，当然可以摆更多资料、坐更多人、放更多白板。
但如果你把所有旧材料、无关材料、重复材料、互相矛盾的材料都搬进去，这个会议室并不会自动变得高效。它只是更吵、更乱、更难抓重点。
在实际使用里，上下文经常会出现三类问题。
第一类是遗漏。
关键信息根本没有放进去。
比如你让 AI 评审一段代码，却没有给相关依赖、调用场景和错误日志。它也许能指出一些表面问题，但很难判断真正的业务风险。
第二类是稀释。
关键信息放进去了，但被大量无关信息淹没。
比如你让 AI 从一份很长的会议纪要里提炼待办事项，但里面混杂了闲聊、背景讨论、重复表达和已经废弃的方案。模型可能看到了待办，但它们被埋得太深，输出时仍然可能漏掉。
第三类是冲突。
上下文里同时存在相互矛盾的信息，但没有说明优先级。
比如你给了一个旧版需求文档，又给了一个新版补充说明，还给了几轮临时讨论。模型不知道哪个版本算数，就可能把它们混在一起，生成一个“看起来完整、实际不一致”的结果。
所以，上下文窗口越大，越需要管理。
长上下文给了我们更多空间，但它没有替我们完成筛选、排序、压缩、标注和冲突处理。
这也正是 Context Engineering 开始变得重要的原因。
问题不只是：
我最多能塞进去多少内容？
更重要的是：
哪些内容值得进入上下文？它们应该以什么顺序出现？模型应该相信它们到什么程度？
图注：上下文窗口变大，不等于上下文自动变好；长上下文更需要筛选、排序和标注。
四、好的上下文应该包含什么？
那一个好的上下文应该长什么样？
这里我不想给你一套复杂模板。模板当然可以有，但一上来就背模板，很容易又回到“提示词咒语”的老路。
我更建议先记住五件事：
目标、背景、材料、约束、验收标准。
第一，目标。
你希望 AI 最终产出什么？
是解释一个概念，还是生成一篇文章？是帮你找 bug，还是帮你设计流程？是给你一个初稿，还是给你一个可以直接使用的版本？
目标越清楚，模型越不需要猜。
第二，背景。
这件事发生在什么场景里？为什么要做？给谁看？面向什么用户？前面已经发生过什么？
很多时候，AI 回答泛泛而谈，不是因为它不会，而是因为它不知道这件事发生在哪里。
第三，材料。
它必须依据哪些事实、文档、数据、历史记录或用户输入？
比如方案草稿、会议纪要、产品需求、代码文件、错误日志、接口文档、政策原文、客户反馈。
材料是上下文里最容易被忽视、但又最关键的一部分。
第四，约束。
哪些不能做？哪些必须遵守？输出格式是什么？语气要怎样？篇幅多长？是否只能基于给定材料？是否要标注不确定性？
约束的作用，是减少模型往无关方向发散。
第五，验收标准。
怎样算回答可用？怎样算不合格？
比如：必须能被业务负责人看懂；必须保留原文观点但减少重复；必须列出风险；必须指出不确定信息；必须给出可以执行的下一步。
验收标准很重要，因为它让模型知道“好答案”大概长什么样。
我们拿产品改进方案举例。
如果你只说：
帮我写一个产品改进方案。
模型能写，但大概率会很泛。
如果你把上下文补成：
我们正在改进一个连锁门店会员运营工具，主要用户是区域运营经理和门店店长。现在有三类材料：上周门店运营会议纪要、20 条一线用户反馈、最近一个月活动创建和核销数据。请只基于这些材料，写一版给业务负责人的产品改进方案。重点说明当前问题、优先级最高的三个改进方向、每个方向的用户价值、实现风险和验证方式。不要引入材料之外的新需求，不确定的地方请单独标注。
这时候，模型就不只是接到一个“写方案”的命令，而是进入了一个更明确的任务现场。
它知道这是一个具体产品，而不是泛泛而谈的管理建议。
它知道用户是谁，也知道这份方案是给业务负责人看的。
它知道必须依据哪些材料，所以不容易凭空扩展一堆看起来高级、但没人提过的需求。
它也知道什么叫可用：要有问题、优先级、用户价值、风险和验证方式。
所以，好的上下文不是把所有信息都堆上去。
好的上下文是让模型少猜。
少猜目标。
少猜背景。
少猜材料。
少猜边界。
少猜什么叫好。
你不是在要求 AI “更聪明一点”，而是在减少它误解任务的空间。
图注：一个好的上下文，通常需要目标、背景、材料、约束和验收标准共同组成任务现场。
五、什么信息不应该放进上下文？
既然上下文重要，是不是给得越多越好？
不是。
这是很多人使用 AI 时会踩的另一个坑。
上下文不是垃圾桶。放进去的每一段信息，都可能影响模型后面的生成。
尤其是 LLM 很擅长顺着上下文继续写。你给它一个错误前提，它可能顺着错误前提推导；你给它一个过期文档，它可能按过期文档回答；你给它很多无关材料，它可能从里面抓出一些看似相关、其实偏题的信息。
所以，有些信息不应该随便放进上下文。
第一类，是明显过期的旧资料。
比如旧版接口文档、旧版业务流程、已经废弃的产品规划。如果必须放进去，就要明确标注：这是旧版本，只用于历史参考，不能作为当前结论依据。
第二类，是没有来源和可信度说明的材料。
一段话到底来自正式文档、临时讨论、用户猜测，还是网上随手摘来的片段？如果不说清楚，模型可能会把它们当成同等可信的事实。
第三类，是和当前任务无关但很长的背景。
人类读材料时会跳读、略读、判断重点。模型也能在一定程度上处理长材料，但这不代表我们应该把所有东西都扔给它。无关信息越多，关键内容越容易被稀释。
第四类，是相互矛盾却没有说明优先级的要求。
比如你一边要求“尽量完整”，一边要求“非常简短”；一边要求“只基于材料”，一边又要求“充分发挥”；一边给旧方案，一边给新方案，却不说哪个为准。
第五类，是你自己也不确定、但写得很像事实的猜测。
这类信息很危险。
因为模型未必能判断它只是猜测。一旦它把猜测当成事实，后面的回答就会围绕这个“事实”继续展开。
所以，给模型材料时，不只要告诉它“这里有什么”，还要告诉它：
哪些是事实，哪些是猜测；哪些是主材料，哪些只是参考；哪些是新版本，哪些是旧版本；哪些必须遵守，哪些可以忽略。
比如你让 AI 基于接口文档写代码。
如果你同时给它一个旧版文档和一个新版文档，但没有说明哪个版本优先，它可能会混合两者，生成一个看起来很合理、实际无法运行的方案。
再比如你让 AI 总结会议结论。
会议中可能有讨论方案、反对意见、临时假设、最终决定。如果你不要求它区分这些层次，它可能把“讨论过的可能性”写成“已经确定的决策”。
这就是上下文污染。
第三篇讲幻觉时我们提到过：幻觉不只来自模型不知道，也可能来自模型看到了不该相信的东西。
到了 Context Engineering 这一层，我们就要更主动地处理这个问题。
不是所有信息都该进入上下文。
进入上下文的信息，在你的组织方式里，也不应该被当成同等可信、同等重要。
图注：上下文污染会把旧资料、无来源材料、冲突要求混进任务现场，从而影响输出方向。
六、从 Prompt Engineering 到 Context Engineering
现在我们可以把这个概念收束一下。
如果说 Prompt Engineering 关心的是：
我该怎么对模型说？
那么 Context Engineering 关心的是：
模型完成这件事时，应该看见什么、按什么顺序看见、相信到什么程度、缺什么时怎么办？
这两者不是对立关系。
Prompt 是上下文的一部分。
只是，真正影响模型表现的，不只有你写给它的那一句指令，还包括围绕这句指令一起进入模型视野的所有东西。
从个人使用角度看，Context Engineering 可以先从几个简单习惯开始。
比如，在让 AI 做产品分析前，先告诉它产品是什么、用户是谁、材料来自哪里、这次只分析什么。
比如，在让 AI 总结材料前，明确要求它只基于原文，并区分“原文观点”和“模型补充”。
比如，在让 AI 改代码前，给它相关文件、报错信息、运行环境和期望行为，而不是只贴一段孤立代码。
比如，在多轮对话变长以后，主动让它总结当前共识、待解决问题和已经废弃的方向。
从工程应用角度看，Context Engineering 会变得更系统。
它要回答的问题包括：
哪些信息应该进入上下文？
历史对话应该保留多少？
用户文件应该怎样切分和压缩？
检索出来的资料如何排序？
工具返回结果应该怎样回填？
冲突信息应该怎样标注？
错误信息应该怎样隔离？
权限、隐私和安全边界应该怎样控制？
你会发现，到了这一步，AI 应用就不再是“一个模型加一句 Prompt”那么简单了。
模型仍然很重要，但模型周围的上下文组织方式，开始变成系统能力的一部分。
Anthropic 在一篇关于 Context Engineering 的文章中，也把它看作 Prompt Engineering 的自然延伸：当 Agent 需要跨多轮推理、使用工具、处理外部数据和历史消息时，问题就不只是“提示词怎么写”，而是“每一次推理前，哪些信息应该进入模型视野”。
很多时候，同一个模型，在一个糟糕的上下文里，会表现得像一个只会套话的助手；在一个设计良好的上下文里，却能像一个真正理解任务现场的协作者。
这也是为什么我觉得，从 Prompt Engineering 走向 Context Engineering，是理解 AI 工程化的一个关键转折点。
它让我们不再迷信一句神奇提示词，而是开始设计模型工作的环境。
结语：真正影响回答的，是模型这一次看见的世界
在本文中，我们讨论了一个很基础、但非常重要的问题：
为什么同一个 AI，换一个上下文，表现差异会这么大？
核心原因并不神秘。
LLM 的输出强依赖当前输入。它不是在真空里回答，也不会自动访问现实世界里的所有事实。它每一次回答，都是基于这一次上下文中能够看见的信息生成出来的。
所以，Prompt 很重要，但 Prompt 不是全部。
好的上下文，不是信息堆砌，而是任务现场的组织。
上下文缺失，会让模型猜。
上下文混乱，会让模型抓不住重点。
上下文污染，会把模型带到错误方向。
而好的 Context Engineering，就是尽量让模型在每一次生成前，看见正确的材料、清楚的目标、明确的边界和可检查的标准。
这件事听起来没有“神奇提示词”那么刺激，但它更接近 AI 真正好用的原因。
很多时候，AI 不是突然变笨了，而是它这一次进入了一个信息不足、重点不清、甚至材料互相打架的现场。
所以，不要只问：
我该怎么提示 AI？
也要问：
我把 AI 放进了一个怎样的世界？
参考资料
- • OpenAI, Prompt Engineering Guide. https://developers.openai.com/api/docs/guides/prompt-engineering
- • OpenAI Help Center, Best practices for prompt engineering with the OpenAI API. https://help.openai.com/en/articles/6654000-prompt-engineering-guide
- • Nelson F. Liu et al., Lost in the Middle: How Language Models Use Long Contexts, 2023. https://arxiv.org/abs/2307.03172
- • Anthropic, Effective context engineering for AI agents. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
- • Anthropic, Prompt engineering for Claude's long context window. https://www.anthropic.com/news/prompting-long-context
