从Prompt到Context：大模型应用开发的范式转移作为一名在前线摸爬滚打的FDE（Full-stack Devel - 掘金
作为一名在前线摸爬滚打的FDE（Full-stack Development Engineer），这两年我亲眼见证了大模型应用开发范式的剧变。从2022年底ChatGPT引爆热潮开始，我们经历了“提示
从Prompt到Context：大模型应用开发的范式转移
HjhIron
2026-07-01
208
阅读5分钟
从“写咒语”到“搭舞台”，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更长，而是谁搭建的上下文系统更智能、更懂业务。
与诸君共勉。