014、系统提示词（System Prompt）设计

014、系统提示词System Prompt设计上个礼拜调一个RAG对话机器人用户反复问“你记得我刚才说了什么吗”机器人每次都答非所问日志里显示上下文窗口里确实有历史消息但模型就是“装失忆”。我一度怀疑是向量检索把记忆片段冲掉了查了半天最后发现是系统提示词里写了这样一句“You are a helpful assistant that only answers questions based on the provided documents.”好家伙模型直接把“只根据文档回答”理解成了“不要管对话历史”凡是跟资料库无关的话它都拒绝回应。那一刻我意识到系统提示词不是一段装饰性的开场白它是最容易让模型“跑偏”的隐形开关。很多人把System Prompt当成给模型“打鸡血”的地方写一堆“你是一个强大的AI助手请认真负责地回答用户问题”然后发现效果没啥变化就认为系统提示词可有可无。真实情况是系统提示词里的每一个字都可能被模型当成硬性约束尤其是那些带否定词、带“只”“必须”“不要”的句子模型会一本正经地执行哪怕执行结果和用户真实意图相悖。这跟写正则表达式一样你写了个^它就绝不匹配换行后的内容你不要跟它讲道理它只认字面含义。我调试那个机器人时把系统提示词改成“你是用户的工作助手。你可以使用对话历史中的信息帮助用户也可以使用文档知识库中的内容。如果两者冲突以用户最新表达为准。”然后重新跑对话机器人立刻记住了用户刚才提到的名字。这里的关键不是“记得”这个词而是我明确告诉它“对话历史中的信息”是可用的而且要“以用户最新表达为准”。模型不懂“你其实应该隐含地知道哪些信息可以用于回答”它需要一条显式的通道。设计系统提示词最重要的一件事是“列出可用的信息源和它们的优先级”。别写成一句笼统的“请基于所有信息回答”要具体到“你可以参考以下内容1. 用户提供的聊天记录2. 系统内置的文档知识库3. 实时工具返回结果。回答时优先采用实时工具结果其次是知识库内容最后才是聊天记录。”这样模型才不会在面对多路信息时自作主张。我见过不少人在系统提示词里只写“你是客服助手”然后把一堆工具描述堆在函数接口里结果模型把工具输出当成无关噪声因为系统提示词根本没告诉它“工具返回的东西是可信的、可用的”。再强调一个容易踩的坑系统提示词里不要写“如果你不知道答案请直接说不知道”。这句话本身没错但模型对“不知道”的判定非常宽松只要检索结果里没有完全重合的关键词它就立刻说“不知道”哪怕答案换个说法就藏在文档里。更好的写法是“当没有任何信息源能提供与问题相关的线索时请回复‘需要更多信息’并说明缺失哪些内容。如果信息源之间存在矛盾请指出矛盾点并给出你认为最合理的解释。”这样模型会主动做推理而不是甩一句“我不知道”来逃避。写系统提示词还要考虑“角色设定”和“任务约束”的边界。有些工程同学喜欢把角色设定写得特别详细比如“你是一位拥有十年Java开发经验的架构师熟悉微服务熟悉K8s熟悉DevOps……”模型确实会模仿那种语气但你如果不在后面跟上“你的任务是分析用户给的代码片段并指出潜在问题”它就会跑偏去写一套完整的架构方案。角色是风格源任务才是行为边界两者要分开且任务描述需要放在角色描述之后并且用“你的任务是”这样的明确动词引导。另外系统提示词里经常需要放一些“行为规则”但规则数量不要超过5条每条最好用肯定句少用否定句。举例来说不要写“不要输出与代码无关的内容”而要写“只输出代码并附上必要的注释”。前者模型可能理解成“可以输出代码但不要提到代码”后者模型才会老老实实给代码块。我做过对比测试同一份代码分析任务用“不要解释”和用“仅提供修复后的完整代码”两种写法后者给出的结果质量高出一大截因为“不要解释”这个否定指令让模型误以为连注释也不能写结果它真的给了一堆裸代码连返回值长啥样都不说。系统提示词还有个经常被忽略的功能约束输出格式。很多人只在生成完结果之后用正则去解析其实不如直接在系统提示词里定义好结构。比如你要求模型返回JSON别只说“返回JSON”要给出一个模板{结论:简要说明,置信度:0.0-1.0,依据:[列出依据]}同时加上一句“严格按此模板输出不要添加任何额外文字。”这样就能省去解析时的一大堆边界处理。但注意模板里的字段名最好和你的代码变量名一致免得还要做映射。我之前吃过亏模型输出里字段名是“reason”代码里写的是“cause”结果解析不到数据白白加了段格式转换逻辑。系统提示词里最怕的是“前后矛盾”。比如你在前面说“你是客服助手”后面对工具的描述里写“当用户要求退款时请调用退款接口”但你没有说明“退款接口”是不是客服助手可以用的模型就会纠结我到底是以客服身份回复还是以系统操作员身份调用接口我建议把工具能力和角色权限直接绑在一起写比如“作为客服助手你可以使用以下工具查询订单状态、生成退款单。如果用户要求修改订单地址请告知当前暂不支持。”这样模型就清楚自己的能力边界了。现实中的系统提示词往往是多轮拼接出来的。第一轮是静态的系统指令第二轮可能是用户上传文档后系统自动注入的“文档摘要”第三轮可能是工具返回结果转成的一段“观察”。这些拼接内容很容易互相覆盖。我见过一个项目系统提示词里写了“回答请使用简体中文”但工具返回结果里自带一句“Reply in English”模型看到后立刻切到英文。为什么因为在模型眼里越靠后的指令优先级越高。解决办法是在系统提示词末尾加一条“以上所有指令中如果出现与第一条指令冲突的内容请以第一条指令为准。”但这招也不是万能的遇到强工具调用模型工具返回内容依然可能带偏它最稳妥的办法是开发侧过滤工具返回里的指令性文本别让模型看到你不希望它看到的“字”。调试系统提示词时我习惯建一个“坏案例集”。每次遇到模型回应奇怪就把当时的输入和输出记录下来然后对着系统提示词反推是哪条指令导致的。比如前阵子那个“装失忆”问题坏案例就是用户问“你记得我刚说的吗”模型说“我没有检索到相关信息”。我记录后检查系统提示词发现“only answers based on the provided documents”是元凶。把它改成显式的信息源优先级后这个坏案例就不再复现。这个坏案例集比任何评估指标都实用因为你真正要解决的不是平均效果而是那些让用户发火的极端场景。还要注意系统提示词的“温度”。虽然温度参数是用来控制生成随机性的但系统提示词里的确定性描述会间接影响模型的“决策温度”。如果你在系统提示词里写“你是一个谨慎的助手”模型会在不确定时明显减少斩钉截铁的结论而如果你写“你是一个激进的助手”模型在信息不足时也会强行回答。这不算什么玄学是模型对齐了语气词汇背后的分布特征。你可以利用这一点在需要保守场景比如医疗建议里用“谨慎”“尽可能提供保守估计”这类词在需要创意场景里用“大胆”“给出多种可能”这类词但别用反了否则模型会诊时敢开药方创意写作时缩手缩脚。还有一个容易被忽略的细节系统提示词里的“人称”。不同的“你”和“用户”的指代会影响模型的共情方向。如果你写“你是用户的心理咨询师用户正经历焦虑”模型会把重心放在“理解情绪”上如果你写“你是心理咨询师面对一位需要帮助的来访者”模型会把重心放在“专业支持”上。这不是咬文嚼字我实测过两版提示词输出风格差异非常明显。所以你在系统提示词里怎么称呼用户其实是在告诉模型“用户在你心中是什么位置”。建议在服务类场景里称呼“用户”而不是“客户”更不要用“对象”“素材”这类词那会让模型潜移默化地冷冰冰。最后讲一个治本的方法把系统提示词当成代码来维护。不要直接写一大段散文要拆成结构化的片段每个片段加注释像写C语言头文件一样。比如system_prompt [角色] 你是RAG助手服务于内部知识库查询。 [信息源] - 聊天记录优先使用特别是用户明确提到的内容。 - 知识库文档当聊天记录不足时从中检索。 - 工具返回始终作为权威结果若与文档冲突以工具返回为准。 [输出规则] - 只输出JSON不要输出解释。 - 字段: {answer: ..., confidence: 0.0-1.0} [边界] - 如果没有任何信息源能回答问题输出 {answer: 信息不足, confidence: 0.0} 这种写法有几个好处第一每个部分都能单独改你不会为了调一个“信息源优先级”去翻整段话第二你可以用diff工具对比不同版本对模型行为的影响第三新增需求时往对应区块里塞句子不会搞乱原有指令的层级关系。我甚至会在代码仓库里给每个痛点场景建一个prompts/bad_case_*.md里面记录当时的提示词、输入、输出、修复后的提示词这样半年后回来看依然知道当初为什么这么做。系统提示词设计没有银弹但有一条金线永远假设模型是一个“文字上极度较真的同事”它会字面理解你的每一句话而且只按你写的做不按你心里想的做。带着这个假设你自然会避免写歧义句会显式声明信息源会把规则减到最少会在每条规则后面补一个示例。能做到这些你的系统提示词就算合格了。剩下的就交给坏案例集慢慢磨吧。