你有没有想过一个问题：为什么同样的AI，有时候特别聪明，有时候又蠢得不行？

答案可能不在AI本身，而在你给它喂了什么上下文。

说白了，上下文工程就是研究"怎么给AI喂对的信息"。以前大家觉得会写提示词就够了，但现在AI越来越复杂，光靠静态的提示词根本不够用。你得学会怎么管好上下文，不然AI就会乱跑、乱说、乱花钱。

这篇文章会讲清楚：

• 上下文工程到底是什么

• Claude Code 是怎么管理上下文的

• 系统提示词要怎么设计才能恰到好处

注：内容基于 Anthropic 的公开博客和社区分析，不代表官方声明。

上下文工程简介：AI 光有脑子不够，还得喂对东西

如果你用过 Cursor、Claude Code 这类AI编程工具，甚至自己搞过AI智能体，你应该知道，这些东西说白了就是：给大语言模型发一段提示词，外加一大堆工程活儿。

有人说这些工具就是个"大语言模型的包装器"，这话没毛病。但问题是，想做出一个好用的包装器，技术功底得够硬。这个包装系统有个专业叫法——智能体框架。

它管什么呢？

• 调用工具

• 控制AI循环

• 处理错误

• 做安全限制

• 最关键的：决定每一步把什么上下文发给AI

你仔细想想就会发现，真正的工程功夫不在模型调用本身，而在它周围那一圈。模型调用本身很简单，真正决定AI靠不靠谱的，是周围系统怎么管状态、管工具、管记忆、管上下文。

因为每次调AI都要带上下文，这些上下文来自四面八方：

• 来自开发者的设定

• 来自用户的输入

• 来自之前的对话记录

• 来自工具调用的结果

而且每天都有新的上下文来源冒出来，信息量越来越大。想给AI喂对的东西，可没你想的那么简单。

从写提示词到管上下文

早些年，大家都觉得会写提示词就够了。搞点花里胡哨的提示词，AI就能乖乖听话。但问题在于：提示词是死的，上下文是活的。

既然上下文是动态的，那管理上下文的方法也得是动态的。这就不是写写提示词的事了。所以我们才说，现在进入了上下文工程的时代。它是提示词工程的自然延伸，但比那玩意儿深多了。

为什么上下文对AI这么重要？

有一句老话："垃圾进，垃圾出。"AI智能体表现不好，八成都是这个原因——你根本没给它对的信息。

大语言模型不会读心术。你得把正确的东西喂给它。而且有时候不光是信息，你还要给它对的工具，让它能自己去查东西、做事。

图 1.1 – 大语言模型上下文窗口

现在大语言模型的推理能力越来越强了。我们可以让它调用工具、拿结果、循环干活，直到任务完成。

图1.2 – 大语言模型工具调用循环

但问题来了：当任务又长又复杂的时候，工具调用的结果会越堆越多。

上下文窗口就越长越长，全塞满了工具调用的结果和中间输出。

图1.3 – 多轮交互中的上下文增长

这就导致几个麻烦：

• 上下文窗口可能撑爆

• 成本和时间都往上涨

• AI的表现开始变差

你不处理它，它就越来越烂。Dan Breunig有篇好文章专门讲这个（https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-how-to-fix-them.html）。

如果上下文一直涨，没人管，AI系统就会出现三个问题：

• 上下文污染

  ：AI之前胡思乱想的东西混进了上下文，影响了后面的回答

• 上下文混淆

  ：不相干的东西影响了回答

• 上下文冲突

  ：上下文里不同部分互相打架

所以，怎么管好上下文非常关键。有些技术是工具开发者帮你实现的，有些则要靠你自己。

就算你不是程序员，想用好AI，也得懂点上下文工程。

Claude Code 的四招上下文管理术

Claude Code 管上下文，主要靠四招：

• 写入上下文

  ：搞一套记忆系统

• 选择上下文

  ：智能地找对的信息

• 压缩上下文

  ：精打细算省空间

• 隔离上下文

  ：不同任务分开管

图 1.4 – 上下文工程的分类

一个一个来看。

第一招：把上下文写进记忆里

Claude Code 有三层记忆系统，让你在不同聊天会话之间还能记住东西。

第一层：项目记忆（./CLAUDE.md）

这是团队共享的上下文，记录项目架构、规范之类的东西。受版本控制管理，全团队都能看到。

第二层：用户记忆（~/.claude/CLAUDE.md）

存在你电脑的 claude 目录下，存的是你个人的偏好和快捷操作。不会传到GitHub，只有你自己有。不管你开多少个Claude Code会话，它都在。

第三层：动态记忆导入

可以用 @ 符号从其他记忆文件里导入内容。就像给Claude Code加载普通的上下文一样，但这次你可以搞专门的记忆文件，放点特殊信息。

# 在任何 CLAUDE.md 文件中 @path/to/memory/file.md @./relative/path/context.md @~/global/user/context.md

你还可以写脚本，让上下文根据Git分支自动切换，再把这个脚本挂到钩子上，实现自动化的上下文切换。

有个坑要注意：别往 CLAUDE.md 里反复追加同样的内容。如果脚本每次跑都加，文件会越来越大，全是重复的。

解决办法很简单：加个检查，如果内容已经存在，就不加了。

下面是个改进版的脚本：

# Script to dynamically update context based on git branch#!/bin/bash# context-switcher.sh# Dynamically load relevant context based on user query# Safe against duplicate imports  CLAUDE_MD="CLAUDE.md"# Create CLAUDE.md if it doesn't existtouch"$CLAUDE_MD"add_context() {   local context_ref="$1"   grep -qxF "$context_ref""$CLAUDE_MD" || echo"$context_ref" >> "$CLAUDE_MD" }  # --- Branch-based context --- branch=$(git branch --show-current 2>/dev/null)  case$branchin"feature/auth-"*)     add_context "@./context/auth-system.md"     ;;   "feature/payment-"*)     add_context "@./context/payment-flow.md"     ;;   "hotfix/"*)     add_context "@./context/production-hotfix.md"     ;; esac# --- Query-based context --- user_input="$1"if [[ -n "$user_input" ]]; thenif [[ $user_input == *"database"* || $user_input == *"migration"* ]]; then     add_context "@./context/database-context.md"elif [[ $user_input == *"API"* || $user_input == *"endpoint"* ]]; then     add_context "@./context/api-context.md"elif [[ $user_input == *"frontend"* || $user_input == *"component"* ]]; then     add_context "@./context/frontend-context.md"fifi

关键就是 add_context 这个函数。它用 grep -qxF 先查一遍引用是不是已经在 CLAUDE.md 里了。有就不加，没有才加。这样不管跑多少次，都不会重复。

然后把脚本挂到钩子上：

{"hooks":{"UserPromptSubmit":{"command":"./scripts/context-switcher.sh \"$PROMPT\"""description":"Dynamically load relevant context based on         branch and user query"}}}

这样设置好，上下文就能动态切换了，而且一直很干净，不会越跑越乱。

第二招：智能地找上下文

Claude 会自动翻文件夹，找有用的上下文文件。如果你在子文件夹里，它还会去父文件夹扒拉，但有更具体的信息时会优先用。常用的、最近用过的信息，也会优先考虑。

这是应用层面的技术，开发者已经帮你实现了。但你自己也可以用 /memory 命令加记忆。比如：

/memory add Always use descriptive variable names

Claude 会问你：存到项目级别还是用户级别？然后自动更新对应的 CLAUDE.md 文件。你不用手动改文件，就能让AI记住你的偏好。

不同的工具，传给AI的上下文也不一样。比如Claude Code要编辑文件时，它会自动记住：先看看现有的代码风格，找找有没有现成的函数。这是跟编辑工具有关的上下文。

再比如，Claude Code要跑终端命令时，它会先检查有没有现成的 npm 脚本，或者确认下文件路径对不对。

第三招：压缩上下文省空间

Claude Code 自带两个压缩命令：

• /clear：清空当前对话历史，但保留项目记忆和用户记忆。对话跑偏了，或者想重新开始又不想丢失项目信息的时候，用这个。

• /compact：把现有对话压缩成更短的形式。不是全扔掉，而是保留关键决定和重要信息，丢掉细枝末节。压缩后的历史占空间更小，省成本、省时间，还给新输入留出更多空间。

第四招：用子代理隔离上下文

每个子代理都跑在自己独立的上下文窗口里，不会继承主代理的完整聊天记录。核心思想就是：不同任务配不同专家，各管各的。

与其让Claude Code带着所有信息一把抓，不如搞几个专门的小组。主代理当经理，负责分派任务。再来个代码审查专家（专攻代码质量），测试专家（专心写测试），调研专家（专门找资料）。像这样：

// Code review agent – focused context Task( description: "Code review", prompt: "Review this PR focusing only on security and performance", subagent_type: "code-reviewer" ) // Research agent – broad context Task( description: "Research implementation", prompt: "Find best practices for OAuth2 implementation", subagent_type: "general-purpose" )

不隔离的话，Claude Code 想用所有信息一次搞定所有事，很容易搞晕。隔离之后，每个专家只知道自己该知道的事，干活更利索。

上面只是演示用的简化代码，不是Claude Code的真实格式。实际定义子代理需要YAML配置，这个以后单独聊。

系统提示词，到底重不重要？

你可能在X和LinkedIn上看过无数遍：系统提示词很重要，你要花时间打磨它、迭代它。说"搞好系统提示词"大概是AI工程里最烂大街的建议了。

网上有人专门收集知名AI工具的系统提示词，比如Claude Code、Cursor、Devin这些。看这些不是要你照抄，而是想告诉你——真正的系统提示词，规模大、结构清晰、经过精心设计，远超你的想象。

我想说的是：系统提示词真的很重要，而且它在不断进化。大语言模型在变，系统提示词也跟着变。背后有大量工程投入，让它们越来越好用。这是一个迭代的过程。

怎么写好系统提示词？

这就像给别人指路。

你只说"往那边走"，人家肯定懵，不知道往哪去。但你给他一本50页的手册，每个路口都标清楚，信息量太大，他还是找不到路。

所以你要做到：清晰、具体、信息量刚刚好。难点就在找到那个最佳平衡点。

金发姑娘区

Anthropic 管它叫金发姑娘区——不要太模糊，不要太具体，刚刚好。

你可以想象一个标尺。最左边是太具体的提示，最右边是太模糊的提示。我们想要的是正中间。

图1.5 – 系统提示的金发姑娘区（来源：Anthropic）

来看看两边都出了什么问题。

太具体也不行

最左边的提示太具体了。核心问题是：你把大语言模型当成了一台确定的机器，而不是一个有脑子的智能体。你在硬编码逻辑。

比如你写：如果用户想解决问题，就问三个问题。为什么非得三个？两个够不够？五个行不行？

还有人喜欢穷举，把所有可能的情况都列一遍。这事根本做不完，还会逼着模型走你预设的路线，跟实际输入对不上。维护起来更是噩梦——每发现一个新情况，就得改一次提示。

如果什么都定死了，那你可能根本不需要什么自主智能体，搞个固定的工作流就够了。

太模糊也不行

最右边的提示又太模糊了。核心问题是：信息不够，AI不知道该怎么表现才稳定。

这种提示里经常看不到可操作的指导。比如：

你是一个面包店助手。你应尝试以符合公司品牌原则和精髓的方式解决客户的问题。如有需要，升级到人工处理。

什么原则？什么精髓？

这就是典型地假设AI"应该知道"。其实AI根本不知道你们公司什么样、品牌什么样、客服规范什么样。

还有那种"如有需要，升级到人工处理"——什么时候算"需要"？AI没法判断。

没有框架、没有结构，AI每次跑出来的结果都不一样。说白了，提示就是一句"做正确的事"，但完全没定义"正确"是什么。

刚刚好是什么样？

来看一个中间地带的例子：

你是Claude面包店的客户支持代理。

你专门协助顾客处理订单及关于面包店的基本问题。利用现有工具来高效且专业地解决问题。

你可以访问订单管理系统、产品目录和门店政策。你的目标是尽可能快速解决问题。在提出解决方案前，先全面了解情况。如果不理解，请提出后续问题。

回应框架：

• 识别核心问题 – 透过表面投诉，了解顾客的真实需求
• 收集必要背景 – 在回应前，利用可用工具核实订单详情、检查库存或查阅政策
• 提供清晰解决方案 – 给出具体后续步骤及合理时间表
• 确认满意度 – 确保顾客理解解决方案，并知道必要时如何跟进

指导原则：

• 当存在多种解决方案时，选择最简单且能完全解决问题的那一个
• 如果用户提到订单，在建议后续步骤前先检查订单状态
• 调用人工协助工具
• 对于法律问题、健康/过敏紧急情况，或需要超出标准政策进行财务调整的情况，请调用人工协助工具

这个提示好在哪？

第一，明确了身份和范围。 这是客户支持，不是营销也不是销售。只处理订单和基本问题，不是复杂业务。

第二，给目标而不是给指令。 没有规定每个场景用什么工具，而是定了个目标：高效专业地解决问题。信任AI自己去选工具。

第三，给框架而不是给流程图。 四步回应框架：识别问题、收集背景、给出方案、确认满意。适用于各种场景，不是死板的条件分支。

第四，划清了边界和原则。 "多个方案选最简单的"——这是个启发式原则，不是死规则。

太具体的提示想替AI思考，一旦跟剧本不一样就完蛋。太模糊的提示又让AI没法干活。

而中间地带的提示，正好发挥了大语言模型的强项：识别模式、把通用原则用在具体场景上。它能搞定新情况，因为教的是原则而不是规定。效率高，因为不浪费字。每条原则能管好多种场景，不重复、不矛盾。

总结

这篇文章讲了上下文工程是什么，以及为什么它对构建靠谱的AI智能体这么重要。

我们聊了上下文跟静态提示词的区别，上下文从哪来，以及不管上下文会出什么问题。

用Claude Code做了例子，看了四大招：

1. 写上下文

   ——通过记忆系统

2. 选上下文

   ——动态发现有价值的信息

3. 压缩上下文

   ——精打细算省空间

4. 隔离上下文

   ——让子代理各管各的

还聊了系统提示词，好提示怎么在太死板和太模糊之间找到平衡。

现在你应该明白了，现代AI智能体是怎么管上下文的，以及开发者和用户怎么影响它们的行为。