从"抽卡"到"搭台"：一文讲透上下文工程（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，可直接运行。如果觉得有帮助，欢迎点赞收藏～有问题评论区交流 🚀