AI工程化 03：给模型喂上下文

给模型喂上下文：从一段代码说起

一个奶茶店老板的 AI 需求

假设你在大学附近开了一家奶茶店。你的客人大多是 17 到 22 岁的学生，每杯饮品卖 15 到 20 块钱。夏天到了，你想让 AI 帮你设计一款新品。

你直接问大模型"给我设计一款奶茶"，它可能会给你一个四平八稳的答案------比如"珍珠奶茶，红茶底，加奶精"。这个答案没错，但它不知道你的客人喜欢什么，不知道你的成本压力，也不知道你需要一个能在小红书和朋友圈传播的产品。

这就是上下文注入的起点：你需要告诉大模型那些它不知道的事情。

注：本文聚焦于"上下文注入"这个核心环节------也就是"把什么信息塞进 prompt、怎么塞"。"上下文工程"作为一个更大的领域，还包括窗口管理、信息检索、上下文压缩、路由和评估等，本文会在最后简要提及。

把信息组织成三个部分

在这段代码里，上下文被拆成了三个字段：

javascript

js 复制代码

const context = {
    background: "我是大学附近的奶茶店老板,客户多是17-22岁学生,客单价15-20元",
    constraints: "夏季要清爽，成本控制在8元内",
    outputRequirements: "要颜值高(适合拍照发朋友圈)，请输出JSON格式，包含饮料名、配料、成本、定价。"
}

背景（background） 回答三个问题：你是谁，你的用户是谁，场景是什么。大学附近的奶茶店，这个信息会直接影响 AI 的建议方向------它可能推荐更年轻化的口味、更有话题性的配料搭配，而不是商务区咖啡馆里的那套思路。

约束（constraints） 划定边界。成本控制在 8 元以内，意味着 AI 不能推荐榴莲、车厘子这种高价原料。夏季清爽这个条件，排除了厚重的奶盖和热饮。约束条件越清楚，AI 给出的方案就越可用。

输出要求（outputRequirements） 定义你想要的交付物。格式是 JSON，字段包括饮料名、配料、成本、定价。还有一个重要的质量要求------"颜值高，适合拍照发朋友圈"。这句话直接关联到产品的社交传播属性，对于以年轻学生为主的客群，这个要求很关键。

三个字段各司其职：背景设定场景，约束划定边界，输出要求定义交付标准。

这里有一点值得留意：outputRequirements 里混合了两种不同性质的要求------"输出 JSON 格式"是硬约束，做不到就是失败；"颜值高"是软目标，能做到最好，做不到也不至于完全不可用。在实际开发中，可以考虑把两者分开标注，比如加上"必须"和"尽可能"的区分，让模型明白哪些是底线，哪些是优化方向。

把上下文变成 Prompt

有了结构化的上下文，下一步是填入 prompt 模板：

javascript

js 复制代码

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

这里做了两件事。第一，给模型分配了一个角色------"饮品研发专家"。角色设定放在最前面，让模型知道自己应该以什么身份来思考。第二，用【背景】【约束】【要求】这样的标签把三段上下文隔开，结构清晰，模型不容易混淆信息。

user 消息只保留了最简单的指令："请开始你的研发设计"。具体的规则和背景已经在 system prompt 里交代清楚了。这是一种常见的分工方式：system 层管规则和上下文，user 层管具体指令。

静态上下文和动态上下文

上面这段代码里的 context 是写死的------它假设你永远是大学附近的奶茶店老板。这种预先准备好的、相对固定的信息，叫做静态上下文。产品手册、公司制度、行业规范都属于这一类。

但实际工程中，很多信息是动态的。比如订单系统的 AI 客服，它需要知道当前这笔订单的物流状态、用户的会员等级、上次投诉的内容。这些信息随着每次请求变化，需要在调用大模型之前实时组装进去。

还有一类是"半静态"上下文------用户偏好、项目规则这类信息，不会在每次请求时都变化，但会随着时间或用户行为逐步积累和更新。它的管理方式介于静态和动态之间：定期刷新，而不是每次实时拉取。

三种上下文的区分在实际工程中很有用：静态的打底，半静态的定期更新，动态的实时注入。各有各的管理方式，混在一起反而容易乱。

上下文冲突怎么办

当多个信息源同时出现在上下文里，冲突是难免的。

比如用户说"我想加榴莲"，但约束里写着"成本控制在 8 元内"。榴莲的进价可能已经超过 8 块了。模型该听谁的？

一种做法是在 prompt 里明确优先级："当用户需求和成本约束冲突时，以成本约束为准"。另一种做法是在 Harness 层提前处理------检测到冲突时，直接告诉用户"榴莲超出了成本预算"，而不把冲突信息同时塞给模型让它为难。

无论哪种方式，冲突问题需要在设计阶段就想清楚，而不是等模型给出了矛盾的答案再困惑。

容错：AI 的输出不一定按你的规矩来

代码里有两层 try-catch，值得留意：

javascript

js 复制代码

try {
    const completion = await client.chat.completions.create({...})
    try {
        const jsonData = JSON.parse(aiResponse)
    } catch(err) {
        console.log("返回的格式不是JSON")
    }
} catch(err) {
    console.log(err.message)
}

外层 catch 处理网络问题、API 限流、认证失败等调用层面的异常。内层 catch 处理大模型不按 JSON 格式输出的情况------你让它输出 JSON，它可能在 JSON 前后加一段解释文字，或者字段名跟你要求的不一致。这种情况在实际使用中非常常见，需要做好兜底。

针对 JSON 解析失败，还有几种更 robust 的做法：

使用 response_format 参数 ：OpenAI 和 DeepSeek 等 API 提供了 response_format: { type: "json_object" }，强制模型输出合法 JSON，能大幅降低解析失败率。
正则提取 ：如果模型在 JSON 前后加了文字，可以用正则提取 {...} 或 [...] 部分再解析。
重试机制：解析失败时，把错误信息传回模型，让它自己修正输出。

temperature 参数的选择也影响稳定性。代码里用了 0.7。更准确地说，temperature 控制的是输出概率分布的锐度------值越高（接近 1），输出越多样甚至随机；值越低（接近 0），输出越确定、越可重复。0.7 适合需要一定创意的任务。如果做的是代码生成或数据提取这类确定性任务，0 到 0.3 的区间更合适。

上下文窗口是共享预算

大模型一次能处理的 token 数量有限。上下文窗口是输入和输出的总预算，输入越长，留给输出的空间就越小，同时 token 消耗也越大。

因此需要在信息完整度和 token 消耗之间找平衡。一个常见的思路是：重要的信息放前面，次要信息做摘要压缩，超大规模的知识用 RAG 检索后按相关性注入。这也是"上下文工程"更大框架里要处理的问题------不仅仅是"把信息塞进去"，还包括"塞不下的怎么办"和"怎么塞最有效率"。

几个可以在实践中注意的点

调试 prompt 时先把完整输出打印出来。 很多时候问题出在拼接时格式错了（比如漏了换行、变量没插进去），而不是模型理解错了。先把最终发给模型的完整 prompt 打出来看一眼，能省很多排查时间。

如果 AI 的回答还是不理想，再按顺序检查： 它有没有理解你的角色设定？约束条件生效了吗？输出格式对不对？顺着这个顺序排查，通常能定位到上下文里遗漏或表述不清的地方。

信息可以分层管理。 有些信息是"永远成立"的（比如行业知识），有些是"这一次请求才成立"的（比如当前订单号）。把不同层级的信息分开维护，便于复用和更新。

格式要求是硬约束，质量要求是软目标。 在写 prompt 时用不同的措辞加以区分------比如"必须输出 JSON"和"尽可能做到颜值高"------模型对两者的执行力度会不同。

总结

上下文注入做的是同一件事：把你知道但大模型不知道的信息，用结构化的方式告诉它。信息组织得越清楚，大模型的输出就越靠谱。而更大的上下文工程，则是在此基础上继续解决"塞不下怎么办""怎么塞最划算""塞完了怎么验证"等一系列问题。