从 Prompt 到 Context 再到 Harness：AI 工程化的三年三级跳

从 Prompt 到 Context 再到 Harness：AI 工程化的三年三级跳

你还在苦思冥想那条"完美 Prompt"吗？醒醒，时代变了。

前言

2022 年底 ChatGPT 横空出世，整个技术圈都在研究怎么写好 Prompt。那时候流传着各种"咒语"：你要给 AI 设定身份、分步骤描述任务、提供示例、限定输出格式...

三年过去了，我今天用 Cursor 开发项目，只需要说一句"帮我实现用户登录功能"，它就能精准理解我的技术栈、代码风格、项目结构，输出的代码比我手写的 Prompt 生成的质量还高。

这不是 Prompt 变得不重要了，而是整个游戏规则变了。

让我们回顾一下这三年，AI 工程化到底经历了什么。

---

一、Prompt Engineering 时代（2022-2023）：和 AI 斗智斗勇的蛮荒期

那个年代，我们和 AI 的关系更像是驯兽师和一头聪明但任性的野兽。

核心问题：不确定性

LLM 本质上是一个基于预训练数据的概率预测模型。你给它一个输入，它根据训练时学到的模式来"猜"下一个词应该是什么。

这就导致了一个致命问题：它可能一本正经地胡说八道。

你问它一个冷门的技术问题，它可能自信满满地给你一个完全错误的答案，还附带一堆看似合理的解释。这就是所谓的"幻觉"（Hallucination）。

我们的应对：精心设计 Prompt

当时社区发展出了一套 Prompt Engineering 方法论：

• 角色设定：你是一个资深前端工程师...
• 任务分解：请分三步完成...
• 提供示例：参考以下格式...
• 约束条件：不要使用任何第三方库...

说白了，就是用更精确的指令来减少 AI 的"发挥空间"。

但问题来了

即使你写出了最完美的 Prompt，结果依然可能不尽人意。为什么？

因为你只是在优化输入，但 AI 的知识来源依然是那套预训练数据。你的 Prompt 再精妙，也没法让 AI 了解你公司的业务逻辑、你项目的代码规范、你团队的技术决策。

---

二、Context Engineering 时代（2023-2025）：给 AI 补上"上下文"这一课

核心转变：从"怎么问"到"给 AI 看什么"

2023 年开始，RAG（检索增强生成）技术逐渐成熟。大家意识到一个关键问题：

AI 不是不聪明，而是它不知道你的情况。

就像你去问一个顶级律师法律问题，如果他不了解你的案件细节，给的建议也只能是泛泛而谈。但如果你把完整的案情资料都给他，他就能给出精准的法律意见。

Context Engineering 就是做这件事------在 AI 回答之前，先帮它检索、整理、注入相关的上下文信息。

实践案例：奶茶店 AI 研发助手

说了这么多理论，来点实际的。我用 Node.js + DeepSeek API 做了一个小 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格式，包含饮料名、配料、成本、定价"
}

// 组装系统提示词
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("\nAI 研发成果:");
        console.log(aiResponse);

        // 尝试解析 JSON
        try {
            const jsonData = JSON.parse(aiResponse);
            console.log("成功解析为JSON对象", jsonData);
        } catch (err) {
            console.error("返回的不是JSON格式");
        }
    } catch (err) {
        console.error(err.message);
    }
}

generateNewTea();

看到了吗？这个例子虽然简单，但体现了上下文工程的核心思想：

1. 背景（Background）：告诉 AI 我是谁、目标客群是谁
2. 约束（Constraints）：季节要求、成本限制
3. 输出要求（Output Requirements）：格式、关键要素

不是写一句"帮我设计奶茶配方"就完事了，而是给 AI 搭建一个完整的信息环境。

RAG：上下文工程的高阶形态

上面的 demo 是静态上下文------你手动把信息写死在代码里。但在真实业务场景中，上下文往往是动态的：

• 电商客服需要查询用户的订单状态
• 法律助手需要检索相关案例
• 代码助手需要读取项目的代码库

这就是 RAG（Retrieval-Augmented Generation）的用武之地------在 AI 回答之前，先从知识库中检索相关信息，然后注入到 Prompt 中。

RAG 本质上就是上下文工程中最高效、最高阶的应用场景。

Cursor 们的做法

Cursor、Trae 这类 AI 编程工具，把上下文工程做到了极致：

• 自动读取你的项目结构
• 理解你的技术栈和依赖
• 分析你的代码风格
• 关联相关的文件和函数

所以你不需要写一大段 Prompt 来描述背景，它已经帮你做好了上下文的采集和注入。这也是为什么简单的 Prompt 就能获得比以前更好的效果。

---

三、Harness Engineering 时代（2025-至今）：给千里马套上缰绳

核心问题：LLM 太强了，需要"驯服"

2025 年，Claude 4、Gemini 3 等新一代模型的推理能力已经强到离谱。但问题是：

千里马虽好，没有缰绳和马鞍，你骑不稳。

LLM 工程化终于在 2025-2026 年走向成熟。我们不再只是"使用 AI"，而是把 AI 纳入到确定性的工程体系中。

Harness Engineering 的核心组件

用户 Prompt
    ↓
┌─────────────────────────────────────────────┐
│  LLM 优化后的 Prompt + 上下文技术 + MCP + Skills  │
└─────────────────────────────────────────────┘
    ↓
Transformer 生成
    ↓
┌─────────────────────────────────────────────┐
│     Loop Engineer + Harness Engineer         │
└─────────────────────────────────────────────┘
    ↓
FDE（AI 工程落地）

1. Rules（规则）

给 AI 设定明确的行为边界。不是"请你尽量做到"，而是"你必须遵守"。

2. LLM Fences（围栏）

安全护栏，防止 AI 产生有害输出。类似传统软件中的输入校验和异常处理。

3. Loop（循环）

AI 不是一次性输出就完事了。复杂的任务需要多轮迭代、自我检查、错误修正。

4. Skills（技能）

预定义的能力模块。就像传统软件中的函数库，AI 可以调用特定的技能来完成特定任务。

5. MCP（模型上下文协议）

标准化的上下文注入协议，让 AI 能够以统一的方式获取外部信息。

本质：确定性交付

Harness Engineering 的核心目标是：让 AI 的输出变得可预测、可控制、可信赖。

就像传统软件工程一样，我们需要的是确定性的交付，而不是"看 AI 心情"。

---

四、为什么 Prompt Engineering 没死，但确实没那么重要了？

回到文章开头的问题。为什么现在简单的 Prompt 就能获得很好的效果？

1. 模型本身更强了

Claude 4、Gemini 3 的推理能力已经今非昔比。以前需要详细指导才能完成的任务，现在模型自己就能"悟"出来。

2. 海量的人类交互数据

这几年，AI 和人类进行了数十亿次对话。模型从这些数据中学到了人类常见的需求模式。你说"帮我做个登录页面"，它知道你大概想要什么。

3. 厂商在帮你优化 Prompt

你以为你的 Prompt 是直接发给模型的？太天真了。

OpenAI、Google、Claude 都在中间层做了大量的 Prompt 优化工作。你输入的简单指令，经过系统优化后，变成了模型更容易理解的结构化输入。

4. 上下文技术的成熟

Cursor 们把上下文工程做得足够好，你不需要手动描述背景了。

---

五、写在最后

回顾这三年，AI 工程化经历了三个阶段：

阶段	时间	核心思想	关键词
Prompt Engineering	2022-2023	怎么问 AI	提示词、角色设定、Few-shot
Context Engineering	2023-2025	给 AI 看什么	RAG、知识库、上下文注入
Harness Engineering	2025-至今	怎么管 AI	规则、围栏、循环、技能

上下文工程（Context Engineering）的本质，不是写一句提示词，而是为 AI 搭建一个包含背景、约束、目的的信息环境，让它能够准确、靠谱地完成任务。

而我们这些开发者，正在从"AI 的使用者"变成"AI 的架构师"。

2025-2026 年，各个企业都在拥抱 AI 数字化转型，FDE（AI 工程落地）人才被大量需要。如果你还在研究怎么写好 Prompt，不妨抬头看看------

更大的世界，已经在 Harness Engineering 这一层了。