Glean 拾遗
日刊 /2026-05-29 / 上下文工程正在替代提示工程:五层框架与实践指南

上下文工程正在替代提示工程:五层框架与实践指南

原文 x.com 收录 2026-05-29 14:47 阅读 12 min
AI 解读

本文提出「上下文工程」正在取代提示工程:随着模型理解力提升,瓶颈不再是提示词本身,而是模型可用的上下文信息。作者给出五层框架:身份上下文(告诉 Claude 你是谁)、知识上下文(上传关键文档)、记忆上下文(持续记录偏好)、工具上下文(接入邮件、日历、代码库等 MCP 工具)、流程上下文(用 Skill 文件固化工作流)。核心观点:精心设计的环境比精心编写的 prompt 更重要。文章偏实操指南,无实测数据,适合重度使用 Claude 的用户。

原文 12 分钟
原文 x.com ↗
§ 1

Context Engineering Is Replacing Prompt Engineering. Here's How It Works

Context Engineering Is Replacing Prompt Engineering. Here's How It Works

§ 2

Here is something that is going to frustrate a lot of people.

Save this :)

All those prompting courses you bought. All those "ultimate prompt templates" you saved. All those threads about chain-of-thought and few-shot examples and role-playing techniques.

They are not useless. But they are no longer the most important skill.

The game has shifted. And most people do not even know it yet.

In 2024 and early 2025, prompt engineering was the skill everyone talked about. Write better words, get better results. And that was true - for a while.

But the models have evolved. Claude 4.6 is not the same tool you were prompting a year ago. It does not need you to say "you are a senior expert" anymore. It does not need twenty lines of instructions for a simple task. It takes you literally and executes precisely.

The bottleneck is no longer the words you type. The bottleneck is the context you provide.

Welcome to context engineering. The skill that is quietly replacing prompt engineering as the most valuable thing you can learn in AI.

这件事会让很多人感到沮丧。

收藏这条,准没错:)

你买过的所有提示词课程、收藏的所有「终极提示模板」、所有关于链式思维和少样本示例和角色扮演技巧的帖子……

它们并非无用。但它们已不再是最重要的技能。

游戏规则已经变了,而大多数人还浑然不知。

2024 年到 2025 年初,提示工程是所有人都在谈论的技能。写出更好的指令,得到更好的结果。这在一段时间内的确如此。

但模型已经进化了。Claude 4.6 已不是你一年前交互的那个工具。它不再需要你告诉它「你是一位资深专家」了,也不再需要针对简单任务写二十行指令。它会逐字理解你的话并精确执行。

瓶颈不再是你输入的词语,而是你提供的上下文。

欢迎来到上下文工程——这项技能正悄然取代提示工程,成为你在 AI 领域能学到的最有价值的东西。

§ 3

Think about prompt engineering like this.

You are telling a brilliant new employee exactly what to do for one task, one time. "Write me a blog post. Make it professional. Use these examples. Follow this format."

That works for single tasks. It falls apart the moment you want consistency across sessions, memory of past work, awareness of your preferences, or integration with your actual tools and data.

Prompt engineering treats every conversation as an isolated event. You start from scratch every time. You re-explain your context every time. You get inconsistent results every time because the prompt is slightly different every time.

Context engineering fixes this by changing the question.

Prompt engineering asks: "What words should I type to get a good result?"

Context engineering asks: "What information does Claude need access to in order to consistently produce the result I want?"

That is a fundamentally different question. And it leads to fundamentally different outcomes.

不妨这样理解提示工程。

你正在告诉一位聪明的新员工,针对一项任务、一次性地精确执行你的指令:「给我写一篇博文。要专业。用这些示例。按这个格式来。」

这在单次任务中很有效。但一旦你想要跨会话保持一致性、记住过往工作、了解你的偏好,或整合你实际使用的工具和数据,它就崩溃了。

提示工程把每次对话都当成孤立事件。每次都要从头开始,每次都要重新解释上下文,每次都因为提示词稍有不同而得到不一致的结果。

上下文工程通过改变提问方式来解决这个问题。

提示工程问的是:「该输入哪些词才能得到好结果?」

上下文工程问的是:「Claude 需要访问哪些信息,才能稳定地产出我想要的结果?」

这是个根本不同的问题,也会带来根本不同的结果。

§ 4

Context engineering is the practice of designing, organizing, and maintaining the complete environment of information that Claude uses when it generates a response.

That includes:

  • System prompts and custom instructions
  • Uploaded knowledge files and documents
  • Memory from previous conversations
  • Connected tools and data sources (MCP servers)
  • Reference files like CLAUDE.md and rules.md
  • Examples of your past work and preferred styles
  • Real-time data from your apps and services

Prompt engineering is typing the right words. Context engineering is building the right environment.

When Claude has the right environment — your style guide, your project history, your tool access, your quality standards — you barely need to prompt at all. You say "write the weekly report" and it already knows what that means because the context tells it everything.

上下文工程指的是:设计、组织和维护 Claude 生成回复时会用到的完整信息环境。

这包括:

  • 系统提示和自定义指令
  • 上传的知识文件和文档
  • 来自之前对话的记忆
  • 连接的工具和数据源(MCP 服务器)
  • 参考文件,如 CLAUDE.mdrules.md
  • 你过往工作和偏好的风格示例
  • 来自你应用和服务的实时数据

提示工程是输入对的词,上下文工程是构建对的环境。

当 Claude 拥有了正确的环境——你的风格指南、项目历史、工具访问权限、质量标准——你几乎不需要提示。你说「写周报」,它已经明白那是什么意思,因为上下文已经告诉它一切。

§ 5

This is the foundation. Claude needs to know who it is talking to.

Most people skip this entirely. They open Claude and start asking questions with no context about themselves, their role, their industry, or their audience. Claude defaults to generic, one-size-fits-all responses. Then people blame the model.

How to implement this:

Go to Claude's custom instructions in settings. Write this:

I am [YOUR NAME], a [YOUR ROLE] in [YOUR INDUSTRY]. My audience is [WHO YOU SERVE]. My communication style is [HOW YOU WRITE/SPEAK]. When I ask for content, default to [YOUR PREFERRED FORMAT]. When I ask for analysis, default to [YOUR PREFERRED DEPTH].

This takes two minutes. It transforms every conversation from that point forward. Claude stops being a generic assistant and starts being your assistant.

If you are using Claude Projects, create a dedicated project for each major area of your work. Each project has its own system prompt and knowledge files. Your content writing project has your style guide. Your business analysis project has your financial data. Your coding project has your tech stack preferences.

Separate contexts for separate work. This is fundamental.

这是根基。Claude 需要知道它在和谁对话。

大多数人完全忽略了这一步。他们打开 Claude 就开始提问,没有任何关于自己、角色、行业或受众的上下文。Claude 默认给出泛泛的、一刀切的答案。然后他们怪模型不好。

如何实现:

在设置中进入 Claude 的自定义指令,写下:

我是 [你的名字],一名 [你的角色],就职于 [你的行业]。 我的受众是 [你服务的人群]。 我的沟通风格是 [你写作/说话的方式]。 当我请求内容时,默认格式为 [你偏好的格式]。 当我请求分析时,默认深度为 [你偏好的深度]。

这只需要两分钟。从此以后,每次对话都会改变。Claude 不再是一个通用助手,而是你的专属助手。

如果你使用 Claude Projects,为你工作的每个主要领域创建一个专门的项目。每个项目都有自己的系统提示和知识文件。你的内容创作项目会有你的风格指南,你的商业分析项目会有你的财务数据,你的编码项目会有你的技术栈偏好。

不同的工作,分开的上下文。这是基本原则。

§ 6

This is where most beginners get the biggest unlock.

You can upload documents directly into Claude Projects and they become permanent knowledge. Style guides. Brand documents. Product specifications. Process documentation. Past work examples. Competitive research.

Everything you would give a new hire on their first day - give to Claude.

Most people paste context into every conversation manually. They copy the same document fifty times. They re-explain their brand voice in every session. They lose consistency because they describe things slightly differently each time.

Knowledge context eliminates all of this. Upload it once. Reference it forever.

What to upload as knowledge files:

  • Your brand guide (tone, voice, visual identity, messaging)
  • Your product documentation or service descriptions
  • Examples of your best work (so Claude can match the standard)
  • Your audience research or customer personas
  • Your content calendar or strategic plan
  • Your coding standards and architecture decisions (for developers)
  • Your templates for repeating deliverables

The more knowledge context Claude has, the less prompting you need to do. This is the trade-off most people miss. They spend time crafting elaborate prompts when they should be spending time building comprehensive knowledge context.

这是大多数新手收获最大的地方。

你可以将文档直接上传到 Claude Projects,它们就会变成永久知识。风格指南、品牌文件、产品规格、流程文档、过往作品范例、竞品研究……

你会给新员工第一天入职时看的所有东西——都可以给 Claude。

大多数人每次对话都手动粘贴上下文。同一份文档复制五十遍,每次会话都重新解释品牌语调,因为描述方式稍有不同而失去一致性。

知识上下文消除了所有这些问题。上传一次,永久引用。

上传什么作为知识文件:

  • 品牌指南(语调、声音、视觉识别、信息传达)
  • 产品文档或服务描述
  • 你最好的作品示例(以便 Claude 对标标准)
  • 受众研究或客户画像
  • 内容日历或战略计划
  • 编码规范和架构决策(面向开发者)
  • 可重复交付物的模板

Claude 拥有的知识上下文越多,你需要做的提示就越少。这是大多数人错过的取舍——他们花时间精心编写提示,却本应花时间构建全面的知识上下文。

§ 7

Memory is what separates a tool from an assistant.

Claude has built-in memory that persists across conversations. When you tell Claude something important — your preferences, your projects, your constraints — it can remember it for future sessions.

But memory is not automatic. You need to actively build it.

How to build memory strategically:

During conversations, explicitly tell Claude to remember things:

  • "Remember that I always want code examples in TypeScript, not JavaScript."
  • "Remember that my newsletter goes out every Tuesday and I need drafts by Monday morning."
  • "Remember that when I say 'write it for the audience' I mean tech-savvy founders aged 25-40."

Over time, your memory builds up into a rich profile. Claude knows your defaults without being told. It knows your preferences without being reminded. It knows your patterns without re-learning them every session.

The compound effect of memory is enormous. After a month of actively building memory, Claude feels like a different tool entirely. It anticipates what you need. It formats things the way you like automatically. It catches mistakes it knows you care about.

Most beginners never tell Claude to remember anything. They start every session from zero. That is like hiring someone and wiping their memory every night.

记忆是区分工具和助手的关键。

Claude 拥有跨对话持久化的内置记忆。当你告诉 Claude 重要的事情——你的偏好、你的项目、你的限制——它能够记住,并在未来会话中使用。

但记忆不是自动形成的。你需要主动构建。

如何有策略地构建记忆:

在对话中,明确要求 Claude 记住这些信息:

  • 「记住,我总是想要 TypeScript 的代码示例,而不是 JavaScript。」
  • 「记住,我的 newsletter 每周二发送,我需要在周一上午前收到初稿。」
  • 「记住,当我说『写给受众看』时,我指的是 25 到 40 岁精通技术的创始人。」

随着时间推移,你的记忆会累积成一个丰富的画像。Claude 不用你告诉就能了解你的默认设置,不用你提醒就知道你的偏好,不用每次会话重新学习就了解你的模式。

记忆的复利效应巨大。主动构建记忆一个月后,Claude 会感觉完全像另一种工具。它会预测你的需求,自动按你喜欢的方式格式化,捕捉它在意的错误。

大多数新手从未让 Claude 记住任何东西。他们每次会话都从零开始。这就像雇了一个人,然后每晚抹掉他的记忆。

§ 8

This is where context engineering gets really powerful.

Claude can connect to external tools through MCP servers and built-in connectors. Gmail. Google Drive. Slack. GitHub. Databases. Web search. Browser automation. Hundreds of integrations.

Every tool you connect is context Claude did not have before.

Without tool context, Claude answers from its training data. With tool context, Claude answers from your actual data — your emails, your files, your codebase, your calendar, your analytics.

The difference between asking Claude "what should I prioritize this week" with no tool access versus asking it with access to your calendar, email, and project management tool is enormous. One gives you generic productivity advice. The other gives you a specific, personalized prioritization based on your actual commitments.

The minimum tool context stack:

  1. Web search — so Claude has current information, not stale training data
  2. File access — so Claude can read and create documents on your machine
  3. Your primary communication tool (Gmail or Slack) — so Claude has context on ongoing conversations
  4. Your primary knowledge tool (Google Drive, Notion, or Obsidian) — so Claude can access your work

Connect these four and Claude goes from "smart chatbot" to "informed assistant."

这是上下文工程真正强大之处。

Claude 可以通过 MCP 服务器和内置连接器连接到外部工具:Gmail、Google Drive、Slack、GitHub、数据库、网页搜索、浏览器自动化……数百种集成。

你连接的每个工具,都是 Claude 之前不曾拥有的上下文。

没有工具上下文,Claude 只能基于训练数据作答。有了工具上下文,Claude 基于你的真实数据作答——你的邮件、文件、代码库、日历、分析数据。

问 Claude「这周我该优先做什么」,在没有工具访问权限和有访问你的日历、邮件、项目管理工具权限时,二者差别巨大。前者给你通用的生产力建议,后者根据你的实际承诺给出具体的、个性化的优先级安排。

最小工具上下文栈:

  1. 网页搜索——使 Claude 拥有当前信息,而非过时的训练数据
  2. 文件访问——使 Claude 能在你的机器上读取和创建文档
  3. 你的主要沟通工具(Gmail 或 Slack)——使 Claude 了解进行中的对话上下文
  4. 你的主要知识工具(Google Drive、Notion 或 Obsidian)——使 Claude 能访问你的工作资料

连上这四个,Claude 就从「聪明的聊天机器人」变成了「通晓全局的助手」。

§ 9

The final layer. This is what turns context engineering into a system.

Process context tells Claude not just what to do, but how to do it — the steps, the quality standards, the output format, the verification checks, the handoff procedures.

This is what Skills and workflow files do. They encode your processes into repeatable, consistent, automated systems.

Example — turning a manual process into process context:

Let's say every week you write a newsletter. Your manual process:

  1. Research trending topics in your niche
  2. Pick the best angle
  3. Write a draft
  4. Edit for tone and length
  5. Format for your email platform
  6. Schedule

Without process context, you prompt Claude separately for each step, with different instructions each time, and get inconsistent results.

With process context, you create a Skill file:

Newsletter Production Skill

Process

  1. Research: Search for the top 5 trending topics in [NICHE] this week. Use web search. Summarize each in 2 sentences.
  2. Selection: Recommend the best topic based on relevance to my audience and uniqueness of angle. Explain your reasoning.
  3. Draft: Write a 500-word newsletter. Use my voice (reference my style guide). Open with a hook. Include one actionable takeaway.
  4. Edit: Review against my quality checklist. Fix any issues. Verify length is 450-550 words.
  5. Format: Output as HTML ready for [EMAIL PLATFORM]. Include subject line (under 50 characters).

Quality Standards

  • Every claim must include a specific number or example
  • Opening line must create curiosity — never start with "in this newsletter"
  • Tone: conversational, direct, zero filler
  • Reading time: under 3 minutes

You run this Skill once and get a complete, polished newsletter. Every week. Consistent quality. No re-prompting.

That is the difference between prompt engineering and context engineering. One is typing instructions every time. The other is building a system once and running it forever.

最后一层,它将上下文工程变成一个系统。

流程上下文不仅告诉 Claude 做什么,还告诉它怎么做——具体步骤、质量标准、输出格式、验证检查、交接程序。

这就是 Skills 和工作流文件的用途。它们将你的流程编码为可重复、一致、自动化的系统。

示例——将手动流程转化为流程上下文:

假设你每周写一份 newsletter,你的手动流程是:

  1. 研究自己细分领域内的热门话题
  2. 选出最佳角度
  3. 撰写初稿
  4. 根据语调和长度进行编辑
  5. 调整为邮件平台所需格式
  6. 安排发送

没有流程上下文时,你针对每一步单独提示 Claude,每次指令都不同,得到的结果也不一致。

有了流程上下文,你创建一个 Skill 文件:

Newsletter Production Skill

Process

  1. Research: Search for the top 5 trending topics in [NICHE] this week. Use web search. Summarize each in 2 sentences.
  2. Selection: Recommend the best topic based on relevance to my audience and uniqueness of angle. Explain your reasoning.
  3. Draft: Write a 500-word newsletter. Use my voice (reference my style guide). Open with a hook. Include one actionable takeaway.
  4. Edit: Review against my quality checklist. Fix any issues. Verify length is 450-550 words.
  5. Format: Output as HTML ready for [EMAIL PLATFORM]. Include subject line (under 50 characters).

Quality Standards

  • Every claim must include a specific number or example
  • Opening line must create curiosity — never start with "in this newsletter"
  • Tone: conversational, direct, zero filler
  • Reading time: under 3 minutes

你运行一次这个 Skill,就能得到一份完整、精炼的 newsletter。每周如此,质量稳定,无需重新提示。

这就是提示工程和上下文工程的区别:一个是每次都要输入指令,另一个是构建一次系统,永久运行。

§ 10

You do not need to implement all five layers at once. Start with the highest-impact, lowest-effort changes and build from there.

Today (5 minutes):Write your custom instructions. Tell Claude who you are, what you do, how you communicate, and what your default preferences are.

This week (30 minutes):Create a Claude Project for your main workflow. Upload your three most important reference documents as knowledge files.

This month (2 hours total):Build memory actively — tell Claude to remember your preferences during every session. Connect at least two external tools. Create one Skill file for your most repetitive task.

你不必一次性实现全部五层。从影响最大、投入最小的改变开始,逐步积累。

今天(5 分钟):写下你的自定义指令。告诉 Claude 你是谁、做什么、如何沟通,以及你的默认偏好。

本周(30 分钟):为你的主要工作流创建一个 Claude Project。把你最重要的三份参考文档作为知识文件上传。

本月(共 2 小时):主动构建记忆——每次会话都让 Claude 记住你的偏好。连接至少两个外部工具。为最重复的任务创建一个 Skill 文件。

§ 11

By the end of the month you will understand why context engineering is replacing prompt engineering. Not because prompts stopped mattering. But because the environment matters more.

The best prompt in the world typed into a context-less session will always lose to an average prompt typed into a perfectly engineered context.

Most people will keep optimizing their prompts - rearranging words, tweaking phrasing, chasing the "perfect" instruction.

The ones who start engineering their context today will wonder why they ever thought the words were the hard part.

Follow me @eng_khairallah1 for more tools, workflows, and systems. No fluff. Just what works.

hope this was useful for you, Khairallah ❤️

一个月结束时,你会明白为什么上下文工程正在取代提示工程——不是因为提示不再重要,而是因为环境更重要。

世界上最好的提示词,输入到一个没有上下文的会话中,永远敌不过一句中等水平的提示词,输入到一个构建得极为完善的上下文环境里。

大多数人会继续优化他们的提示词——重新排列词语、微调措辞、追逐「完美」指令。

而那些从今天开始构建上下文的人,会纳闷:自己当初怎么会以为词语才是最难的部分。

关注我 @eng_khairallah1,获取更多工具、工作流和系统。不花哨,只分享管用的东西。

希望这对你有用,Khairallah ❤️

打开原文 ↗