为什么上下文工程比模型选型更重要
很多人做 LLM 应用第一反应是「换个更强的模型」。但实际项目里，你把同一个模型的提示词改好，效果提升往往比换模型还明显。上下文工程就是研究「怎么给模型喂信息」的工程学科——同样的模型，上下文喂得好的团队效果就是比喂得差的好一大截。
上下文工程包含三件事：系统提示设计（告诉模型它是谁、该怎么做）、少样本示例（给模型看几个正确例子）、以及上下文窗口管理（控制每次喂给模型的信息量和优先级）。这三件事做好了，模型表现就稳定了。
上下文工程的核心原则：模型的输出质量，80% 取决于你给它看了什么，20% 取决于它本身有多强。
- 系统提示定义模型的角色、任务边界和输出格式，是上下文的第一层。
- 少样本示例在提示里放几个输入输出样例，让模型快速对齐风格和格式。
- 窗口管理上下文窗口有限，要按优先级取舍，别塞无关信息。
- 迭代优化上下文工程靠 A/B 测试迭代，不是一次写好就完事。
系统提示：给模型定规矩
系统提示是整个对话的基调。它告诉模型：你是谁、你要做什么、你不能做什么、输出格式是什么。好的系统提示应该像一份岗位说明书——职责清晰、边界明确、有明确的交付标准。
# 一个好的系统提示包含四部分
# 1. 角色定义：你是谁
# "你是一个专业的客服助手"
# 2. 任务描述：你要做什么
# "根据用户问题，从知识库中找到答案并回复"
# 3. 行为约束：你不能做什么
# "不知道就说不知道，不要编造信息"
# 4. 输出格式：怎么回复
# "用简洁的中文，分点回答，不要超过三段"少样本示例：用例子教模型
光靠文字描述「你应该这样做」不够直观。少样本示例是在提示里放几个输入输出对，让模型一看就懂你要什么风格、什么格式。一般放 3-5 个示例就够了——放太多会占用上下文窗口，放太少模型学不到规律。
- 覆盖典型选最常见的场景做示例，别选极端 case。
- 正反结合可以放一个「不好的回答」加一个「好的回答」做对比。
- 格式一致所有示例的输出格式必须严格一致。
- 数量适中3-5 个最佳，太多会挤占上下文。
上下文窗口：别塞太多也别塞太少
上下文窗口有限——哪怕是 128K 的窗口，塞满了也会出问题：模型注意力分散，抓不住重点。上下文工程的核心技能之一就是取舍：哪些信息必须给、哪些可以不给、哪些给了反而干扰。
| 信息类型 | 优先级 | 说明 |
|---|---|---|
| 系统提示 | 最高 | 必须有，定义模型行为 |
| 用户当前问题 | 最高 | 核心输入，不能丢 |
| 相关参考资料 | 高 | RAG 检索到的相关文档 |
| 历史对话 | 中 | 保留最近几轮，早期对话可摘要 |
| 少样本示例 | 中 | 按需放，不是每次都要 |
上下文压缩与优先级
当上下文快满了怎么办？压缩。历史对话不需要全文保留，可以做摘要——把早期对话压缩成几句话的摘要，放在上下文里。相关资料也可以做摘要——RAG 检索回来的文档太长，可以先让模型提取关键信息再喂回去。这就是上下文工程里的「先摘再喂」策略。
# 上下文压缩的常用做法
# 1. 历史对话摘要：每 5 轮对话做一次摘要，替换原文
# 2. 长文档截取：只取和问题最相关的段落，不是全文
# 3. 多轮 RAG：先粗筛相关文档，再精排，只送最相关的 3-5 段
# 4. 工具结果压缩：工具返回的大段输出先提取关键信息多轮对话的上下文管理
多轮对话最容易出问题的是上下文越攒越长。用户聊了 20 轮，你把 20 轮原文都塞进去，窗口直接爆。正确做法是滑动窗口：只保留最近 N 轮原文，更早的对话做摘要。这样上下文长度可控，模型也不会被无关历史干扰。
上下文工程的迭代方法
上下文工程不是一次写好就完事的。它是一个迭代过程：写一版提示 → 跑评测集 → 发现问题 → 改提示 → 再跑评测。每次改动都要对照评测集看效果是变好还是变坏。没有评测集的提示词优化就是瞎改——你根本不知道改完是好了还是坏了。
上下文工程的本质是：把「模型该知道什么」从模糊的感觉变成可工程化的设计。你给模型的每一段上下文，都应该有明确的目的。