Anthropic 工程师 8 倍产出——背后的上下文工程系统

Anthropic 工程师 8 倍产出。这就是它背后的上下文工程系统。 July 4, 2026 · 阅读时长11分钟 · 查看原文 ↗ Claude AI MCP 硬件 Anthropic 的工程师每天合并的代码量是一年前的多 8 倍。模型没变。硬件没变。团队规模没变。变的是 Claude 在开始工作之前看到的东西。 大多数开发者花时间写更好的提示词。Anthropic 的工程师花时间构建更好的上下文。这一个转变，就解释了整个 8 倍的差距。 Anthropic 自己的研究说得很直接：一个 AI agent 的质量，更少取决于模型，更多取决于你给它的上下文。Claude 只能看到上下文窗口里的东西。窗口之外的一切都不存在。这意味着，一个认真的 AI 工程师的全部工作，不是写聪明的提示词——而是确保 Claude 在采取任何一个动作之前，恰好拥有正确的信息。 这门学科现在有了名字。上下文工程（Context engineering）。它正在取代提示词工程，就像两年前提示词工程取代手工写脚本一样。 收藏这篇，并关注 I'm Noisy，一个有 4 年经验的开发者。我构建 AI 系统、自动化管线，并寻找把技术变成真实收入的方法。 为什么你的 AI agent 给出糟糕的答案 当一个 AI agent 失败时，大多数人责怪模型。改错了文件。做错了假设。任何开发者都会抓到的明显错误。 模型几乎从来不是问题。问题是缺失的上下文。 提示词是一句话。上下文是 Claude 运作其中的整个信息环境。一个能用的 agent 和一个不能用的 agent 之间的区别，几乎总是那个环境里有什么——而不是跑的是哪个模型。 Anthropic 是这样描述的：LLM 只看到上下文窗口里的东西。上下文是 AI 的操作系统。构建错了，无论模型多强，什么都跑不起来。 上下文到底是什么 大多数人以为上下文就是他们在问题之前粘贴的文本。那只是一层。一个正确工程化的上下文有七个组件协同工作。 每次 Claude 采取一个动作，上下文都会增长。工具结果回来。新文件被读取。状态更新。Claude 看到新上下文，决定下一个动作。这个循环才是 agent 的实际机制——不是提示词，不是模型，而是随着每一步演化的上下文。 一个糟糕的 agent 在第二步就打破了这个循环。上下文不完整，所以 Claude 做假设。假设错了，所以输出错了。大多数开发者通过重写提示词来修复。真正的修复是正确地构建上下文。 三层上下文栈 Anthropic 建议分三层来思考上下文。每一层服务于不同的目的，在 agent 工作的不同时点被加载。 全局上下文（Global Context）是永久层。身份、核心规则、编码风格、agent 绝不该做什么。它在会话之间永不改变，也永不需要重新解释。 项目上下文（Project Context）是知识层。Claude 理解这个具体代码库所需要的一切——架构、用到的模式、做过的决策以及为什么、之前出错的地方。 任务上下文（Task Context）是执行层。正在处理的具体文件、当前的 ticket、眼前的目标、适用于这个确切任务的约束。 大多数开发者只给 Claude 任务上下文。agent 每次会话开始时都没有全局或项目上下文，只能猜测它所不知道的一切。那些猜测正是错误的来源。 AGENTS.md —— 改变一切的文件 https://docs.claude.com/en/docs/claude-code/memory 任何认真的 Claude Code 配置里最重要的单个文件。研究者已经把 AGENTS.md 认定为 AI 编码 agent 上下文的新标准——它现在出现在成千上万个生产仓库里，恰恰是因为它有效。 AGENTS.md 是项目上下文永久驻留的地方。Claude 在每次会话开始时自动读取它。之后它就再也不需要被告知其中的任何内容了。 这个文件里的每一条规则，都是 Claude 永远不会再犯的一个错误。项目运行得越久，AGENTS.md 就变得越具体、越有价值——它是 agent 犯过的每一个错误、以及团队确立的每一项约定的累积知识。 驱动认真 agent 的上下文栈 最好的 AI 工程师不会从写提示词开始一个任务。他们构建一个上下文栈——一个结构化的信息序列，在 Claude 采取任何一个动作之前加载。 对比一个上下文工程做得好的 agent 和默认状态下的样子： 第二个 agent 不是更聪明。它是信息更充分。模型完全相同。上下文不同。 记忆 —— 在会话之间存活的上下文 Anthropic 清楚地区分了喂给上下文的记忆类型。大多数 agent 只有一种——当前对话。这就是它们每次会话都从零开始的原因。 长期记忆是让一个 agent 的价值随时间复利的东西。每次会话都往里加东西。每个错误都被记录。每个成功的模式都被存起来。一个在某代码库上跑了六个月的 agent，知道关于那个项目的、任何提示词都无法复刻的事情。 实际实现是一个记忆文件——对话之外的一个 markdown 文档，agent 在每次会话开始时读取，在结束时更新。 每次会话这个文件都被读取。每次会话它都被更新。agent 从不遗忘。 MCP —— 来自各处的上下文 上下文不只是来自仓库里的文件。一个生产级 agent 需要来自团队工作的每一个系统的上下文——issue 跟踪器、错误监控器、文档、数据库、沟通工具。 Model Context Protocol 就是 Claude 从外部系统拉取上下文、而无需为每个系统做定制集成的方式。 一个配置了 MCP 的 agent 不只是看到代码。它看到描述「为什么需要这个功能」的 ticket、决定架构的那场 Slack 对话、显示用户如何踩中 bug 的 Sentry 错误，以及修复必须尊重的数据库 schema。 那才是完整的上下文。Claude 做正确决策、无需猜测所需要的一切。 上下文工程工作流 这就是一个上下文工程做得好的任务从头到尾的样子。 而不是： 你给 Claude： 同样的任务。完全不同的上下文。输出不是渐进地更好——它是类别层面的不同，因为 Claude 是在用完整信息做决策，而不是在做聪明的猜测。 这个周末的实操设置 第 1 天 - 构建三层上下文栈。写一个包含身份和核心规则的全局上下文文件。创建 AGENTS.md，包含你的项目架构、编码约定和「绝不触碰」清单。设置一个在会话开始时加载、在会话结束时更新的记忆文件。 第 2 天 - 通过 MCP 连接外部上下文。安装 GitHub 连接器，让 Claude 看到你的 issue 跟踪器和 PR 历史。安装文件系统连接器，让它高效地浏览代码库。如果你的团队用 Slack 或 Linear 做决策，加上它们。 第 3 天 - 测试差异。用你旧的「只靠提示词」的方法、以及完整的上下文栈，分别跑同一个任务。输出的差距，就是 8 倍生产力来源的地方。 已经发生的转变 提示词工程是关于找到正确的词。上下文工程是关于构建正确的信息环境。 Anthropic 最好的 AI 工程师不花时间打磨聪明的提示词。他们花时间确保 Claude 在采取任何一个动作之前，恰好拥有正确的知识、记忆、文件、规则和状态。提示词是工作的最后 1%。上下文是另外的 99%。 一个提示词完美但上下文糟糕的 agent，会犯聪明的错误。一个提示词普通但上下文完整的 agent，会做出正确的决策。模型是一样的。信息环境不一样。 上下文是 AI 的操作系统。把它构建对了，8 倍产出差距就不再只是发生在 Anthropic 的事，而开始发生在你的代码库里。 大多数开发者会继续重写他们的提示词，纳闷为什么结果没改善。少数人会花一个周末构建一个正确的上下文栈，然后就再也回不去了。 你构建自己的人生——所以选择正确的路。 / 如果这对你有用——关注 / 提示词 Filesystem | 本地文件、配置、代码库 GitHub | issue、PR、提交历史、CI 结果 Linear / Jira | ticket、优先级、项目状态 Slack | 做过的决策、讨论中的上下文 Postgres | 实时数据、schema、查询结果 Google Drive | 文档、规格、会议纪要 Sentry | 实时错误、频率、受影响用户 第 1 步 | 加载全局上下文 —— 身份、规则、风格 第 2 步 | 加载项目上下文 —— AGENTS.md、架构、文档 第 3 步 | 在记忆中搜索相关的过往经验 第 4 步 | 为这个具体任务加载相关文件 第 5 步 | 加载当前状态 —— 测试结果、近期变更 第 6 步 | 用清晰的成功标准定义任务目标 第 7 步 | Claude 用完整信息行动 全局上下文包含： - Agent 身份和角色 - 编码标准和风格规则 - 安全约束 - 绝不触碰或修改的东西 - 如何处理不确定性 目标 导出功能正在阻碍免费转付费的转化。 见信号：/signals/export-too-hidden.md 相关文件 src/features/export/ —— 当前实现 src/components/ui/Button.md —— 要遵循的按钮模式 tests/features/export.test.ts —— 现有的测试覆盖 架构约束 阅读 AGENTS.md 的：Export Rules 部分 绝不直接修改账单集成 成功标准 所有现有测试通过 新测试覆盖三种导出格式 PR 打开并关联 Linear ticket EXP-47 不改动 src/payments/ # 项目记忆 ## 架构决策 - 选择 Supabase 而非 Firebase：实时性不那么关键，需要 SQL 查询 - 从 REST 迁移到 tRPC：全栈类型安全，2026 年 6 月 ## 什么奏效了 - 重构前更高的测试覆盖能防止回归 - 把大 PR 拆成功能开关发布能减少审查时间 ## 什么没奏效 - 自动生成迁移：schema 漂移引发了生产事故 - 并行 agent 写同一个文件：永远用 worktree ## 反复出现的模式 - 认证问题几乎总是追溯到中间件顺序 - 性能问题通常始于数据库查询层 糟糕的 agent： 问题 → Claude → 答案 Claude 猜测它所不知道的一切 好的 agent： 问题 ↓ 搜索文档 ↓ 搜索记忆 ↓ 读 AGENTS.md ↓ 读相关文件 ↓ 检查当前状态 ↓ Claude ↓ 建立在完整信息上的答案 项目上下文包含： - README 和架构概览 - 带项目专属规则的 AGENTS.md - 文件夹结构和命名约定 - 测试要求和模式 - 关键依赖以及为什么选它们 长期记忆 | 在所有过往会话中学会的一切 短期记忆 | 本次对话中早些时候发生的事 工作记忆 | 现在上下文窗口里的东西 任务上下文包含： - 当前文件和相关文件 - 本次会话的具体目标 - 近期变更及其结果 - 当前测试结果 - 适用于这个具体任务的约束 记忆 | agent 从过往会话中知道的东西 指令 | 规则、约束、编码风格 示例 | 好的输出实际长什么样 文件 | 相关代码、文档、架构 先前的动作 | agent 已经尝试过什么 工具结果 | 搜索和函数返回了什么 状态 | 任务当前进行到哪 构建导出功能。 大多数人给 Claude 的 | 一个提示词 Claude 真正需要的 | 知识、记忆、文件、 | 规则、示例、工具、 | 状态、先前的动作 用户请求 ↓ 由全部七个组件构建的上下文 ↓ Claude 决定动作 ↓ 工具执行 ↓ 结果加入上下文 ↓ Claude 看到新上下文 ↓ 下一个动作 ↓ 重复直到完成 # AGENTS.md ## 架构 带 Next.js 前端和 Express 后端的 Monorepo。 所有 API 路由都在 /api 下。绝不直接修改 /legacy。 ## 编码规则 绝不使用 axios。永远用 fetch。 每个组件：TypeScript、Tailwind、Server Actions。 除页面外，不用默认导出。 ## 测试 Vitest 做单元测试。Playwright 做 E2E。 每次提交前运行 npm test。 绝不禁用一个失败的测试——修它，或者上报。 ## Git 绝不直接提交到 main。 永远开一个带清晰描述的 PR。 每个 PR 关联一个 Linear ticket。 ## 绝不触碰 src/payments/ —— 任何改动都需要人工批准 src/auth/tokens/ —— 需要安全审查 .env 文件 —— 绝不读取或修改 全局上下文 | 永远在场，每次会话都有 项目上下文 | 在项目启动时加载 任务上下文 | 为具体任务加载 Links docs.claude.com/en/docs/claude-code/memory 标签： # X # Claude # AI # MCP # 硬件 # 指南 相关文章 如何让 Cloud 聪明 8 倍（Anthropic 工程师的方法） Anthropic 工程师每天合并的代码量是一年前的多 8 倍。模型、硬件、团队都没变。唯一变了的是 Claude 开始工作前看到的东西…… Claude AI MCP 硬件