三种消息角色怎么分工
聊天式接口把一次请求拆成消息数组，每条消息带一个角色。system 承载全局规则，跨轮有效；user 承载本次要处理的输入与任务；assistant 承载此前的回复，多轮对话时由平台或调用方维护。这个分工的意义是让稳定的内容与变化的内容各归其位：规则写一次就够，数据每轮替换，既省 token 也让改动范围清晰。
角色分工
| system | 全局、稳定、跨轮有效：身份、职责边界、固定格式与风格 |
|---|---|
| user | 每次变化的任务输入与数据，附本次的临时要求 |
| assistant | 历史回复（多轮上下文）或预填的部分输出 |
| 预填技巧 | 在 assistant 位置预填开头（如左花括号），可抑制客套开场并锚定格式 |
| 顺序 | 多轮时按时间顺序排列，最后一轮是本次的 user 输入 |
典型使用场景
- 多轮客服助手：规则固定在 system，客户消息逐轮追加为 user
- 格式锚定：在 assistant 预填 {"result": 让输出直接进入 JSON
- 角色扮演与教学：system 定身份与讲解深度，user 只提问题
- 批量任务：同一 system + 同一模板，user 只换数据，便于并行处理
- 上下文维护：超过窗口后由程序裁剪最早的轮次，保留 system 与最近几轮
消息数组示例
消息数组示例
[
{"role": "system", "content": "全局规则：输出中文；金额保留两位小数；不做内部实现解释"},
{"role": "user", "content": "本次输入：对账单如下……"},
{"role": "assistant", "content": "{"} # 预填输出开头，锚定 JSON 格式
]
# 规则留 system，数据放 user，历史回复由平台维护放错位置的后果
| 内容 | 放错的典型位置 | 后果 |
|---|---|---|
| 全局格式规则 | 每轮 user 末尾重复 | 提示变长、规则容易随轮次偏移 |
| 本次数据 | system | 缓存命中率下降，规则与数据混在一起难以维护 |
| 临时的一次性要求 | system | 沉淀成长期约束，影响后续所有轮次 |
| 历史回复 | user 里以「之前你说过」转述 | 上下文失真，模型按转述作答 |
不同平台对 system 的数量、可编辑性与优先级处理不一致；把同一套提示迁移到另一平台时，先复跑一批回归用例再上线。