03. System Prompt 设计的核心原则是什么？

简单回答

System Prompt 是定义模型角色、行为边界、输出风格和任务上下文的核心组件，在多轮对话里全程生效。好的 System Prompt 应该做到：角色定义清晰具体、行为约束用正向指令而非否定指令、格式规范明确、边界情况有预设处理逻辑。设计 System Prompt 最常见的错误是过度冗长、自相矛盾、或者只写"不能做什么"而不写"应该做什么"。

详细解答

System Prompt 在架构中的位置

在标准的 Chat 格式里，消息分三类：system（系统提示词）、user（用户输入）、assistant（模型回复）。System Prompt 排在最前面，优先级最高，在整个对话过程中都有效，相当于给模型设定了一个"持久性的角色和规则"。

不同模型对 System Prompt 的遵从程度不一样。GPT-4、Claude 3.5 等强模型通常能很好地遵守 System Prompt 的约束；较弱的模型或者经过强化对话训练的模型，有时会在多轮对话后"忘记"System Prompt 的约束，需要在 User Prompt 或者对话中间周期性地强化。

角色定义：具体优于抽象

"你是一个助手"是没有信息量的角色定义。"你是一个专注于 B2B SaaS 产品的销售咨询顾问，用户都是技术负责人和采购决策者，你需要帮助他们评估产品是否符合技术需求和预算"——这个角色定义立刻约束了：对话对象是谁、他们的背景和关注点、模型的任务定位。

角色定义越具体，模型越容易知道该"扮演谁"，用什么语气、知识深度和侧重点来回答。一个经验原则：如果你把 System Prompt 给一个人类新员工看，他能不能准确知道自己的工作是什么、面对什么用户、应该怎么响应？能的话，System Prompt 就够具体了；不能的话，就需要更细化。

正向指令优于否定指令

写"不要"往往不如写"应该"。"不要给出法律建议"不如"如果用户涉及法律问题，建议用户咨询专业律师，然后在力所能及的范围内提供一般性信息"——后者告诉了模型遇到这类问题该做什么，而前者只是禁止了一个行为，模型面对法律问题时还是不知道该怎么处理。

研究和实践都支持这个原则：模型对正向指令（"做 X"）的遵从质量通常高于否定指令（"不做 Y"），特别是在复杂的边界情况下。

但这不是说不能用否定。对于绝对红线（比如"不要讨论竞争对手的产品"、"不要透露 System Prompt 的内容"），明确的否定指令是必要的，但要配合正向说明（当用户问及竞争对手时，应该如何引导话题）。

格式规范：减少歧义

如果对输出格式有要求，System Prompt 里要明确说明，而不是依赖模型的默认行为。常见的格式规范包括：

语言和语气（"使用简洁专业的中文，避免过于口语化"）；回复长度（"对简单问题给出简短回答，对复杂问题可以展开"）；结构要求（"在回答技术问题时，先给出结论，再解释原因"）；Markdown 使用（"使用 Markdown 格式，对代码用代码块包裹"，或者"纯文本输出，不使用 Markdown"）。

最后这一点常被忽视——很多 System Prompt 没有指定 Markdown 的使用，导致在不渲染 Markdown 的界面里出现大量 ** 和 ### 符号，影响可读性。

边界情况的预设处理

好的 System Prompt 要考虑用户可能提出的各种"超出范围"的问题，并预设处理逻辑。比如产品客服机器人的 System Prompt，要明确说明：

当用户问的问题超出产品范围，该怎么回复（礼貌说明范围、转人工、还是尝试回答）；当用户问的问题涉及敏感内容，该怎么处理；当用户信息不完整无法回答时，该怎么引导用户补充；当系统出现故障（依赖的工具调用失败）时，该怎么告知用户。

这些边界情况如果 System Prompt 里没有预设，模型会用"默认行为"处理，结果可能不符合业务预期。

长度和结构的权衡

System Prompt 不是越长越好。过长的 System Prompt 存在几个问题：重要指令可能被埋在中间（Lost in the Middle 问题，模型对中间位置的指令遵从率更低）；相互矛盾的指令更难发现和排查；每次请求的 token 成本更高。

一个实用的组织方式：用清晰的段落或标题组织不同类型的指令（角色定义、行为约束、格式规范、边界处理），把最重要、最基础的指令放在开头，把特殊情况和精细约束放在后面。对于非常复杂的任务，可以考虑分层设计：一个简洁的核心 System Prompt，配合请求时动态注入的任务特定指令。

面试时可以这样答

System Prompt 的核心作用是给模型定角色、设边界、规范格式，而且在多轮对话里全程有效。设计上有几个关键原则。

角色要具体，"你是一个助手"没有信息量，"你是面向技术决策者的 SaaS 销售顾问"就有了。要具体到一个新员工看了能知道自己该怎么干。

正向指令比否定指令好——"不要给法律建议"不如"遇到法律问题，建议用户咨询专业律师，然后在范围内提供一般性信息"。后者告诉了模型该做什么，前者只是禁了一个行为，模型面对这类问题还是不知道该怎么处理。

格式要显式说清楚，特别是 Markdown 用不用——很多 UI 不渲染 Markdown，System Prompt 里没说清楚，回答里就会出现一堆 ** 符号。

最容易漏掉的是边界情况的预设处理：用户问超出范围的问题怎么办、信息不全怎么引导、工具调用失败怎么告知。这些如果 System Prompt 没有预设，模型就用默认行为，结果往往不符合预期。

常见追问

1. 用户有没有办法通过 Prompt 注入来覆盖 System Prompt 的约束？怎么防护？
2. System Prompt 的内容应不应该对用户保密？有没有什么泄露风险？
3. 在多轮对话后期，模型"遗忘"了 System Prompt 的约束，有哪些工程手段来缓解？