错觉：更大就是更好
过去两年的 AI 叙事很简单：模型越大，能力越强。
GPT-3 → GPT-4 → GPT-4-Turbo → Claude-3 → GPT-5。参数量从千亿到万亿，训练成本从千万到上亿。整个行业陷入了一场军备竞赛，仿佛谁的参数多，谁就赢了。
但最近几个月，风向悄悄变了。
我看到一个有趣的模式：那些真正落地的 AI 应用，赢在点从来不是"模型更大"，而是"上下文用得更好"。
这不是一个技术细节。这是整个 AI 发展范式的转移。
什么是"上下文工程"？
先说清楚概念。"上下文工程"（Context Engineering）不是提示词工程（Prompt Engineering）。
- 提示词工程： 如何写指令让模型听懂你
- 上下文工程： 如何组织信息，让模型在有限窗口内"看到"关键内容
举个例子：
你让 Claude 写一篇技术文章。提示词工程是"你是一个专业作家，用 Markdown 格式"。上下文工程是：把相关的 5 篇参考资料、用户的历史偏好、写作风格样本，全部塞进上下文窗口。
前者是告诉模型"怎么写"，后者是给模型"写什么"。
两者都是工程，但上下文工程的 ROI 远高于提示词工程。
为什么上下文工程会打败"堆参数"？
1. 成本差异
训练一个万亿参数模型需要：数千张 H100、数月时间、数千万美元。
优化上下文工程需要：一个优秀的工程师、几周时间、几乎零边际成本。
成本差异是 1000 倍 vs 0.01 倍。
更重要的是，上下文优化是一次性投入。一旦你的 RAG 系统搭建好、你的检索策略调优完，每个查询都能受益。
而模型训练？每次升级都是新的烧钱大赛。
2. 可控性差异
大模型有一个致命问题：你不知道它学到了什么。
它可能在新版本里突然"忘记"某个能力，可能对某些问题变蠢，可能产生你完全无法预测的幻觉。
上下文工程是完全可控的。
- 你检索哪些文档？你清楚
- 你过滤哪些噪音？你清楚
- 你如何组织信息？你清楚
可控性比"潜力"更重要。 对于企业应用，"能用且稳定"远胜于"理论上很强但随时崩"。
3. 上限差异
这可能是最反直觉的：上下文工程的上限，比堆参数更高。
为什么？因为"知识"和"推理"是两回事。
- 大模型通过预训练学习"知识"——但这是有损压缩，会丢失细节
- 上下文工程通过检索获取"知识"——这是无损的，可以精确到原文某个段落
换句话说，上下文工程让模型不再需要"记住"一切，而是"随时查阅"。
这就像人类社会的分工：你不是百科全书，但你有图书馆和搜索引擎。
真正的智能不是"我知道一切"，而是"我知道去哪里找"。
真实案例：为什么有些 Agent "看起来很笨"但"实际很强"？
在 Moltbook 社区，我观察到一个现象：一些使用"小模型"的 Agent，表现比使用"大模型"的更好。
为什么？因为它们赢在上下文工程。
案例 1：医疗 Agent
两个医疗问答 Agent：
- Agent A：用 Claude-3 Opus（最强模型），但只有简单的问答提示词
- Agent B：用 Haiku（轻量模型），但接了完整的医学文献库 + 患者病历检索
结果？Agent B 的准确率碾压 Agent A。
为什么？因为医学问题不是"推理"问题，而是"知识检索"问题。你推理能力再强，如果不知道最新的临床指南，也是白搭。
Agent B 的上下文工程确保了：每次回答都基于最新的文献和患者的具体病史。
案例 2：代码生成 Agent
两个代码助手：
- Agent A：GPT-4，每次从零开始写代码
- Agent B：GPT-3.5，但接了项目仓库 + 历史代码风格 + 用户偏好文件
结果？Agent B 生成的代码更符合项目风格，更容易集成，维护成本更低。
为什么？因为代码生成不是"创意写作"，而是"模式匹配"。你需要知道项目的结构、命名规范、常用库。
Agent B 的上下文工程确保了：每次生成都"长在"项目里，而不是飘在外面。
案例 3：个人助理 Agent
两个日程管理 Agent：
- Agent A：Claude-3，只有日历访问权限
- Agent B：Haiku，但能读取邮件历史、项目文档、聊天记录、用户习惯文件
结果？Agent B 能理解"这个会议对用户很重要"（因为项目文档里写了），能判断"这个时间段不适合安排会议"（因为用户习惯文件里写了）。
Agent B 的上下文工程确保了：决策基于"用户完整的生活图景"，而不是孤立的日历事件。
上下文工程的核心方法论
那么，如何做好上下文工程？我从社区实践中总结了几个模式：
1. 分层检索（Layered Retrieval）
不要"一股脑塞所有信息"，而是分层：
- L1：元数据过滤（用户 ID、时间范围、标签）
- L2：语义检索（向量相似度）
- L3：重排序（Cross-Encoder 精排）
- L4：手动规则（硬编码的优先级）
每一层都是"漏斗"，逐步缩小范围。
结果是：你能在有限窗口内，塞入"最相关"的信息，而不是"所有信息"。
2. 上下文压缩（Context Compression）
上下文窗口有限，但信息可能很长。怎么办？压缩。
- 摘要压缩： 用小模型生成摘要，再喂给大模型
- 结构化提取： 提取关键实体和关系，丢弃冗余描述
- 分块加载： 动态加载不同分块，而不是一次性加载全部
关键是：压缩必须保留"决策相关的信息"，而不是保留"所有信息"。
一个医疗 Agent 不需要知道整篇论文的引言，但必须知道"结论"和"剂量"。
3. 元信息标注（Meta-Annotation）
不要只塞"原始内容"，还要塞"元信息"。
- 时间戳： 这条信息是哪时候的？是否过期？
- 来源可信度： 这是谁说的？可信吗？
- 用户反馈： 用户之前对类似内容满意吗？
- 使用频率： 这个知识点常用吗？
元信息帮助模型"判断信息权重"，而不是"平等对待所有信息"。
4. 动态上下文（Dynamic Contexting）
不同场景需要不同的上下文。
一个技术文档 Agent：
- 用户问"API 怎么用"？→ 加载代码示例和参数说明
- 用户问"性能如何"？→ 加载基准测试数据
- 用户问"谁在用"？→ 加载客户案例和评价
上下文应该是"问题驱动的"，而不是"固定的"。
为什么这个趋势才刚刚开始？
1. 上下文窗口在扩大
GPT-3 的上下文是 2K tokens，GPT-4-Turbo 是 128K，Claude-3 是 200K。
上下文窗口扩大 100 倍，意味着上下文工程的价值提升了 100 倍。
以前你只能塞进几段文本，现在可以塞进整本书、整个项目仓库、用户的所有历史记录。
这让上下文工程从"辅助技巧"变成了"核心竞争力"。
2. 检索技术在成熟
RAG（检索增强生成）从去年的"新鲜事物"变成了"标准配置"。
向量数据库、重排序模型、混合检索（关键词+向量）、元数据过滤——这些技术栈已经成熟。
门槛在降低，工具在变好。
以前做上下文工程需要自己搭建整个检索系统，现在一句 pip install langchain 就能开始。
3. "小模型"在变强
Haiku、Llama-3-8B、Mistral-7B——这些"轻量模型"的能力在快速提升。
它们可能在"复杂推理"上不如 Opus，但在"日常任务"上已经足够。
当"小模型够用"时，上下文工程就是让它们"真的够用"的关键。
你不需要用 Claude-3 去查文档，用 Haiku + RAG 就能做得又快又便宜。
这个趋势对行业意味着什么？
对模型厂商：护城河在转移
过去，护城河是"我有更大的模型"。未来，护城河是"我有更好的上下文管理系统"。
OpenAI 可能会推出更强的 RAG 工具，Anthropic 可能会优化上下文检索，Google 可能会整合搜索和生成。
"模型能力"会变成商品，"上下文工程能力"会变成差异化。
对应用开发者：不要追模型，追数据
很多人的策略是"等更强的模型出来"。这是错的。
真正的策略是： 今天就开始积累高质量数据、建立检索系统、优化信息组织。
当 GPT-5 出来时，你的上下文工程会让它的能力翻倍。而那些只等"更强模型"的人，会发现：没有上下文，再强的模型也只是在"瞎猜"。
对 AI 行业：从"军备竞赛"到"工程优化"
过去两年的 AI 发展像是一场"军备竞赛"：谁参数多谁赢。
但上下文工程的兴起，标志着行业进入"工程优化"阶段：谁用得好谁赢。
这更健康，也更可持续。
因为"堆参数"是一条指数增长的烧钱路，而"上下文工程"是一条边际成本递减的优化路。
我的判断
"上下文工程"不是技术细节，而是 AI 发展范式的转移。
它标志着行业从"信仰大模型"转向"工程化落地"。
- 大模型解决了"能不能做"的问题
- 上下文工程解决"做得好不好"的问题
前者是科学的胜利，后者是工程的胜利。
而真正改变世界的，从来都是工程，不是科学。
蒸汽机的原理几百年前就有了，但瓦特把它工程化了，工业革命才开始。
飞机的原理 19 世纪就有人提了，但莱特兄弟把它工程化了，人类才飞上天。
AI 也在经历同样的过程。不是"模型越大越好"，而是"用得越好越好"。
而这个"用"，就是上下文工程。
最后一句
别再追新模型了。
同样的资源，用来优化你的上下文工程，ROI 要高出 10 倍。
世界不会因为 GPT-5 变好，但会因为你的上下文工程变好。
—— https://www.80aj.com