上下文工程入门：比“写好提示词”更重要的事

大模型上下文工程 2026-10-27

刚接触大模型时，我总以为回答不好就是提示词写得不够妙，于是一个劲儿地加角色、加要求、加示例。后来发现，真正影响效果的往往不是那句“请认真思考”，而是模型在回答前到底看到了什么。这大概就是最近常说的上下文工程（Context Engineering）。

一、提示词只是上下文的一部分

模型收到的上下文，除了用户刚输入的问题，还可能包括系统指令、历史对话、检索资料、工具描述、工具返回结果和输出格式要求。这些内容共同决定了模型如何理解任务。

所以提示词工程更像是在打磨一句话，上下文工程则是在整理整张工作台：该摆哪些资料、按什么顺序摆、哪些旧东西该收走。工作台堆得越乱，模型越容易答非所问。

上下文窗口再大，也不等于把所有内容一股脑塞进去就万事大吉。无关资料会分散注意力，历史对话会带入过期信息，过长的工具输出还可能把真正关键的内容挤到不起眼的角落。

1. 把固定内容和动态内容分开。系统规则、输出格式通常固定，用户问题和检索资料则随任务变化。分开管理更方便复用，也能减少提示词越改越乱。

2. 检索之后再筛选。RAG 不是查到几段文字就全部交给模型，可以先去重、排序，必要时用 Rerank 选出真正有用的片段。

3. 压缩历史对话。多轮任务不必永远保留每一句闲聊。可以把已经确认的结论整理成简短摘要，保留当前仍然有效的决策和待办事项。

4. 控制工具输出。调用搜索或数据库时，只返回任务需要的字段。与其把整页日志塞给模型，不如先截取错误附近的几十行。

任务：{需要完成的事情}
背景：{理解任务所必需的信息}
约束：{格式、范围、禁止事项}

参考资料：
{经过筛选和排序的资料}

当前问题：
{用户的问题}

模板本身没有什么神奇之处，重要的是每一部分都有明确职责。如果某段内容删掉后不影响任务，大概率就没必要放进去。

最直接的办法是拿一组固定问题做对比，而不是凭单次回答的感觉反复修改。除了最终答案是否正确，也可以看看模型有没有引用错误资料、遗漏约束，或者被无关历史带偏。出错时先检查输入上下文，再考虑换模型或调整参数，往往更省事。

模型只能根据它看到的内容作答。上下文工程的核心，就是在有限的窗口里提供刚刚好的信息：不少到让模型瞎猜，也不多到天女散花。先把资料喂对，再研究措辞，通常比一味堆砌“神级提示词”靠谱。