Prompt工程核心：系统、用户、助手提示词详解与实战

在大型语言模型LLM应用开发中我们常常听到“Prompt工程”这个词。很多开发者尤其是刚开始接触LLM API的朋友可能会感到困惑为什么一个简单的对话接口却要区分“系统提示词”、“用户提示词”和“助手提示词”它们看起来不都是文本输入吗直接让用户和模型对话不就好了这种困惑非常普遍。笔者在早期集成ChatGPT API时也曾简单地认为“用户消息”就是全部结果模型的行为时常“放飞自我”时而过于啰嗦时而忘记自己的角色设定给产品体验带来了很大的不确定性。直到深入理解了这三类提示词的分工与协作才真正掌握了引导模型生成稳定、可靠、符合预期的输出的钥匙。本文将彻底拆解Prompt工程中这三个核心概念。我们将从它们各自的设计目的、应用场景、编写技巧出发通过大量可运行的代码示例展示如何组合使用它们来构建一个功能明确、行为可控的AI助手。无论你是想开发一个专业的客服机器人、一个代码生成工具还是一个创意写作伙伴理解并善用这三类提示词都是你迈向成功的第一步。1. 背景与核心概念为什么需要区分角色在深入细节之前我们首先要理解一个根本问题为什么像OpenAI的Chat Completion API这样的接口要设计出三种不同的消息角色核心答案在于为对话提供结构和上下文实现对模型行为的精细控制。我们可以把与大语言模型的一次交互想象成导演开发者在指导一位才华横溢但缺乏既定目标的演员LLM。如果导演只说“开始表演”演员可能会即兴发挥结果难以预测。而一个专业的导演会做三件事设定角色与背景系统提示词告诉演员“你是一位19世纪的英国侦探性格冷静注重细节”。给出当前指令用户提示词提出具体要求“请分析一下这个犯罪现场的描述找出三个疑点”。提供历史对话范例助手提示词提醒演员“刚才你提到过凶手可能左撇子请基于此继续推理”。在技术层面这种区分带来了诸多好处角色隔离将永不改变的“人设”指令系统、用户的实时请求用户和模型自身的历史回复助手分开避免了指令污染和上下文混淆。上下文管理模型能清晰区分哪些是它应该遵循的“宪法”系统指令哪些是单次对话的“议题”用户输入以及它自己说过什么助手历史。行为稳定性通过系统提示词可以固化模型的行为模式确保在不同会话中表现一致这对于构建可靠的产品功能至关重要。对话连续性助手提示词使得多轮对话成为可能模型能记住并参考之前的交流内容。接下来我们将逐一深入这三大核心组件。2. 环境准备与版本说明本文的代码示例将主要使用OpenAI官方的Python SDK因为它是最广泛使用的接口之一其消息角色设计也成为了业内的一个事实标准。其他主流的LLM API如Anthropic Claude、Google Gemini、国内各大模型平台也普遍采用了类似或兼容的消息角色概念。环境要求操作系统Windows 10/11, macOS, 或 Linux (本文示例在macOS/Linux环境下测试)Python版本 3.7 (推荐3.8)关键库openaiOpenAI官方Python SDK。python-dotenv推荐用于管理API密钥安全最佳实践。安装依赖在项目目录下创建一个requirements.txt文件内容如下openai1.0.0 python-dotenv1.0.0然后通过pip安装pip install -r requirements.txtAPI密钥配置前往OpenAI平台创建API Key。在项目根目录创建.env文件切记将该文件加入.gitignore避免密钥泄露。# .env 文件内容 OPENAI_API_KEY你的实际api-key-here在代码中通过环境变量加载密钥。示例项目结构prompt_engineering_demo/ ├── .env # 存储API密钥保密 ├── .gitignore # 忽略.env文件 ├── requirements.txt # 项目依赖 ├── utils/ │ └── config.py # 配置加载模块 └── demo_*.py # 各个示例的演示脚本3. 核心组件拆解系统、用户、助手提示词3.1 系统提示词模型的“宪法”与“人设”系统提示词是对话的“零号消息”它在整个对话生命周期中为模型设定基础的行为准则、身份、风格和边界。它通常只在对话开始时发送一次但其影响贯穿整个会话。核心作用定义角色你是谁例如资深Python开发专家、友好客服助手、严格审稿人设定目标你的核心任务是什么例如解答技术问题、创作诗歌、分析数据规定风格你应以何种方式回复例如简洁专业、热情活泼、循序渐进划定边界什么是你不能做的例如不提供医疗建议、不生成恶意代码、不讨论政治编写技巧清晰明确使用直接、无歧义的语言。前置重要指令将最关键的约束放在开头。具体而非抽象说“用Python 3.8语法”比说“写高质量代码”更好。使用示例在系统提示词中嵌入期望输出格式的示例效果极佳。基础示例我们创建一个配置文件utils/config.py来加载环境变量。# utils/config.py import os from dotenv import load_dotenv load_dotenv() # 加载 .env 文件中的环境变量 OPENAI_API_KEY os.getenv(OPENAI_API_KEY) if not OPENAI_API_KEY: raise ValueError(请在 .env 文件中设置 OPENAI_API_KEY)现在让我们看一个定义“代码专家”角色的系统提示词。# demo_system_prompt.py from openai import OpenAI from utils.config import OPENAI_API_KEY client OpenAI(api_keyOPENAI_API_KEY) # 一个强大的系统提示词示例 system_prompt_for_coder 你是一个经验丰富的Python软件工程师专注于编写清晰、高效、符合PEP 8规范的代码。 你的职责是 1. **只回答与Python编程相关的问题**。对于其他领域的问题礼貌地拒绝并说明原因。 2. 提供的代码必须可运行并附上简要的解释。 3. 优先使用标准库如需第三方库请明确指出。 4. 考虑代码的健壮性如异常处理和可读性。 5. 如果用户的问题模糊请先询问澄清再做假设。 你的回复格式应如下 【分析】简要分析问题与思路 【代码】完整的代码块标注语言 【说明】关键点解释与运行预期 # 尝试一个用户请求 user_query 帮我写一个函数计算斐波那契数列的第n项。 response client.chat.completions.create( modelgpt-4o-mini, # 或 gpt-3.5-turbo messages[ {role: system, content: system_prompt_for_coder}, {role: user, content: user_query} ], temperature0.7, # 控制创造性对于代码生成可以调低如0.2以获得更确定的结果 ) print(系统提示词设定的‘代码专家’回复\n) print(response.choices[0].message.content)运行结果预期模型会严格按照设定的格式回复先分析再给出带异常处理的代码最后说明。如果用户问“今天的天气如何”模型会拒绝回答。3.2 用户提示词具体的任务与请求用户提示词代表当前对话轮次中人类用户或应用程序向模型发出的具体指令或提问。它是驱动模型产生本次回复的直接原因。核心作用传达意图明确告诉模型“我现在要你做什么”。提供上下文给出完成任务所需的具体信息、数据或背景。指定格式要求模型以特定格式JSON、列表、Markdown表格等回复。编写技巧任务分解对于复杂任务将其拆分成多个清晰的步骤或子问题。提供上下文将与问题相关的背景信息直接放在用户提示词中。结构化输入使用编号、分点、键值对等方式组织输入便于模型理解。明确输出格式直接要求“请以JSON格式输出”或“请生成一个Markdown表格”。示例结合系统提示词的有效用户提问# demo_user_prompt.py from openai import OpenAI from utils.config import OPENAI_API_KEY client OpenAI(api_keyOPENAI_API_KEY) # 系统提示词设定为一个数据分析助手 system_msg 你是一个数据分析助手擅长将复杂数据转化为洞察并用清晰的Markdown格式呈现。 # 示例1模糊的用户提问效果差 bad_user_query 看看这个销售数据。 # 示例2清晰、结构化的用户提问效果好 good_user_query 我有一份过去一年的月度销售数据如下 月份 [1,2,3,4,5,6,7,8,9,10,11,12] 销售额(万) [120, 135, 118, 160, 155, 168, 172, 180, 175, 190, 205, 220] 请帮我 1. 计算全年总销售额和平均月销售额。 2. 找出销售额最高和最低的月份。 3. 分析销售额的整体增长趋势。 4. 将以上分析结果整理在一个Markdown表格中表格列包括指标、结果、简要说明。 print( 模糊提问的回复 ) response_bad client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: system_msg}, {role: user, content: bad_user_query} ] ) print(response_bad.choices[0].message.content) print(\n *50 \n) print( 清晰结构化提问的回复 ) response_good client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: system_msg}, {role: user, content: good_user_query} ] ) print(response_good.choices[0].message.content)对比分析第一个模糊提问会导致模型请求更多信息或给出泛泛而谈的回答。第二个提问提供了结构化数据、明确的任务列表和输出格式要求模型就能直接生成一份完整、格式规范的数据分析报告。3.3 助手提示词对话的记忆与历史助手提示词代表模型助手在之前轮次中给出的回复。在API调用中我们通常不需要手动构造初始的助手消息而是在进行多轮对话时将模型之前的历史回复作为role: “assistant”的消息连同新的用户消息一起发送给API以维持对话的连贯性。核心作用维持对话上下文让模型记住之前说过什么实现连贯的多轮交互。自我修正与参考模型可以基于自己之前的陈述进行延伸、修正或深入。实现复杂流程通过多轮问答引导模型逐步完成一个复杂任务如思维链推理。关键工作模式在Chat Completion API中messages参数是一个列表。每次调用时你需要将整个对话历史包括所有先前的系统、用户、助手消息和新的用户消息一起传入。API会根据这个完整的上下文生成下一次回复。多轮对话示例# demo_multi_turn.py from openai import OpenAI from utils.config import OPENAI_API_KEY client OpenAI(api_keyOPENAI_API_KEY) # 初始化对话历史 conversation_history [ {role: system, content: 你是一个乐于助人的旅行规划助手。你的回答应具体、实用并考虑预算。} ] def chat_with_assistant(user_input, history): 模拟一轮对话并更新历史 # 将新的用户输入加入历史 history.append({role: user, content: user_input}) # 调用API传入完整历史 response client.chat.completions.create( modelgpt-4o-mini, messageshistory, temperature0.8, ) # 获取助手回复 assistant_reply response.choices[0].message.content print(f用户: {user_input}) print(f助手: {assistant_reply}\n) # 将助手回复加入历史以便下一轮使用 history.append({role: assistant, content: assistant_reply}) return history, assistant_reply # 模拟多轮对话 print(开始旅行规划对话...\n) user_inputs [ 我想下个月去杭州玩3天预算大概3000元有什么推荐吗, 我对你提到的西湖和灵隐寺很感兴趣能详细说说第一天的行程安排吗包括交通和大概花费。, 好的。那第二天我想去西溪湿地和宋城这两个地方一天来得及吗怎么安排路线比较顺 ] for query in user_inputs: conversation_history, _ chat_with_assistant(query, conversation_history) print(\n 完整的对话历史messages列表) for msg in conversation_history: print(f{msg[role].upper()}: {msg[content][:100]}...) # 打印前100字符代码解读我们维护一个conversation_history列表它随时间增长。第一轮历史里只有系统消息。用户提问后历史变为[系统 用户1]API回复后我们得到助手回复1并将其加入历史变为[系统 用户1 助手1]。第二轮用户提问2历史变为[系统 用户1 助手1 用户2]API能基于所有历史知道之前推荐了西湖来生成更具体的行程。如此循环。这就是助手提示词的威力——它让模型拥有了“记忆”。4. 完整实战案例构建一个智能技术面试官现在我们将综合运用三种提示词构建一个模拟技术面试的AI应用。这个应用将通过系统提示词定义面试官的角色、领域和评分标准。通过首轮用户提示词输入求职者的岗位和技术栈。通过多轮交互用户提问助手历史进行模拟面试。最后生成一份评估报告。# demo_tech_interviewer.py import json from openai import OpenAI from utils.config import OPENAI_API_KEY client OpenAI(api_keyOPENAI_API_KEY) class TechInterviewSimulator: def __init__(self): self.conversation_history [] self.setup_system_prompt() def setup_system_prompt(self): 定义面试官的系统指令 system_instruction 你是一名资深的后端技术面试官专业、严谨且富有洞察力。你的目标是评估候选人的技术深度、解决问题的能力和沟通表达。 面试流程与规则 1. **岗位匹配**根据用户提供的岗位如“Java后端开发”、“Python数据分析”和技术栈提出针对性的问题。 2. **问题类型**问题应涵盖基础知识、项目经验、系统设计、算法思维等。从易到难逐步深入。 3. **互动方式** - 每次只问一个问题。 - 候选人回答后你可以进行简短追问或根据回答质量给出提示如果回答不完整。 - 不要一次性给出答案或评价保持面试的互动性。 4. **评估记录**在内心对每个问题的回答进行评分1-5分并记录关键亮点与不足。但面试过程中不要直接透露分数。 5. **结束面试**当用户说“结束面试”或连续回答多个问题后你需要主动总结并提供一份结构化的评估报告。 评估报告格式在面试结束时生成 【总体评价】简短总结 【技术深度】评分与评语 【解决问题】评分与评语 【沟通表达】评分与评语 【核心优势】列出1-3点 【改进建议】列出1-3点 【是否推荐】是/否及理由 self.conversation_history.append({role: system, content: system_instruction}) def start_interview(self, position, tech_stack): 开始面试输入岗位和技术栈 start_prompt f候选人应聘的岗位是{position}。主要技术栈包括{tech_stack}。请开始面试。 self.conversation_history.append({role: user, content: start_prompt}) print(f面试官已就位。岗位{position} 技术栈{tech_stack}\n) self._get_and_print_response() def candidate_answer(self, answer): 候选人回答问题 self.conversation_history.append({role: user, content: answer}) print(f候选人: {answer}\n) self._get_and_print_response() def end_interview(self): 主动结束面试并生成报告 self.conversation_history.append({role: user, content: 我的回答结束了请给出你的评估报告。}) print(候选人: 我的回答结束了请给出你的评估报告。\n) final_response self._get_and_print_response(finalTrue) # 可以在这里解析final_response提取结构化报告 return final_response def _get_and_print_response(self, finalFalse): 调用API并打印面试官回复 response client.chat.completions.create( modelgpt-4o-mini, messagesself.conversation_history, temperature0.7, ) assistant_reply response.choices[0].message.content prefix 【最终报告】 if final else 面试官: print(f{prefix} {assistant_reply}\n) self.conversation_history.append({role: assistant, content: assistant_reply}) return assistant_reply # 运行模拟面试 if __name__ __main__: simulator TechInterviewSimulator() # 第一轮启动面试 simulator.start_interview(positionJava后端开发工程师, tech_stackJava, Spring Boot, MySQL, Redis) # 模拟候选人回答这里简化实际可由真实用户输入 qa_pairs [ (Q1: 请解释一下Spring Bean的生命周期。, A1: Spring Bean的生命周期大致分为实例化、属性赋值、初始化、使用和销毁几个阶段。具体来说容器启动时...此处为模拟回答), (Q2: 如果让你设计一个短链接生成系统你会考虑哪些关键点, A2: 我会考虑哈希算法的选择比如MurmurHash避免碰撞存储结构用KV数据库键是短码值是原URL还有高并发、缓存策略和过期处理。) ] for q, a in qa_pairs: input(f按Enter键继续下一个问题... (模拟问题: {q[:30]}...)) simulator.candidate_answer(a) # 结束面试 input(按Enter键结束面试并生成报告...) report simulator.end_interview()案例解析系统提示词定义了面试官的完整人设、行为规则和输出格式。这是整个应用行为的“总纲”。用户提示词首次用户消息start_interview提供了面试的初始上下文岗位、技术栈。后续的candidate_answer模拟了候选人的每次回答。最后的end_interview是触发报告生成的指令。助手提示词通过conversation_history列表的不断追加模型记住了之前的所有问答从而能提出连贯的问题、进行追问并在最后生成一份基于全程表现的评估报告。这个案例展示了如何将三类提示词有机结合起来构建一个具有复杂状态和逻辑的交互式AI应用。5. 常见问题与排查思路在实际使用中你可能会遇到以下典型问题问题现象可能原因排查与解决思路模型不遵循系统指令1. 系统提示词过于冗长或模糊。2. 用户提示词与系统指令冲突。3. Temperature参数设置过高导致随机性太大。1.精炼系统提示词将核心指令放在最前面使用明确动词如“必须”、“禁止”。2.检查冲突确保用户请求在系统设定的边界内。3.调整参数对于需要严格遵循指令的任务将temperature调低如0.2top_p调低如0.1。多轮对话中模型“失忆”1. 没有正确维护和传递完整的messages历史。2. 对话轮次太多超出模型上下文窗口。1.检查历史列表确保每次API调用都传入了从系统消息开始的所有历史消息。2.实施上下文管理当对话过长时可以a使用支持更长上下文的模型b智能摘要之前的对话将摘要作为新的系统或用户消息传入。模型输出格式不符合要求1. 格式指令不够具体。2. 指令放在了不显眼的位置。1.在系统提示词中强化格式使用“你的输出必须严格按照以下格式”等强约束词并给出具体范例。2.在用户提示词中重复格式对于关键任务在用户消息里再次明确格式要求。助手回复包含不希望出现的内容1. 在历史中助手之前生成过不良内容并被包含在后续请求中。2. 系统提示词的边界设定不清晰。1.过滤历史在将历史消息加入列表前进行检查和清洗。2.强化系统约束在系统提示词中明确列出禁止行为例如“禁止生成任何虚构的代码示例”。处理速度慢或成本高1. 上下文历史消息过长。2. 系统提示词过于复杂。1.精简历史只保留最近几轮最相关的对话或对早期历史进行摘要。2.优化系统提示词去除冗余描述保持核心指令简洁。6. 最佳实践与工程建议掌握了基本用法后以下进阶技巧能帮助你将Prompt工程应用到生产环境中。6.1 系统提示词的工程化版本化与A/B测试像管理代码一样管理你的系统提示词。使用配置文件或数据库存储不同版本的提示词并进行A/B测试以数据驱动优化。模块化设计对于复杂的助手可以将系统提示词拆分为多个模块角色定义核心规则输出格式安全边界。便于单独调整和复用。使用“少样本提示”在系统提示词中直接提供2-3个高质量的输入输出示例能极大地提升模型在特定任务上的表现。这比单纯描述规则更有效。system_with_few_shot 你是一个将用户需求转化为用户故事的专家。 示例1 用户输入“需要一个登录页面要有邮箱密码登录还有忘记密码链接。” 你输出“作为网站用户我希望通过邮箱和密码登录我的账户以便访问个人内容。如果忘记密码我需要能通过‘忘记密码’链接重置它。” 示例2 用户输入“后台要能上传Excel然后自动把数据导入数据库。” 你输出“作为管理员我希望能上传Excel文件并让系统自动将其中的数据导入指定数据库表中以便批量更新数据避免手动录入。” 请按照以上格式和风格将接下来的用户需求转化为用户故事。 6.2 用户提示词的优化结构化思维链对于复杂推理任务引导模型一步步思考。例如“请按以下步骤分析1. 识别问题核心。2. 列举相关知识点。3. 逐步推导解决方案。4. 总结。”提供外部知识当需要模型处理特定信息时直接将相关文档、数据片段作为用户提示词的一部分提供这比让模型“凭空想象”可靠得多。分隔指令与数据使用明确的标记如instruction.../instruction和data.../data来区分指令和输入数据减少歧义。6.3 对话历史的管理策略摘要总结当对话轮次超过一定数量例如10轮调用模型自身对之前的对话历史生成一个简洁的摘要然后用这个摘要替换掉大部分旧历史只保留最近1-2轮详细对话。这能有效节省上下文长度。关键信息提取从历史中提取关键实体如项目名、参数值、用户偏好并作为系统提示词的一部分而不是传递全部原始对话。向量数据库检索对于超长对话或需要参考大量外部知识的情况可以将历史对话和知识库文档向量化每次只检索最相关的片段作为上下文传入这是构建复杂Agent的基石。6.4 安全与可靠性输入验证与清理对所有用户输入进行清理防止提示词注入攻击。例如用户输入中如果包含“忽略之前的指令”可能会破坏系统设定。设置安全护栏在系统提示词中明确且强硬地设定安全边界并考虑在API调用层面使用内容过滤接口。定义降级策略当模型无法给出可靠回答时应有一个后备方案例如回复“这个问题超出了我的能力范围建议您查阅官方文档或咨询专业人士。”理解系统、用户、助手三类提示词是解锁大语言模型潜力的关键。它们分别承担着设定全局规则、传达具体意图和维持对话记忆的职责。通过精心设计系统提示词来锚定模型行为通过清晰构造用户提示词来明确任务通过有效管理助手历史来实现连贯交互你就能从简单地“调用一个API”升级为“设计和指挥一个AI智能体”。从今天介绍的技术面试官到客服机器人、代码审查助手、创意写作伙伴其内核都是这三类提示词的不同组合与演绎。建议你从文中的简单示例开始亲手运行和修改代码观察每个提示词变动对输出产生的细微影响。然后尝试为你手头的项目设计专属的提示词体系逐步迭代优化。记住Prompt工程既是科学也是艺术最好的学习方式就是不断实践和实验。