个人知识库

2026-07-05-juejin-context-engineering-harness

15分钟阅读

提示词彻底过时？一套上下文工程方案，3步让LLM落地生产

这篇掘金教程用“奶茶店饮品研发 AI”的 Node.js 示例，把 LLM 工程化从 Prompt Engineering、Context Engineering 到 Harness Engineering 的三阶段演进讲清楚：单靠提示词只能约束一次输出，结构化上下文能把业务背景、硬性约束和输出格式拆成可维护对象，而真正上线还要补上 JSON 校验、Loop 重试、RAG/MCP 工具能力和安全围栏。

基本信息

核心观点

1. LLM 工程化正在从“写更长提示词”转向“管理可复用上下文”

文章把 2022-2023 年的 提示词工程 定位为第一阶段：靠人工堆砌详尽指令、示例和步骤来约束模型输出。这种方式上手简单，但痛点是提示词越长越难维护，换一个模型容易跑偏，模型仍会幻觉，而且脱离业务本地数据。作者特别强调，LLM 基于 Transformer 做文本预测，如果没有实时、专属业务上下文支撑，所谓“完美提示词”依旧容易翻车。

第二阶段是 2024-2025 年的 上下文工程：不再把全部要求揉进一段自然语言，而是提前结构化注入三类上下文——业务背景、硬性约束、静态资料。它的直接收益是日常 Prompt 可以变短，业务文档和代码库可以被模型看见，输出更贴合真实业务，幻觉也会下降。

2. 上下文工程的最小可运行形态是把 context 对象拆成 background / constraints / outputRequirements

文章给出的 Node.js 示例并没有先写一段几千字 Prompt，而是先定义一个 context 对象：

  • background：大学附近奶茶店老板、客户多是 17-22 岁学生、客单价 15-20 元；
  • constraints：夏季清爽、成本控制在 8 元内；
  • outputRequirements：颜值高、适合拍照发朋友圈、输出纯 JSON，包含饮料名、配料、成本、定价。

系统提示词再把这些字段按【业务背景】【硬性约束】【输出强制要求】拼接。这个拆法的价值不在“看起来更工程化”，而在维护边界清楚：后续如果成本从 8 元改成 10 元，只改 constraints；如果后台导入格式变化，只改 outputRequirements，不必重写一整段散文式提示词。

3. JSON 输出不是“要求模型输出 JSON”就完事，必须做格式容错

示例代码在模型返回后立即执行 JSON.parse(aiResponse)，并用内层 try/catch 捕获格式异常。作者指出，大模型偶尔会在 JSON 前后附带解释文字、Markdown 代码块或多余说明，直接解析会导致线上流程崩溃。因此工程化的第一层闭环不是“相信模型听话”，而是对输出做机器可判定校验；解析失败时应进入 Loop Engineering 循环重生成或修复，而不是把错误传到业务系统。

这条观点和现有知识库里“执行者和验证者必须分开”“无证据不算完成”的 Agent 工程观点一致：模型负责生成，程序或独立评估器负责验收。

4. Harness Engineering 是从“能生成”到“能上线”的企业级落地层

文章把 2025-2026 年的成熟企业方案称为 Harness Engineering 闭环落地工程，链路是：

用户简易 Prompt → LLM 自动优化提示词 + 注入上下文 + 加载 MCP 技能 → 模型生成内容 → Loop 循环校验 + 安全围栏 Harness 约束 → 标准化工程落地 FDE

这里的关键不是新名词，而是补齐生产约束：

  • Loop Engineering：发现 JSON 格式错误、成本超限、输出不合规后自动重试或修正；
  • 安全围栏：限制违规输出、越权工具调用、成本超标和偏离业务目标；
  • MCP 模型上下文协议：把工具调用、数据查询、外部能力标准化接入；
  • FDE/工程交付：把 AI 结果嵌入实际业务系统，而不是停留在“看起来不错”的回答。

5. 企业 AI 项目不能停在通用模型，必须注入本地业务资料

文章列出“只用通用大模型，不注入本地业务资料”是四个高频坑之一。通用模型的预训练数据滞后，不懂企业内部代码、业务规则和产品资料，容易生成看似合理但不符合实际的内容。正确做法是搭配 RAG 知识库 检索本地文档、代码库和业务规则作为补充上下文。

这与企业 AI 落地主题中的既有共识一致：AI 项目不是“换一个更强模型”，而是先治理数据、规则、文档和流程，把业务现场变成模型可用的上下文供给侧。

实操内容保留

代码/配置：Node.js 上下文工程示例

原文给出可运行的 Node.js 示例，使用 dotenv 和 openai SDK，DeepSeek 通过 OpenAI 兼容接口调用：

javascript 代码解读复制代码import 'dotenv/config';
import OpenAI from 'openai';
 
// 初始化大模型客户端，兼容DeepSeek、OpenAI、Claude
const client = new OpenAI({
    apiKey: process.env.DEEPSEEK_API_KEY,
    baseURL: process.env.DEEPSEEK_BASE_URL
});
 
// 【上下文工程核心】结构化拆分上下文，解耦易维护
const context = {
    // 背景：身份、场景、用户画像
    background: "我是大学附近的奶茶店老板，客户多是17-22岁学生， 客单价15-20元",
    // 硬性约束：成本、季节、限制条件
    constraints: "夏季要清爽， 成本控制在8元内 ",
    // 输出规范：统一格式，避免解析报错
    outputRequirements: `要颜值高（适合拍照发朋友圈）, 请输出纯JSON，无多余文字，包含
    饮料名、配料、成本、定价。
    `
}
 
// 系统提示词统一拼接结构化上下文，可读性拉满
const systemPrompt = `
你是一个专业的饮品研发专家，请严格依据下方上下文完成新品研发。
【业务背景】 ${context.background}
【硬性约束】 ${context.constraints}
【输出强制要求】${context.outputRequirements}
`
 
// 封装生成函数，增加双重容错（网络异常+JSON格式异常）
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("✅ 成功解析为JSON 对象", jsonData);
        } catch(err) {
            console.log("❌ 返回内容非标准JSON，需开启Loop循环重生成");
        }
    } catch(err) {
        // 第二层容错：捕获接口超时、密钥错误、服务限流等网络异常
        console.error("大模型接口请求失败：", err.message);
    }
}
 
// 执行函数
generateNewTea();

环境配置

env 代码解读复制代码DEEPSEEK_API_KEY=你的密钥
DEEPSEEK_BASE_URL=https://api.deepseek.com/v1

运行步骤

  1. 安装依赖：npm i dotenv openai
  2. 填充密钥后执行：node index.js
  3. 模型会结合奶茶店场景、成本约束输出标准化 JSON
  4. 后续修改需求只改 context 对象，不需要重写大段提示词

四个高频踩坑与修复方式

坑典型错误正确做法
上下文杂乱把背景、约束、格式混在一句话里拆成 background / constraints / outputRequirements，分段标注
忽略格式容错直接 JSON.parse 模型输出先 try/catch 捕获格式异常，再接 Loop 重试
不注入本地资料只用通用大模型回答企业规则用 RAG 检索本地文档、代码库、业务规则补充上下文
缺少 Harness 安全约束生成后不校验成本、格式、合规性增加校验循环、成本检查、合规检查和不合格重生成

关键概念

  • 提示词工程：早期阶段，重点是把单次指令写清楚，但维护性、幻觉控制和业务数据接入都有限。
  • 上下文工程：把业务背景、约束、静态资料和输出格式结构化管理，让短 Prompt 也能利用稳定上下文。
  • Harness闭环工程：在上下文工程之上加入 Loop 校验、安全围栏、MCP 技能和工程交付，把 LLM 输出接入生产系统。
  • Loop Engineering：承担格式错误、成本超限、合规失败后的自动重试与修复。
  • RAG 知识库：为模型注入企业内部文档、代码和规则，避免通用模型脱离业务现场。
  • MCP 模型上下文协议：把工具调用、数据查询和外部能力标准化，成为 Harness 链路中的技能加载层。

与其他素材的关联

原文精彩摘录

前两年全网都在卷Prompt Engineering提示词工程，所有人都在抠完美指令。 但2024-2026行业早就迭代到 上下文工程 Context Engineering ，再进阶到Harness工程闭环落地。

当下成熟企业AI数字化标准方案，完整链路： 用户简易Prompt → LLM自动优化提示词+注入上下文+加载MCP技能 → 模型生成内容 → 循环校验Loop + 安全围栏Harness约束 → 标准化工程落地FDE 配套能力：LLM安全围栏、Loop循环校验、MCP标准化技能。

很多新手把背景、约束、格式混在一段文字里，模型识别优先级混乱。 ✅ 正确做法：拆分background/constraints/outputRequirements，分段标注，层级清晰。

大模型偶尔会附带解释文字、markdown代码块，直接解析必报错。 ✅ 正确做法：增加try-catch捕获格式异常，搭配Loop工程自动重试生成。

相关页面

关系图谱

快速导航

反向链接