最近在准备大厂AI后端岗位的面试发现“Prompt Engineering”和“Context Engineering”这两个概念出现的频率越来越高但很多资料讲得比较零散容易混淆。尤其是在设计AI应用架构、优化大模型交互以及处理长文本对话时理解两者的区别与联系至关重要。本文将从后端工程师的视角系统梳理这两个核心概念通过具体代码示例和架构设计帮你彻底搞懂它们的差异、应用场景以及如何在实际项目中落地。1. 背景与核心概念为什么后端工程师必须关注在传统的Web后端开发中我们处理的是HTTP请求、数据库CRUD、业务逻辑和微服务通信。但随着大语言模型LLM成为应用的核心“大脑”后端工程师的角色正在演变。我们不仅要提供数据和服务还要成为“AI交互的架构师”负责设计如何高效、准确、安全地向大模型“提问”和“提供信息”。这就是Prompt Engineering提示工程和Context Engineering上下文工程登台的原因。它们是大模型时代后端开发必须掌握的新技能。Prompt Engineering提示工程的核心是“如何问”。它专注于设计单个问题或指令即Prompt以引导大模型生成符合预期的回答。这就像你向一个知识渊博但“死板”的专家提问问题的措辞、结构、示例Few-shot直接决定了答案的质量。例如让模型总结文章、生成代码、分类文本都需要精心设计的Prompt。Context Engineering上下文工程的核心是“给什么背景”。它关注于如何管理、筛选、组织和注入对话历史、相关文档、系统指令等上下文信息以维持对话的连贯性、提供足够的参考依据并突破模型的上下文长度限制。这就像你在和专家进行多轮对话需要不断帮他回忆之前聊过什么并提供新的参考资料。对于后端工程师而言两者的区别可以类比于Prompt Engineering像是设计一个API的请求体Request Body结构清晰意图明确。Context Engineering更像是管理整个会话状态Session State和外部知识检索RAG, Retrieval-Augmented Generation的流程涉及数据的存储、检索、裁剪和组装。不理解这两者可能会导致AI应用出现以下问题回答偏离主题、遗忘历史对话、无法处理长文档、消耗过多Token导致成本飙升或响应变慢。接下来我们将深入技术细节。2. 环境准备与概念具象化在深入代码之前我们先明确讨论的技术边界。本文的示例将围绕构建一个“智能技术问答助手”的后端服务展开。假设环境编程语言Python 3.9核心框架/库openai/langchain用于与大模型如GPT-4交互。faiss-cpu/chromadb用于向量检索实现Context Engineering中的知识库查找。flask/fastapi构建Web API。大模型以OpenAI GPT系列或开源Llama 3等兼容API的模型为例。核心概念实体System Prompt系统提示设定AI的角色和行为准则属于Prompt Engineering的顶层设计。User Prompt用户提示用户当前轮次的问题或指令。Conversation History对话历史之前多轮的问答对是Context的核心组成部分。Retrieved Context检索上下文从向量数据库或其他知识源中查找到的相关文档片段。我们的目标是将这些实体通过后端逻辑有机地组合起来形成一次有效的模型调用。3. Prompt Engineering 深度拆解从技巧到代码Prompt Engineering 是直接与模型交互的“最后一公里”。它的质量决定了单次请求的成败。3.1 核心要素与最佳实践一个优秀的Prompt通常包含以下部分角色Role“你是一个资深的Java后端架构师。”任务Task“请为以下需求设计一个微服务接口。”上下文Context“我们的系统使用Spring Boot 3.x和MySQL 8.0。” 注意这是Prompt内部的静态上下文与动态的Context Engineering不同。指令Instructions“请输出JSON格式包含接口路径、方法、请求/响应体结构。”示例Few-shot Examples提供一两个输入输出样例让模型模仿。格式Format“最后请用‘---’分隔每个接口设计。”用户输入User Input实际的需求描述。3.2 代码示例构建一个Prompt模板引擎在后端我们不会每次都手动拼接字符串。通常会使用模板或配置类来管理Prompt。# prompt_templates.py class CodeReviewPromptTemplate: 代码审查提示词模板 SYSTEM_TEMPLATE 你是一位严谨的{language}后端专家。请对以下代码进行审查重点关注 1. 潜在的性能瓶颈和内存泄漏风险。 2. 代码风格和可读性问题。 3. 安全性问题如SQL注入、XSS。 4. 是否符合常见的设计模式。 请以表格形式列出问题列包括严重程度高/中/低、行号、问题描述、修改建议。 classmethod def build_prompt(cls, language: str, code_snippet: str) - list: 构建OpenAI API格式的messages列表 messages [ {role: system, content: cls.SYSTEM_TEMPLATE.format(languagelanguage)}, {role: user, content: f请审查以下{language}代码\n{language}\n{code_snippet}\n} ] return messages # 使用示例 if __name__ __main__: sample_code GetMapping(/users) public ListUser getUsers(RequestParam String name) { String sql SELECT * FROM users WHERE name name ; // ... 执行查询 return userRepository.executeRaw(sql); } prompt_messages CodeReviewPromptTemplate.build_prompt(Java, sample_code) print(prompt_messages) # 输出 # [ # {role: system, content: 你是一位严谨的Java后端专家。请对以下代码进行审查...}, # {role: user, content: 请审查以下Java代码\nJava\n...\n} # ]这个例子展示了典型的Prompt Engineering结构化将System和User角色分离符合ChatML等标准格式。参数化使用模板将{language}和{code_snippet}作为变量注入。指令清晰在System Prompt中明确列出了审查的四个维度。输出格式要求指定了“表格形式”让模型输出更规整便于后端解析。3.3 进阶技巧思维链Chain-of-Thought与后处理提示对于复杂问题可以引导模型分步思考。class ComplexAnalysisPromptTemplate: 复杂分析提示词模板使用思维链 SYSTEM_TEMPLATE 请按步骤分析以下技术方案。在最终答案前请先以‘思考过程’为开头阐述你的推理步骤。 USER_TEMPLATE 方案{scenario} 问题{question} classmethod def build_prompt(cls, scenario, question): messages [ {role: system, content: cls.SYSTEM_TEMPLATE}, {role: user, content: cls.USER_TEMPLATE.format(scenarioscenario, questionquestion)} ] return messages # 调用模型后后端可以解析响应提取“思考过程”和“最终答案” # 这有助于调试和向用户展示推理的可靠性。后端工程化要点模板管理将Prompt模板存储在数据库或配置中心如Apollo实现动态更新。版本控制对Prompt模板进行版本管理便于A/B测试和回滚。性能监控监控不同Prompt的Token消耗、响应时间和成功率。4. Context Engineering 深度拆解管理对话的记忆与知识如果Prompt是“问题”那么Context就是模型回答问题时所拥有的“参考资料和记忆”。对于多轮对话或需要外部知识的任务Context Engineering至关重要。4.1 核心挑战与解决方案上下文长度限制Context Window Limit模型有最大Token限制如128K。长对话或大文档会超出限制。信息冗余与噪声不是所有历史对话或检索到的文档都相关噪声会降低回答质量。长期记忆与关键信息丢失简单的“滑动窗口”会遗忘早期的重要信息。4.2 代码示例实现一个基础的对话上下文管理器# context_manager.py from typing import List, Dict, Tuple import tiktoken # 用于计算Token class ConversationContextManager: 管理对话上下文的类 def __init__(self, model_namegpt-4, max_tokens8000, system_promptNone): self.model_name model_name self.max_context_tokens max_tokens self.system_prompt system_prompt or 你是一个有帮助的助手。 self.encoding tiktoken.encoding_for_model(model_name) # 初始化编码器 self.message_history: List[Dict] [] if system_prompt: self.message_history.append({role: system, content: system_prompt}) def _count_tokens(self, text: str) - int: 计算文本的token数量 return len(self.encoding.encode(text)) def _calculate_messages_tokens(self, messages: List[Dict]) - int: 计算整个消息列表的token总数简化版 total 0 for msg in messages: total self._count_tokens(msg[content]) 4 # 粗略估计每个消息有额外开销 return total def add_user_message(self, user_input: str): 添加用户消息并自动进行上下文窗口管理 self.message_history.append({role: user, content: user_input}) self._trim_context() def add_assistant_message(self, assistant_reply: str): 添加助手回复 self.message_history.append({role: assistant, content: assistant_reply}) self._trim_context() def _trim_context(self): 修剪上下文确保不超过token限制。优先保留system prompt和最近的对话。 while self._calculate_messages_tokens(self.message_history) self.max_context_tokens: # 从历史中删除最早的一轮对话user assistant但永远保留system prompt if len(self.message_history) 1: # 至少有system prompt和一个消息 # 找到第一个非system消息的索引 first_non_system_idx 1 if self.message_history[0][role] system else 0 if len(self.message_history) first_non_system_idx 1: # 删除最早的一对问答如果存在 del self.message_history[first_non_system_idx:first_non_system_idx2] else: # 如果只剩一个用户消息删除它极端情况 del self.message_history[first_non_system_idx] else: break # 只有system prompt无法再修剪 def get_current_context(self) - List[Dict]: 获取当前修剪后的完整上下文消息 return self.message_history.copy() def clear_history(self): 清空对话历史但保留系统提示 self.message_history [msg for msg in self.message_history if msg[role] system] if not self.message_history and self.system_prompt: self.message_history.append({role: system, content: self.system_prompt}) # 使用示例 if __name__ __main__: manager ConversationContextManager( system_prompt你是一个技术文档助手回答要简洁专业。, max_tokens100 # 设置很小以便演示修剪 ) manager.add_user_message(什么是RESTful API) manager.add_assistant_message(RESTful API是一种基于HTTP协议的架构风格它使用标准方法如GET、POST来操作资源。) print(f第一轮后消息数{len(manager.get_current_context())}) manager.add_user_message(那和GraphQL有什么区别) # 由于max_tokens设得很小这里可能会触发修剪 print(f第二轮后消息数{len(manager.get_current_context())}) print(当前上下文, manager.get_current_context())这个上下文管理器解决了基础的长度限制问题但它只是简单地丢弃旧信息属于被动式Context管理。4.3 进阶主动式Context Engineering - 检索增强生成RAG这是Context Engineering的核心场景。当用户提问超出模型内部知识或需要最新、特定领域信息时我们从外部知识库如向量数据库动态检索相关片段并将其作为上下文注入Prompt。# rag_context_engine.py import hashlib from typing import List # 假设我们已经有了向量数据库客户端和嵌入模型 from vector_db_client import VectorDBClient # 伪代码代表FAISS/Chroma/Pinecone等 from embedding_model import get_embedding # 伪代码代表OpenAI或本地嵌入模型 class RAGContextEngine: 检索增强生成上下文引擎 def __init__(self, vector_db: VectorDBClient, top_k: int 3): self.vector_db vector_db self.top_k top_k # 检索最相关的K个片段 def retrieve_relevant_context(self, query: str) - str: 根据用户查询从知识库中检索最相关的上下文 # 1. 将查询转换为向量 query_embedding get_embedding(query) # 2. 在向量数据库中进行相似性搜索 search_results self.vector_db.similarity_search(query_embedding, kself.top_k) # 3. 将检索到的文档片段组装成上下文字符串 context_parts [] for i, doc in enumerate(search_results): context_parts.append(f[参考文档{i1}] {doc.page_content} (来源{doc.metadata.get(source, 未知)})) retrieved_context \n\n.join(context_parts) return retrieved_context def build_prompt_with_context(self, user_query: str, conversation_history: List[Dict] None) - List[Dict]: 构建包含检索上下文的完整Prompt # 1. 检索 relevant_context self.retrieve_relevant_context(user_query) # 2. 构建系统提示明确告知模型如何使用上下文 system_message { role: system, content: f你是一个技术问答助手。请严格根据以下提供的“参考文档”来回答问题。 如果参考文档中没有足够信息来回答问题请如实告知“根据现有资料无法回答”。 参考文档开始 {relevant_context} 参考文档结束。 } # 3. 组装消息历史如果有的话和当前问题 messages [system_message] if conversation_history: # 通常只保留最近几轮历史避免过长 messages.extend(conversation_history[-4:]) # 保留最近2轮对话 messages.append({role: user, content: user_query}) return messages # 模拟使用流程 # 1. 初始化向量数据库通常在服务启动时完成 # db_client VectorDBClient.load_index(tech_docs.index) # 2. 初始化RAG引擎 # rag_engine RAGContextEngine(db_client) # 3. 处理用户请求 # user_question Spring Boot中如何配置多数据源 # final_prompt rag_engine.build_prompt_with_context(user_question) # 4. 将final_prompt发送给LLM API这就是Context Engineering的主动形态动态检索根据每次查询实时获取相关知识。上下文注入将检索结果作为System或User Prompt的一部分。引用与溯源在Prompt中要求模型引用来源并在回复中标注增强可信度。解决幻觉通过限定回答范围减少模型“胡编乱造”。5. 综合实战构建一个融合PE与CE的AI问答后端服务现在我们将Prompt Engineering和Context Engineering结合起来设计一个完整的API端点。项目结构ai_backend_service/ ├── app.py # FastAPI 主应用 ├── prompts/ # Prompt模板管理 │ ├── templates.py │ └── manager.py ├── context/ # 上下文管理 │ ├── manager.py # 对话历史管理 │ └── rag_engine.py # 知识检索引擎 ├── core/ # 核心逻辑 │ └── orchestrator.py # 编排器组合PE和CE └── models/ # 数据模型 └── schemas.py核心编排器代码# core/orchestrator.py from typing import Optional, Dict, Any from prompts.manager import PromptManager from context.manager import ConversationContextManager from context.rag_engine import RAGContextEngine from models.schemas import ChatRequest, ChatResponse class AIOrchestrator: AI交互编排器整合Prompt Engineering和Context Engineering def __init__(self, prompt_manager: PromptManager, context_manager: ConversationContextManager, rag_engine: Optional[RAGContextEngine] None): self.prompt_manager prompt_manager self.context_manager context_manager self.rag_engine rag_engine self.llm_client OpenAI() # 或其他LLM客户端 async def process_chat_request(self, request: ChatRequest) - ChatResponse: 处理一次聊天请求。 步骤 1. 更新对话上下文Context Engineering - 状态管理。 2. 如果需要检索相关知识Context Engineering - 知识增强。 3. 构建最终的Prompt消息列表Prompt Engineering。 4. 调用大模型。 5. 更新上下文并返回响应。 # 1. 将用户新消息加入上下文管理器 self.context_manager.add_user_message(request.message) # 2. 获取当前对话历史修剪后的 conversation_history self.context_manager.get_current_context() # 注意这里通常要排除system prompt因为我们要用更动态的方式构建它 pure_history [msg for msg in conversation_history if msg[role] ! system] # 3. 动态构建Prompt融合检索上下文 final_messages [] if self.rag_engine and request.use_rag: # 模式A使用RAG需要外部知识 # 从对话历史中提取最近的用户问题或直接用当前问题检索 search_query request.message # 简化直接用当前问题检索 final_messages self.rag_engine.build_prompt_with_context( querysearch_query, conversation_historypure_history ) else: # 模式B不使用RAG仅基于对话历史 # 使用Prompt Manager获取系统提示模板 system_prompt_content self.prompt_manager.get_system_prompt( template_namegeneral_tech_assistant, params{user_level: request.user_level} ) final_messages [{role: system, content: system_prompt_content}] final_messages.extend(pure_history) # 附加上下文历史 final_messages.append({role: user, content: request.message}) # 当前问题已在history中这里可加可不加 # 4. 调用大模型API try: llm_response await self.llm_client.chat.completions.create( modelrequest.model or gpt-4-turbo, messagesfinal_messages, temperaturerequest.temperature or 0.7, max_tokensrequest.max_tokens or 1000 ) assistant_reply llm_response.choices[0].message.content # 5. 将助手回复加入上下文管理器完成本轮对话闭环 self.context_manager.add_assistant_message(assistant_reply) # 6. 构造响应 return ChatResponse( replyassistant_reply, conversation_idrequest.conversation_id, token_usedllm_response.usage.total_tokens if hasattr(llm_response, usage) else None ) except Exception as e: # 错误处理 return ChatResponse( replyf请求处理失败{str(e)}, conversation_idrequest.conversation_id, errorTrue ) # app.py (FastAPI 主文件片段) from fastapi import FastAPI, HTTPException from core.orchestrator import AIOrchestrator from models.schemas import ChatRequest, ChatResponse app FastAPI(titleAI问答后端服务) # 依赖注入实际项目中会用更优雅的方式初始化 prompt_manager PromptManager() context_manager ConversationContextManager() rag_engine RAGContextEngine() # 如果配置了知识库 orchestrator AIOrchestrator(prompt_manager, context_manager, rag_engine) app.post(/v1/chat, response_modelChatResponse) async def chat_endpoint(request: ChatRequest): 核心聊天接口 if not request.message or not request.conversation_id: raise HTTPException(status_code400, detail消息和会话ID不能为空) # 这里应该根据conversation_id从数据库或缓存中加载对应的context_manager # 为简化示例我们使用一个全局管理器生产环境需用会话隔离 response await orchestrator.process_chat_request(request) return response这个服务清晰地展示了分工PromptManager负责Prompt Engineering管理各种系统提示模板根据场景general_tech_assistant和参数user_level生成定制的系统指令。ConversationContextManager和RAGContextEngine负责Context Engineering前者管理对话的记忆状态后者负责从外部获取知识检索。AIOrchestrator作为协调者决定在什么场景下使用哪种策略并将两者组装成最终发送给大模型的请求。6. 常见问题与排查思路在实际开发和面试中你会遇到各种相关问题。以下是一些典型场景问题现象可能原因PE相关可能原因CE相关解决思路模型回答完全偏离主题或不符合角色。系统提示System Prompt太弱或缺失用户提示User Prompt模糊。上下文历史中包含误导性信息检索的文档不相关。1. 强化System Prompt明确角色和边界。2. 在User Prompt中提供更具体的指令和示例。3. 检查检索相关性优化向量化模型或检索策略。在多轮对话中模型“忘记”了之前讨论的重要内容。-上下文窗口被填满旧消息被修剪掉修剪策略过于激进。1. 实现更智能的上下文窗口管理如总结压缩。2. 将关键信息如用户偏好、决策点显式提取并存储在单独的“摘要”或“元数据”中在后续Prompt中注入。回答包含事实性错误“幻觉”。Prompt中未要求模型“基于给定信息回答”或“承认无知”。RAG检索到的文档质量差或不全未在Prompt中强制模型引用来源。1. 在System Prompt中加入“仅根据提供的信息回答”。2. 改进知识库的文档质量和检索精度。3. 在Prompt中要求模型列出参考来源。Token消耗过高导致成本激增或响应变慢。Prompt本身过于冗长包含不必要的示例或说明。上下文历史过长检索返回的文档片段太多或太长。1. 精简Prompt模板。2. 实施更严格的上下文修剪和摘要。3. 限制RAG返回的片段数量和长度chunk size。对于长文档如代码库模型无法有效处理。试图将整个文档塞进一个Prompt。未使用RAG进行分块检索检索粒度不合适。1.必须采用RAG。将文档切片、向量化、存储。2. 根据问题动态检索最相关的几个片段而不是全部。7. 最佳实践与工程建议结合大厂项目经验以下是在后端系统中落地PE和CE的最佳实践7.1 Prompt Engineering 工程化模板化与配置化不要将Prompt硬编码在业务逻辑里。使用YAML、JSON或数据库存储模板支持动态加载和热更新。版本管理与A/B测试对Prompt模板进行版本控制。通过流量切分对比不同Prompt版本的效果回答质量、Token消耗等。结构化输出要求模型以JSON、XML或特定标记格式输出便于后端解析和集成到下游流程。例如请以{summary: ..., keywords: [...]}格式输出。防御性设计在Prompt中明确限制模型的行为例如“不得生成有害内容”、“不得执行代码”、“仅用中文回答”。7.2 Context Engineering 工程化分层上下文管理会话级存储当前对话的原始历史。摘要级定期如每10轮或当上下文过长时用模型将长对话总结成一段摘要用摘要替代部分旧历史实现“长期记忆”。实体级从对话中提取关键实体如产品名、参数设置单独存储确保核心信息不被遗忘。智能检索优化混合检索结合向量检索语义相似和关键词检索精确匹配。重排序Re-ranking对检索到的Top K个结果用更精细的模型进行重排选取最相关的Top N个注入上下文。元数据过滤在检索时利用文档的元数据如创建时间、作者、类型进行过滤。上下文压缩与精炼提取式摘要从长文档或历史中提取关键句子。生成式摘要让模型对长内容进行概括。选择性上下文只注入与当前问题最相关的部分而不是全部检索结果。7.3 系统设计与监控限流与降级为AI服务设置QPS限制。当RAG检索失败或超时时应有降级策略如回退到仅用对话历史。可观测性全链路监控包括Prompt版本、上下文长度Token数、RAG检索耗时与召回率、模型调用耗时与Token消耗、最终回答质量可通过简单规则或抽样人工评估。成本控制监控Token消耗设置预算告警。对于内部工具可以考虑使用更小的模型或设置最大Token限制。理解Prompt Engineering和Context Engineering的区别本质上是理解与大模型交互的“静态指令设计”和“动态信息流管理”。作为AI后端开发者你的核心价值在于设计稳健、高效、可扩展的架构将这两种工程能力无缝集成到产品中从而构建出真正智能、实用且可控的AI应用。 大模型时代后端开发核心技能：Prompt与Context工程详解
最近在准备大厂AI后端岗位的面试发现“Prompt Engineering”和“Context Engineering”这两个概念出现的频率越来越高但很多资料讲得比较零散容易混淆。尤其是在设计AI应用架构、优化大模型交互以及处理长文本对话时理解两者的区别与联系至关重要。本文将从后端工程师的视角系统梳理这两个核心概念通过具体代码示例和架构设计帮你彻底搞懂它们的差异、应用场景以及如何在实际项目中落地。1. 背景与核心概念为什么后端工程师必须关注在传统的Web后端开发中我们处理的是HTTP请求、数据库CRUD、业务逻辑和微服务通信。但随着大语言模型LLM成为应用的核心“大脑”后端工程师的角色正在演变。我们不仅要提供数据和服务还要成为“AI交互的架构师”负责设计如何高效、准确、安全地向大模型“提问”和“提供信息”。这就是Prompt Engineering提示工程和Context Engineering上下文工程登台的原因。它们是大模型时代后端开发必须掌握的新技能。Prompt Engineering提示工程的核心是“如何问”。它专注于设计单个问题或指令即Prompt以引导大模型生成符合预期的回答。这就像你向一个知识渊博但“死板”的专家提问问题的措辞、结构、示例Few-shot直接决定了答案的质量。例如让模型总结文章、生成代码、分类文本都需要精心设计的Prompt。Context Engineering上下文工程的核心是“给什么背景”。它关注于如何管理、筛选、组织和注入对话历史、相关文档、系统指令等上下文信息以维持对话的连贯性、提供足够的参考依据并突破模型的上下文长度限制。这就像你在和专家进行多轮对话需要不断帮他回忆之前聊过什么并提供新的参考资料。对于后端工程师而言两者的区别可以类比于Prompt Engineering像是设计一个API的请求体Request Body结构清晰意图明确。Context Engineering更像是管理整个会话状态Session State和外部知识检索RAG, Retrieval-Augmented Generation的流程涉及数据的存储、检索、裁剪和组装。不理解这两者可能会导致AI应用出现以下问题回答偏离主题、遗忘历史对话、无法处理长文档、消耗过多Token导致成本飙升或响应变慢。接下来我们将深入技术细节。2. 环境准备与概念具象化在深入代码之前我们先明确讨论的技术边界。本文的示例将围绕构建一个“智能技术问答助手”的后端服务展开。假设环境编程语言Python 3.9核心框架/库openai/langchain用于与大模型如GPT-4交互。faiss-cpu/chromadb用于向量检索实现Context Engineering中的知识库查找。flask/fastapi构建Web API。大模型以OpenAI GPT系列或开源Llama 3等兼容API的模型为例。核心概念实体System Prompt系统提示设定AI的角色和行为准则属于Prompt Engineering的顶层设计。User Prompt用户提示用户当前轮次的问题或指令。Conversation History对话历史之前多轮的问答对是Context的核心组成部分。Retrieved Context检索上下文从向量数据库或其他知识源中查找到的相关文档片段。我们的目标是将这些实体通过后端逻辑有机地组合起来形成一次有效的模型调用。3. Prompt Engineering 深度拆解从技巧到代码Prompt Engineering 是直接与模型交互的“最后一公里”。它的质量决定了单次请求的成败。3.1 核心要素与最佳实践一个优秀的Prompt通常包含以下部分角色Role“你是一个资深的Java后端架构师。”任务Task“请为以下需求设计一个微服务接口。”上下文Context“我们的系统使用Spring Boot 3.x和MySQL 8.0。” 注意这是Prompt内部的静态上下文与动态的Context Engineering不同。指令Instructions“请输出JSON格式包含接口路径、方法、请求/响应体结构。”示例Few-shot Examples提供一两个输入输出样例让模型模仿。格式Format“最后请用‘---’分隔每个接口设计。”用户输入User Input实际的需求描述。3.2 代码示例构建一个Prompt模板引擎在后端我们不会每次都手动拼接字符串。通常会使用模板或配置类来管理Prompt。# prompt_templates.py class CodeReviewPromptTemplate: 代码审查提示词模板 SYSTEM_TEMPLATE 你是一位严谨的{language}后端专家。请对以下代码进行审查重点关注 1. 潜在的性能瓶颈和内存泄漏风险。 2. 代码风格和可读性问题。 3. 安全性问题如SQL注入、XSS。 4. 是否符合常见的设计模式。 请以表格形式列出问题列包括严重程度高/中/低、行号、问题描述、修改建议。 classmethod def build_prompt(cls, language: str, code_snippet: str) - list: 构建OpenAI API格式的messages列表 messages [ {role: system, content: cls.SYSTEM_TEMPLATE.format(languagelanguage)}, {role: user, content: f请审查以下{language}代码\n{language}\n{code_snippet}\n} ] return messages # 使用示例 if __name__ __main__: sample_code GetMapping(/users) public ListUser getUsers(RequestParam String name) { String sql SELECT * FROM users WHERE name name ; // ... 执行查询 return userRepository.executeRaw(sql); } prompt_messages CodeReviewPromptTemplate.build_prompt(Java, sample_code) print(prompt_messages) # 输出 # [ # {role: system, content: 你是一位严谨的Java后端专家。请对以下代码进行审查...}, # {role: user, content: 请审查以下Java代码\nJava\n...\n} # ]这个例子展示了典型的Prompt Engineering结构化将System和User角色分离符合ChatML等标准格式。参数化使用模板将{language}和{code_snippet}作为变量注入。指令清晰在System Prompt中明确列出了审查的四个维度。输出格式要求指定了“表格形式”让模型输出更规整便于后端解析。3.3 进阶技巧思维链Chain-of-Thought与后处理提示对于复杂问题可以引导模型分步思考。class ComplexAnalysisPromptTemplate: 复杂分析提示词模板使用思维链 SYSTEM_TEMPLATE 请按步骤分析以下技术方案。在最终答案前请先以‘思考过程’为开头阐述你的推理步骤。 USER_TEMPLATE 方案{scenario} 问题{question} classmethod def build_prompt(cls, scenario, question): messages [ {role: system, content: cls.SYSTEM_TEMPLATE}, {role: user, content: cls.USER_TEMPLATE.format(scenarioscenario, questionquestion)} ] return messages # 调用模型后后端可以解析响应提取“思考过程”和“最终答案” # 这有助于调试和向用户展示推理的可靠性。后端工程化要点模板管理将Prompt模板存储在数据库或配置中心如Apollo实现动态更新。版本控制对Prompt模板进行版本管理便于A/B测试和回滚。性能监控监控不同Prompt的Token消耗、响应时间和成功率。4. Context Engineering 深度拆解管理对话的记忆与知识如果Prompt是“问题”那么Context就是模型回答问题时所拥有的“参考资料和记忆”。对于多轮对话或需要外部知识的任务Context Engineering至关重要。4.1 核心挑战与解决方案上下文长度限制Context Window Limit模型有最大Token限制如128K。长对话或大文档会超出限制。信息冗余与噪声不是所有历史对话或检索到的文档都相关噪声会降低回答质量。长期记忆与关键信息丢失简单的“滑动窗口”会遗忘早期的重要信息。4.2 代码示例实现一个基础的对话上下文管理器# context_manager.py from typing import List, Dict, Tuple import tiktoken # 用于计算Token class ConversationContextManager: 管理对话上下文的类 def __init__(self, model_namegpt-4, max_tokens8000, system_promptNone): self.model_name model_name self.max_context_tokens max_tokens self.system_prompt system_prompt or 你是一个有帮助的助手。 self.encoding tiktoken.encoding_for_model(model_name) # 初始化编码器 self.message_history: List[Dict] [] if system_prompt: self.message_history.append({role: system, content: system_prompt}) def _count_tokens(self, text: str) - int: 计算文本的token数量 return len(self.encoding.encode(text)) def _calculate_messages_tokens(self, messages: List[Dict]) - int: 计算整个消息列表的token总数简化版 total 0 for msg in messages: total self._count_tokens(msg[content]) 4 # 粗略估计每个消息有额外开销 return total def add_user_message(self, user_input: str): 添加用户消息并自动进行上下文窗口管理 self.message_history.append({role: user, content: user_input}) self._trim_context() def add_assistant_message(self, assistant_reply: str): 添加助手回复 self.message_history.append({role: assistant, content: assistant_reply}) self._trim_context() def _trim_context(self): 修剪上下文确保不超过token限制。优先保留system prompt和最近的对话。 while self._calculate_messages_tokens(self.message_history) self.max_context_tokens: # 从历史中删除最早的一轮对话user assistant但永远保留system prompt if len(self.message_history) 1: # 至少有system prompt和一个消息 # 找到第一个非system消息的索引 first_non_system_idx 1 if self.message_history[0][role] system else 0 if len(self.message_history) first_non_system_idx 1: # 删除最早的一对问答如果存在 del self.message_history[first_non_system_idx:first_non_system_idx2] else: # 如果只剩一个用户消息删除它极端情况 del self.message_history[first_non_system_idx] else: break # 只有system prompt无法再修剪 def get_current_context(self) - List[Dict]: 获取当前修剪后的完整上下文消息 return self.message_history.copy() def clear_history(self): 清空对话历史但保留系统提示 self.message_history [msg for msg in self.message_history if msg[role] system] if not self.message_history and self.system_prompt: self.message_history.append({role: system, content: self.system_prompt}) # 使用示例 if __name__ __main__: manager ConversationContextManager( system_prompt你是一个技术文档助手回答要简洁专业。, max_tokens100 # 设置很小以便演示修剪 ) manager.add_user_message(什么是RESTful API) manager.add_assistant_message(RESTful API是一种基于HTTP协议的架构风格它使用标准方法如GET、POST来操作资源。) print(f第一轮后消息数{len(manager.get_current_context())}) manager.add_user_message(那和GraphQL有什么区别) # 由于max_tokens设得很小这里可能会触发修剪 print(f第二轮后消息数{len(manager.get_current_context())}) print(当前上下文, manager.get_current_context())这个上下文管理器解决了基础的长度限制问题但它只是简单地丢弃旧信息属于被动式Context管理。4.3 进阶主动式Context Engineering - 检索增强生成RAG这是Context Engineering的核心场景。当用户提问超出模型内部知识或需要最新、特定领域信息时我们从外部知识库如向量数据库动态检索相关片段并将其作为上下文注入Prompt。# rag_context_engine.py import hashlib from typing import List # 假设我们已经有了向量数据库客户端和嵌入模型 from vector_db_client import VectorDBClient # 伪代码代表FAISS/Chroma/Pinecone等 from embedding_model import get_embedding # 伪代码代表OpenAI或本地嵌入模型 class RAGContextEngine: 检索增强生成上下文引擎 def __init__(self, vector_db: VectorDBClient, top_k: int 3): self.vector_db vector_db self.top_k top_k # 检索最相关的K个片段 def retrieve_relevant_context(self, query: str) - str: 根据用户查询从知识库中检索最相关的上下文 # 1. 将查询转换为向量 query_embedding get_embedding(query) # 2. 在向量数据库中进行相似性搜索 search_results self.vector_db.similarity_search(query_embedding, kself.top_k) # 3. 将检索到的文档片段组装成上下文字符串 context_parts [] for i, doc in enumerate(search_results): context_parts.append(f[参考文档{i1}] {doc.page_content} (来源{doc.metadata.get(source, 未知)})) retrieved_context \n\n.join(context_parts) return retrieved_context def build_prompt_with_context(self, user_query: str, conversation_history: List[Dict] None) - List[Dict]: 构建包含检索上下文的完整Prompt # 1. 检索 relevant_context self.retrieve_relevant_context(user_query) # 2. 构建系统提示明确告知模型如何使用上下文 system_message { role: system, content: f你是一个技术问答助手。请严格根据以下提供的“参考文档”来回答问题。 如果参考文档中没有足够信息来回答问题请如实告知“根据现有资料无法回答”。 参考文档开始 {relevant_context} 参考文档结束。 } # 3. 组装消息历史如果有的话和当前问题 messages [system_message] if conversation_history: # 通常只保留最近几轮历史避免过长 messages.extend(conversation_history[-4:]) # 保留最近2轮对话 messages.append({role: user, content: user_query}) return messages # 模拟使用流程 # 1. 初始化向量数据库通常在服务启动时完成 # db_client VectorDBClient.load_index(tech_docs.index) # 2. 初始化RAG引擎 # rag_engine RAGContextEngine(db_client) # 3. 处理用户请求 # user_question Spring Boot中如何配置多数据源 # final_prompt rag_engine.build_prompt_with_context(user_question) # 4. 将final_prompt发送给LLM API这就是Context Engineering的主动形态动态检索根据每次查询实时获取相关知识。上下文注入将检索结果作为System或User Prompt的一部分。引用与溯源在Prompt中要求模型引用来源并在回复中标注增强可信度。解决幻觉通过限定回答范围减少模型“胡编乱造”。5. 综合实战构建一个融合PE与CE的AI问答后端服务现在我们将Prompt Engineering和Context Engineering结合起来设计一个完整的API端点。项目结构ai_backend_service/ ├── app.py # FastAPI 主应用 ├── prompts/ # Prompt模板管理 │ ├── templates.py │ └── manager.py ├── context/ # 上下文管理 │ ├── manager.py # 对话历史管理 │ └── rag_engine.py # 知识检索引擎 ├── core/ # 核心逻辑 │ └── orchestrator.py # 编排器组合PE和CE └── models/ # 数据模型 └── schemas.py核心编排器代码# core/orchestrator.py from typing import Optional, Dict, Any from prompts.manager import PromptManager from context.manager import ConversationContextManager from context.rag_engine import RAGContextEngine from models.schemas import ChatRequest, ChatResponse class AIOrchestrator: AI交互编排器整合Prompt Engineering和Context Engineering def __init__(self, prompt_manager: PromptManager, context_manager: ConversationContextManager, rag_engine: Optional[RAGContextEngine] None): self.prompt_manager prompt_manager self.context_manager context_manager self.rag_engine rag_engine self.llm_client OpenAI() # 或其他LLM客户端 async def process_chat_request(self, request: ChatRequest) - ChatResponse: 处理一次聊天请求。 步骤 1. 更新对话上下文Context Engineering - 状态管理。 2. 如果需要检索相关知识Context Engineering - 知识增强。 3. 构建最终的Prompt消息列表Prompt Engineering。 4. 调用大模型。 5. 更新上下文并返回响应。 # 1. 将用户新消息加入上下文管理器 self.context_manager.add_user_message(request.message) # 2. 获取当前对话历史修剪后的 conversation_history self.context_manager.get_current_context() # 注意这里通常要排除system prompt因为我们要用更动态的方式构建它 pure_history [msg for msg in conversation_history if msg[role] ! system] # 3. 动态构建Prompt融合检索上下文 final_messages [] if self.rag_engine and request.use_rag: # 模式A使用RAG需要外部知识 # 从对话历史中提取最近的用户问题或直接用当前问题检索 search_query request.message # 简化直接用当前问题检索 final_messages self.rag_engine.build_prompt_with_context( querysearch_query, conversation_historypure_history ) else: # 模式B不使用RAG仅基于对话历史 # 使用Prompt Manager获取系统提示模板 system_prompt_content self.prompt_manager.get_system_prompt( template_namegeneral_tech_assistant, params{user_level: request.user_level} ) final_messages [{role: system, content: system_prompt_content}] final_messages.extend(pure_history) # 附加上下文历史 final_messages.append({role: user, content: request.message}) # 当前问题已在history中这里可加可不加 # 4. 调用大模型API try: llm_response await self.llm_client.chat.completions.create( modelrequest.model or gpt-4-turbo, messagesfinal_messages, temperaturerequest.temperature or 0.7, max_tokensrequest.max_tokens or 1000 ) assistant_reply llm_response.choices[0].message.content # 5. 将助手回复加入上下文管理器完成本轮对话闭环 self.context_manager.add_assistant_message(assistant_reply) # 6. 构造响应 return ChatResponse( replyassistant_reply, conversation_idrequest.conversation_id, token_usedllm_response.usage.total_tokens if hasattr(llm_response, usage) else None ) except Exception as e: # 错误处理 return ChatResponse( replyf请求处理失败{str(e)}, conversation_idrequest.conversation_id, errorTrue ) # app.py (FastAPI 主文件片段) from fastapi import FastAPI, HTTPException from core.orchestrator import AIOrchestrator from models.schemas import ChatRequest, ChatResponse app FastAPI(titleAI问答后端服务) # 依赖注入实际项目中会用更优雅的方式初始化 prompt_manager PromptManager() context_manager ConversationContextManager() rag_engine RAGContextEngine() # 如果配置了知识库 orchestrator AIOrchestrator(prompt_manager, context_manager, rag_engine) app.post(/v1/chat, response_modelChatResponse) async def chat_endpoint(request: ChatRequest): 核心聊天接口 if not request.message or not request.conversation_id: raise HTTPException(status_code400, detail消息和会话ID不能为空) # 这里应该根据conversation_id从数据库或缓存中加载对应的context_manager # 为简化示例我们使用一个全局管理器生产环境需用会话隔离 response await orchestrator.process_chat_request(request) return response这个服务清晰地展示了分工PromptManager负责Prompt Engineering管理各种系统提示模板根据场景general_tech_assistant和参数user_level生成定制的系统指令。ConversationContextManager和RAGContextEngine负责Context Engineering前者管理对话的记忆状态后者负责从外部获取知识检索。AIOrchestrator作为协调者决定在什么场景下使用哪种策略并将两者组装成最终发送给大模型的请求。6. 常见问题与排查思路在实际开发和面试中你会遇到各种相关问题。以下是一些典型场景问题现象可能原因PE相关可能原因CE相关解决思路模型回答完全偏离主题或不符合角色。系统提示System Prompt太弱或缺失用户提示User Prompt模糊。上下文历史中包含误导性信息检索的文档不相关。1. 强化System Prompt明确角色和边界。2. 在User Prompt中提供更具体的指令和示例。3. 检查检索相关性优化向量化模型或检索策略。在多轮对话中模型“忘记”了之前讨论的重要内容。-上下文窗口被填满旧消息被修剪掉修剪策略过于激进。1. 实现更智能的上下文窗口管理如总结压缩。2. 将关键信息如用户偏好、决策点显式提取并存储在单独的“摘要”或“元数据”中在后续Prompt中注入。回答包含事实性错误“幻觉”。Prompt中未要求模型“基于给定信息回答”或“承认无知”。RAG检索到的文档质量差或不全未在Prompt中强制模型引用来源。1. 在System Prompt中加入“仅根据提供的信息回答”。2. 改进知识库的文档质量和检索精度。3. 在Prompt中要求模型列出参考来源。Token消耗过高导致成本激增或响应变慢。Prompt本身过于冗长包含不必要的示例或说明。上下文历史过长检索返回的文档片段太多或太长。1. 精简Prompt模板。2. 实施更严格的上下文修剪和摘要。3. 限制RAG返回的片段数量和长度chunk size。对于长文档如代码库模型无法有效处理。试图将整个文档塞进一个Prompt。未使用RAG进行分块检索检索粒度不合适。1.必须采用RAG。将文档切片、向量化、存储。2. 根据问题动态检索最相关的几个片段而不是全部。7. 最佳实践与工程建议结合大厂项目经验以下是在后端系统中落地PE和CE的最佳实践7.1 Prompt Engineering 工程化模板化与配置化不要将Prompt硬编码在业务逻辑里。使用YAML、JSON或数据库存储模板支持动态加载和热更新。版本管理与A/B测试对Prompt模板进行版本控制。通过流量切分对比不同Prompt版本的效果回答质量、Token消耗等。结构化输出要求模型以JSON、XML或特定标记格式输出便于后端解析和集成到下游流程。例如请以{summary: ..., keywords: [...]}格式输出。防御性设计在Prompt中明确限制模型的行为例如“不得生成有害内容”、“不得执行代码”、“仅用中文回答”。7.2 Context Engineering 工程化分层上下文管理会话级存储当前对话的原始历史。摘要级定期如每10轮或当上下文过长时用模型将长对话总结成一段摘要用摘要替代部分旧历史实现“长期记忆”。实体级从对话中提取关键实体如产品名、参数设置单独存储确保核心信息不被遗忘。智能检索优化混合检索结合向量检索语义相似和关键词检索精确匹配。重排序Re-ranking对检索到的Top K个结果用更精细的模型进行重排选取最相关的Top N个注入上下文。元数据过滤在检索时利用文档的元数据如创建时间、作者、类型进行过滤。上下文压缩与精炼提取式摘要从长文档或历史中提取关键句子。生成式摘要让模型对长内容进行概括。选择性上下文只注入与当前问题最相关的部分而不是全部检索结果。7.3 系统设计与监控限流与降级为AI服务设置QPS限制。当RAG检索失败或超时时应有降级策略如回退到仅用对话历史。可观测性全链路监控包括Prompt版本、上下文长度Token数、RAG检索耗时与召回率、模型调用耗时与Token消耗、最终回答质量可通过简单规则或抽样人工评估。成本控制监控Token消耗设置预算告警。对于内部工具可以考虑使用更小的模型或设置最大Token限制。理解Prompt Engineering和Context Engineering的区别本质上是理解与大模型交互的“静态指令设计”和“动态信息流管理”。作为AI后端开发者你的核心价值在于设计稳健、高效、可扩展的架构将这两种工程能力无缝集成到产品中从而构建出真正智能、实用且可控的AI应用。