系统提示词和用户提示词有什么区别？用实例讲清分工与优先级

很多人调提示词时把规则、背景、问题全塞在一段里，改来改去不知道哪句起了作用。这篇用几个通用实例，把系统提示词和用户提示词的分工、优先级、以及被覆盖时怎么排查讲清楚，顺带说清哪些场景其实不必分两层。

调提示词最常撞上的场景：把所有要求——角色、语气、禁止事项、这次的任务、粘贴的材料——全塞进一段话，改几轮之后自己也说不清到底是哪句在起作用。分开写之后问题往往更具体：规则写哪一层、两边冲突听谁的、输出不对该动哪一段。这篇不讲概念定义，直接用通用实例把分工、优先级和一个可执行的排查顺序讲清楚。

先给个结论方便你带着看：系统提示词管「一直成立的事」，用户提示词管「这一次要干的事」。前者一次设定整段对话生效，后者每轮都在换。想验证这个分工是不是真的，最简单的办法是把同一段要求拆开放两层跑一遍，看模型先守哪条。

两层各管什么：一句实例看懂分工

拿一个通用例子拆开看。系统层写：「你是客服，只回答产品相关问题，不确定就直说不知道，回答控制在三句话内。」用户层写：「帮我写一段退货话术。」模型会先带着客服身份和三句话的限制去完成退货话术，而不是自由发挥写一篇长文。这个顺手的感觉，就是分工在起作用。

什么情况下不必分两层：一次性问答、不需要稳定人设的临时调用、脚本里单次拼出来的 prompt，把要求写进用户提示词就够了。分层的成本在于多维护一个文件、多一个要回归的变量，没有长期稳定需求时这笔账不划算。

两边打架时听谁的

最常见的冲突长这样：系统层写「只输出 JSON，不要任何解释」，用户层顺手加了句「顺便说说你为什么这么判断」。结果模型两样都给，JSON 外面裹了一段说明，下游解析直接报错。这不是模型不听话，是两条指令都具体、都合理，它只能尽量都满足。

• 优先级不是硬保证：系统提示词通常被当作更靠前的约束，但服从度取决于厂商、模型和指令的具体程度，不是切换开关
• 越具体的指令越容易压过笼统的：系统层写「简洁」、用户层写「每个字段不超过十个字」，后者赢
• 两条都很具体且互斥时，模型会挑一条执行，挑哪条不稳定，同一段提示多跑几次可能换结果
• 真正要防的是重复：同一条约束在两层各写一版，措辞略有差异就变成隐性冲突，比只写一处更危险

什么时候别死磕优先级：任务本身需要模型发挥，比如头脑风暴、创意发散、文案变体，这时越收紧系统层结果越干瘪。这类场景的正确做法是系统层只留安全边界和输出结构，把口径放开，让用户层一次给足方向。

改哪一层：一个排查顺序

1. 一轮只动一层先固定用户提示词，只改系统提示词跑一遍；再反过来。两轮输出对比，哪层动了结果跟着动，说明那层在当前任务里权重更高。
2. 按症状分流输出格式不对、混入额外解释，优先改系统层或改用结构化输出约束；内容不对、缺信息、答偏方向，优先改用户层，把材料和期望补全。
3. 怀疑多层拼接两层都改还是不对，先确认你的系统提示词是不是真的在最前面。客户端模板、中转层、SDK 默认参数都可能悄悄拼进去一段，把你写的内容挤到后面甚至覆盖掉。
4. 做最小可复现把提示词剥到只剩一条系统要求加一句用户输入，如果这时行为正常，说明问题出在你后来加的某条约束上，逐条加回来定位。

不适用的情况也要说清：如果任务是开放式创作，或者你根本控制不了系统层（只能在用户层提要求），上面这套「改系统层解决格式问题」的顺序就不成立，这时该做的是把格式要求写进用户层并接受它更弱。

写两层提示词的清单

• 系统层只放长期不变的东西：角色、语气、禁止事项、输出格式、不确定时怎么办；一句话能说清就别写三句
• 用户层放这次的任务、输入材料、示例、期望长度；材料长的时候明确标出哪段是数据、哪段是指令，别混在一起
• 给约束排序：安全与合规 > 输出格式 > 内容口径 > 风格偏好。冲突时按这个顺序取舍，别让风格要求压过格式
• 把两层都当版本管理的文件，改完用同一组用例回归一遍，别凭一次感觉就定稿
• 回归用的用例至少覆盖：正常请求、边界请求、以及一条故意和系统层冲突的请求，看模型怎么处理

如果你在做的是调用各家接口的产品，系统提示词和用户提示词的拼接方式、参数名、是否支持独立字段，各家并不一致，同一个写法换一家可能行为完全不同。这类差异建议到站内的模型资料与接口说明页面核对当时的字段定义，别照搬另一家的经验。