上下文工程是什么？从提示词工程到上下文，一文讲透 AI 不跑偏

大家好，我是晚安code。

假设重构一个模块，聊到第 20 轮，它突然开始无视你最开始的约束——"数据库表结构不能动"。翻回去看，最初那轮对话早被挤到十万八千里外，它"看得见"，但已经"记不住"了。

这问题不在提示词没写清楚，而在上下文没管好。这篇把 AI 回答质量的底层逻辑讲透：提示词、提示词工程、上下文、上下文工程，一层层拆开，再聊聊怎么让 AI 自己记笔记、把上下文变短。天天用 AI 写代码、写文案、做分析的朋友，都值得读完。

先花 5 秒点个收藏，上下班路上看。

一、提示词是什么：AI 只回答你发给它的那一段话

提示词就是用户发给 AI 的那段话，也是 AI 和用户之间的唯一通道——AI 的每一次回答，只依赖它这一次收到的内容。

提示词（Prompt）：用户发给 AI 的一段输入文本，是 AI 唯一能"听见"的声音。你可以把它理解成递给 AI 的一张纸条，纸条上写什么，它就只能回什么。

提示词分两种：

1. 系统提示词（System Prompt）：后台预设的全局指令，规定 AI 的身份、风格、边界。你打开对话框看不到它，但它一直在背后压着 AI 的行为。
2. 用户提示词（User Prompt）：你每次敲进对话框的话，是具体任务指令。

举个客服机器人的例子：系统提示词写着"你是 xx 官方客服，语气亲切，只回答产品问题"；你发的"今天能发货吗"就是用户提示词。一个管"你是谁、怎么说话"，一个管"今天办什么事"。

很多朋友觉得自己在"聊天"，其实你每次发出去的是一封信，信里除了你的新问题，还装着前面所有的话。这个细节是理解全文的关键，先记住它。

二、提示词工程：用技巧让 AI 回答更准

提示词工程解决的是"怎么问"——通过一套设计技巧，把 AI 的行为约束到你想要的方向，本质是换取更精准的回答。

提示词工程（Prompt Engineering）：精心设计提示词、引导 AI 输出行为的方法论。它不是玄学，是把"怎么问"沉淀成可以复用的规则。

核心技巧就三类，按复杂度递增：

1）Zero-Shot（零样本提示）：只提要求，不给例子。适合目标明确、答案唯一的事，比如"把这段话翻译成英文"。

2）Few-Shot（少样本提示）：先给几个输入-输出的例子，让 AI 照着你的例子回答。需要 AI 返回特定格式时特别好用，比如要它做分类：

把下面每个句子分类为正面或负面：

示例 1：这个产品太好用了 → 正面
示例 2：客服半天不回消息 → 负面

现在请分类：新版本更新后软件一直闪退

3）思维链（Chain-of-Thought）：让 AI 自己分解问题、输出推理过程。最经典的一句触发词是"让我们一步步思考"（Let's think step by step）。

思维链（Chain-of-Thought，CoT）：通过提示词让 AI 把复杂问题拆成中间推理步骤再作答。相当于要求 AI"把草稿纸摊开"给你看，算术、逻辑题的正确率会明显提升。

可能有人会问：Few-shot 给越多例子越好吗？
不是。Anthropic 的经验是"典型优于边缘"——给 3 个覆盖 80% 主流场景的示例，比堆 20 条罕见 corner case 更管用。示例是让 AI 学模式，不是让它背题。

提示词工程很有用，但天花板也很明确：它管得住"这一句"，管不住"聊了三十轮之后 AI 还记不记得你的初心"。要解决后者，得往更底层看——AI 到底"记不记得"东西。

三、AI 没有记忆：你看到的"记忆"是每次重新发的上下文

大模型没有记忆，是架构决定的——它无状态，你感觉到的"记得"，来自应用层每次把完整历史重新发一遍。

上下文（Context）：某一次请求里，AI 眼前全部输入 token 的总和，包括系统提示词、聊天历史、工具定义、检索到的资料。它是单次调用的临时输入区，聊完即焚，不是能长期存东西的数据库。

模型每次推理都是一次独立的前向计算，权重在推理时冻结，请求之间不保留任何状态，服务商也不会为下次请求保存你的对话。所以你在界面里觉得"一直在聊"，实际是应用层维护一份本地消息列表，每次发消息时把完整历史重新拼进请求里再发一遍。

看这张图就明白了——第 1 轮发"系统提示词 + 问题 1"，第 2 轮就得发"系统提示词 + 全部历史 + 问题 2"，历史越长，每次打包的东西越多：

重发历史的代价有三：按 token 计费，累积成本接近二次方增长；对话越长，每轮越慢越贵；逼近窗口上限还会直接报错。更麻烦的是"看得见不等于记得住"——上下文越长，模型准确召回关键信息的能力反而越差，这叫上下文腐烂（Context Rot），还有个专门的名字叫 Lost in the Middle（中间迷失）：开头和结尾权重高，中间的容易被忽略。有个 NoLiMa 基准测过一批号称支持 128K 上下文的模型，结果在 32K 时就有一大半得分腰斩。

打个比方，上下文窗口像餐厅的后厨台面：台面越大，主厨反而越难找到他要的那瓶调料。

可能有人会问：上下文窗口不是越做越大吗？1M token 还不够用？
窗口是"预算"不是"免费空间"。越大越要挑：关键信息放哪、放多少、什么时候补，都影响模型能不能想起来。上下文工程要做的，就是在预算里把"最能帮模型答对"的东西摆进去。

所以答案不是"把窗口做大"，而是"把该上桌的选好"——这也是下一节上下文工程要解决的。

四、上下文工程：管理的不是一句话，是 AI 眼前的一切

上下文工程管的是"AI 看到什么"——系统性地设计每一次请求进入上下文窗口的全部信息，这是提示词工程之后的下一个战场。

上下文工程（Context Engineering）：系统性地设计和管理进入模型上下文窗口的全部 token，包括系统指令、历史、工具和检索数据，在模型能力约束下让输出尽量稳定可靠。这个说法 2025 年由 Karpathy 提出，Anthropic 随后用一篇官方长文把它推到台前。

它要解决的核心问题很具体：怎么用一套程序化的规则，自动地管理和修改上下文，确保 AI 在几十轮、几百步的长任务里，始终贴合用户最初的要求。

所谓"程序化"，不是人肉每轮检查聊天记录，而是把"该保留什么、该丢弃什么、该补充什么"写成可执行的规则和机制，让系统和 AI 自己维持上下文健康。提示词工程和上下文工程的分工，可以这样看：

为什么非要"工程化"地管上下文？因为前面说了，上下文越长越笨。那思路就反过来——不是往里堆，而是往里挑：

这里有个反常识的结论：Anthropic 在 Claude Code 里砍掉了大部分系统提示词——官方口径是超过八成——结果代码能力测评不降反升。模型越强，需要的"管束"反而越少——给它目标和判断依据，比堆一长串"禁止 XX"更有效。上下文不是越多越好，高信噪比、越小越关键才是方向。

五、上下文工程三板斧：记笔记、压缩、子智能体

让 AI 长任务不跑偏，目前最成熟的套路是三板斧：让 AI 记笔记、把上下文变短、用子智能体隔离脏活——这三条，恰好就是"程序化管理上下文"里最常见的执行规则。

先看图，注意每条规则都在做同一件事：让上下文保持"小而关键"：

1）结构化笔记：让 AI 自己记笔记

原理是让 AI 把关键状态写进上下文窗口之外的持久化文件（比如 NOTES.md、TODO.md），之后按需读回。这是成本最低的"外挂记忆"——因为压缩不可靠、会话会重置，只有写进磁盘文件的东西能干净地活过一轮又一轮。

Claude Code 里，AI 会自动维护待办列表；网上有个很出名的例子，开发者让 AI 玩宝可梦，模型靠自写的"等级/地图/策略笔记"，在上下文被重置后照样无缝续盘。这就像程序员开会随手记纪要——脑子记不住没关系，翻笔记就行。

2）压缩（Compaction）：把上下文变短

对话接近上下文窗口上限时，把历史交给模型总结成摘要，用"摘要 + 最近内容"重启上下文，接着干活。Claude Code 里一条 /compact 命令就能触发。

但压缩是有损的：为了省空间，那些"微妙但关键"的上文可能被压平，比如最初拍板的架构决策被一句"按之前的方案来"带过。所以压缩之前，先把关键决定写进笔记，才是稳妥的组合。

3）子智能体：隔离脏活，保持主窗口干净

让专门的子智能体去啃硬骨头——它可以消耗几万 token 做深度搜索和分析，但只把一两千 token 的精炼结论带回主窗口。这样主智能体的上下文始终保持干净，不会被探索过程污染。这就像组长派组员去查资料，组员回来只汇报结论，不把原始文档逐页念一遍。

三板斧之外还有一招"渐进式披露"：上下文里只放轻量指针（文件路径、URL、行号），按需用工具拉取完整内容，就像你打开文件树找文件，而不是把整个仓库塞进脑子。

六、结语：怎么问重要，但 AI 看到什么更重要

提示词工程没有过时，它变成了上下文工程的一个子集：怎么问依然重要，但决定 AI 靠不靠谱的，越来越是"它眼前摆着什么"。以 2026 年 8 月的实践看，学会让 AI 记笔记、压缩对话、按需加载，比背一百条提示词技巧更值钱。

想深入的话，推荐读 Anthropic 的官方长文《Effective context engineering for AI agents》，以及 Claude 官方的会话管理文档，链接放下面了。

我是晚安code，持续分享编程干货。觉得有用的话记得点赞收藏和关注~也欢迎在评论区聊聊：你让 AI 干活时，有没有遇到过"聊着聊着它就把你的要求忘了"？你有哪些上下文工程的小技巧？