⭐ 从写 Prompt 到搭上下文：AI 终于不再对我"正确的胡说八道"了

写在前面：今天老师带我们从"提示词工程"进化到了"上下文工程"。以前我用 ChatGPT，写一大段精心设计的 Prompt，结果它还是经常"一本正经地胡说八道"。老师说：那是因为你只给了它"任务"，没给它"背景"和"约束"。就像你让一个人做菜，只告诉他"做一道菜"，和告诉他"我是江西人、很吃辣、预算 20 块"------出来的结果完全不一样。

一、AI 工程化的三次进化：从抽卡到 Harness

1.1 22-23 年：Prompt Engineering------"抽卡时代"

老师说：

"22-23 年 Prompt Engineering，不确定性，正确的胡说八道。"

那时候我们用 ChatGPT、GitHub Copilot，拼命研究怎么写 Prompt。

"你是一个资深前端工程师......"
"请分步骤回答......"
"以下是示例......"

写了一大段，结果 AI 还是可能胡说八道。 就像抽卡------prompt 写得好，只是提高了"抽到好答案"的概率。

老师说：

"AIGC 基于预训练数据的一部分，通过设计完美的提示词，升级到工程化的级别。"

但问题是------即使写出最完美的提示词，也可能得不到好结果。

1.2 24-25 年：Context Engineering------"补课时代"

老师说：

"24-25 年 Context Engineering，LLM 幻觉。补全上下文，上下文工程，更靠谱、更准确。"

Context Engineering 的核心思想：不是直接利用预训练回答，而是在回答之前，先去检索一些资料，加到 prompt 里面。

阶段	核心	解决的问题
Prompt Engineering	写好提示词	输出质量不确定
Context Engineering	补全上下文	LLM 幻觉、知识不足

老师说：

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

RAG（检索增强生成）就是 Context Engineering 最常见、最高阶的实现方式。

"Cursor / Trae / 法律专家 RAG。Cursor 基于 VSCode，又干掉了 VSCode。将我们整个代码库作为上下文（技术架构、代码风格、功能模块......）让它去开发，我们辅助。"

Cursor 为什么比 ChatGPT 写代码强？因为它把整个项目代码库作为上下文，AI 知道你的技术栈、代码风格、依赖关系------而不是凭空乱写。

1.3 25-26 年：Harness Engineering------"驯马时代"

老师说：

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

Harness（马具）= 规则 + 围栏 + 安全 + 可靠 + Loop + Skills + MCP。

老师说：

"类似传统软件确定性交付的工程化。LLM 工程化终于在 25-26 年成熟了，各个企业都拥抱 AI 数字化，FDE 被大量需要。"

从"抽卡"到"补课"再到"驯马"，AI 工程化终于成熟了。

二、为什么 Prompt Engineering 不够用了？

2.1 LLM 进化了，不需要你"手把手教"

老师说了一个关键变化：

"早期需要详细且准确的指令，现在随着 AI 的发展，没有那么依赖了。"

以前的 GPT-3.5：

你需要写超长超详细的 Prompt。
"身份 + 详细准确的任务 + 分步骤 + 例子......"
长且工程化设计的 Prompt，才能提升生成代码的质量。

现在的 Claude 4.6 / Gemini 3 / GPT-5：

简单的 prompt 就可以完成之前复杂 prompt 还要好的结果。
为什么？

老师说：

"LLM 更强大了，推理能力更强。AI 和人类已经交互了数年，积累了海量 Prompt 数据。OpenAI、Google、Claude，新的强大模型，用户的 prompt 不是拿去直接生成的，LLM 会自动优化你的提示词，AI 已经理解了人类常见的需求模式。"

现在的 LLM 会自动"脑补"你的需求，不需要你写几百字的 Prompt 了。

2.2 那为什么还需要上下文工程？

因为 LLM 再聪明，也有两个致命弱点：

知识截止到训练时间点------它不知道你公司的内部文档、最新数据。
不知道你的具体场景------它是通用模型，不是你的私人助理。

Context Engineering 解决的就是这两个问题。

三、上下文工程实战：给 AI 一个"人设"+"场景"+"约束"

3.1 上下文结构化的思想

老师说：

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

看代码：

javascript 复制代码

const context = {
    // 需求背景：你是谁？做这事的目的
    background: 
        '我是大学附近的奶茶店老板，客户多是 17-22 岁学生，客单价 15-20 元',
    // 约束
    constraints: "夏季要清爽，成本控制在 8 元内",
    outputRequirements: `要颜值高（适合拍照发朋友圈），请输出 JSON 格式，包含饮料名、配料、成本、定价。`
}

上下文框架三要素：

字段	作用	比喻
background	需求背景，你是谁、做什么	告诉厨师你的餐厅定位
constraints	约束条件，限制和边界	告诉厨师预算和口味偏好
outputRequirements	输出要求，格式和规范	告诉厨师菜要摆什么盘

3.2 拼接成 systemPrompt

javascript 复制代码

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

把上下文结构化成 systemPrompt，比直接丢给 AI 一句"帮我设计一款奶茶"靠谱得多。

这就像：

普通 Prompt："帮我做道菜。" → 厨师可能给你做一道佛跳墙，但你只想吃碗面。
Context Engineering："我是开面馆的，顾客是上班族，预算 15 块，要快、要饱腹、不要辣。" → 厨师给你做一碗红烧牛肉面，完美匹配。

3.3 调用 DeepSeek 生成结果

javascript 复制代码

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(`\n成功解析 JSON 对象：`, jsonData);
        } catch (err) {
            console.log(`返回的格式不是 JSON`);
        }
    } catch (err) {
        console.error(err.message);
    }
}

generateNewTea();

注意 temperature: 0.7：

temperature	效果	适用场景
0.0-0.3	保守、确定性高	代码生成、数据分析
0.5-0.7	平衡、有创造性	文案创作、产品设计
0.8-1.0	发散、创意强	头脑风暴、故事创作

设计奶茶需要创意，所以用 0.7。

3.4 容错处理：代码工程的重要部分

老师说：

"容错，代码工程的重要部分。"

代码里有两层 try-catch：

外层：捕获 API 调用失败（网络问题、Key 失效等）。
内层：捕获 JSON 解析失败（AI 返回的不是标准 JSON）。

AI 返回的内容不一定 100% 符合预期，代码必须有容错能力。

这就像你请别人帮忙做事：

他可能不来（API 失败）。
他可能来了但做得不对（格式不对）。
你都得有应对方案。

四、用户的 prompt 去哪了？被 LLM "优化"了

老师说了一个特别有意思的现象：

"用户的 prompt 不是拿去直接生成的，LLM 会自动优化你的提示词。"

你以为你输入的是：

arduino 复制代码

"帮我设计一款奶茶"

实际上 LLM 内部处理的是：

arduino 复制代码

"用户是一个奶茶店老板，需要设计一款适合大学生、成本 8 元以内、
夏季清爽的奶茶，要求颜值高适合发朋友圈，输出 JSON 格式......"

LLM 会自动根据上下文补全、优化你的提示词。 这就是为什么简单的 prompt，在 Cursor/Trae/Claude Code 里也能有很好的效果。

老师说：

"用户 prompt -> (LLM 优化后的 prompt、上下文技术、MCP、Skills) -> Transformer 生成 -> Loop Engineer + Harness Engineer -> FDE（AI 工程落地）"

你的 prompt 只是入口，真正驱动 AI 的是一整套工程化的上下文系统。

五、总结：上下文工程，是 AI 落地的"地基"

阶段	年代	核心	解决的问题
Prompt Engineering	22-23	写好提示词	输出质量
Context Engineering	24-25	补全上下文	幻觉、知识不足
Harness Engineering	25-26	规则+围栏+Loop	确定性交付

上下文要素	作用
background	需求背景，告诉 AI 你是谁、做什么
constraints	约束条件，划定边界
outputRequirements	输出要求，规定格式和规范
temperature	控制创造性
容错处理	应对 AI 的不确定性

Context Engineering 的本质：不是写一句完美的提示词，而是搭建一个完整的上下文框架，让 AI 在正确的背景、约束和要求下，给出靠谱的答案。

写在最后

今天最大的收获，是理解了"上下文工程"的思维方式。以前写 Prompt 像是在"抽卡"------写一大段，祈祷 AI 给个好答案。现在知道了，要给 AI 足够的背景、约束和要求，让它在正确的框架内工作。AI 不是魔法，它需要一个清晰的"工作说明书"。

下次面试官问你："什么是 Context Engineering？和 Prompt Engineering 有什么区别？"

你可以淡定地说：

"Prompt Engineering 是 22-23 年的范式，核心是通过精心设计的提示词来提升输出质量，但结果不确定，容易出现幻觉。Context Engineering 是 24-25 年的升级，核心是给 LLM 补全上下文------包括背景信息、约束条件和输出要求，让 AI 在正确的框架内工作。RAG 就是 Context Engineering 的典型实现。现在的 LLM 更强大了，会自动优化用户的 prompt，但上下文工程仍然至关重要，因为它解决了 LLM 知识截止和场景缺失的问题。"

然后看着面试官满意的表情，心里默念：这波，又稳了。

本文所有代码示例均来自课堂学习资料，真实可运行。