第02章：上下文工程——1M窗口的真实用法
第02章：上下文工程——1M窗口的真实用法
2026年之前，使用AI的一个核心技能是"压缩信息"——你有一份20页的文档，但AI的上下文窗口只有8K，所以你要学会提取关键信息，把文档压缩成AI能处理的形式。
DeepSeek V4的1M token上下文出来之后，这个技能变得不那么重要了。
但随之而来的问题是：很多人以为1M上下文意味着"可以把所有东西都扔进去"，然后期望AI给出完美答案。实际不是这样的。
1M上下文解决的是"信息放得进去"的问题，但没有解决"AI知道怎么处理这些信息"的问题。
上下文工程，是让AI真正理解和使用你放入的信息，而不是拥有信息。这是一个完全不同的技能。
上下文窗口的实际工作原理
先说一个工程师角度的基础知识，不会太技术，但对后面的所有内容都有帮助。
AI语言模型处理文本的方式是：把你的整个对话（包括你之前的所有输入、AI之前的所有回复）都放进一个"窗口"里，然后在这个窗口里生成下一个回复。
窗口越长，理论上AI能"记住"的信息越多，也能做越复杂的推理。
1M tokens大概是什么概念：
- 1M tokens ≈ 75万英文单词 ≈ 约60-70万汉字
- 一部普通中文小说大概20-30万字
- 一个中等规模的代码库（含注释）大概在500K-1M tokens之间
- 100个PDF页面的文字内容，大概是100K-150K tokens
DeepSeek V4确实能把一整本书放进去处理，这不是噱头。问题不在"能不能放"，在于放进去之后怎么组织，AI才能有效使用。
上下文组织的四个层次
我把上下文组织分为四个层次，从低到高：
层次一：信息堆砌
大多数人的做法：把所有相关材料直接粘贴进去，然后问AI一个问题。
[粘贴了30页的需求文档]
[粘贴了5份竞品分析报告]
[粘贴了10份用户访谈记录]
帮我分析我们产品的下一个版本应该做什么功能？
这么做的问题：AI会给你一个答案，但这个答案的质量很难评估——你不知道AI重点参考了哪些材料，也不知道它是否看到了关键信息，还是被大量低信噪比的内容稀释了注意力。
层次二：有结构的信息输入
把材料分类组织，并告诉AI每类材料的性质和权重：
## 背景材料（信息参考，不是决策依据）
[竞品分析报告摘要]
## 决策输入（高权重）
[用户访谈里的高频痛点列表]
[上季度的功能使用数据]
## 已有的约束
- 开发资源：3个前端+2个后端，Q3周期约12周
- 不能动的模块：[列举]
## 我的问题
基于以上，我需要决定Q3的功能优先级。你认为哪3个功能的ROI最高？
请说明你的推理过程。
这个版本里，AI知道材料的性质（参考vs决策依据），知道约束，问题也更聚焦。
层次三：分层信息+处理指令
除了组织信息，还明确告诉AI用什么方式处理信息：
## 处理方式
你是一个产品策略顾问，你的任务是：
1. 先从用户访谈里提取出频率最高的3个痛点（每个痛点附上代表性原话）
2. 交叉对照功能使用数据，看这3个痛点和低使用率功能是否有关联
3. 在开发约束范围内，提出针对性的优先级建议
## 材料
[按类别组织的材料]
这个版本里，AI有明确的处理流程，不是自己决定怎么看这些材料。
层次四：迭代上下文管理
对于复杂项目，把一次长对话拆成多次短对话，每次对话有明确的阶段目标，然后把前一次对话的关键结论带入下一次：
第一次对话：提取和整理
第二次对话：分析和推理（带入第一次的结论）
第三次对话：决策和行动计划（带入前两次的关键判断）
这和"一次对话扔进所有材料"的主要区别是：你在每个阶段都参与审核AI的输出，而不是期望一次性得到完美答案。
1M窗口的三个真实使用场景
场景一：大文档分析
典型需求：读一份100页的合同/报告/代码库，找出关键信息或问题
工程师的做法：
你是一个[法律/领域]专家，你的任务是分析以下[合同/报告]。
在阅读完整个文件之后，我需要你：
1. 提取所有[关键风险条款/核心数据指标]，按重要性排序
2. 指出文件内部的逻辑矛盾（如果有）
3. 找出文件里没有说明清楚的内容（"模糊地带"）
以下是文件全文：
[完整文件内容]
注意：在给出分析结果之前，先简要说明你如何界定"关键风险条款"的标准，让我可以判断你的理解是否和我预期一致。
最后那个"先说明你的判断标准"很重要——它让你在AI深入分析之前，先校准AI的理解，而不是在拿到大量分析结果之后发现AI的理解方向不对。
场景二：跨文档综合推理
典型需求：我有5份材料，分别是用户调研、竞品分析、技术评估、财务数据和历史决策记录——帮我综合这些材料做出判断
工程师的做法：
我需要做一个关于[产品方向]的决策，我已经收集了以下5类材料，每类的目的不同：
## 材料A：用户调研
目的：了解真实痛点
[内容]
## 材料B：竞品分析
目的：了解市场差异化空间
[内容]
## 材料C：技术可行性评估
目的：了解实现约束
[内容]
## 材料D：财务数据
目的：了解ROI预期
[内容]
## 材料E：历史决策记录
目的：了解过去做过类似决策的结果
[内容]
请完成以下分析：
1. 跨材料的主要矛盾是什么？（比如用户想要的，技术上是否可行？竞品的空白，财务上是否值得填）
2. 五份材料里，哪一份对这个决策的影响最大？为什么？
3. 综合以上，给出你对这个决策的建议，并标注每个建议依据的是哪份材料。
场景三：长期项目的上下文管理
对于持续3个月以上的项目，你和AI的对话会积累大量历史。
工程师的做法是维护一份"项目上下文摘要文档"，每隔一段时间更新一次，新开对话时把这份摘要粘贴进去：
## 项目摘要（上次更新：[日期]）
项目名称：[填写]
当前阶段：[填写]
关键决策（已确定的）：
- [列举]
关键假设（尚未验证的）：
- [列举]
当前卡点：
- [填写]
---
基于以上上下文，今天的问题是：[填写]
这比每次开新对话都重新解释一遍背景要高效得多。
常见的上下文工程错误
错误1：放入所有信息但没有重点标注
当你往上下文里放了大量材料，你需要显式地告诉AI哪些是高优先级的。不要假设AI会自动识别。
修复：在每段材料前加一个"重要程度"标注：
## [核心材料] 用户访谈摘录（这份对今天的决策最关键）
## [参考材料] 竞品功能列表（背景参考，不要花太多分析精力在这里）
错误2：一次性塞进所有材料，然后问一个模糊问题
这是1M窗口带来的新陷阱——以前因为窗口限制，你必须精简，这反而帮你把问题聚焦了；现在没有限制了，很多人反而不做信息筛选了。
修复：先问自己"这个材料对我的具体问题有什么用"，如果答不上来，先不要放进去。
错误3：把上下文管理全部交给AI
有人期望AI能自动追踪对话历史、自动整合前几轮的结论，做到"你只要一直聊，AI会记住所有"。DeepSeek V4确实有1M窗口，但窗口不等于记忆——在新的对话里，窗口是空的。
修复：建立自己的"项目上下文摘要文档"习惯，新对话开始时主动把摘要带入。
上下文工程的工具：结构化前缀
在实战中，我用得最多的上下文组织工具是"结构化前缀"——用统一的格式来标记不同类型的信息：
[背景] 你是一个[角色]。以下是[项目名]的相关信息。
[约束] 你的回答必须符合以下约束：[列举]
[材料] 以下是参考材料：
[材料A - 高优先级]：[内容]
[材料B - 参考]：[内容]
[任务] 基于以上，请完成以下任务：
1. [任务1]
2. [任务2]
[输出格式] 以[格式]的形式输出，每个结论附上材料依据。
这个结构不是死板的规定，是一个思考框架——让你在组织上下文的时候，主动思考每类信息的作用。
测试你的上下文质量
用这个简单测试来评估你的上下文组织质量：
把你的提示词给另一个人看（不懂AI也可以），问他：
- 看完这个提示词，你知道AI要做什么吗？
- 你能判断什么样的输出是"成功"吗？
- 有没有材料你不理解它为什么在这里？
如果三个问题有任何一个答案是否定的，说明你的上下文组织还需要改进。
这个测试的本质是：一个没有AI背景的人能不能从你的提示词里读出你的意图。如果读不出来，AI也读不出来。
如果今天只记一件事：1M上下文解决的是"信息放得进去"的问题，但你需要主动组织信息的层次和权重，告诉AI每份材料的性质，以及你要它用什么方式处理。有组织的上下文，比堆砌的上下文效果强10倍以上。