1. 先搞清楚“系统、用户、助手”提示词到底在解决什么问题如果你刚开始接触大语言模型LLM的应用开发或者在使用 ChatGPT、Claude、文心一言这类工具时发现对话效果时好时坏指令总被误解那核心问题很可能出在提示词Prompt的结构上。很多人以为提示词就是“用户问什么模型答什么”但真正想让模型稳定、可控地工作必须理解“系统提示词”、“用户提示词”和“助手提示词”这三个角色的分工。这不是一个纯理论概念而是直接决定你的应用能否跑起来、跑得稳的关键。简单来说系统提示词是给模型设定的“人设”和“工作守则”。它决定了模型在整个对话中的身份、行为边界和核心任务。比如你告诉模型“你是一个专业的代码审查助手只回答与代码质量和安全相关的问题对其他问题一律礼貌拒绝”。用户提示词就是我们通常发出的具体指令或问题。比如“请帮我检查下面这段Python函数的潜在风险”。助手提示词通常是模型在对话历史中自己之前的回复。在多轮对话中它帮助模型维持上下文的一致性。为什么必须区分它们因为混在一起会导致模型“精神分裂”。如果你把所有要求都塞进用户提示词模型可能只对最新指令做出反应而忘记了更早的、全局性的约束。区分角色就是给对话建立一个清晰的“舞台设定”和“台词本”让模型知道什么时候该扮演什么角色遵循什么规则。对于开发者、产品经理或者任何想用LLM构建稳定服务的人来说理解这三者的作用优先级应该是先定好系统提示词立规矩再设计用户提示词发指令最后利用助手提示词维持状态。下面我就按这个实操顺序结合具体场景拆解每一步该怎么设计、怎么验证以及最常见的坑在哪里。2. 系统提示词为对话设定不可动摇的“宪法”系统提示词是整个交互的基石通常在对话开始时一次性注入并且在整个会话周期内持续生效。它的核心作用是定义模型的角色、目标、行为规范和输出格式。你可以把它想象成产品的需求文档或服务的SLA服务等级协议。2.1 系统提示词的核心构成要素一个有效的系统提示词通常包含以下几个部分我一般会按这个清单来检查身份与角色明确告诉模型“你是谁”。例如“你是一位经验丰富的网络安全专家”、“你是一个专注于将复杂技术概念通俗化的科普作家”。核心任务与目标清晰定义对话的终极目标。例如“你的任务是分析用户提供的日志文件识别潜在的安全威胁并按风险等级排序输出”、“你的目标是根据用户提供的产品描述生成吸引人的营销文案”。行为规范与限制这是避免模型“胡言乱语”或越界的关键。需要明确规定能力边界哪些问题可以回答哪些必须拒绝。例如“只处理与Python编程相关的问题对于其他编程语言或非技术问题请告知能力范围。”输出格式要求模型以特定结构回复。例如“请始终以Markdown表格形式列出问题包含‘风险点’、‘严重等级’、‘修复建议’三列。”风格与语气例如“请使用专业、冷静、客观的语气进行回答避免使用感叹号和过度情绪化的词汇。”安全与合规例如“严禁生成任何涉及暴力、歧视或违法内容。如果用户请求涉及此类内容请明确拒绝并说明原因。”上下文与知识截止告知模型其知识范围。例如“你的知识截止日期为2024年7月。对于此后的事件请注明‘根据我的知识库该信息可能已过时’。”2.2 如何设计与测试系统提示词不要一次性写一个很长的系统提示词。我建议采用“增量测试法”第一步先定核心身份和任务。写一个最简单的版本只包含角色和核心任务。例如你是一个代码审查助手。你的任务是检查用户提供的代码片段找出潜在的bug、性能问题和安全漏洞。用这个简单的提示词让模型处理几个样例。观察它是否理解了基本任务。第二步逐步添加约束条件。根据第一步的结果补充限制。比如你发现模型有时会主动重写代码但你只想要问题列表。那就加上… 你只负责指出问题不要提供修改后的完整代码。如果发现模型对非代码问题也回应就加上… 如果用户输入不是代码请回复“我专注于代码审查请提供需要检查的代码片段。”第三步格式化输出。当问题识别基本准确后再要求特定的输出格式… 请将发现的问题以列表形式呈现每个条目包含1) 行号或代码位置2) 问题类型如‘语法错误’、‘逻辑错误’、‘安全风险’3) 具体描述4) 修复建议可选。测试要点边界测试故意输入一些不符合系统提示词约束的请求如非代码内容、越界请求看模型是否按规则拒绝。压力测试输入一个非常复杂或模糊的指令看模型是否还能紧扣其“人设”和核心任务来回应。一致性测试在长达多轮的对话中反复用不同方式询问其角色和规则看它是否始终记得。一个常见的坑是把系统提示词写得太冗长或自相矛盾。例如既要求“回答简洁”又要求“详细解释每个步骤”。模型可能会困惑导致输出不稳定。所以系统提示词要力求清晰、无歧义、条款之间不冲突。3. 用户提示词发出清晰、可执行的“操作指令”用户提示词是每次交互的触发器它告诉模型在当前轮次具体要做什么。如果说系统提示词是“宪法”那么用户提示词就是具体的“法案”或“行政命令”。3.1 用户提示词的优化原则用户提示词的质量直接决定单次请求的成败。好的用户提示词不是“问问题”而是“下指令”。以下是我总结的几个关键原则具体化避免模糊。不要问“帮我写点东西”而是问“帮我写一封给潜在客户的英文商务邮件介绍我们的新产品A核心卖点是轻便和长续航语气专业且略带热情字数在200字左右”。结构化对于复杂任务将指令分点列出。这能显著提升模型的理解准确度。例如请完成以下任务总结下面这篇文章的中心思想。提取文章中的三个关键数据。基于这些数据提出一个可能的趋势预测。提供上下文如果任务依赖于特定信息将这些信息直接包含在提示词中。例如在代码审查时直接把代码贴出来在翻译时提供需要翻译的原文。指定输出格式即使在系统提示词中已有规定在用户提示词中重申或细化格式也是好习惯。例如“请将分析结果用JSON格式输出包含risk_level,description,line_number字段。”3.2 从单轮指令到多轮对话设计在简单的单轮问答中用户提示词就是一切。但在多轮对话中用户提示词需要承担“引导对话流”的责任。任务链将一个复杂任务拆分成多个用户提示词一步步引导模型完成。例如先让模型生成大纲再根据大纲撰写具体内容。纠正与迭代当模型输出不符合预期时用户提示词用于提供反馈和纠正方向。例如“你刚才生成的方案成本太高。请基于‘成本控制在1万元以内’这个前提重新提供一个方案。”上下文引用在多轮对话中可以通过用户提示词明确引用之前的对话内容。例如“针对我们刚才讨论的第一个方案你能否详细解释一下它的第三步”一个关键技巧在用户提示词中“复习”关键约束。即使系统提示词已经定义了角色在关键的用户提示词开头也可以温和地提醒一下。例如“作为我的代码审查助手请看看这段函数有没有内存泄漏的风险[代码]”。这能加强模型在当前轮次对角色的认知。最常见的错误是假设模型能“读心”。用户提示词过于简短、依赖未阐明的背景知识是效果不佳的主要原因。永远记住模型只能看到你提供的文本。4. 助手提示词维持对话记忆与状态的“粘合剂”助手提示词在技术实现上通常指的是在对话历史中模型助手之前做出的回复。它的主要作用是在多轮对话中维持上下文连贯性让模型记得自己说过什么从而进行有逻辑的延续。4.1 助手提示词是如何工作的当你使用ChatGPT这样的聊天接口进行多轮对话时后台实际上是将整个对话历史包括你的所有“用户”消息和它的所有“助手”消息作为上下文一起发送给模型来生成下一个回复。模型通过阅读自己之前的回复助手提示词来理解对话的进展、已经达成的共识、以及它自己承诺过要做什么。例如用户“写一个关于春天的诗。”助手“生成了一首诗”用户“把它翻译成英文。” 在这个例子中当处理第二个用户请求时模型不仅看到了新的指令“翻译成英文”也看到了历史中的助手消息那首诗。因此它知道要翻译的对象是什么。4.2 开发者如何管理与利用助手提示词对于最终用户他们通常感知不到助手提示词的存在。但对于开发者在构建基于LLM的应用时管理对话历史即管理好助手提示词至关重要。保存完整的对话历史如果你想实现真正的多轮对话必须在服务器端保存完整的(用户 助手)消息对序列。每次新的用户请求到来时将整个历史序列作为上下文传入。上下文长度限制与摘要所有模型都有上下文窗口限制如4K、8K、128K tokens。当对话历史超过这个限制时你需要进行截断或摘要。一种策略是保留最近的几轮对话另一种更高级的策略是让模型自己生成一个对之前长历史的“摘要”然后将这个摘要作为新的“系统提示词”或对话开头的一部分以维持长期记忆。主动塑造助手角色在某些设计中你甚至可以“伪造”或“插入”助手提示词。例如你想让模型以某种特定风格开始对话你可以不仅在系统提示词中定义还可以在历史中预先放置一条符合该风格的“助手”消息让模型去“模仿”和“延续”这种风格。处理幻觉与纠正如果模型在之前的回复中出现了“幻觉”虚构信息这些错误信息会通过助手提示词污染后续上下文。此时用户提示词需要承担纠正功能而开发者可能需要考虑在历史中删除或标记那条错误的助手消息。关键注意事项盲目保留所有历史可能会带来问题。一是成本增加处理更长的上下文更贵更慢二是可能让模型陷入无关细节。因此设计对话历史的管理策略保留什么、丢弃什么、如何摘要是生产级应用必须考虑的问题。5. 三者的协同与实战中的经典工作流理解了各自的作用后我们来看它们如何协同工作。一个典型的、稳健的LLM应用交互流程是这样的5.1 初始化阶段设定系统提示词应用启动或会话开始时将精心设计的系统提示词加载到对话上下文的开头。这部分内容对用户不可见但对模型有全局约束力。5.2 第一轮交互用户发起助手回应用户输入用户发出第一个请求用户提示词。模型处理模型接收到的完整上下文是[系统提示词] [用户提示词1]。它基于系统规则处理用户指令生成第一个回复。记录历史将(用户提示词1 助手回复1)这对消息保存到对话历史中。5.3 第N轮交互利用完整历史用户输入用户发出第N个请求用户提示词N。模型处理模型接收到的完整上下文是[系统提示词] [用户提示词1 助手回复1 用户提示词2 助手回复2 ... 用户提示词N]。它基于系统规则并参考整个对话历史尤其是之前的助手回复来生成新的回复。更新历史继续保存新的消息对。5.4 实战案例构建一个技术文档问答机器人让我们用一个具体案例串联所有概念系统提示词设计你是“TechDoc Helper”一个专门回答关于“Project Phoenix”API技术文档问题的助手。你的知识来源仅限于提供的官方文档内容。你必须严格基于文档回答如果文档中没有相关信息请明确说“根据现有文档未找到相关信息”。你的回答应专业、准确优先引用文档中的章节和代码示例。如果用户问题模糊请请求澄清。第一轮用户提示词用户“如何认证API请求”第一轮助手回复被记录为助手提示词助手“根据《Project Phoenix API v2.1》第3.2节‘认证’您需要在请求头中使用Bearer Token。具体格式为Authorization: Bearer your_api_key。请确保从项目控制台获取有效的API Key。”第二轮用户提示词用户“如果我收到‘401 Unauthorized’错误该怎么办”模型处理时的完整上下文系统提示词定义角色、知识范围、行为规范。历史用户问“如何认证”助手回答了具体方法和格式。当前用户新问题“收到401怎么办”。模型生成的新回复 模型会结合系统提示词必须基于文档、历史刚刚讨论过认证格式和当前问题生成一个连贯的回复例如“‘401 Unauthorized’通常表示认证失败。请根据文档第3.2节按我上面提到的格式检查1) 您的Authorization头格式是否正确Bearer Token2) 您的API Key是否有效且未过期。如果问题依旧请参考文档第3.5节‘故障排查’。”在这个流程中系统提示词确保了机器人不胡编乱造、不回答无关问题用户提示词驱动了每一轮的具体问答而助手提示词模型自己之前的回复使得机器人能在第二轮中说出“按我上面提到的格式检查”实现了对话的连贯性。6. 进阶从对话到工程化——提示词的管理与测试当你的应用从Demo走向生产环境提示词的管理就成了一项工程。它不再是一段写死的文本而需要被当作可配置、可测试、可迭代的“代码”来对待。6.1 提示词的模块化与版本控制分离配置将系统提示词、常用的用户提示词模板如“总结”、“翻译”、“分类”模板存储在配置文件如YAML、JSON或数据库中而不是硬编码在业务逻辑里。版本管理使用Git等工具对提示词进行版本控制。每次对系统提示词的修改都可能显著影响模型行为必须留有回滚和对比的余地。环境隔离为开发、测试、生产环境配置不同的提示词例如测试环境的系统提示词末尾可以加上“你是测试版本请在回答开头标明[TEST]”。6.2 建立提示词的测试套件不要凭感觉评价提示词好坏。需要建立客观的测试集功能测试集包含一系列标准输入和期望的输出。每次修改提示词后跑一遍测试集确保核心功能没有退化。边界测试集包含各种刁钻、模糊、越界的输入用于测试模型的鲁棒性和是否遵守系统提示词的约束。性能/成本测试监控不同提示词下生成回复的平均长度、耗时和token消耗这直接关联成本。6.3 A/B测试与持续优化对于关键任务如客服机器人、内容生成可以对不同的系统提示词或用户提示词模板进行A/B测试。通过分析用户满意度、任务完成率、人工审核通过率等指标持续迭代和优化提示词。6.4 监控与反馈闭环在生产环境中需要监控模型的输出。可以设置关键词过滤、敏感内容检测等。更重要的是建立用户反馈机制如“回答是否有用”的点赞/点踩将不满意的对话案例收集起来分析是系统提示词约束不够还是用户提示词设计有问题从而形成优化闭环。7. 常见问题排查清单当对话效果不佳时当你发现模型输出不符合预期时可以按照以下顺序进行排查这个清单我每次调试时都会过一遍7.1 检查系统提示词是否清晰无歧义角色、任务、限制是否用最直白的语言写清楚了避免使用比喻或可能产生多重理解的句子。是否存在内部矛盾例如既要求“详细”又要求“不超过50字”。是否过于冗长过长的系统提示词可能导致模型无法抓住重点。尝试精简只保留最核心的指令。是否被覆盖在某些API调用中如果你错误地在后续消息中发送了新的“系统”角色消息可能会覆盖最初的设定。确保系统提示词只在对话开始时发送一次。7.2 检查用户提示词指令是否具体是不是太模糊给了模型太多自由发挥空间上下文是否充足模型是否拥有回答问题所必需的全部信息如果没有需要在用户提示词中补充。格式要求是否明确如果需要特定格式是否在用户提示词中明确指出来了是否与系统提示词冲突例如系统提示词说“只回答中文”但用户提示词是英文的。虽然模型通常会遵循系统指令但清晰的对应关系更好。7.3 检查对话历史助手提示词历史是否被正确传递在API调用中是否完整地包含了之前所有轮次的消息历史是否过长导致被截断如果对话轮次很多模型可能“忘记”了最早的内容。需要考虑实现历史摘要或关键信息提取。历史中是否存在错误引导如果之前模型的某个回复有误这个错误信息可能会影响后续回答。对于关键任务有时需要清空历史或手动纠正。7.4 检查模型与参数模型选择是否合适不同的模型如GPT-4、Claude-3、GLM-4对指令的理解能力和遵循程度有差异。对于要求严格遵循系统提示的任务可能需要选择指令遵循能力更强的模型。温度Temperature参数是否过高过高的温度如0.8以上会增加输出的随机性可能导致模型偶尔“偏离轨道”。对于需要稳定、可预测输出的任务可以尝试降低温度如0.2。是否存在随机性即使所有输入相同模型输出也可能有微小波动。对于需要完全一致输出的场景可以将温度设为0但要注意这可能让回答显得机械。归根结底把“系统、用户、助手”提示词理解清楚并用好是构建可靠LLM应用的第一个硬门槛。我的建议是先从设计一个简单的系统提示词和明确的用户提示词开始跑通一个最小闭环。然后通过观察对话历史助手消息如何影响后续回答逐步迭代优化。记住提示词工程是一个实验和迭代的过程没有一劳永逸的“银弹”最好的提示词往往来自于对业务场景的深刻理解和对模型行为的持续观察。