上下文工程实战：从 Prompt 到 Harness 的三次 AI 工程化浪潮

上下文工程实战：从 Prompt 到 Harness 的三次 AI 工程化浪潮

本文回顾 AI 工程化的三次浪潮演进------从 Prompt Engineering 的不确定性，到 Context Engineering 的精准补全，再到 Harness Engineering 的确定性交付。结合奶茶研发的实战代码，手把手教你用结构化上下文让 LLM 输出更靠谱。

---

前言

"即使写出最完美的提示词，也可能得不到好结果。"

这是 2022-2023 年每个 Prompt Engineering 实践者的痛。那时我们以为，只要提示词写得足够详细、足够工程化，AI 就能给出完美的答案。但随着 LLM 的演进，我们发现：

• Prompt Engineering 的不确定性太高------同样的 Prompt，每次输出都不一样
• Context Engineering 通过补全上下文，让 AI 更靠谱、更准确
• Harness Engineering 通过规则、围栏、安全机制，实现确定性交付

本文将带你理解这三次浪潮的演进逻辑，并掌握上下文工程的核心实战技巧。

---

一、AI 工程化的三次浪潮

1.1 第一次浪潮：Prompt Engineering（2022-2023）

时代特征：

• ChatGPT 横空出世，GitHub Copilot 引领 AIGC Coding
• 核心思路：通过设计完美的提示词，让 AI 生成高质量内容
• 模型代表：GPT-3.5

痛点：

用户：写一个小红书文案

Prompt 1（简单）："写一个小红书文案"
→ 结果一般，每次都不一样

Prompt 2（工程化）：
  "你是一位拥有100万粉丝的小红书美妆博主，
   写一篇关于口红的文案，标题带数字，
   正文<300字，结尾有行动号召"
→ 结果好一些，但仍然不确定

Prompt 3（极致工程化）：
  身份 + 详细任务 + 分步骤 + 示例 + 格式约束...
→ 质量提升，但"正确地胡说八道"的问题依然存在

核心问题：

问题	原因
不确定性	同样的 Prompt，每次输出不同
幻觉（Hallucination）	AI 基于预训练数据"编造"答案
正确地胡说八道	输出看起来合理，但事实是错的

💡 本质原因：AIGC 基于 Transformer 架构，根据预训练知识预测下一个词。模型不是在"思考"，而是在"接龙"。

1.2 第二次浪潮：Context Engineering（2024-2025）

时代特征：

• LLM 幻觉问题被重视，补全上下文成为关键
• Cursor / Trae / 法律专家 RAG 兴起
• 核心思路：不是直接利用预训练数据回答，而是先检索资料，加到 Prompt 里

核心洞察：

Prompt Engineering：
  用户 Prompt → LLM 直接生成 → 结果不确定

Context Engineering：
  用户 Prompt + 检索资料 + 背景信息 + 约束条件
      → LLM 基于完整上下文生成 → 结果更靠谱

典型应用：

应用	上下文补全方式
Cursor / Trae	将整个代码库作为上下文（技术架构、代码风格、功能模块）
法律专家 RAG	检索法律条文、判例，注入到 Prompt 中
客服机器人	检索产品知识库、订单信息，补充到对话中

💡 关键转变：从"写一句提示词"到"为 AI 搭建一个包含背景、约束、规则的完整上下文"。

1.3 第三次浪潮：Harness Engineering（2025-2026）

时代特征：

• Claude Code、Codex 等 Agent 工具成熟
• 核心思路：给 LLM 装上"马鞍和缰绳"，在指定场景中跑得快又稳
• 目标：类似传统软件的确定性交付

Harness（ harness = 马具/ harness = 利用）的核心组件：

┌─────────────────────────────────────────┐
│         Harness Engineering             │
│              LLM 的"马具"               │
├─────────────────────────────────────────┤
│                                         │
│  规则（Rules）        → 定义行为边界     │
│  围栏（Guardrails）   → 防止越界输出     │
│  安全（Safety）       → 过滤有害内容     │
│  LOOP                → 自迭代优化       │
│  Skills              → 可复用能力模块    │
│  MCP                 → 模型上下文协议    │
│                                         │
└─────────────────────────────────────────┘

类比：

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

工程化成熟标志：

• 25-26 年，LLM 工程化终于成熟
• 各个企业拥抱 AI 数字化
• FDE（Forward Deployed Engineer） 被大量需要

---

二、上下文工程的本质：结构化思想

2.1 上下文不是一句话，而是一个系统

Context Engineering 的本质：

不是写一句提示词（Prompt）
而是为 AI 搭建一个包含"背景、约束、规则"的系统
目的是：准确、靠谱地完成 AI 任务

2.2 上下文的结构化组成

const context = {
  // 1. 需求背景：你是谁？做这事的目的？
  background: "...",

  // 2. 约束条件：相关事实、限制条件
  constraints: "...",

  // 3. 输出要求：格式、风格、标准
  outputRequirements: "..."
};

字段	作用	示例
background	定义角色和场景	"我是大学附近的奶茶店老板，客户多是 17-22 岁学生"
constraints	限制条件和事实	"夏季要清爽，成本控制在 8 元内"
outputRequirements	输出格式和标准	"输出 JSON，包含饮料名、配料、成本、定价"

2.3 上下文的来源

上下文不是固定的，它来自不同的地方、不同的形式：

上下文的来源：
├── 动态资料
│   ├── API 查询结果（订单、库存、天气）
│   ├── 数据库查询（用户信息、历史记录）
│   └── 实时计算（推荐算法、风险评估）
│
├── 静态文档
│   ├── 产品说明书
│   ├── 公司规章制度
│   └── 技术文档
│
└── 系统配置
    ├── 角色设定（system prompt）
    ├── 输出格式（JSON / Markdown）
    └── 安全规则（过滤敏感词）

💡 RAG 是上下文工程中最核心、最高级的应用场景之一 ------它通过检索外部知识库，动态地将相关知识注入到上下文中。

---

三、实战：奶茶研发的上下文工程

3.1 场景定义

场景：奶茶店老板要研发一款夏季新品

需求：
  - 目标客户：17-22 岁大学生
  - 客单价：15-20 元
  - 季节：夏季，要清爽
  - 成本：控制在 8 元内
  - 颜值：适合拍照发朋友圈
  - 输出：JSON 格式（饮料名、配料、成本、定价）

3.2 上下文构建

const context = {
  // 需求背景：你是谁？做这事的目的
  background:
    "我是大学附近的奶茶店老板，客户多是17-22岁学生，客单价15-20元",

  // 约束：相关事实，限制条件
  constraints: "夏季要清爽，成本控制在8元内",

  // 输出要求
  outputRequirements: `要颜值高（适合拍照发朋友圈），请输出JSON格式，包含
  饮料名、配料、成本、定价。`
};

3.3 System Prompt 组装

const systemPrompt = `
你是一个专业的饮品研发专家，请根据以下上下文信息完成任务。
【背景】 ${context.background}
【约束】 ${context.constraints}
【要求】${context.outputRequirements}
`;

组装后的 System Prompt：

你是一个专业的饮品研发专家，请根据以下上下文信息完成任务。
【背景】 我是大学附近的奶茶店老板，客户多是17-22岁学生，客单价15-20元
【约束】 夏季要清爽，成本控制在8元内
【要求】 要颜值高（适合拍照发朋友圈），请输出JSON格式，包含
  饮料名、配料、成本、定价。

3.4 完整代码实现

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

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

// ===== 1. 定义上下文 =====
const context = {
  background:
    "我是大学附近的奶茶店老板，客户多是17-22岁学生，客单价15-20元",
  constraints: "夏季要清爽，成本控制在8元内",
  outputRequirements: `要颜值高（适合拍照发朋友圈），请输出JSON格式，包含
  饮料名、配料、成本、定价。`
};

// ===== 2. 组装 System Prompt =====
const systemPrompt = `
你是一个专业的饮品研发专家，请根据以下上下文信息完成任务。
【背景】 ${context.background}
【约束】 ${context.constraints}
【要求】${context.outputRequirements}
`;

// ===== 3. 调用 LLM =====
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('\nAI 研发成果:');
    console.log(aiResponse);

    // 尝试解析 JSON
    try {
      const jsonData = JSON.parse(aiResponse);
      console.log('成功解析为 JSON 对象:', jsonData);
    } catch (err) {
      console.log('返回的格式不是 JSON，需要后处理');
    }

  } catch (err) {
    console.error('请求失败:', err.message);
  }
}

generateNewTea();

3.5 预期输出示例

{
  "饮料名": "青提茉莉冰沙",
  "配料": ["青提果酱", "茉莉花茶", "冰块", "寒天晶球", "奶盖"],
  "成本": 7.5,
  "定价": 18
}

3.6 代码工程的容错设计

try {
  // 主逻辑：调用 LLM
  const completion = await client.chat.completions.create({...});
  const aiResponse = completion.choices[0].message.content;

  // 内层 try：JSON 解析容错
  try {
    const jsonData = JSON.parse(aiResponse);
    console.log('成功解析为 JSON 对象:', jsonData);
  } catch (err) {
    // JSON 解析失败，但不影响主流程
    console.log('返回的格式不是 JSON，需要后处理');
  }

} catch (err) {
  // 外层 catch：API 调用失败
  console.error('请求失败:', err.message);
}

💡 容错是代码工程的重要部分：LLM 的输出不一定总是完美的 JSON，内层 try-catch 确保即使解析失败，程序也不会崩溃。

---

四、为什么简单的 Prompt 现在也能效果很好？

4.1 三个关键变化

变化	说明
LLM 更强大了	Claude 4.6、Gemini 3 等模型的推理能力大幅提升
海量 Prompt 数据	AI 和人类交互数年，积累了海量 Prompt 数据，模型理解了人类常见需求模式
上下文技术	系统自动优化提示词，注入相关上下文

4.2 现代 LLM 的工作流程

用户输入的简单 Prompt
      │
      ▼
┌─────────────────────────────────────────┐
│         LLM 内部优化                     │
│  · 自动优化提示词                        │
│  · 上下文技术补全                        │
│  · MCP（模型上下文协议）                 │
│  · Skills（可复用能力）                  │
└─────────────────────────────────────────┘
      │
      ▼
Transformer 生成
      │
      ▼
┌─────────────────────────────────────────┐
│         后处理层                         │
│  · Loop Engineering（自迭代优化）        │
│  · Harness Engineering（规则围栏）       │
└─────────────────────────────────────────┘
      │
      ▼
FDE（AI 工程落地）

💡 用户的 Prompt 不是拿去直接生成的 ------ LLM 会在内部自动优化你的提示词，结合上下文技术和各种工程化手段，最终生成高质量输出。

---

五、知识图谱

上下文工程实战
├── AI 工程化三次浪潮
│   ├── Prompt Engineering（2022-2023）
│   │   ├── 详细且准确的指令
│   │   ├── 不确定性高
│   │   └── 正确地胡说八道
│   ├── Context Engineering（2024-2025）
│   │   ├── 补全上下文
│   │   ├── RAG 检索增强
│   │   └── Cursor / Trae 代码库上下文
│   └── Harness Engineering（2025-2026）
│       ├── 规则（Rules）
│       ├── 围栏（Guardrails）
│       ├── 安全（Safety）
│       ├── LOOP / Skills / MCP
│       └── 确定性交付
├── 上下文工程本质
│   ├── 不是写一句 Prompt
│   ├── 而是搭建背景+约束+规则的系统
│   └── 目的：准确、靠谱地完成 AI 任务
├── 上下文结构化组成
│   ├── background（需求背景）
│   ├── constraints（约束条件）
│   └── outputRequirements（输出要求）
├── 上下文的来源
│   ├── 动态资料（API / 数据库 / 实时计算）
│   ├── 静态文档（说明书 / 规章制度）
│   └── 系统配置（角色 / 格式 / 安全）
└── 实战：奶茶研发
    ├── 场景定义
    ├── 上下文构建
    ├── System Prompt 组装
    ├── API 调用（temperature=0.7）
    └── JSON 解析容错

---

六、总结

本文回顾了 AI 工程化的三次浪潮，并实战演示了上下文工程的核心技巧：

1. Prompt Engineering（2022-2023） 的不确定性太高，同样的提示词每次输出不同，存在"正确地胡说八道"的问题。
2. Context Engineering（2024-2025） 的核心是补全上下文------不是直接利用预训练数据回答，而是先检索资料，加到 Prompt 里。RAG 是其最核心、最高级的应用。
3. Harness Engineering（2025-2026） 通过规则、围栏、安全、LOOP、Skills、MCP 等组件，实现类似传统软件的确定性交付。
4. 上下文工程的本质不是写一句提示词，而是为 AI 搭建一个包含"背景、约束、规则"的系统。
5. 上下文结构化组成 ：background（需求背景）+ constraints（约束条件）+ outputRequirements（输出要求）。
6. 现代 LLM 的强大不仅来自模型本身，还来自内部的自动优化、上下文技术、MCP 和 Skills 等工程化手段。

🚀 学习建议：在设计 AI 应用时，先思考"上下文是否完整"------背景是否清晰？约束是否明确？输出要求是否具体？上下文越完整，AI 的输出越靠谱。

---

参考资源

• Cursor 官方文档
• Claude Code 文档
• MCP 模型上下文协议
• RAG 检索增强生成

---

📌 标签：#ContextEngineering #PromptEngineering #HarnessEngineering #AI工程化 #上下文工程 #RAG #LLM #确定性交付

💬 互动：你在使用 AI 时，更倾向于写详细的 Prompt 还是构建完整的上下文系统？欢迎在评论区分享！