从提示词工程到上下文工程：大模型时代的 AI 工程化演进与落地实践

从提示词工程到上下文工程：大模型时代的 AI 工程化演进与落地实践

• [一、 AI 工程化的演进历程](#一、 AI 工程化的演进历程)
• • [1. 2022--2023 年：提示词工程（Prompt Engineering）](#1. 2022–2023 年：提示词工程（Prompt Engineering）)
  • [2. 2024--2025 年：上下文工程（Context Engineering）](#2. 2024–2025 年：上下文工程（Context Engineering）)
  • [3. 2025--2026 年：马缰工程（Harness Engineering）](#3. 2025–2026 年：马缰工程（Harness Engineering）)
• [二、 什么是上下文工程？](#二、 什么是上下文工程？)
• [三、 项目初始化与环境配置](#三、 项目初始化与环境配置)
• • [1. 初始化项目](#1. 初始化项目)
  • [2. 安装核心依赖](#2. 安装核心依赖)
  • [3. 配置文件 `.env`](#3. 配置文件 .env)
• [四、 核心代码实现与逐行解析](#四、 核心代码实现与逐行解析)
• [五、 代码片段深度剖析](#五、 代码片段深度剖析)
• • [1. 动态加载与环境隔离](#1. 动态加载与环境隔离)
  • [2. 结构化上下文设计（Structured Context）](#2. 结构化上下文设计（Structured Context）)
  • [3. 工程化双层容错机制（Robustness & Handling）](#3. 工程化双层容错机制（Robustness & Handling）)
• [六、 总结](#六、 总结)

在大语言模型（LLM）驱动的技术变革中，如何让 AI 提供稳定、准确且符合业务预期的输出，一直是开发者探索的核心课题。从早期的"盲盒式"提问，到如今工业级的确定性交付，AI 应用开发已经历了多次范式转移。

本文将从 AI 工程化的演进历程出发，深入探讨**上下文工程（Context Engineering）**的核心思想，并结合完整的 Node.js 代码示例，详细剖析如何在实际工程中通过结构化上下文与容错机制实现 AI 的稳定交付。

---

一、 AI 工程化的演进历程

纵观过去几年的技术发展，AI 工程化大致经历了三个主要阶段。每一次演进，本质上都是在试图解决大模型输出的"不确定性"与业务场景所要求的"确定性"之间的矛盾。

1. 2022--2023 年：提示词工程（Prompt Engineering）

在 GPT-3 和 ChatGPT 爆发初期，AI 主要依赖其预训练数据进行文本预测。由于模型缺乏特定业务场景的认知，极易产生"正确的胡说八道"（即生成逻辑通顺但事实错误的文本）。

为了优化输出质量，开发者开始研究提示词工程。这一阶段的特点是：

• 结构繁琐：通常需要在大篇幅的 Prompt 中强行注入角色设定（Role）、详细任务描述（Task）、分步执行指南（Steps）以及少样本示例（Few-Shot）。
• 高不确定性：即使写出极其完美的提示词，由于 Transformer 架构本质上是在预测概率，大模型的输出依然存在明显的随机性，难以直接应用于严谨的工业级交付。

2. 2024--2025 年：上下文工程（Context Engineering）

随着技术的发展，行业意识到：决定 AI 输出质量的关键，不在于指令有多华丽，而在于输入的上下文有多完整。

大模型并不需要直接死记硬背所有领域的知识，而是在回答前，先去检索相关的资料并将其填充到 Prompt 中，以此来消除大模型的"幻觉"。

• 典型应用：Cursor、Trae 等新一代 AI IDE 的兴起。它们之所以能够精准地编写代码，是因为它们将整个代码库（技术架构、代码风格、依赖关系）作为动态上下文喂给了模型。
• 高阶范式：**RAG（检索增强生成）**成为了上下文工程中最核心的应用场景。通过将静态文档、企业知识库转化为向量并按需检索，为 AI 搭建了一个包含"背景与约束"的准确环境。

3. 2025--2026 年：马缰工程（Harness Engineering）

当模型演进至强推理时代，AI 的泛化与理解能力大幅提升。用户不再极度依赖冗长繁琐的 Prompt，因为前置系统会自动对用户的需求进行优化和意图对齐。

当前的焦点转移到了马缰工程（Harness Engineering），即为 AI 戴上"马鞍和缰绳"：

• 围栏机制（Guardrails）：在指定的边界、安全规则和业务闭环（Loop）中约束 AI。
• MCP（模型上下文协议）与 Skills：允许 AI 自主调用外部工具和环境。
• FDE（全栈/全智能体工程师）落地：AI 工程化正式迈向成熟，从"人写 Prompt 提效"转变为"确定性交付的系统工程"。

---

二、 什么是上下文工程？

上下文工程（Context Engineering）本质上不是在写一句简单的提示词（Prompt），而是为 AI 搭建一个包含"背景（Background）"与"约束（Constraints）"的闭环环境，目的是准确、靠谱地完成特定的业务任务。

在通用大模型中，虽然其知识"大而全"，但在面对特定行业（如特定的订单服务、企业内部工作流、私有文档）时，必须通过结构化的思想来补全上下文。构成上下文的数据可以存在于不同的地方（数据库、本地文件、API），并以不同的形式被动态组装。

---

三、 项目初始化与环境配置

在正式编写业务代码前，首先需要搭建 Node.js 开发环境，并安装大模型交互所需的依赖库。

1. 初始化项目

在终端中执行以下命令，快速初始化一个标准的 package.json 文件：

npm init -y

2. 安装核心依赖

接下来，利用 pnpm 安装 openai SDK（用于与大模型交互）以及 dotenv（用于安全管理环境变量）：

pnpm i openai dotenv

3. 配置文件 .env

为了避免将敏感的 API 密钥硬编码在代码中，在项目根目录下创建一个 .env 文件，用于存放环境变量：

DEEPSEEK_API_KEY=your_api_key_here
DEEPSEEK_API_BASE_URL=https://api.deepseek.com/v1

---

四、 核心代码实现与逐行解析

以下是一个完整的上下文工程落地示例。代码模拟了一个奶茶店老板利用大模型研发新品的场景，通过结构化的上下文控制 AI 的输出格式与业务边界。

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

// 1. 实例化大模型客户端
const client = new OpenAI({
  apiKey: process.env.DEEPSEEK_API_KEY,
  baseURL: process.env.DEEPSEEK_API_BASE_URL,
});

// 2. 上下文的结构化思想设计
const context = {
    // 需求背景：明确"你是谁"以及做这件事情的核心目的
    background: "我是大学附近的奶茶店老板,客户多是17-22岁的学生, 客单价15-20元",
    
    // 约束条件：限制相关事实与硬性边界
    constraints: "夏季要清爽, 成本控制在8元内",
    
    // 输出要求：规范返回的数据格式，便于下游工程处理
    outputrequirements: `要颜值高（适合拍照发朋友圈）,
    请输出JSON格式,包含饮料名、配料，成本、定价。
    `
}

// 3. 动态组装 System Prompt（系统提示词框架）
const systemPrompt = `
你是一个专业的饮品研发专家，请根据以下上下文信息完成任务。
【背景】 ${context.background}
【约束】 ${context.constraints}
【输出要求】 ${context.outputrequirements}
`

// 4. 业务核心异步函数
async function gegerateNewTea(){
    // 外部 try-catch：捕获网络请求或大模型服务层面的异常
    try {
        console.log(`正在请求大模型，上下文工程已就绪...`);
        
        // 调用大模型的 Chat Completions API
        const completions = await client.chat.completions.create({
            model: "deepseek-v4-pro", 
            messages: [
                { role: "system", content: systemPrompt },
                { role: "user", content: "请开始你的研发设计" }
            ],
            temperature: 0.7, // 设置适中的创造度
        });
        
        // 提取大模型生成的文本内容
        const aiResponse = completions.choices[0].message.content;
        console.log("\n AI 研发成果：");
        console.log(aiResponse);
        
        // 内部 try-catch：针对返回数据格式的工程化容错
        try {
            const jsonData = JSON.parse(aiResponse);
            console.log("成功解析为JSON对象:", jsonData);
        } catch(err) {
            console.log("返回的格式不是JSON, 无法直接进行下级系统解析。")
        }
        
    } catch(err) {
        // 捕获 API 报错、网络超时或非法鉴权等底层错误
        console.log("请求失败，错误信息:", err.message)
    }
}

// 执行研发函数
gegerateNewTea();

---

五、 代码片段深度剖析

上述代码虽然精简，但在架构上体现了严谨的 AI 工程化思维。以下针对关键片段进行细致解读：

1. 动态加载与环境隔离

import 'dotenv/config'

该行代码在程序启动的最前端执行，会自动读取根目录下的 .env 文件，并将其中的变量注入到 Node.js 的 process.env 中。这保护了诸如 DEEPSEEK_API_KEY 等核心资产的安全，实现了开发环境与生产环境的配置隔离。

2. 结构化上下文设计（Structured Context）

const context = {
    background: "...",
    constraints: "...",
    outputrequirements: "..."
}

这是上下文工程的核心体现。传统的 Prompt Engineering 会把所有话揉成一段密密麻麻的文字。而在这里，上下文被拆解为三个独立的维度：

• background 赋予 AI 业务场景的认知，使其理解受众是"17-22岁的大学生"；
• constraints 锁死了商业边界（成本小于 8 元），防止 AI 天马行空地设计出高成本产品；
• outputrequirements 声明了技术接口的契约（要求 JSON 格式）。
  这种结构化的资产利于维护，后续可以通过程序动态从数据库中读取并拼接。

3. 工程化双层容错机制（Robustness & Handling）

在代码中，使用了两层 try-catch 嵌套块，这是保证软件确定性交付的关键：

• 外层 try-catch 拦截的是网络与调用风险。大模型 API 可能会因为网络抖动、QPS 超限、余额不足等原因报错。外层捕获能防止整个 Node.js 进程崩溃。
• 内层 try-catch 拦截的是内容生成风险 。尽管在 outputrequirements 中强烈要求了"输出 JSON 格式"，打大模型依然有概率夹带 markdown 标记或者输出纯文本。通过 JSON.parse(aiResponse) 进行尝试性解析，并包裹在 try-catch 中，确保了即使 AI "失控"输出了错误格式，程序也能平稳降级，不会导致下游业务逻辑报错。

---

六、 总结

从提示词工程走向上下文工程，标志着 AI 应用开发正在走向工业化与规范化。通过明确的背景注入、刚性的条件约束，以及代码工程层面的多重容错保护，开发者才能够将大模型的概率化输出收敛为可控的、确定性的商业交付。在未来的 AI 落地实践中，深入理解并构建严谨的上下文环境，将是每位软件开发者的必备技能。