你有没有想过一个问题为什么同样的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_MDCLAUDE.md# Create CLAUDE.md if it doesnt existtouch$CLAUDE_MDadd_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$branchinfeature/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$1if [[ -n $user_input ]]; thenif [[ $user_input *database* || $user_input *migration* ]]; then add_context ./context/database-context.mdelif [[ $user_input *API* || $user_input *endpoint* ]]; then add_context ./context/api-context.mdelif [[ $user_input *frontend* || $user_input *component* ]]; then add_context ./context/frontend-context.mdfifi关键就是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 namesClaude 会问你存到项目级别还是用户级别然后自动更新对应的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做了例子看了四大招写上下文——通过记忆系统选上下文——动态发现有价值的信息压缩上下文——精打细算省空间隔离上下文——让子代理各管各的还聊了系统提示词好提示怎么在太死板和太模糊之间找到平衡。现在你应该明白了现代AI智能体是怎么管上下文的以及开发者和用户怎么影响它们的行为。