system prompt 和 user prompt 有什么区别？为什么指令要放 system？
谁在问：一面必问（各类公司通用）；追问深度直接决定分档
口语化问法
- system 和 user 有什么区别？你写提示词的时候怎么分？
- 为什么大家都说指令要放 system 里？放 user 里不行吗？
- 你们客服机器人那条『不能承诺退款』的规则，写在哪儿？
考察意图
一面的经典送分题，但它的价值全在追问链上。面试官真正想看三件事：
- 你知不知道 API 是无状态的、多轮对话是怎么拼出来的；
- 你能不能把「放 system」这个习惯，讲成一个有成本和缓存依据的工程决策，而不是一句听来的规矩；
- 你会不会误以为 system 是安全边界。
第三点答错的人，后面聊提示词注入和权限设计基本聊不下去。
参考答案
60 分答案（及格线）
system 定义模型的角色、语境和行为边界，是整个会话里基本不变的部分；user 是本轮用户的具体诉求；assistant 是模型此前说过的话，回传给它才能形成多轮。
指令放 system，一是模型对 system 里的内容优先级更高、更稳定地遵守；二是它不随每轮变化，便于统一维护，改一处全局生效。
90 分答案（有生产经验的回答）
在上面基础上加三层：
第一，Messages API 是无状态的。 所谓多轮对话，是每一轮把 system + 全部历史 + 本轮 user 重新发一遍——模型没有记忆，记忆在我的应用里。这直接决定了成本模型：长会话的费用是累加而不是常数。
第二，「放 system」不只是优先级问题，更是缓存问题。 服务端按 tools → system → messages 的层级建立缓存前缀，改上层会让下层全部失效。所以恒定内容必须靠前、变化内容必须靠后。我们踩过一次反面案例：把一条产品规则拼进了每轮 user 前缀，结果缓存命中率恒为 0、同一条规则被重复计费十几次，而且它跟用户输入紧挨着、来源标签相同，绕过成本极低——一个位置错误，同时打到成本、性能和安全三处。
第三，system 不是安全边界。 角色是训练出来的优先级倾向，不是操作系统级的隔离。OWASP 在 2026-08 发布的新版 LLM Top 10 里，把原来的「系统提示词泄露」更名并扩展为 Hidden Context Exposure，涵盖你拼进窗口但不打算给用户看的一切，包括每一个工具 schema。它的准则是：假定它会泄露，所以不放凭证、不靠它做授权。真正的防线在执行层和权限层。
追问链
那 API 是有状态的吗？多轮对话到底怎么实现的？
期望无状态。每轮由客户端把完整历史重新发一遍 → 上下文长度和成本随轮次增长 → 「模型记得上一轮」是应用层回传造成的错觉信号答「API 会自动记住」→ 基本没独立写过多轮应用，只用过封装好的 SDK 会话对象；这一问筛掉一大半为什么把指令放 system 能省钱？说具体点。
期望稳定前缀可被缓存复用，命中时这部分输入按远低于原价计费；缓存按tools → system → messages层级建立，改上层废下层；断点要落在跨请求完全一致的最后一个块上 —— 落在带时间戳或本轮输入的块上，等于每次付写入费、永远读不到信号把「省钱」归到缓存前缀机制、说得出层级顺序 → 真调过账单；只说「少写点字就省钱」→ 想当然把「绝不承诺退款」写进 system，用户能绕过吗？为什么？
期望能。模型无法可靠区分「指令」与「数据」—— 两者最终都是同一条 token 序列上的内容，只差一个来源标签，而标签带来的是概率倾向不是硬隔离；提示词层只能降低概率，真防线在执行层：退款这个动作有没有 API 权限、金额上限、人工确认信号说「写在 system 里就安全」→ 直接淘汰这一档；主动把防线推到执行层与权限层 → 理解了核心2026 年系统提示词的写法有什么变化？
期望在变薄：截至 2026-08，Anthropic 删掉了 Claude Code 系统提示词的 80% 以上，编码评测无可测损失。三个转变：给规则→让模型自己判断、给示例→设计更有表达力的接口、全部前置→渐进披露。留下的是模型推不出来的：品牌口径、价格底线、审批权限、保密边界信号说清「删的是模型能自己推断的、留的是只有你知道的」→ 读过一手材料且想过；只说「提示词要简洁」→ 泛泛客服 system prompt 4000 字、60 多条禁令，换新模型后犹豫、自相矛盾、延迟涨，怎么治？
期望① 先做冲突审计，别急着删：把打架的指令挑出来（一处要「简洁」、一处要「详尽解释每步」），延迟涨有一部分正是模型在冲突里做判断 → ② 按「谁推得出来」分类：格式习惯、语气、常识性禁止先删，价格底线、审批权限、合规口径、保密边界保留 → ③ 长内容改渐进披露按需加载 → ④ 每删一批跑一次评测，别一次性重写 → ⑤ 顺手修缓存：稳定块前置、断点落恒定块末尾信号先说「先审冲突，不是先删」并明确「每删一批跑评测」→ 做过灰度；答「照最佳实践重写一版」→ 没做过归因
评分要点
- 说清三个角色各自承载什么
- 明确 API 无状态、历史由客户端回传
- 能把「放 system」关联到缓存前缀与成本，而不只是优先级
- 知道缓存层级是 tools → system → messages，改上层废下层
- 明确 system 不是安全边界，并给出替代防线
- 知道 2026 年系统提示词在变薄，说得出删什么留什么
- 治理旧提示词时先审冲突、分批删、用评测验证