考察点
这道题考的是候选人对大模型对话机制的理解深度：System Prompt 不是「更长的 Prompt」，它在注意力权重、缓存复用、优先级上都有特殊性。面试官想知道你是否真的在生产环境维护过 System Prompt，追问常落在「System Prompt 太长有什么问题」「指令冲突了模型听谁的」。
参考答案
System Prompt 的特殊性
先讲机制再讲原则。主流模型训练时对 system 角色的消息做了专门的指令遵循强化，它的「权重」天然高于 user 消息——用户说「忽略之前的指令」，模型大概率不会忽略 system 里的内容。另外工程上，System Prompt 是每次请求不变的前缀，vLLM 这类推理框架对它做 prefix caching，前缀部分的 KV Cache 直接复用，省掉重复 prefill 的开销。这两个特性决定了它的定位：放稳定、高优先级的指令。
四条设计原则
第一，只放稳定的东西。 角色设定、业务规则、输出格式、安全红线，这些一次设定长期不变的内容放 System；每轮变化的用户输入、检索结果放 User。混着放既浪费缓存，又让优先级混乱。
第二，规则要可执行、可验证。 「回复要友好」是坏规则，模型没法操作；「回复不超过三句话，不使用感叹号」是好规则。我写规则的标准是：能写成一个单元测试断言的才是合格的规则。这条原则也天然限制规则数量——每条都要能在评测集上验证，规则自然膨胀不起来。
第三，分层组织，别写一堵文字墙。 我们的 System Prompt 按 # 角色、# 业务流程、# 输出格式、# 禁止事项 分节，用 markdown 标题隔开。改业务规则时只动对应小节，diff 清晰，code review 能看。几百行不分段的 System Prompt 维护两次就没人敢动了。
第四，长度克制。 不是越长越安全。指令太多模型会顾此失彼，实测规则堆到几十条后遵循率明显下降，而且每条指令都在消耗每次调用的 token 成本。我们的做法是定期审计：把评测集上过不了的 case 对应规则留下，长期没触发过的规则下线。
常见坑
- 指令互相冲突：一条说「详细解答」，一条说「回复不超过 50 字」，模型只能随机听一个，表现为输出不稳定。上线前把所有规则两两过一遍，有冲突的合并或排优先级。
- 把业务数据写死进去：汇率、活动规则这类会变的业务数据硬编码进 System Prompt，改一次要发版一次。这类信息应该走上下文注入或工具调用。
- 指望 System Prompt 兜底安全：它能提高注入攻击门槛，但不是安全边界。敏感操作的权限控制必须在代码层做，这是安全题里要展开的点。
可能的追问
- System Prompt 和用户指令冲突时模型听谁的？ 训练上 system 优先级更高，但不是绝对的，强越狱话术仍可能覆盖。所以优先级是「提高概率」，不是「保证」，关键防线还得在模型外。
- 多 Agent 系统里每个 Agent 的 System Prompt 怎么管？ 公共部分（安全红线、格式约定）抽成共享片段，角色和工具说明各自维护，渲染时拼装，避免改一处漏十处。
- System Prompt 会影响模型的哪些行为指标？ 直接影响指令遵循率、格式合规率；间接影响幻觉率（约束写得好幻觉会降）和平均输出长度。改动后这些指标要在评测集上回归一遍。