What is context engineering and why does it matter for developers?

Context engineering is the skill of deliberately designing the information you provide to an AI — its role, background state, task, constraints, and output format — so it produces useful results without back-and-forth. It matters because the quality of AI output is almost entirely determined by the quality of input: vague, thin context produces generic, off-target answers, while rich, structured context produces specific, actionable ones. Most developers underestimate this and focus on rephrasing prompts instead.

What is the difference between context engineering and prompt engineering?

Prompt engineering is about word choice — how to phrase a request so the model interprets it correctly. Context engineering is a level deeper: it's about what information you make available before the model generates anything. You can have a perfectly phrased prompt and still get a poor answer because the model lacks background, state, or constraints. Context engineering addresses the information architecture; prompt engineering addresses the wording within it.

What are the five pillars of great context?

The five pillars are: (1) Role — who the model should be (persona, expertise, audience perspective); (2) State — what already exists, what's been tried, what constraints apply; (3) Task — exactly what you want done, not a vague category; (4) Constraints — what to avoid, scope limits, hard rules; (5) Format — the shape of the output (length, structure, level of detail). Addressing all five reduces back-and-forth dramatically and improves first-draft quality.

How do I build a reusable context template?

Structure your template around the five pillars: Role (who the model is and for whom), Background State (tech stack, what exists, what's been tried), Task (one precise sentence), Constraints (explicit negatives: what not to do), and Output Format (length, structure, detail level). You don't need to fill in every field every time — for a simple lookup, role + task + format is enough. For complex debugging or code review, all five matter. The template is a scaffold, not a form.

What does 'token budget' mean in context engineering?

Every interaction with an AI happens inside a context window with a fixed size measured in tokens. Everything you include — the system prompt, pasted code, conversation history, your question — competes for space in that window. Token budget management means being selective about what you include: paste specific functions rather than whole files, strip boilerplate from pasted code, summarize conversation history after long sessions, and put standing instructions in the system prompt rather than repeating them per-message. Irrelevant content isn't neutral — it's noise the model has to reason through.

上下文工程：区分优秀 AI 用户与普通用户的关键技能

大多数 AI 结果令人失望，不是因为模型不好，而是因为上下文太薄。上下文工程实用指南——模型窗口中有什么、优质上下文的五大支柱、常见反模式，以及能持续产出更好结果的可复用模板。

作者：Nguyen Le Phong2026年5月31日15 分钟阅读

AI
上下文工程
提示词工程
LLM
开发者生产力
AI 工具

你一定有过这种感受。你输入了一个看似清晰的问题，AI 给出的回答却……偏差了。技术上相关，但没抓住重点。于是你换个方式重问，再试一次，又得到一个稍微偏差的答案。五轮对话后终于得到有用的东西——但耗时比自己动手还长。

实际发生的是：模型只能根据你放在它面前的内容来工作。它不知道你的代码库是什么样子，不了解你的约束条件，看不到你已经尝试过什么，也不明白你为什么要问。当 AI 回答跑偏时，根本原因几乎总是信息不足——而非措辞不当或缺少"咒语式"技巧。这就是 AI 社区所称的上下文工程的核心所在。

定义

上下文工程是一种技能：有意识地设计提供给 AI 的信息——角色、背景状态、任务、约束条件和输出格式——使其无需反复对话便能产出真正有用的结果。

上下文工程究竟是什么

2025 年，Andrej Karpathy 推广了这个术语。与"提示词工程"的区别至关重要：提示词工程关注的是措辞选择；上下文工程深入一层，关注的是在模型生成任何内容之前，你提供了哪些信息。

可以把它想象成米其林式准备（mise en place）——厨师在开始烹饪前备齐所有食材的习惯。优秀的厨师不会在烹饪中途因缺少食材而即兴发挥。上下文工程就是为你的 AI 协作者做好这种准备工作。

上下文窗口的解剖

与 AI 的每次交互都发生在一个"上下文窗口"这一固定工作内存中，它包含模型在生成回复时能"看到"的所有内容，分为四个层次。

上下文窗口的四个层次。大多数人只关注第 4 层（用户消息），但最强大、最常被忽视的是前两层。

系统提示词是最强大却最容易被忽略的层。它设定了模型的角色、专业水平以及每次回复都遵循的规则。

注入上下文是你提供原材料的地方：代码文件、文档、错误日志、数据库架构。模型在此基础上进行推理。

对话历史随着会话的推进而累积，有用但也消耗 token。

用户消息是实际的问题或任务。尽管是大家最关注的部分，在设计良好的配置中它通常只占总 token 的 5% 以下。

优质上下文的五大支柱

五大支柱。第 3 支柱（任务）获得了最多关注，但正是其他四个支柱让任务能够被很好地回答。

支柱 1：角色（Role）

定义模型应该扮演什么角色——专业知识、视角、沟通风格。

无角色	有角色
`解释一下认证。`	`你是一位专注于安全的高级后端工程师，正在为一名了解 JavaScript 但从未实现过 auth 的初级开发者写作。解释 JWT，重点关注安全权衡和可能出现的问题。`

支柱 2：状态（State）

告诉模型当前的情况——代码库结构、已尝试的内容、不起作用的内容、已做出的决定。

无状态	有状态
`修复这个 bug。` （仅粘贴代码）	`[代码] 这个 debounce 函数在普通输入时正常，但在快速滚动时立即触发而非等待。已尝试在开头添加 clearTimeout，仍然触发。Stack: React 18, TypeScript。控制台错误：[消息]。`

支柱 3：任务（Task）

精确指定你想要什么，而不是一个类别。"帮我处理 API"是类别。"写一个 Express 中间件，验证 JWT token，无效或缺失时返回 401，并将解码后的用户附加到 req.user"是任务。

支柱 4：约束（Constraints）

告诉模型不能做什么、应该避免什么。约束听起来像限制，但实际上解放了回答——它消除了整类"技术正确但对我的情况无用"的答案。

约束的写法

用明确的"不要"或"避免"陈述来书写约束。模型被训练为尽可能有帮助，会自然地扩大范围。明确的否定是最可靠的护栏。

支柱 5：格式（Format）

指定输出的形态：长度、结构、详细程度。没有格式指导，你得到的是模型认为合适的内容——可能是你想要简洁要点时给了 500 字的论述。

构建可复用的上下文模板

## 角色
你是 [角色]，专注于 [领域]。
目标受众是 [受众] 的 [关键背景]。

## 背景状态
技术栈：[语言 / 框架 / 工具]
当前情况：[简短描述]
已尝试：[尝试和结果]
相关错误：[如有]

## 任务
[精确的一句话：动词 + 对象 + 范围]

## 约束
- 不要使用 [库 / 方法]
- 将 [方面] 控制在 [限制] 以内

## 输出格式
[长度] — [结构] — [详细程度]

核心要点

上下文工程 > 提示词工程：你提供的信息比你的措辞更重要。更好的输入 = 更好的输出。
四个层次，一个预算：系统提示词、注入上下文、对话历史、用户消息——各有不同用途，共享同一个 token 预算。
五大支柱，五个缺口：角色、状态、任务、约束、格式。覆盖全部五项，反复对话的次数会显著减少。
质量胜于数量：相关、聚焦、结构化的上下文始终优于大量无焦点的内容堆砌。

你觉得这篇文章如何？

常见问题

What is context engineering and why does it matter for developers?: Context engineering is the skill of deliberately designing the information you provide to an AI — its role, background state, task, constraints, and output format — so it produces useful results without back-and-forth. It matters because the quality of AI output is almost entirely determined by the quality of input: vague, thin context produces generic, off-target answers, while rich, structured context produces specific, actionable ones. Most developers underestimate this and focus on rephrasing prompts instead.
What is the difference between context engineering and prompt engineering?: Prompt engineering is about word choice — how to phrase a request so the model interprets it correctly. Context engineering is a level deeper: it's about what information you make available before the model generates anything. You can have a perfectly phrased prompt and still get a poor answer because the model lacks background, state, or constraints. Context engineering addresses the information architecture; prompt engineering addresses the wording within it.
What are the five pillars of great context?: The five pillars are: (1) Role — who the model should be (persona, expertise, audience perspective); (2) State — what already exists, what's been tried, what constraints apply; (3) Task — exactly what you want done, not a vague category; (4) Constraints — what to avoid, scope limits, hard rules; (5) Format — the shape of the output (length, structure, level of detail). Addressing all five reduces back-and-forth dramatically and improves first-draft quality.
How do I build a reusable context template?: Structure your template around the five pillars: Role (who the model is and for whom), Background State (tech stack, what exists, what's been tried), Task (one precise sentence), Constraints (explicit negatives: what not to do), and Output Format (length, structure, detail level). You don't need to fill in every field every time — for a simple lookup, role + task + format is enough. For complex debugging or code review, all five matter. The template is a scaffold, not a form.
What does 'token budget' mean in context engineering?: Every interaction with an AI happens inside a context window with a fixed size measured in tokens. Everything you include — the system prompt, pasted code, conversation history, your question — competes for space in that window. Token budget management means being selective about what you include: paste specific functions rather than whole files, strip boilerplate from pasted code, summarize conversation history after long sessions, and put standing instructions in the system prompt rather than repeating them per-message. Irrelevant content isn't neutral — it's noise the model has to reason through.