如何让 Cloud 变聪明 8 倍（Anthropic 工程师的方法）

如何让 Cloud 聪明 8 倍（Anthropic 工程师的方法） 2026年7月6日 · 10 分钟阅读 · 查看来源 ↗ Claude AI MCP 硬件 Anthropic 工程师每天合并的代码量比一年前多了 8 倍。模型没变，硬件没变，团队也没变。唯一改变的，是 Claude 在开始工作之前所看到的东西。 把这篇收藏起来。 你的时间只会流向两个地方之一。你可以把它投入到更精妙的提示词里，或者投入到更好的上下文里。这唯一的选择，就是那 8 倍差距的全部来源。 Anthropic 自己的研究说得非常直白：一个智能体的质量，更多取决于你喂给它的上下文，而不是模型本身。Claude 只能看到上下文窗口里的内容。窗口之外的一切，等同于不存在。所以一个 AI 工程师真正的本职工作，不是巧妙的措辞，而是确保 Claude 在动手之前，面前摆着正确的信息。 这份工作现在有了名字。上下文工程（Context engineering）。它正在取代提示词工程（prompt engineering），就像几年前提示词工程取代了手工编写脚本一样。 为什么你的智能体会给出糟糕的答案 当一个智能体失败时，背锅的往往是模型。它改错了文件，做了错误的假设，交出了一个任何开发者都能看出来的错误。 模型很少是原因。原因在于缺失的上下文。 大多数人给 Claude 的是 | 一个提示词 Claude 真正需要的是 | 知识、记忆、文件、 | 规则、示例、工具、 | 状态、之前的操作 提示词只是一句话。上下文是 Claude 在其中工作的整个信息环境。一个智能体成功还是失败，取决于那个环境里装着什么，而不是运行的是哪个模型。 Anthropic 的说法很简单：模型只能看到上下文窗口里的内容，而上下文是 AI 的操作系统。构建错了，一切都不工作，无论模型多强大。 上下文到底是什么 上下文不只是你在提问之前粘贴的那段文字。那只是其中一层。一个构建得当的上下文有 7 个部分协同工作。 记忆 | 智能体从过往会话中知道的东西 指令 | 规则、约束、编码风格 示例 | 好的输出到底是什么样子 文件 | 相关的代码、文档、架构 之前的操作 | 智能体已经尝试过什么 工具结果 | 搜索和函数返回了什么 状态 | 任务目前进行到哪一步 Claude 采取的每一个行动都会让上下文增长。工具结果返回，新文件被读取，状态更新。Claude 读取新的上下文，然后挑选下一步行动。是这个循环——而不是提示词，也不是模型——真正驱动着一个智能体运行。 用户请求 ↓ 从全部七个组件构建上下文 ↓ Claude 决定行动 ↓ 工具执行 ↓ 结果被加入上下文 ↓ Claude 看到新的上下文 ↓ 下一步行动 ↓ 重复直到完成 一个弱智能体在第 2 步就破坏了循环。上下文不完整，于是 Claude 用假设来填补空白，而错误的假设产生错误的输出。通常的修法是重写提示词。真正有效的修法，是把上下文构建正确。 三层上下文栈 Anthropic 把上下文框定为 3 层。每一层有自己的职责，并在工作的不同时刻加载。 全局上下文 | 始终存在，每个会话都在 项目上下文 | 在项目开始时加载 任务上下文 | 针对具体任务加载 全局上下文是永久层：身份、核心规则、编码风格、智能体绝对不能做的事情。它在各个会话之间保持不变，永远不需要重新解释。 全局上下文包含： - 智能体的身份和角色 - 编码标准和风格规则 - 安全约束 - 绝对不能触碰或修改的东西 - 如何处理不确定性 项目上下文是知识层：Claude 理解这个代码库所需要的一切。架构、正在使用的模式、决策及其背后的原因、以前坏掉过的东西。 项目上下文包含： - README 和架构概览 - 带项目专属规则的 AGENTS.md - 文件夹结构和命名约定 - 测试要求和模式 - 关键依赖以及为什么选择它们 任务上下文是执行层：它面前的文件、当前的工单、眼前的目标、适用于这个具体任务的限制。 任务上下文包含： - 当前文件和相关文件 - 本次会话的具体目标 - 最近的改动及其结果 - 当前的测试结果 - 针对这个任务的约束 只给 Claude 任务上下文，它每个会话都会对全局层和项目层视而不见，对所有从未被告知的事情全靠猜。那些猜测，就是错误的来源。 AGENTS.md，那个改变一切的文件 在一个严肃的 Claude Code 配置里，这是最重要的单个文件。AGENTS.md 已经成为了 AI 编码智能体的标准，现在存在于成千上万个生产仓库中，原因只有一个：它管用。 项目上下文永久地住在这里。Claude 在每个会话开始时读取 AGENTS.md，之后再也不需要被重新告知任何内容。 # AGENTS.md ## Architecture（架构） Monorepo，Next.js 前端加 Express 后端。 所有 API 路由都在 /api 下。永远不要直接修改 /legacy。 ## Coding Rules（编码规则） 永远不要用 axios。始终用 fetch。 每个组件：TypeScript、Tailwind、Server Actions。 除了页面之外，不允许默认导出。 ## Testing（测试） 单元测试用 Vitest。E2E 用 Playwright。 每次提交前运行 npm test。 永远不要禁用一个失败的测试——修好它或者上报。 ## Git 永远不要直接提交到 main。 始终开一个带清晰描述的 PR。 把每个 PR 关联到一个 Linear 工单。 ## Never Touch（绝不触碰） src/payments/ - 任何改动都需要人工审批 src/auth/tokens/ - 需要安全审查 .env 文件 - 永远不要读取或修改 那个文件里的每一行，都是 Claude 不会再犯的一个错误。一个项目运行得越久，AGENTS.md 就越锋利，因为它收集了智能体犯过的每一个错误、团队设定的每一条约定。 驱动严肃智能体的上下文栈 强大的 AI 工程师不会靠敲一个提示词来开始一项任务。他们会加载一个上下文栈——一组固定顺序的信息，在 Claude 采取任何行动之前就位。 第 1 步 | 加载全局上下文 - 身份、规则、风格 第 2 步 | 加载项目上下文 - AGENTS.md、架构、文档 第 3 步 | 在记忆中搜索相关的过往经验 第 4 步 | 为这个具体任务加载相关文件 第 5 步 | 加载当前状态 - 测试结果、最近的改动 第 6 步 | 用清晰的验收标准定义任务目标 第 7 步 | Claude 带着完整信息行动 下面是默认智能体和做了上下文工程的智能体的对比： 糟糕的智能体： 问题 → Claude → 答案 Claude 对所有它不知道的东西全靠猜 好的智能体： 问题 ↓ 搜索文档 ↓ 搜索记忆 ↓ 读 AGENTS.md ↓ 读相关文件 ↓ 检查当前状态 ↓ Claude ↓ 建立在完整信息之上的答案 第二个智能体并不更聪明。它只是信息更充分。同一个模型，不同的上下文。 记忆，那个在会话之间存活的上下文 Anthropic 区分了喂给上下文的记忆种类。大多数智能体只持有一种——当前对话——这就是为什么它们每次都要从零重启。 长期记忆 | 在所有过往会话中学到的一切 短期记忆 | 在这次对话中更早发生的事 工作记忆 | 此刻在上下文窗口里的东西 长期记忆是让一个智能体随着时间越来越值钱的东西。每个会话都在为它添砖加瓦，每个错误都被记录下来，每个奏效过的模式都被存储起来。一个在某个代码库上跑了 6 个月的智能体，知道一些任何提示词都无法复现的东西。 在实践中，这是一个记忆文件——一个位于对话之外的 markdown 文档，智能体在会话开始时读取它，在会话结束时更新它。 Project Memory（项目记忆） Architecture decisions（架构决策） - 选择 Supabase 而非 Firebase：实时性不那么关键，需要 SQL 查询 - 从 REST 迁移到 tRPC：全栈类型安全，2026 年 6 月 What has worked（奏效过的） - 重构前更高的测试覆盖率可以防止回归 - 把大 PR 拆成功能开关发布可以减少审查时间 What has not worked（没奏效过的） - 自动生成迁移：schema 漂移引发了一次生产事故 - 多个智能体并行写同一个文件：始终用 worktree Recurring patterns（反复出现的模式） - 认证问题几乎总能追溯到中间件顺序 - 性能问题通常始于数据库查询层 每个会话开始时读取，结束时更新。智能体不再遗忘。 MCP，来自四面八方的上下文 上下文不只是来自仓库里的文件。一个生产级的智能体需要团队所接触的每一个系统的上下文：问题追踪器、错误监控器、文档、数据库、聊天。 Model Context Protocol 就是 Claude 从外部系统拉取上下文的方式，而不需要为每一个系统做定制集成。 Filesystem | 本地文件、配置、代码库 GitHub | issues、PR、提交历史、CI 结果 Linear / Jira | 工单、优先级、项目状态 Slack | 已做出的决策、讨论中的上下文 Postgres | 实时数据、schema、查询结果 Google Drive | 文档、规格说明、会议记录 Sentry | 实时错误、频率、受影响的用户 一个接入了 MCP 的智能体看到的不只是代码。它看到解释这个功能为何重要的工单、做出架构决策的那条 Slack 线程、显示用户如何踩到这个 bug 的 Sentry 错误，以及修复必须遵守的数据库 schema。 那就是完整的上下文。Claude 做出正确判断、无需猜测所需要的一切。 一个做了上下文工程的任务长什么样 而不是这样： 构建导出功能。 你交给 Claude 的是这样： Goal（目标） 导出功能正在阻碍免费转付费的转化。 参考信号：/signals/export-too-hidden.md Relevant files（相关文件） src/features/export/ - 当前实现 src/components/ui/Button.md - 需要遵循的按钮模式 tests/features/export.test.ts - 现有的测试覆盖 Architecture constraints（架构约束） 阅读 AGENTS.md 的 Export Rules 一节 永远不要直接修改账单集成 Success criteria（验收标准） 所有现有测试通过 新测试覆盖三种导出格式 PR 开出来并关联 Linear 工单 EXP-47 不改动 src/payments/ 同一个任务，不同的上下文。输出不只是好一点点。它是完全不同性质的输出，因为 Claude 是在用完整信息做决定，而不是用聪明的猜测。 这个周末就把你的上下文栈搭起来 第 1 天 搭建三层栈。写一个带身份和核心规则的全局上下文文件。创建 AGENTS.md，写上你的架构、编码约定和绝不触碰清单。建立一个记忆文件，在会话开始时加载，在会话结束时更新。 第 2 天 用 MCP 接入外部上下文。加上 GitHub 连接器，让 Claude 看到你的 issues 和 PR 历史。加上文件系统连接器，让它快速穿行于代码库。如果你们团队在 Slack 或 Linear 上做决策，也加上。 第 3 天 测试差距。把同一个任务跑两遍，一遍用你旧的只用提示词的方式，一遍用完整的栈。那个差距，就是 8 倍提升的来源。 转变已经发生了 提示词工程是找到正确的措辞。上下文工程是构建正确的信息环境。 Anthropic 最强的工程师并不把一天花在打磨提示词上。他们花在确保 Claude 在行动之前拥有正确的知识、记忆、文件、规则和状态上。提示词是最后 1% 的工作。上下文是另外的 99%。 在薄弱的上下文之上叠加完美的提示词，你得到的仍然是聪明的错误。用平平无奇的提示词，把完整的上下文喂给同一个模型，它就能做出正确的判断。决定这个的不是模型，而是信息环境。 上下文是 AI 的操作系统。把它构建正确，8 倍就不再是 Anthropic 的故事，而是发生在你自己的代码库里。 收藏这篇，给它一个周末。 标签：# X # Claude # AI # MCP # 硬件 # Thread # Guide 相关文章 Anthropic 工程师输出提升 8 倍。这是背后的上下文工程系统。Anthropic 工程师每天合并的代码量比一年前多了 8 倍。模型没变。硬件没变。团队规模没变。变的是 Claude 在开始之前所看到的…… Claude AI MCP 硬件