从"抽卡"到"搭台"：一文讲透上下文工程（Context Engineering）的底层逻辑

从"抽卡"到"搭台"：一文讲透上下文工程（Context Engineering）的底层逻辑

2023年我们痴迷于写"完美Prompt"，2025年却发现：决定AI输出质量的早已不是那句提示词，而是你为它搭建的整个"上下文世界"。

---

开篇：两个奶茶店老板的故事

假设你是一名大学城附近的奶茶店老板，想让AI帮你设计一款夏季新品。

老板A的做法（传统Prompt）：

帮我设计一款夏季奶茶新品。

AI回复："建议推出珍珠奶茶，深受年轻人喜爱..." ------ 正确的废话，毫无商业价值。

老板B的做法（上下文工程）：

const context = {
    // 我是谁？在什么场景下？为什么要做这件事？
    background: "我是大学附近的奶茶店老板，客户多是17-22岁学生，客单价15-20元",
    // 有哪些限制条件？边界在哪里？
    constraints: "夏季要清爽，成本控制在8元内",
    // 我要什么样的答案？什么格式？什么风格？
    outputRequirements: "要颜值高（适合拍照发朋友圈），请输出JSON格式，包含饮料名、配料、成本、定价"
};

AI返回：

{
  "饮料名": "翡翠青柠冰茶",
  "配料": ["茉莉绿茶底", "新鲜青柠汁", "薄荷糖浆", "脆波波", "青柠片装饰"],
  "成本": "6.8元",
  "定价": "16元",
  "卖点": "透明杯身+绿色渐变分层，ins风拍照神器"
}

同样的AI模型，天壤之别的输出。 区别在哪？

老板A只给了一句"指令"，老板B给了一个"世界"。

这就是我们今天要聊的核心------上下文工程（Context Engineering）。

---

一、先搞清楚：为什么"完美Prompt"也会翻车？

1.1 Prompt Engineering时代的真相

2022-2023年，ChatGPT引爆全球。所有人都在学同一件事------怎么写好Prompt。

那时的AI开发就像抽卡游戏：

设计一套精美Prompt → 期待模型输出好结果 → 翻车 → 改Prompt → 再抽一次...

大家总结了一堆技巧：给AI人设、分步骤指令、Few-shot示例、要求Chain-of-Thought......

有用吗？有用。 可靠吗？不可靠。

📌 知识点①：Prompt Engineering的天花板

Prompt Engineering是在模型能力不变 的前提下，通过调整输入来碰运气。它的本质问题是：LLM是概率模型------同一个Prompt，两次请求可能得到不同答案。这决定了纯Prompt路线天然存在不确定性。

1.2 最致命的真相：LLM不是"查资料"，而是"猜答案"

笔记里有一句很关键的话：

"即使写出最完美的提示词，也可能得不到好结果。为啥？AIGC transformer架构，根据预训练知识预测。"

┌──────────────────────────────────────────┐
│          LLM 的本质：概率预测机器           │
│                                          │
│  输入文字 → 预训练知识库 → 概率计算 → 输出   │
│                                          │
│  ❌ 不是"检索数据库"                       │
│  ❌ 不是"理解并推理"                       │
│  ✅ 是"预测下一个最可能出现的Token"          │
└──────────────────────────────────────────┘

这意味着什么？如果你的问题涉及的领域在训练数据中覆盖不足，无论Prompt写得多好，模型都会"胡说八道" ------这就是幻觉（Hallucination）。

📌 知识点②：幻觉的本质

LLM的幻觉不是bug，是feature。它是概率模型在"知识盲区"中的自然行为------模型不是故意骗你，而是它必须输出下一个Token，只能硬着头皮"编"。这就好比让一个只学过中学物理的人去解量子力学题，他也会硬着头皮写，但写出来的东西基本靠蒙。

---

二、时代变了：为什么现在"简单Prompt"反而效果更好？

2.1 一个反直觉的现象

你有没有注意到：早期用ChatGPT要写几百字的详细Prompt，现在用Cursor/Trae/Claude Code，随口说一句话就能得到惊艳的结果？

笔记里总结了三个原因：

2.2 原因一：LLM本身进化了

2023年的模型：你说"帮我写个登录"，它给你一个<input>标签
2025年的模型：你说"帮我写个登录"，它给你完整的表单+校验+loading+错误处理+响应式

📌 知识点③：LLM的推理能力飞跃

GPT-5、Claude 4.6、Gemini 3这一代模型，核心突破在于推理能力（Reasoning）。早期模型是"你说A它回A"，现在模型是"你说A，它推断出你其实需要A+B+C+D，然后一次性给你"。

2.3 原因二：AI已经被全人类"训练"了三年

OpenAI、Google、Anthropic积累了海量的人类Prompt数据。新模型的背后，你的Prompt不是直接拿去生成的------

你的Prompt → LLM自动优化 → 理解深层意图 → 生成回复

AI已经学会了人类常见的需求模式。你写"写个登录"，它知道99%的用户还需要校验、错误提示、loading态。这不是读心术，这是基于数亿次对话的模式匹配。

2.4 原因三：上下文技术（今天真正的主角）

这才是最核心的进化。现代AI产品（Cursor、Claude Code、Trae）的秘密不在于模型更强，而在于它们在背后默默收集和注入了海量上下文。

2023年：用户Prompt → 模型 → 输出
2025年：用户Prompt + 项目代码 + 开发规范 + 历史对话 + 外部资料 → 模型 → 输出
         ↑___________________上下文工程___________________↑

这就是从 Prompt Engineering 到 Context Engineering 的质变。

---

三、Context Engineering深度拆解：不只是"多写几个字"

3.1 到底什么是上下文工程？

笔记里给了一个精炼的定义：

"上下文工程（Context Engineering）本质不是写一句提示词，而是为AI搭建一个包含'背景、约束、规则'的信息框架，目的是准确、靠谱地完成AI任务。"

拆开来看，三个关键词：

┌────────────────────────────────────────────┐
│           上下文工程的三个支柱                │
│                                            │
│  🎯 背景（Background）                      │
│     → 我是谁？在什么场景下？为什么要做这件事？  │
│     → "奶茶店老板，大学生客户，客单价15-20"   │
│                                            │
│  🚧 约束（Constraints）                     │
│     → 什么能做？什么不能做？边界在哪？         │
│     → "夏季清爽，成本<8元"                   │
│                                            │
│  📐 规则（Rules）                           │
│     → 输出什么格式？什么风格？什么维度？       │
│     → "JSON格式，含配料成本定价，颜值高"      │
└────────────────────────────────────────────┘

📌 知识点④：结构化上下文 vs 自然语言Prompt

自然语言Prompt是线性的："帮我设计夏季奶茶新品，要清爽，成本8元内，颜值高适合拍照，输出JSON..."

结构化上下文是分层 的：每个维度独立维护，互不干扰。当需求变化时（比如季节从夏季变成冬季），你只需改一个字段，而不是重写整段Prompt。这就是工程化思维------可维护、可复用、可扩展。

3.2 奶茶Demo全貌：从代码里读懂上下文工程

import 'dotenv/config';
import OpenAI from 'openai';

const client = new OpenAI({
    apiKey: process.env.DEEPSEEK_API_KEY,
    baseURL: process.env.DEEPSEEK_API_BASE_URL
});

// ═══════════════════════════════════════
// 上下文的结构化设计 ------ 上下文工程的核心
// ═══════════════════════════════════════
const context = {
    // 需求背景：你是谁？做这事的目的
    background: "我是大学附近的奶茶店老板，客户多是17-22岁学生，客单价15-20元",
    // 约束：相关事实、限制条件
    constraints: "夏季要清爽，成本控制在8元内",
    // 输出要求：格式、风格、维度
    outputRequirements: `要颜值高（适合拍照发朋友圈），请输出JSON格式，包含
    饮料名、配料、成本、定价。`
};

// 工程角度：把结构化上下文拼入system prompt
const systemPrompt = `
你是一个专业的饮品研发专家，请根据以下上下文信息完成任务。
【背景】 ${context.background}
【约束】 ${context.constraints}
【要求】 ${context.outputRequirements}
`;

async function generateNewTea() {
    // 容错 ------ 代码工程的重要组成部分
    try {
        console.log(`正在请求大模型，上下文工程已就绪...`);
        const completion = await client.chat.completions.create({
            model: "deepseek-v4-pro",
            messages: [
                { role: "system", content: systemPrompt },  // 上下文在这里注入
                { role: "user", content: "请开始你的研发设计" }
            ],
            temperature: 0.7  // 创造力参数
        });

        const aiResponse = completion.choices[0].message.content;
        console.log("\n AI 研发成果:");
        console.log(aiResponse);

        // 二次容错：校验输出格式
        try {
            const jsonData = JSON.parse(aiResponse);
            console.log("成功解析为JSON对象", jsonData);
        } catch (err) {
            console.log("返回的格式不是JSON，需要重试或调整上下文约束");
        }
    } catch (err) {
        console.error(err.message);
    }
}

generateNewTea();

📌 知识点⑤：容错是上下文工程的一等公民

注意代码中的两层容错 ：外层 try-catch 兜底API调用异常，内层 try-catch 校验输出格式。上下文工程不是"写好上下文就完事了"，AI的输出天然不可靠，你必须在工程层面做好兜底------这就是工程化和"玩玩而已"的分界线。

---

四、RAG：上下文工程的"杀手级应用"

笔记里说："RAG是上下文工程中最高阶的应用场景之一。"为什么？

4.1 LLM的两个致命短板

短板一：知识截止日期
  → 模型训练完成后，不知道之后发生的事

短板二：私有知识盲区
  → 模型不知道你公司的内部数据、业务规则、订单信息

这两个短板，Prompt解决不了------因为问题出在训练数据 层面，不是输入格式层面。

4.2 RAG怎么破局？

RAG = Retrieval-Augmented Generation（检索增强生成）。核心思想就一句话：

"不是直接利用预训练数据回答，在回答前，先去检索一些资料，加到Prompt里面。"

┌──────────────────────────────────────────────┐
│               RAG 工作流程                     │
│                                               │
│  用户问："我的订单怎么还没发货？"                │
│       │                                       │
│       ▼                                       │
│  ┌──────────┐    ┌──────────────────┐         │
│  │ 检索系统  │ ←→ │ 知识库             │         │
│  │          │    │ · 订单数据库       │         │
│  │          │    │ · 物流API         │         │
│  │          │    │ · 售后政策文档     │         │
│  └──────────┘    └──────────────────┘         │
│       │                                       │
│       │ 检索到：订单#1234，已发货，物流单号SF...  │
│       ▼                                       │
│  ┌──────────────────────────────────────┐     │
│  │  增强后的Prompt                        │     │
│  │  【参考资料】订单#1234，物流SF...       │     │
│  │  【用户问题】我的订单怎么还没发货？      │     │
│  └──────────────────────────────────────┘     │
│       │                                       │
│       ▼                                       │
│  ┌──────────┐                                 │
│  │   LLM    │ → "您的订单已于昨天发货，        │
│  └──────────┘    物流单号SF123456，预计明天送达" │
└──────────────────────────────────────────────┘

这就是为什么法律AI能引用真实法条、企业客服能查真实订单------不是模型更聪明，而是上下文更丰富。
📌 知识点⑥：RAG是上下文工程，不是Prompt工程

• Prompt工程：人工在Prompt里写知识 → 上限是你的知识量
• 上下文工程（RAG）：系统自动检索知识注入Prompt → 上限是整个知识库的大小

前者是人脑的延伸，后者是整个企业信息系统的延伸。量级完全不同。

---

五、Cursor和Claude Code：上下文工程的工业化实践

5.1 Cursor：一把"干掉"VSCode的上下文利刃

笔记里有一句很有意思的话："Cursor基于VSCode又干掉了VSCode。"

Cursor的技术底座就是VSCode的开源代码，但它把编辑器变成了一个上下文工程引擎：

传统AI编程工具：
  用户："帮我写个登录接口"
  AI：基于训练数据生成一个通用登录接口
  结果：和你的项目风格完全不一致，改到你崩溃

Cursor：
  用户："帮我写个登录接口"
  Cursor在后台做的事：
    ① 读取项目目录结构，理解技术架构
    ② 扫描已有的路由定义、中间件、数据库模型
    ③ 分析你的代码风格（命名、缩进、注释习惯）
    ④ 理解功能模块之间的依赖关系
    ⑤ 将以上全部作为上下文，生成符合项目规范的代码
  结果：开箱即用，风格统一，仿佛是你自己写的

📌 知识点⑦：代码库即上下文

Cursor的核心壁垒不是编辑器UI，而是将整个代码库工程化为LLM可理解的上下文。"将我们的整个代码库作为上下文（技术架构、代码风格、功能模块...），让它去开发，我们辅助"------这就是上下文工程的工业级实践。

5.2 Claude Code：上下文工程的进化完全体

Claude Code走得更远------它不只是给LLM注入上下文，而是构建了一个完整的Harness系统来驾驭LLM。

笔记里用一个很形象的比喻：

"LLM非常牛逼，Claude 4.6、Gemini 3有如千里马，用上马鞍、缰绳，在指定的环境和场景中才能跑得又快又好。"

---

六、Harness Engineering：进化终局

6.1 三年三级跳

笔记梳理的这条演进路线，是整个AI工程领域最核心的认知：

2022 ─────────── 2023 ─────────── 2024 ─────────── 2025 ─────────── 2026
                                                                     
  Prompt              Context               Harness                  
  Engineering         Engineering           Engineering              
  (提示词工程)         (上下文工程)            (缰绳工程)               
                                                                     
  "写好指令"           "搭好舞台"             "建好系统"               
  依赖人的技巧         依赖信息的质量          依赖工程规则的确定性       
  AI是工具             AI是协作伙伴            AI是自主运行的系统        

6.2 Harness Engineering到底加了什么？

┌─────────────────────────────────────────────────────┐
│                 Harness Engineering 系统              │
│                                                      │
│  📏 Rules（规则）     → "围栏"：什么能做、什么不能做      │
│                        类似传统软件的权限和校验系统       │
│                                                      │
│  🔄 Loop（循环）      → AI自己驱动自己                  │
│                        观察→思考→行动→验证→再观察       │
│                                                      │
│  🛠️ Skills（技能）    → 预定义的领域能力模块             │
│                        code-review、test、deploy...   │
│                                                      │
│  🔌 MCP（协议）       → 标准化的外部工具连接             │
│                        数据库、文件系统、API...         │
│                                                      │
│  📋 CLAUDE.md        → 项目级别的最高行为准则           │
│                        技术栈、架构约定、编码规范...      │
└─────────────────────────────────────────────────────┘

📌 知识点⑧：Harness Engineering的终局意义

笔记说："LLM工程化终于在25-26年成熟了，各个企业都拥抱AI数字化，FDE（AI工程落地工程师）被大量需要。"

FDE的工作不再是"调Prompt"，而是设计整套Harness系统------让千里马（LLM）戴上缰绳，在指定轨道上确定性交付 。这才是AI落地的最终形态：像传统软件工程一样可靠，但能力远超传统软件。

6.3 一张图串起全流程

用户的一句Prompt
    │
    ▼
┌───────────────────────────────────┐
│  LLM 自动优化Prompt                │
│  （AI已内化人类常见需求模式）        │
└───────────────────────────────────┘
    │
    ├──→ 上下文技术注入
    │    ├── RAG（检索增强）
    │    ├── MCP（外部工具连接）
    │    ├── Skills（领域能力模块）
    │    └── 代码库上下文
    │
    ├──→ Transformer 推理生成
    │
    └──→ Harness 工程控制
         ├── Loop（自循环驱动）
         ├── Rules（行为约束）
         └── Skills（能力编排）
              │
              ▼
         ┌──────────┐
         │   FDE    │
         │ AI工程落地 │
         │ 确定性交付 │
         └──────────┘

---

七、三个时代，一张对比表

维度	Prompt Engineering	Context Engineering	Harness Engineering
时期	2022-2023	2024-2025	2025-2026
核心动作	写好指令	搭好舞台	建好系统
依赖什么	人的Prompt技巧	上下文信息的质量	工程规则的确定性
AI角色	被动工具	协作伙伴	自主运行系统
可靠性	低（抽卡）	中（有资料就不瞎编）	高（确定性交付）
代表产品	ChatGPT	Cursor / Trae	Claude Code / Codex
工程师角色	Prompt调校师	上下文设计师	FDE（AI落地工程师）

---

八、核心知识点速查

#	知识点	一句话
①	Prompt的天花板	LLM是概率模型，同一Prompt不同结果，天然不确定
②	幻觉的本质	知识盲区中模型必须"编"出下一个Token，不是bug是feature
③	LLM推理进化	现代模型能"推断出你真正需要什么"，不再只是字面回应
④	结构化上下文	背景/约束/规则分层组织，可维护、可复用、可扩展
⑤	容错是一等公民	AI输出不可靠，工程层面必须做兜底，这是工程化的分界线
⑥	RAG vs Prompt	前者是系统自动检索知识，后者是人工写知识，量级完全不同
⑦	代码库即上下文	Cursor的核心壁垒是将整个代码库工程化为LLM可理解的上下文
⑧	FDE的崛起	2025年后最热门的新兴岗位，设计Harness系统而非调Prompt

---

写在最后

回顾上下文工程的进化，本质上是一个从不确定到确定的过程：

• Prompt Engineering ：你祈祷模型给个好结果------这是玄学
• Context Engineering ：你给模型提供充足的信息------这是科学
• Harness Engineering ：你用规则和系统驾驭模型------这是工程

笔记里有句话说得好：

"小龙虾记忆力不如（token太费），爱马仕（Hermes）。"

Token就是LLM的"记忆力成本"。上下文工程要做的，就是在有限的Token预算内，把最有价值的信息精准地注入Prompt，让模型少瞎猜、多干活。

下次当你在Cursor里随手敲下"帮我实现这个功能"，然后看到它生成了一段完全契合你项目风格的代码时------ 你要知道，幕后的上下文工程已经为你搭好了整个舞台。你只需要说出那句"Action"。

而这，就是AI工程化的魅力。

---

📌 系列文章：

• 想理解Agent的核心架构 → \[掘金文章-从零理解AI-Agent]
• 想搞懂LLM的"无状态"本质 → \[掘金文章-无状态LLM]
• 想深入Tool Use原理 → \[掘金文章-Tool-Use原理与实践]
• 想了解Token与Embedding → \[掘金文章-从Token到Embedding理解LLM是如何理解文字的]

---

本文基于对AI Agent开发的学习与实践整理，Demo代码基于DeepSeek API + OpenAI SDK，可直接运行。如果觉得有帮助，欢迎点赞收藏～有问题评论区交流 🚀