用Claude Code经验告诉你：别只盯着 Prompt，上下文才是生死线！

大家好，我是智见君！

即使 Prompt 写得再好，AI 助手有时还是会犯迷糊，会忘记之前的对话，搞错你的指令，或者在处理复杂任务时彻底“掉线”。

这不是你的错觉。

昨天，创造了 Claude 的公司 Anthropic 发布了一篇有关提示词和上下文的重磅指南，一针见血地指出了问题的根源。他们说，AI 发展的下一个阶段，核心已经不是“提示词工程 (Prompt Engineering)”，而是“上下文工程 (Context Engineering)”，在 Claude Code 设计中也都是在遵循这这些规则，了解这些内容对于你自己的 AI Agent 设计也会有一些帮助。

简单来说，决定 AI Agent 聪明与否的关键，已经从“怎么问问题”，变成了“给它看什么信息”。

这篇文章，我们用最简单的话，为你讲清楚这个能改变 AI 行业游戏规则的新概念。

告别 Prompt，欢迎来到“上下文”！

过去我们都在学习怎么写 Prompt。大家想尽办法，用各种技巧，希望 AI 能听懂我们的话。这就像我们在学习一门新的外语，努力让自己的表达更清晰。

但是，Anthropic 告诉我们，这条路快走到头了。

因为 AI Agent 正在处理越来越复杂的任务，它不再是简单的一问一答。它需要像人一样，能够联系上下文，进行多步骤的思考和行动。

这时候，只优化 Prompt 就像只教一个员工“好好听话”，却不给他提供工作需要的资料和背景信息。他听得再明白，也干不好活。

“上下文工程” 就是解决这个问题的。它研究的是，在 AI 执行任务的每一步，我们应该给它提供哪些最关键、最有效的信息。这些信息，就是 AI 的“工作记忆”。

你看，Prompt 只是我们输入的一部分。而上下文，包含了系统指令、工具、MCP、外部数据、历史对话等等，是 AI 当下能看到的所有信息。管理好这些信息，才是让 AI 变聪明的核心。

AI “注意力” 是有限的

你可能会问，信息不是越多越好吗？我把所有资料都给 AI 不就行了？

恰恰相反。

研究发现，当 AI 的上下文窗口（Context Window）里的信息越来越多时，它的表现会下降。这个现象叫做 “上下文腐烂 (Context Rot)”。

这和我们人类很像。想象一下，你正在处理一个重要项目，如果有人不停地在你耳边说各种无关紧要的话，你的注意力会被分散，工作效率会大大降低。

AI 也有 “注意力预算 (Attention Budget)”。每一个进入上下文的信息，都会消耗它的注意力。信息过载，AI 就会像我们一样出现“脑雾”，抓不住重点，甚至忘记了最初的目标。

所以，上下文工程的核心原则就是：用最少、最高效的信息，让 AI 做出最正确的决策。

打造一个好的上下文，Anthropic 给出的三条规则

既然上下文这么重要，我们该如何管理它？Anthropic 给了我们三个简单又实用的建议。

1. 系统提示 (System Prompts)

系统提示是给 AI 定规矩的地方。这里的写作要像个好领导，目标明确，指令清晰，但又给员工留出自主发挥的空间。

• • 太死板不行：如果你用一堆 if-else 逻辑把 AI 的每一步都写死，它就会变得很脆弱，遇到一点新情况就“死机”。
• • 太模糊也不行：如果你只给一个“要智能一点”这样模糊的指令，AI 根本不知道该干嘛。

最好的方式是，用清晰的语言，比如 Markdown 标题或 XML 标签，把指令分成不同模块，比如 <background_information>（背景信息）、<instructions>（操作指令）、## 输出格式。这样 AI 就能一目了然。

2. 工具 (Tools)

我们给 AI 的工具，本质上是一种全新的软件。它不再是传统代码那样，输入 A 就必须输出 B。它是 确定性系统（你的代码） 和 不确定性智能体（AI） 之间的一份合约。

这份合约写得好不好，直接决定了 AI 的办事效率。Anthropic 发现，最让 AI “头大”的工具，通常有几个共同的问题：

• • 命名模糊，让人猜谜：想象一个工具的参数叫 user。这个 user 到底是指用户 ID、用户名还是邮箱地址？连人都得猜，AI 就更容易犯错。一个好的参数应该叫 user_id 或者 user_email，清晰明确。
• • 功能重叠，选择困难：如果你同时给了 AI 一个 search_jira 和一个 find_issue_in_jira 的工具，它可能就要当场“死机”了。因为它不知道这两个功能相似的工具该用哪个。最好的做法是使用 命名空间，比如把工具命名为 jira.search_issue 和 asana.search_task，这样 AI 就能清晰地知道不同工具的服务边界。
• • 返回一堆“天书”：工具执行完，返回给 AI 一大堆计算机才看得懂的 uuid 或者内部 ID，这不仅浪费了宝贵的“注意力预算”，还让 AI 难以理解。一个好的工具，应该返回人类可读的 name，并且可以提供 “简洁模式 (concise)” 和 “详细模式 (detailed)” 的选项。这样，AI 就可以只在需要时才去获取那些技术细节，平时则用最少的信息来做判断。

简单来说，设计工具的原则和管理上下文一样：用最清晰、最高效的方式，给 AI 提供决策所需的最少信息。 好的工具能让 AI 把注意力集中在解决问题上，而不是猜测你的工具到底该怎么用。

3. 少样本提示 (Few-shot)

用示例（Few-shot Prompting）来教 AI 是个好办法。但很多人会在这里犯错，他们恨不得把所有想到的极端情况都写成例子塞给 AI。

Anthropic 说，这完全是反效果。

正确的做法是，精心挑选几个 多样化、有代表性 的经典案例。对 AI 来说，一个好的例子，就是一张胜过千言万语的图片，能让它迅速领悟到我们期望的行为模式。

三种更高级玩法

对于那些需要几个小时甚至更长时间的超长任务，比如迁移一个大型代码库，AI 的上下文窗口肯定不够用。怎么办？

Anthropic 提出了三种更高级的玩法：

1. 1. 压缩 (Compaction)：当对话快要超出限制时，让 AI 自己把前面的聊天记录做个总结，提炼出关键信息，然后带着这个“会议纪要”开始新的对话。
2. 2. 结构化笔记 (Structured Note-taking)：让 AI 学会自己记笔记。比如，在做一个复杂项目时，它可以随时把重要发现、待办事项写在一个外部的 NOTES.md 文件里。需要的时候再拿出来看，这样就不会忘记关键信息。
3. 3. 子智能体架构 (Sub-agent Architectures)：把一个大任务，分包给几个“专家” AI。比如一个“资料搜集员”，一个“代码分析师”，一个“报告撰写员”。主 AI 负责统筹，各个子 AI 专注于自己的领域，最后把结果汇总。这样既高效，又不会让主 AI 的“脑子”过载。这个就是 Claude Code 的 Subagents。

下次当你的 AI Agent 表现不佳时，别再只去折腾 Prompt 了。去看看它的上下文里，是不是塞了太多垃圾信息，或者缺少了关键的指引。

热文推荐