从Prompt到Context：大模型应用开发的范式转移作为一名在前线摸爬滚打的FDE（Full-stack Devel

从“写咒语”到“搭舞台”，AI工程化的进化之路

作为一名在前线摸爬滚打的FDE（Full-stack Development Engineer），这两年我亲眼见证了大模型应用开发范式的剧变。从2022年底ChatGPT引爆热潮开始，我们经历了“提示词工程师”被神化的时代，也正在经历“上下文工程”成为行业标配的当下。

最近翻看自己的学习笔记（readme44.md 和 readme45.md），发现了一条清晰的技术演进路线。今天就来和大家聊聊我的理解：上下文工程（Context Engineering）到底是什么？它为什么是LLM工程化成熟的关键？

一、进化简史：三个时代的跨越

1. 2022-2023：Prompt Engineering时代——“正确的胡说八道”

那时候，我们面对的是GPT-3.5这类模型。为了让AI生成像样的代码，我们不得不变成“咒语大师”，在Prompt里塞满身份设定、分步骤指令、Few-shot示例……

痛点：极度依赖提示词的质量，且充满不确定性。你永远不知道它什么时候会开始“正确的胡说八道”，生成看似合理实则荒谬的代码。
场景：ChatGPT、GitHub Copilot初代。我们负责写代码，AI只负责“提效”（偶尔捣乱）。
本质：直接利用预训练数据中的“死知识”进行预测。

2. 2024-2025：Context Engineering时代——“补全上下文”

LLM幻觉问题被放大后，我们意识到：不能只靠AI脑子里的记忆，得让它学会“翻书” 。

于是，RAG（检索增强生成）成了核心技术。在回答前，先从外部知识库检索相关资料，拼接到Prompt里喂给AI。

标志性工具：Cursor / Trae / 法律专家RAG系统。
经典案例：Cursor基于VSCode改造，它之所以强，不只是因为它接入了强模型，更是因为它默认将整个项目代码库作为上下文（技术架构、代码风格、功能模块）。我们辅助它，它主导开发。
本质：这是上下文工程的早期形态——将动态知识注入Prompt。

3. 2025-2026：Harness Engineering时代——“给千里马配马鞍”

Claude Code、Codex等工具出现后，我们发现LLM本身已经进化成了“千里马”（如Claude 4.6、Gemini 3）。

这时候不再需要事无巨细地写Prompt了，而是通过规则（Rules）、围栏（Fences）、循环（Loops）、技能（Skills）和MCP（模型上下文协议） ，为AI划定赛道和方向。

核心理念：像传统软件开发一样，追求确定性交付的工程化。
关键词：Loop Engineer + Harness Engineer = FDE（AI工程落地专家） 。

二、上下文工程的核心认知

在整理笔记 readme45.md 时，我悟出了一句话：

上下文工程(Context Engineering) 的本质不是写一句提示词(prompt)，而是为 AI 搭建一个包含“背景、约束、规则”的舞台，目的是准确、靠谱地完成 AI 任务。

为什么现在的简单Prompt效果更好？

以前我们需要写“论文级”的长Prompt，现在写一句“帮我生成一个奶茶配方”就能得到不错的结果。原因有三：

模型变强了：Transformer架构升级，推理能力跃升。
数据飞轮：AI与人类交互数年，积累了海量高质量Prompt数据。
隐式优化：用户的原始Prompt并不是直接进入Transformer的。现在的LLM服务层会自动优化你的提示词，通过上下文技术、MCP、Skills进行补全。

AI已经比你更懂你想要的提示词长什么样了。

三、实战演练：用上下文工程研发一杯“夏季特饮”

光说不练假把式。我根据笔记里的 index.mjs 案例，跑了一个“奶茶店AI研发”的Demo。

1. 结构化上下文（代码片段）

javascript

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}
`;

2. 调用与容错

在实际开发中，代码工程的容错性至关重要。

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("\n AI研发成果：");
    console.log(aiResponse);

    // 工程化容错：尝试解析JSON
    try {
      const jsonData = JSON.parse(aiResponse);
      console.log("\n 解析后的JSON数据：");
      console.log(jsonData);
    } catch (parseError) {
      console.error("JSON解析错误：", parseError.message);
    }
  } catch (error) {
    console.error("请求大模型失败：", error.message);
  }
}

generateNewTea();

3. 运行结果与思考

这是终端输出的结果，AI完美地给出了符合要求的配方：

json

{
  "饮料名": "荔荔清风冰",
  "配料": {
    "茶底": "茉莉绿茶",
    "水果": ["新鲜荔枝果肉 30g", "青柠片 2片"],
    "小料": "脆波波 30g",
    "顶饰": "薄荷叶 1支",
    "糖浆": "竹蔗冰糖浆 20ml",
    "冰量": "满杯冰"
  },
  "成本": 6.8,
  "定价": 16
}

四、总结：AI工程的未来

站在2026年年中回看，上下文工程已经不再是“高级技巧”，而是准入门槛。

从“教AI做事”到“给AI信息” ：我们不再需要把大模型当成“笨蛋”去手把手教，而是要把它当成“实习生”，给它清晰的目标、明确的约束和充足的参考资料。
RAG是核心：动态检索、MCP协议、Skills机制，都是为了让上下文更丰满。
工程化落地：最终落脚点是确定性。如何让AI的输出稳定可控，如何解析、容错、重试，这才是FDE的价值所在。

未来的AI应用开发，拼的不是谁写的Prompt更长，而是谁搭建的上下文系统更智能、更懂业务。

与诸君共勉。

从Prompt到Context：大模型应用开发的范式转移

一、 进化简史：三个时代的跨越