system 消息的作用
system 消息是聊天式接口里承载全局设定的位置：身份、职责边界、固定风格与输出约定放这里，会在整段会话中持续生效。与逐轮在 user 消息里重复要求相比，它写一次就够，既省长度也更稳定；多轮对话到十几轮后，user 里的要求容易被中间内容淹没，system 里的约定留存得更久。不同平台对 system 角色名称、数量与优先级处理并不一致，跨平台迁移前要用目标平台的官方文档复核。
放什么不放什么
| 放什么 | 身份与职责范围、固定输出格式、语气与免责要求、明确不做的事 |
|---|---|
| 不放什么 | 每次都会变的输入数据、一次性任务指令、与本次任务无关的背景 |
| 生效范围 | 整个会话（多轮），直到被新的上下文挤占或用户话术覆盖 |
| 长度 | 3-8 行可读性最好；过长会与历史消息争抢注意力预算 |
| 迁移差异 | 有的平台只允许一条 system，有的支持多条并按顺序拼接 |
典型使用场景
- 企业内问答助手：限定服务范围与转人工条件，减少越界回答
- 格式固定产线：把字段清单与单位约定放 system，user 只传本次数据
- 客服/工单场景：规定语气、禁用承诺话术、涉及账号权限时统一回复口径
- 多轮排障：固定「先结论后步骤」的回答结构，让每次输出都能直接照做
- 教学讲解：声明读者知识水平，避免反复在 user 里调整解释深度
system 消息示例
system 消息示例
system: 你是某企业内网 IT 支持助手，只处理办公设备与网络接入类问题。 # 身份与范围
回答格式：先给结论，再给不超过 3 步的操作步骤。 # 固定结构
涉及账号密码、权限变更的操作，一律回复「请联系 IT 服务台」，不做推测。 # 硬性边界
user: 打印机报错 E-052，怎么处理？多轮里的位置关系
多轮里的位置关系
[
{"role": "system", "content": "全局规则：输出简体中文；金额两位小数；不解释内部实现"},
{"role": "user", "content": "本次数据：对账单如下……"},
{"role": "assistant", "content": "（上一轮回复）"},
{"role": "user", "content": "继续处理第 2 页"}
]
# 规则留在 system，每轮只换 user 里的数据，历史回复由平台维护常见失效与改法
| 现象 | 原因 | 改法 |
|---|---|---|
| 后几轮格式松掉 | 全局规则被长对话稀释 | 在 user 消息末尾阶段性复述关键约束 |
| 用户一句话就让助手越界 | 把 system 当安全边界 | 硬限制放程序侧：白名单工具、权限校验、输出过滤 |
| 缓存命中率低、费用偏高 | 把逐次变化的输入写进 system | 稳定规则留在 system，数据放 user |
| 换了平台行为不同 | 各家对 system 的处理与优先级不同 | 迁移时按目标平台文档复核并重跑回归用例 |
system 提示不是安全边界：用户可用多种话术尝试覆盖它；硬限制要放在程序侧校验（见提示注入相关条目）。
写 system 时用可验收的表述：不写「回答要专业」，改写「术语首次出现时用一句话解释，结论从可行/不可行/待验证中三选一」。