上下文工程是提升AI编程助手效能的核心技术，通过CLAUDE.md、规则文件、技能包、子代理、MCP服务器等十二种配置手段，精准控制AI看到的上下文内容，在自动化与可控性之间找到最佳平衡，避免过度工程化陷阱。
本文作者比尔吉塔·伯克勒（Birgitta Böckeler）是Thoughtworks公司的技术总监，也是马丁·福勒（Martin Fowler）网站上的常驻作者。Thoughtworks是全球知名的软件咨询公司，以敏捷开发和前沿技术实践著称，能在这种公司当技术总监，说明作者绝对不是纸上谈兵的理论派。
为什么你的AI助手像个失忆的实习生
假如你招了一个超级聪明的实习生，这哥们能写代码、能查资料、能跑命令，智商高达250，但有个致命缺陷：记忆力跟金鱼差不多，每次跟你说话都得重新介绍一遍公司规章制度。这就是现在AI编程助手的真实写照。
上下文工程（Context Engineering）这门手艺，本质上就是给这个实习生配个超级笔记本，让他记住该记住的东西，忘掉该忘掉的东西，最终从一个需要手把手教的菜鸟进化成能独当一面的得力干将。
过去几个月里，配置和丰富编程助手上下文的选项简直像爆米花一样噼里啪啦炸开了花，Claude Code在这个领域一马当先冲锋陷阵，其他编程助手也紧随其后拍马追赶。强大的上下文工程正在成为这些工具开发者体验的核心组成部分，搞不定这个，你就等着跟AI助手鸡同鸭讲吧。
上下文工程到底是个啥玩意儿
同事巴拉尼·苏布拉马尼安（Bharani Subramaniam）给了一个简单粗暴的定义：上下文工程就是精心策划模型能看到的东西，这样你就能得到更好的结果。听起来像废话？那你可就错了。这就好比你给厨师看菜谱，你给他看满汉全席的菜谱，他给你做满汉全席；你给他看泡面的包装袋，他就只能给你泡碗面。
对于编程助手来说，现在已经涌现出一套上下文工程的方法和术语体系。这套体系的基础是工具提供的配置功能，比如各种规则文件、技能包之类的；然后更细致的部分在于我们如何概念性地使用这些功能，比如各种规格说明、工作流程设计。这篇备忘录就是一份关于当前上下文配置功能状态的入门指南，最后会以Claude Code为例进行实战演示。
编程助手的上下文到底包含啥
"万物皆上下文"——这话听起来像哲学家的胡言乱语，但实际上，在编程助手的语境里，上下文配置主要包含以下几个大类。
第一类是可复用的提示词（Prompts），几乎所有AI编程上下文工程最终都归结为一堆Markdown文件里写的提示词。这里说的提示词是2023年那种最宽泛的定义：提示词就是我们发给大语言模型（LLM）以获取回应的文本。
这些提示词背后主要有两类意图：
一类是指令（Instructions），告诉助手去做某件事，比如"按照以下方式写一个端到端测试：..."；
另一类是指导（Guidance），也叫规则或护栏，是助手应该遵循的一般性约定，比如"始终编写相互独立的测试"。这两类经常混在一起，但区分它们仍然很有用。
上下文接口：给AI开外挂的说明书
我找不到一个现成的术语来描述我所谓的上下文接口（Context Interfaces），这玩意儿本质上就是给大语言模型的说明书，告诉它如何获取更多上下文，前提是它决定这么做。
具体包括：工具（Tools），内置的能力，比如调用Bash命令、搜索文件等；MCP服务器（MCP Servers），运行在你机器上或服务器上的自定义程序或脚本，给助手提供数据源访问和其他操作能力；
技能（Skills），这是编程上下文工程领域最新的 热门，描述额外的资源、指令、文档、脚本等，大语言模型可以在认为与手头任务相关时按需加载。你配置的这些东西越多，它们占用的上下文空间就越大，所以得战略性思考哪些上下文接口对特定任务是真正必要的。
编码代理中最基本、最强大的上下文接口是文件读取和搜索，它们用于理解你当前的代码库，因此我在这里特别提及它们。值得思考的是，你现有的代码在多大程度上能作为上下文，这关系到你是否拥有对人工智能友好的代码库设计。
工作区文件：最基础也是最强力的上下文
编程助手最基本也最强大的上下文接口就是文件读取和搜索功能，用来理解你当前的代码库，所以这里特别提一下。
值得反思的是，你现有的代码作为上下文的效果如何，基本上就是你是否采用了对AI友好的代码库设计。如果你的代码写得像天书一样，那AI读得也费劲；如果你的代码结构清晰、命名规范，那AI就能事半功倍。
这就好比你给AI看一本排版精美、目录清晰的教科书，和给它看一堆随手记的草稿纸，效果肯定天差地别。
谁来决定加载上下文：AI、人类还是软件本身
这里有个关键问题：谁来决定什么时候加载上下文？
有三种主要方式：
第一种是让大语言模型自己决定，这是让助手在无人监督情况下运行的前提条件，但这里总有一些不确定性，或者说非确定性，大语言模型是否会在我们期望的时候真正加载上下文。技能（Skills）就是这种方式的典型例子。
第二种是人类触发，人类调用上下文给了我们控制权，但整体上降低了自动化程度，斜杠命令（Slash commands）就是这种模式的代表。
第三种是Claude Code本身触发，某些上下文功能由助手软件在确定的时间点触发，Claude Code的钩子（Hooks）就是这种情况。
上下文管理的黄金法则：少即是多
上下文工程的目标之一是平衡给出的上下文数量：既不要太少，也不要太多。
尽管上下文窗口在技术层面上已经变得非常大，但这并不意味着毫无节制地往里面塞信息是个好主意。当助手获得太多上下文时，它的效率会下降，而且太多上下文当然也是一个成本因素。
有些大小管理取决于开发者：我们创建了多少上下文配置，以及在里面放了多少文字。我的建议是逐步构建上下文，比如规则文件，不要一开始就塞太多东西进去。模型已经变得相当强大，所以半年前你可能不得不放进上下文的东西，现在可能根本不需要了。
关于上下文有多满、什么占用了多少空间的透明度，是工具中帮助我们平衡这一点的关键功能。
Claude Code实战：上下文配置的十八般武艺
以下是截至2026年1月Claude Code的上下文配置功能概览，以及它们在上述维度中的定位。
首先是CLAUDE.md文件，这属于指导（Guidance）类别，由Claude Code在会话开始时自动加载，用于最频繁重复的、适用于整个项目的一般性约定。典型用例包括："我们用yarn而不是npm"、"运行任何东西前别忘了激活虚拟环境"、"重构时我们不关心向后兼容性"。基本上所有编程助手都有这种主"规则文件"功能，现在还有人试图将其标准化为AGENTS.md。
规则文件：模块化管理你的AI家规
规则（Rules）也属于指导类别，由Claude Code在加载配置路径的文件时自动加载。这有助于组织和模块化指导，从而限制始终加载的CLAUDE.md的大小。规则可以限定到特定文件，比如*.ts对应所有TypeScript文件，这意味着它们只会在相关时加载。
典型用例是："编写Bash脚本时，变量应该引用为${var}而不是$var"，路径配置为**/*.sh。越来越多的编程助手允许这种基于路径的规则配置，比如GitHub Copilot和Cursor都支持。
斜杠命令：人类亲自上阵的精准打击
斜杠命令（Slash commands）属于指令类别，由人类触发使用。适用于你有特定较长提示词的常见任务，比如审查、提交、测试等，你想自己在主上下文中触发。
注意这个功能在Claude Code中已弃用，被技能（Skills）取代。典型用例包括：/code-review、/e2e-test、/prep-commit。GitHub Copilot和Cursor等助手也普遍支持这个功能。
技能包：AI的瑞士军刀和懒加载秘籍
技能（Skills）可以包含指导、指令、文档、脚本等各种东西，由大语言模型基于技能描述决定加载，或者由人类手动触发。
最简单的形式是，这适用于你只想"懒加载"的指导或指令，即只在相关时加载。但你可以在技能的文件夹里放任何额外的资源和脚本，并从主SKILL.md中引用它们来加载。典型用例包括：JIRA访问（技能描述助手如何使用CLI访问JIRA）、"React组件应遵循的约定"、"如何集成XYZ API"。
Cursor的"智能应用"规则一直有点像这样，但他们现在也在转向Claude Code风格的技能。
子代理：派个小弟去干脏活累活
子代理（Subagents）包含指令加上模型和可用工具集的配置，会在自己的上下文窗口中运行，可以并行化。
由大语言模型或人类触发使用。适用场景包括：适合且值得在自己的上下文中运行的常见大型任务，以提高效率（通过更有意的上下文来改善结果）或降低成本；通常需要使用默认模型之外的其他模型的任务；需要特定工具或MCP服务器但你不想在默认上下文中始终可用的任务；可编排的工作流。
典型用例包括：为刚构建的所有内容创建端到端测试、由单独的上下文和不同模型完成的代码审查，给你"第二意见"而不带原始会话的包袱。子代理是claude-flow或Gas Town等群体实验的基础。
Roo Code有子代理已经有一段时间了，他们称之为"modes"；
Cursor刚刚获得这个功能；
GitHub Copilot允许代理配置，但目前只能由人类触发。
MCP服务器：给AI装上万能遥控器
MCP服务器（MCP Servers）是一个运行在你机器上或服务器上的程序，通过模型上下文协议（Model Context Protocol）给助手提供数据源访问和其他操作能力。由大语言模型触发使用。适用于你想给助手访问API或运行在你机器上的工具的情况。
把它想象成你机器上的一个脚本，有很多选项，这些选项以结构化方式暴露给助手。一旦大语言模型决定调用这个，工具调用本身通常是确定性的。现在有个趋势是用描述如何使用脚本和CLI的技能来取代部分MCP服务器功能。
典型用例包括：JIRA访问（可以执行对Atlassian的API调用的MCP服务器）、浏览器导航（比如Playwright MCP）、访问你机器上的知识库。所有主流编程助手现在都支持MCP服务器。
钩子：自动化流水线里的定时炸弹
钩子（Hooks）是脚本，由Claude Code的生命周期事件触发。适用于你想在每次编辑文件、执行命令、调用MCP服务器等时确定性地发生某些事情的情况。
典型用例包括：自定义通知、每次文件编辑后检查是否是JS文件，如果是则运行prettier、Claude Code的可观测性用例，比如在某个地方记录所有执行的命令。
钩子这个功能目前还比较罕见，Cursor刚开始支持。
插件：团队协作的上下文配置分发器
插件（Plugins）是一种分发上述所有或任何这些东西的方式。典型用例包括：向组织中的团队分发一套通用的命令、技能和钩子。这个列表相当长！不过，我们现在正处于"风暴"阶段，肯定会收敛到更简单的功能集上。我预计技能不仅会吸收斜杠命令，还会吸收规则，这样列表就能减少两项。
分享上下文配置：复制粘贴的陷阱
正如我开头所说，这些功能只是基础，人类需要做实际工作并用合理的内容填充它们。
建立一个好的设置需要相当多的时间，因为你得使用一段时间才能判断配置是否工作良好——上下文工程没有单元测试。
因此，人们热衷于互相分享好的设置。但分享也有挑战：分享者和接收者的上下文必须尽可能相似，这在团队内部比在互联网上的陌生人之间效果好得多；有一种倾向是过度工程化上下文，提前复制粘贴不必要的指令，根据我的经验，最好逐步构建；不同经验水平可能需要不同的规则和指令；如果你因为复制了很多陌生人的东西而对上下文内容缺乏了解，可能会无意中重复指令或相互矛盾，或者责怪可怜的编程助手没用，而它只是在遵循你的指令。