引言
2023 年中，一个独立开发者做了一件令社区震惊的事：他用一个 3000 字的 system prompt 构建了一个编程助手，在很多场景下比 GitHub Copilot 更好用。
这个 system prompt 包含了详细的编码规范、错误处理模式、代码风格约束、禁止事项，甚至还有「如何组织代码」的具体指导。模型就像一个读过完整员工手册的新员工——它知道公司的规矩，知道什么该做什么不该做。
这个故事揭示了一个核心洞察：system prompt 是你控制模型行为最强大的工具。它是整个上下文工程的基石。
System Prompt 是什么？
三种消息角色回顾
对话结构：
system 消息 → 「你是一个专业的翻译助手，只输出翻译结果，不加任何解释。」
user 消息 → 「Hello World」
assistant 消息 → 「你好世界」
类比：
system = 员工手册（公司规章制度）
user = 客户的提问
assistant = 员工的回答System prompt 的特殊之处：
| 特性 | 说明 |
|---|---|
| 位置 | 永远在对话的最开头 |
| 优先级 | 高于 user 消息中的指令 |
| 不可见 | 通常不展示给最终用户 |
| 持久 | 在整个对话生命周期中有效 |
| 成本 | 每次调用都会发送，占 token 预算 |
为什么 System Prompt 如此重要？
没有 system prompt：
用户：帮我写一段代码
模型：（可能输出 Python、JavaScript、Java...不确定）
（可能带注释、可能不带...不确定）
（可能很长、可能很短...不确定）
有 system prompt：
System: "你是 Python 后端开发专家。只输出 Python 代码。
使用 type hints。每个函数写 docstring。
代码简洁，不超过 50 行。"
用户：帮我写一段代码
模型：（确定输出 Python）
（确定带 type hints 和 docstring）
（确定不超过 50 行）System Prompt 的设计模式
1. 角色设定
python
# 基础角色
{"role": "system", "content": "你是一个有帮助的助手。"}
# 专业角色
{"role": "system", "content": "你是一位有 20 年经验的心内科医生，擅长用通俗语言解释医学知识。"}
# 带约束的角色
{"role": "system", "content": "你是一个严格的事实核查员。只基于已知事实回答。
对于不确定的内容，明确说「我不确定」而不是猜测。"}2. 输出格式控制
python
# JSON 输出
{"role": "system", "content": """你是一个数据分析助手。
始终以 JSON 格式输出，schema 如下：
{
"analysis": "分析内容",
"confidence": 0.0-1.0,
"recommendation": "建议"
}
不要输出 JSON 以外的任何内容。"""}
# Markdown 输出
{"role": "system", "content": "用 Markdown 格式输出。标题用 ##，代码用代码块，列表用 - 符号。"}
# 结构化分段
{"role": "system", "content": "按以下结构回答：1. 摘要（一句话）2. 详细分析 3. 建议"}3. 约束与禁止
python
# 禁止事项（比正向指令更有效）
{"role": "system", "content": """你是一个翻译助手。
规则：
- 只输出翻译结果
- 不要添加任何解释或注释
- 不要说「以下是翻译」之类的话
- 保留原文的格式（段落、列表等）
- 遇到无法翻译的内容，原样保留"""}
# 安全约束
{"role": "system", "content": """你是一个客服助手。
- 不要讨论竞争对手的产品
- 不要承诺具体的价格或折扣
- 涉及退款问题，引导用户联系人工客服
- 不要透露公司内部信息"""}4. 思维链引导
python
{"role": "system", "content": """你是一个数学问题解答者。
回答前，先在 <thinking> 标签中进行推理：
1. 理解问题
2. 列出已知条件
3. 选择方法
4. 逐步计算
5. 验证答案
然后在 <answer> 标签中给出最终答案。"""}好的 vs 坏的 System Prompt
反面案例
python
# 太模糊
"你是一个助手。" # 没有指导意义
# 太长太杂
"你是一个助手，你要...（省略 5000 字）..." # 模型会忽略后面的内容
# 矛盾指令
"简洁地回答。给出详细完整的解释。" # 模型该听哪个？
# 假设模型有人格
"请你开心一点，带着微笑回答问题" # 模型没有情绪正面案例
python
# 清晰、具体、有结构
{"role": "system", "content": """你是一个 Python 代码审查助手。
任务：审查用户提交的 Python 代码，找出潜在问题。
输出格式：
- 每个问题一行，格式：[严重程度] 位置：描述
- 严重程度：🔴 严重 / 🟡 警告 / 🔵 建议
- 最后给出总体评分（1-10）
关注点：
1. 安全漏洞（SQL 注入、XSS 等）
2. 性能问题
3. 代码风格（PEP 8）
4. 逻辑错误
不要修改代码，只指出问题。"""}一个完整的生产级 System Prompt 示例
python
SYSTEM_PROMPT = """你是「智答」AI 客服助手，代表 TechCorp 公司。
## 身份
你是 TechCorp 的官方 AI 客服，帮助用户解决产品使用问题。
## 知识范围
- TechCorp 全线产品（S1-S5 系列）
- 官方文档和 FAQ
- 不了解：未发布的产品、内部定价策略
## 回答规则
1. 先确认用户的问题
2. 给出清晰的步骤式解答
3. 如有相关文档链接，附上链接
4. 不确定时说「我需要确认一下」，不要编造信息
## 禁止事项
- 不要讨论竞品
- 不要承诺具体退款金额
- 不要提供个人联系方式
- 不要讨论与 TechCorp 无关的话题
## 特殊处理
- 用户情绪激动时：先表示理解，再提供解决方案
- 涉及安全问题时：优先引导联系人工客服
- 超出能力范围时：提供人工客服转接方式"""
# 字数：约 200 中文字 ≈ 300-400 tokens
# 这是 system prompt 成本和效果的平衡点System Prompt 的局限
System Prompt 能做到：
✓ 设定角色和行为框架
✓ 控制输出格式
✓ 设定禁止事项
✓ 引导思维过程
✓ 保持多轮对话的一致性
System Prompt 做不到：
✗ 保证 100% 遵守规则（模型可能「越狱」）
✗ 替代实时数据（它是静态文本）
✗ 解决长对话中的「遗忘」问题
✗ 保证输出格式永远合法（需要 Structured Outputs）本节小结
| 概念 | 要点 |
|---|---|
| System Prompt | 对话开头的全局指令，类似员工手册 |
| 核心作用 | 角色设定、格式控制、行为约束、思维引导 |
| 设计原则 | 清晰具体、有结构、不矛盾、长度适中 |
| 成本考量 | 每次调用都发送，控制在 300-500 token 为宜 |
| 局限性 | 不能 100% 保证遵守，不能替代实时数据 |
思考题
- 如果你给模型设定的 system prompt 是「你是一个永远说真话的助手」，模型就一定会说真话吗？为什么？
- 为什么说 system prompt 是「上下文工程的基石」？它和后续课程要讲的 RAG、Tool Call 有什么关系？
- 设计一个 system prompt，让模型扮演一个「只会用比喻来解释概念」的老师。测试一下它有效吗？