上下文工程
比提示词工程更重要的概念：管理 AI 的"记忆"，让模型在正确的信息上做推理。
核心观点
上下文工程关注“模型在执行任务时能看到什么”。提示词工程关注“怎么表达指令”。两者互补，但上下文缺失时，再精致的提示词也很难补救。
什么意思？提示词工程关注"怎么问"，上下文工程关注"给什么信息"。两者不是二选一，而是递进关系——先解决"给什么"，再解决"怎么问"。
实际项目里，先检查目标、相关文件、现有示例、约束和验收方式是否齐全，再优化措辞。
Context Window 是什么
上下文窗口（Context Window）是模型一次能"看到"的最大 Token 数量。你可以把它理解为模型的"工作台"——所有信息都要放在这个台面上，模型才能处理。
不同模型和接入方式的窗口差异很大，具体数字也会随着版本变化。使用前看对应模型的官方文档，不要依赖旧教程里的静态表格。
窗口大是好事，但不是越大越好。我的经验：
- 长上下文不是让你一次性把所有东西都塞进去。模型对中间部分的关注力天然比开头和结尾弱（lost in the middle 现象）。
- 窗口越大，单次推理通常越贵。经典全注意力的计算量会随序列长度近似平方增长，具体实现可能通过稀疏注意力、缓存等方式优化。
- 真正重要的是窗口内的信息密度，不是窗口尺寸。
为什么上下文比提示词更关键
给模型一个模糊的提示词，但配上高质量、高相关性的上下文，结果往往不差。反过来，提示词写得再精致，上下文里塞了一堆无关信息，模型照样跑偏。
举个例子：你要让 AI 帮你写一段 SQL 查询。
如果只给提示词"帮我写个 SQL"，结果很泛。但如果你把数据库表结构、字段注释、一个已存在的查询示例都放进上下文，AI 几乎能一次写出可用的代码。
这就是上下文工程的核心：让任务所需的信息全部在上下文中可及。
上下文管理策略
1. 把目标和完成标准写清楚
长任务先说明目标、允许范围、约束和完成标准。关键规则可以在开头说明，并在最终任务描述里简短重申。
2. 用摘要压缩历史
对话太长时，不要简单截断。让模型自己总结之前的对话，把总结作为新的上下文起点。我常用这个 prompt：
请用 3-5 句话总结我们之前的对话，保留所有技术决策和具体数字。3. 分块检索（RAG 思想）
不要把整个文档库塞进上下文。先检索最相关的 3-5 个片段，只放这些进去。质量 > 数量。
4. 系统提示词做框架，用户提示词做内容
系统提示词放不变的规则和角色设定，用户提示词放每次变化的具体需求。这样缓存机制能大幅降低成本。
什么时候上下文工程特别重要
- 大型代码库重构：把相关函数定义和调用关系组织好再给 AI
- 技术方案设计：把业务背景、现有架构、约束条件一次性交代清楚
- 数据分析任务：提前准备表结构、字段含义、样例数据
下一步
这篇文档有问题？