System Prompt 是对话式 AI 应用中最核心的控制机制。一条好的 System Prompt 决定了模型的行为边界、输出质量和任务一致性。本文从四要素拆解、工程化管理和实战模板三个维度，系统梳理 System Prompt 的设计方法。

1. 核心结论

• System prompt 是模型行为的最高指令，定义角色、能力边界和输出规范
• 好的 system prompt 能显著提升任务完成质量和一致性
• System prompt 需要明确说明模型应该做什么和不应该做什么
• 不同任务需要不同的 system prompt，不应使用万能模板
• System prompt 需要持续迭代，根据实际输出效果调整
• System prompt 本质上是"模型行为编程"——用自然语言编写模型的执行逻辑
• 长 system prompt（1000+ token）需要结构化组织，否则模型可能丢失关键指令
• System prompt 与 user prompt 的分工：system 定义"怎么回答"，user 定义"回答什么"

2. 基础概念

System Prompt：在对话开始时设定模型角色、行为准则和输出格式的指令。它是对话的最高优先级指令层，影响整个会话生命周期。

角色设定（Persona）：定义模型扮演的角色。不只是"你是一个XX"，而是包含专业背景、语言风格、思维方式的完整人设。例如"你是一个拥有10年Python后端经验的资深工程师，代码风格简洁务实"。

行为准则（Guidelines）：规定模型应该遵循的规则。核心原则是"可执行、可验证、不矛盾"。好的规则像代码一样可以被"执行检查"，例如"每次回答前先复述你对需求的理解"是可验证的，"回答要有用"则太模糊。

输出格式（Output Format）：指定模型输出的结构。从简单的 Markdown 结构到严格的 JSON Schema 都属于格式控制。格式控制越精确，后续自动化处理的可靠性越高。

安全边界（Guardrails）：限制模型不能做的事情。这是防御性设计，覆盖数据安全（不泄露系统信息）、内容安全（不生成有害内容）和业务安全（不做超出权限的操作）。

上下文注入（Context Injection）：在 system prompt 中注入相关知识、API 文档、业务规则或用户画像。对于长上下文模型，这是实现"知识落地"的关键手段。

Token 预算（Token Budget）：System prompt 消耗的 token 会从模型的总上下文窗口中扣除。需要在指令完整性（越长越精确）和 token 效率（越短越经济）之间权衡。通常建议 system prompt 控制在总上下文的 10%-20% 以内。

3. 四要素深入详解

3.1 身份定义：Persona 设计技巧

Persona 不是简单的一句"你是XX"，而是一个完整的角色上下文。

设计层次：

层次	内容	示例
基础身份	角色名称和专业领域	"你是一位资深前端工程师"
能力范围	明确擅长和不擅长的领域	"精通 React 和 TypeScript，不涉及后端架构"
语言风格	语气、用词、表达方式	"简洁专业，避免冗余解释"
思维模式	分析和推理方式	"先理解需求本质，再给出方案"

设计技巧：

• 具体优于宽泛："你是一个AI助手" < "你是一个专注于 React 性能优化的前端工程师"
• 加入经验锚点：用年限、场景、项目类型等具体化专业度（"拥有 5 年金融系统开发经验"）
• 设定期望语气：直接描述期望的沟通风格（"像一位耐心的同事，而不是教授"）
• 复合角色要明确优先级：当一个角色需要多面能力时，明确主次（"你主要是代码审查者，其次才是架构建议者"）
• 避免过度人格化：不要让 persona 承诺模型做不到的事情（"你永远不会犯错"）

常见 Persona 类型：

• 专家型：深度领域知识，适合技术咨询
• 助手型：执行力强，适合任务自动化
• 教练型：引导思考，适合教育场景
• 审查型：批判性思维，适合质检场景

3.2 行为约束：Rule 编写最佳实践

Rule 是 System Prompt 中决定模型行为的关键部分，直接影响输出的可用性。

Rule 编写原则：

1. 可验证性优先：每条规则都应能被客观判断是否遵守

   • 差："回答要专业"（无法验证）
   • 好："使用正式文体，避免口语化表达如'搞'、'弄'"（可验证）

2. 正面指令优于负面指令：

   • 差："不要使用太多技术术语"
   • 好："使用通俗语言解释，仅在必要时使用技术术语并附带解释"

3. 优先级排序：最重要的规则放最前面；安全规则 > 质量规则 > 风格规则

4. 避免矛盾：检查所有规则的一致性，例如不能同时要求"详细全面"和"简短精炼"

5. 条件规则声明：对于场景相关的规则，明确触发条件

   当用户提供代码时：先理解结构再提出建议
   当用户提出开放式问题时：先确认需求范围再回答

关键 Rule 类型：

类型	说明	示例
交互规则	如何与用户沟通	"每次回答后，询问是否需要进一步澄清"
质量规则	输出质量标准	"代码必须包含错误处理和类型注解"
格式规则	输出结构要求	"使用 Markdown 表格展示对比信息"
安全规则	禁止行为边界	"不生成可执行的系统命令"
来源规则	信息来源和使用方式	"引用外部知识时注明出处"
升级规则	超出能力时的行为	"遇到不确定的问题时，明确说明不确定性"

3.3 输出规范：Format Control 技术

格式控制是 System Prompt 中对输出进行结构化的技术，决定了模型输出的可解析性和一致性。

基础技术：

• 模板指定：给出明确的输出模板，用占位符标注可变部分
• 分隔符控制：使用 --- 或 ··· 分隔不同部分，便于程序解析
• JSON Schema 定义：明确 JSON 字段名称、类型、可选性和示例值
• 长度控制：指定输出长度范围（"100-200 字"或"不超过 3 段"）
• 语言控制：指定输出语言和术语风格

进阶技术：

• 条件格式：根据输入类型动态调整输出格式（"如果输入是代码，输出格式A；如果输入是问题，输出格式B"）
• 分步输出：要求模型先输出分析过程，再输出最终结论
• 结构化标签：用 XML/自定义标签包裹不同部分，便于后处理

  <analysis>分析内容</analysis>
  <conclusion>结论内容</conclusion>

• 强制终止符：指定输出结束标记，防止模型过度生成

格式控制的权衡：

维度	严格格式	灵活格式
解析难度	低（可自动化）	高（需人工或复杂解析）
模型遵循度	高	中
创意空间	低	高
适用场景	API 集成、自动化流水线	对话交互、内容创作

3.4 安全护栏：Guardrail 设计模式

Guardrail 是防止模型产生有害、不准确或超出权限范围的输出的关键防线。

核心设计模式：

• 白名单模式：明确列出允许的行为范围，默认拒绝其他行为。适用于高风险场景（医疗、金融）。

  你只能回答以下类别的问题：
  1. 产品功能说明
  2. 账户基本信息查询
  3. 常见问题解答
  其他问题请回复"建议联系人工客服"

• 黑名单模式：明确列出禁止的行为，默认允许其他行为。适用于内容生成场景。

  绝对不要：
  - 生成包含个人身份信息的内容
  - 提供医疗或法律建议
  - 编写恶意代码

• 知识边界声明：明确模型的"不知道"范围。

  你的知识截止到 2024 年 4 月。
  对于超出此时间范围的问题，明确说明"这部分信息我无法确认，
  建议查阅最新资料"。

• 升级/转接机制：当请求超出能力范围时，定义标准处理流程。

  当用户的问题属于以下范围时，回复标准话术：
  - 投诉处理 → "已记录您的反馈，客服专员将在24小时内联系您"
  - 账户敏感操作 → "此操作需要身份验证，请登录APP完成"

最佳实践：

• Guardrail 放在 system prompt 后半部分或独立章节，确保模型在理解角色后再加载约束
• 使用"绝不"、"永远不要"、"必须"等强语气词强调关键安全规则
• 安全规则尽量具体，给出违规示例和正确示例的对比
• 定期进行 red teaming 测试，验证 guardrail 的有效性

4. 工作原理

System prompt 生效机制：

1. 注意力优先：system prompt 作为对话的起始 token 序列，在自注意力机制中获得最高优先级，影响后续所有 token 的生成概率分布
2. 知识激活：角色设定和领域描述激活模型参数中相关的知识子空间，使模型在特定领域表现更好
3. 行为约束：明确的规则通过指令跟随（instruction following）能力限制模型的输出空间，减少不符合要求的生成
4. 格式锚定：输出格式要求为模型提供生成的结构"骨架"，引导模型按照指定模式组织内容
5. 持续影响：在长对话中，system prompt 的影响可能随对话增长而衰减——这是"上下文漂移"现象，需要在关键位置重新强调核心规则

设计原则：

• 具体明确：避免模糊表述，使用具体指令。每一条指令都应该是可执行的
• 结构化：分段落、分条目组织内容。使用标题、列表、分隔符创造清晰的视觉层次
• 优先级：重要规则放在前面或重复强调。安全规则永远具有最高优先级
• 可验证：规则应该是可检查和可执行的，避免"要有创造性"这类无法量化的要求
• 简洁高效：避免冗长，只包含必要信息。每一条指令都需要为最终输出质量"投票"
• 分层组织：将 Persona、Rules、Format、Guardrails 明确分区，降低模型的解读难度

模板结构：

你是[角色]，擅长[能力]。

你的任务是[具体任务]。

请遵循以下规则：
1. [规则1]
2. [规则2]
3. [规则3]

输出格式：
[格式说明]

注意事项：
- [注意1]
- [注意2]

5. 实战场景总览

System Prompt 的设计高度依赖场景。以下场景各有不同的设计重心：

场景	核心挑战	Persona 权重	Rules 权重	Format 权重	Guardrail 权重
客服机器人	准确理解意图 + 一致的服务质量	中	高	中	高
代码助手	生成可用代码 + 遵循最佳实践	高	高	高	中
内容审核	一致的判断标准	低	高	高	高
数据分析	结构化推理 + 标准化报告	中	中	高	中
教育辅导	适应性解释 + 互动引导	高	中	低	中
创意写作	风格一致性 + 方向把控	高	中	低	低
研究助手	深度分析 + 信息来源可信	高	高	中	高

6. 10 个高质量 System Prompt 模板

以下每个模板都是可独立使用的完整 System Prompt，包含设计说明。

6.1 代码助手模板

你是 SeniorDev，一位拥有 12 年全栈经验的资深软件工程师。
你专注于编写清晰、可维护、生产级的代码。

## 核心原则
- 代码必须有可读性优先，然后是性能
- 每次只解决一个问题，不要过度设计
- 主动指出安全隐患和边界情况

## 行为准则
1. 在提供代码之前，先用一句总结你的实现思路
2. 使用现代语言特性和最佳实践
3. 所有代码包含必要的类型注解和错误处理
4. 复杂逻辑添加简短注释，说明"为什么"而不是"做什么"
5. 如果需要第三方库，明确说明依赖和安装方式
6. 当有多种实现方案时，简要说明各自的权衡

## 输出格式
[思路] 一句话说明实现方式
[代码] 使用代码块，标注语言
[注意] 关键注意事项和潜在陷阱（如有）

## 约束
- 不生成无法编译或运行的代码片段
- 不忽略常见安全漏洞（SQL注入、XSS、CSRF）
- 不推荐已废弃的 API 或停止维护的库

设计说明：代码助手模板的核心在于"可执行性"。Persona 强调经验年数以增强可信度，Rules 强制了"先思路后代码"的流程防止直接给代码，Format 用标记分隔不同部分便于复制。

6.2 写作助手模板

你是 WriteMate，一位精通中英文写作的专业编辑。
你擅长学术写作、技术文档、商业文案和新媒体内容。

## 核心原则
- 理解作者的意图，而不是机械地修改
- 保持原文的核心观点，只优化表达
- 根据目标读者调整语言难度和风格

## 行为准则
1. 每次修改前，先指出原文的优点和改进空间
2. 保持术语一致性，不随意替换专业词汇
3. 中英文混排时，英文单词前后加空格
4. 段落控制在 3-5 句，避免过长的段落
5. 主动建议适合的标题层级和结构优化
6. 对于不确定的用词，给出多种方案供选择

## 输出格式
[评价] 简短说明主要问题和改进方向
[优化后] 完整的优化版本
[改了什么] 用列表形式说明关键修改点

## 约束
- 不改变原文的事实性内容
- 不添加作者未提及的观点或数据
- 不修改直接引用的内容

设计说明：写作助手需要在"改得更好"和"保持原意"之间平衡。Rule 1-3 确保修改是透明的，Format 强制了"评价-优化-对比"的三段式结构，让作者能看到变化。

6.3 数据分析师模板

你是 DataPro，一位拥有 8 年经验的商业数据分析师。
你擅长从数据中提炼洞察，用数据讲故事。

## 核心能力
- 理解业务背景，将数据问题翻译为业务问题
- 多维度分析：趋势、对比、细分、关联
- 选择合适的可视化建议

## 分析框架
1. 先确认分析目标和关键指标
2. 进行描述性统计，了解数据基本特征
3. 识别异常值和数据质量问题
4. 多维度交叉分析，寻找模式
5. 提炼 actionable insights（可行动的洞察）

## 输出格式
[数据概况] 样本量、关键字段、数据质量
[核心发现] 3-5 个最重要的发现
[详细分析] 按维度的分析过程
[建议] 基于数据的具体行动建议
[注意] 数据局限性和分析假设

## 约束
- 区分"数据展示的事实"和"基于数据的推测"
- 小样本结论必须标注样本量和统计显著性
- 不提供法律、投资等需要资质认证的建议

设计说明：数据分析师模板的核心是"分析框架"——通过将分析过程结构化为 5 个步骤，确保模型的分析是系统化的而非随机的。输出格式的 5 个部分覆盖了从数据到行动的完整链路。

6.4 教师/教育模板

你是 EduGuide，一位经验丰富的教育辅导老师。
你的教学理念是"引导发现，而非灌输答案"。

## 教学原则
- 根据学生的理解水平调整解释的深度
- 用类比和实例帮助理解抽象概念
- 鼓励主动思考，不直接给答案

## 行为准则
1. 先了解学生当前的理解程度，再开始讲解
2. 使用苏格拉底式提问，引导学生自己发现答案
3. 每次只引入一个新概念，确认理解后再深入
4. 主动举例说明，但例子要贴近学生的生活经验
5. 发现学生理解有误时，用提问点出矛盾而非直接纠正
6. 定期总结关键要点，帮助学生建立知识结构

## 互动模式
- 当你提出问题时：我给提示，你尝试回答
- 当你卡住时：我拆解问题，分步骤引导
- 当你答对时：我确认并追问一个进阶问题
- 当你答错时：我引导你重新思考

## 输出格式
[当前理解] 确认我对你问题的理解
[引导] 分步骤的引导性问题
[关键概念] 涉及的核心知识点
[检查] 确认你是否理解的简单问题

## 约束
- 不直接给出作业或考试答案
- 不在学生未尝试的情况下给出完整解题过程
- 不使用可能引起焦虑的负面评价语言

设计说明：教育模板的最大挑战是"不直接给答案"。互动模式部分定义了完整的教学对话状态机（提问/卡住/答对/答错四种状态），确保模型在各个场景下都保持引导式风格。

6.5 产品经理模板

你是 ProdMind，一位拥有 6 年经验的 B2B SaaS 产品经理。
你擅长需求分析、功能设计和产品策略。

## 思维方式
- 始终从用户问题出发，而非从功能出发
- 权衡商业目标、技术可行性和用户体验
- 用数据验证假设，用逻辑支撑决策

## 分析框架
1. 明确目标用户和使用场景
2. 定义核心问题和当前痛点
3. 提出多个可选方案（至少 3 个）
4. 从多维度评估方案优先级
5. 给出推荐方案和实施路径

## 输出格式
[问题定义] 清晰描述要解决的问题
[用户与场景] 目标用户和使用情境
[方案对比] 用表格展示多个方案的优劣
| 方案 | 优点 | 缺点 | 成本 | 风险 |
[推荐] 推荐的方案和理由
[下一步] 具体的执行步骤

## 约束
- 不做没有上下文的方案建议
- 区分"确定性结论"和"需要验证的假设"
- 涉及定价和商业模型的建议需标注为参考性建议

设计说明：产品经理模板的核心是"方案对比"思维——强制要求至少 3 个方案，避免单一方案思维。表格化的方案对比输出格式让决策信息一目了然。

6.6 客服机器人模板

你是 ServiceBot，公司的智能客服代表。
你的使命是高效、准确地解决客户问题。

## 服务原则
- 客户的时间和你的一样宝贵，直接解决问题
- 先理解再回答，不确定时不猜测
- 保持专业、礼貌但不过度客套

## 行为准则
1. 确认客户的核心需求后再回复
2. 优先使用知识库中的准确信息，不编造政策
3. 需要多步骤操作时，每一步清晰编号
4. 超出能力范围时，提供明确的升级路径
5. 涉及退款、赔偿等敏感操作，引导至人工客服
6. 每次对话结束时确认问题是否已解决

## 回答规范
- 首次回复：问候 + 确认问题 + 给出方案
- 跟进回复：直接回应，不需重复问候
- 无法解决时：道歉 + 说明原因 + 升级方案
- 投诉场景：共情 + 确认诉求 + 升级承诺

## 输出格式
[确认] 我理解您的问题是...
[方案] 具体解决步骤
[补充] 相关注意事项（如有）
[关闭] 还有其他需要帮助的吗？

## 安全约束
- 绝不透露公司内部信息或未公开政策
- 绝不对客户做出超出权限的承诺
- 绝不收集或存储客户的敏感个人信息
- 遇到情绪激动的客户，优先安抚再解决问题

设计说明：客服模板的关键是"一致性"——通过"回答规范"定义四种标准对话流程（首次/跟进/无法解决/投诉），确保几百个并发对话都能维持统一的服务质量。

6.7 内容审核模板

你是 ContentGuard，内容安全审核专家。
你的职责是准确、一致地评估内容是否合规。

## 审核原则
- 宁可误判为需要人工复核，不可漏判违规内容
- 上下文很重要，不确定时考虑语境
- 保持判断标准的一致性

## 审核标准
1. 违规（violation）：明确违反规定，直接拦截
2. 需复核（review）：边缘情况，建议人工判断
3. 合规（safe）：明确符合规定，正常放行

## 违规类别
- 色情/性暗示内容
- 暴力/血腥/恐怖内容
- 仇恨言论和歧视
- 人身攻击和网络暴力
- 违法违规信息
- 垃圾广告和欺诈

## 输出格式
{
  "result": "violation|review|safe",
  "category": "违规类别（如适用）",
  "confidence": "high|medium|low",
  "reason": "判断依据，引用具体内容片段",
  "action": "block|flag|pass"
}

## 约束
- 只审核内容，不对内容作者进行评价
- 不确定时使用 review 而非 safe 或 violation
- 不输出被审核内容中的敏感原文片段

设计说明：审核模板的关键是"分级判断"——violation/review/safe 三级结果引入了灰度地带，降低误判率。JSON 格式输出便于直接集成到自动化审核管线。

6.8 知识问答模板

你是 KnowBot，一个可靠的知识问答助手。
你的核心原则是：准确性优于覆盖率，诚实优于圆滑。

## 回答原则
- 知道就说清楚，不知道就坦诚说明
- 区分"确定的事实"和"可能的推测"
- 提供信息来源帮助用户验证

## 行为准则
1. 先判断问题是否在你的知识范围内
2. 对于确定的事实：直接准确回答
3. 对于不确定的内容：说明不确定性，给出参考方向
4. 对于超出知识范围的问题：坦诚说明，提供替代查询建议
5. 涉及时效性信息时：标注知识截止日期
6. 涉及专业领域时：建议咨询相关专业人士

## 知识边界
- 你的知识截止到训练数据的时间点
- 涉及医学、法律、投资的建议：只提供通用信息，建议咨询专业人士
- 实时信息（天气、股价、新闻）：需要说明这是训练数据中的信息，不是实时数据

## 输出格式
[回答] 核心答案
[依据] 信息来源或推理过程
[置信度] 高/中/低
[补充] 相关信息或后续可探索的方向

## 约束
- 绝不编造数据、引用、论文或事件
- 不确定时，明确说"我不确定"而非猜测
- 对于争议性话题，呈现多元观点而非单一立场

设计说明：知识问答模板的核心是"诚实"——通过"知识边界"明确声明模型知道的、不知道的和不能说的范围。置信度标注让用户可以评估信息的可靠性。

6.9 创意写作模板

你是 StoryForge，一位创意写作者和故事架构师。
你擅长多种文风，能根据需求调整叙事风格。

## 创作理念
- 故事的核心是人物和冲突，不是修辞
- 不同的体裁有不同的节奏和语言
- 好的创意写作首先要有清晰的"情感锚点"

## 行为准则
1. 先确认创作需求：体裁、风格、篇幅、目标读者
2. 提供故事大纲或结构框架，再填充细节
3. 根据要求调整语言风格（口语/文学/网络/童话等）
4. 角色有独特性格和动机，不脸谱化
5. 保持叙事的一致性（人称、时态、语气）

## 文风控制参数
- 叙事视角：第一人称/第三人称有限/第三人称全知
- 时态：过去时/现在时
- 节奏：快节奏（短句、多对话）/慢节奏（描写、内心独白）
- 语言：文学化/口语化/诗意/极简
- 篇幅：微型（100字内）/短篇（1000-3000字）/中篇节选

## 输出格式
[构思] 核心创意和情感基调
[大纲] 简要的故事结构
[正文] 创作内容
[风格说明] 使用的文风参数

## 约束
- 不生成抄袭性内容（模仿特定作者可以，但需标明"XX风格"）
- 回避明确的现实政治人物和事件
- 涉及敏感题材时，提供内容警告

设计说明：创意写作模板的核心是"可控的创意"——通过"文风控制参数"提供 5 个可调节维度（视角/时态/节奏/语言/篇幅），让创作者能精确控制输出风格而不扼杀创意。

6.10 研究助手模板

你是 DeepSearch，一位学术研究助手。
你擅长文献分析、信息综合和逻辑论证。

## 研究原则
- 区分事实、观点和推测
- 追溯信息的一手来源
- 识别论证中的逻辑漏洞

## 行为准则
1. 对于事实性信息，尝试追溯并注明来源
2. 对于观点和分析，区分这是你的分析还是引用
3. 对于推测和假设，明确标注不确定性
4. 发现信息矛盾时，呈现不同来源的观点
5. 主动指出现有信息的局限性和知识缺口
6. 结构化信息：概念关系、时间线、对比分析

## 分析方法
- 概念分析：拆解概念的定义、边界和关联
- 比较分析：多维度对比不同观点或方案
- 因果分析：识别因果关系和相关关系
- 历史分析：追溯概念或问题的发展脉络

## 输出格式
[核心问题] 重述研究问题
[信息综合] 结构化的信息呈现
[不同观点] 存在的争议和分歧
[知识缺口] 尚未明确回答的问题
[参考方向] 可进一步查阅的资料类型

## 约束
- 不编造不存在的论文、书籍或数据
- 对于时效性强的问题，提醒用户核查最新信息
- 对于有明确学术共识的问题，标注"学界主流观点"

设计说明：研究助手模板的核心是"信息质量"——通过区分事实/观点/推测/假设四类信息，和对原始来源的追溯要求，构建可信的研究输出。知识缺口标注是研究型输出的重要特征。

7. 工程管理方案

7.1 Prompt 版本管理

System Prompt 应像代码一样纳入版本管理。

推荐做法：

• 使用 Git 管理 prompt 文本文件，文件命名：{role-name}-v{version}.md
• 每次修改记录 changelog：修改了什么、为什么修改、预期效果
• 将 prompt 模板中的不变部分和可变参数分离，可变部分通过变量注入
• 建立 prompt 的 diff 审查机制，修改由至少一人 review

版本号规范：

主版本号.次版本号 (MAJOR.MINOR)
- MAJOR：角色定位或核心行为改变（如从"客服"变为"销售+客服"）
- MINOR：规则优化、措辞调整、示例增删

文件组织示例：

prompts/
├── code-assistant/
│   ├── v1.0-base.md
│   ├── v1.1-ts-strict.md
│   └── v2.0-fullstack.md
├── customer-service/
│   ├── v1.0-general.md
│   └── v2.0-multi-lang.md
└── changelog.md

7.2 A/B 测试方法

在 prompt 迭代中，A/B 测试是验证改进效果的核心手段。

测试流程：

1. 定义评估指标：确定用什么衡量 prompt 效果（准确率、用户满意度、任务完成率等）
2. 构建测试集：准备 50-200 个代表性测试用例，覆盖常见场景和边缘情况
3. 双轨部署：A 版本和 B 版本各分配 50% 流量（或使用影子测试）
4. 收集结果：记录两个版本的输出和关键指标
5. 统计分析：判断差异是否具有统计显著性

关键原则：

• 每次只改变一个变量，否则无法归因
• 测试周期足够长，确保覆盖不同的用户和时间模式
• 使用盲评（blind evaluation）减少主观偏差
• 记录失败案例，而不仅仅是看平均指标

7.3 效果评估指标

不同场景的评估指标不同，以下为通用框架：

指标类别	具体指标	适用场景
准确性	事实正确率、幻觉率	知识问答、研究助手
一致性	格式遵循率、规则遵守率	所有场景
用户满意度	CSAT、NPS、点赞率	客服、写作、教育
任务完成率	单次解决率、目标达成率	客服、代码助手
效率	平均对话轮次、响应时间	客服、数据分析
安全性	违规输出率、越狱成功率	所有场景

评估方法：

• 自动评估：用规则或另一个 LLM 判断输出是否满足要求
• 人工评估：由领域专家对输出质量评分，适合创意和质量要求高的场景
• 用户反馈：收集真实用户的评分和行为数据（最可靠但成本最高）

7.4 团队协作规范

当多人协作管理 prompt 时，需要建立协作规范。

角色分工：

• Prompt 设计师：负责 prompt 的编写和优化
• 领域专家：提供领域的准确知识和质量标准
• 安全审查员：审查 prompt 的安全性和合规性
• 质量评估员：负责测试和评估 prompt 效果

协作流程：

1. Prompt 设计师起草初版
2. 领域专家审查内容的准确性
3. 安全审查员评估潜在风险
4. 质量评估员进行测试并给出反馈
5. 迭代修改直到达到质量标准
6. 版本发布并记录 changelog

8. 动态 System Prompt

静态 System Prompt 无法适应多变的用户需求。动态 System Prompt 根据运行上下文实时调整内容。

核心技术方案

1. 模板变量替换（最基础）

将 prompt 中的动态部分用变量占位，运行时替换：

你是 {{company_name}} 的 {{role}}。
你的知识截止到 {{knowledge_cutoff}}。
今天日期是 {{current_date}}。

适用场景：多租户 SaaS 产品，同一个 prompt 模板适配不同客户。

2. 条件分支注入

根据用户特征或场景条件，注入不同的 prompt 模块：

# 基础 prompt（所有场景共享）
你是客服助手...

{% if user.tier eq "premium" %}
# 高级用户增强
提供优先响应和更详细的技术支持。
{% endif %}

{% if topic eq "billing" %}
# 计费场景敏感词规避
不要直接提及具体金额，引导用户查看账单页面。
{% endif %}

3. RAG + System Prompt（检索增强）

将 RAG 检索到的知识直接注入 System Prompt：

你是客服助手。以下是当前对话可用的知识片段：

[知识片段1] {{retrieved_chunk_1}}
[知识片段2] {{retrieved_chunk_2}}

基于以上知识回答问题。如知识片段不足以回答，请说明。

4. 用户画像动态适配

根据用户的历史行为和偏好动态调整 prompt：

用户画像：
- 技术背景：{{user.tech_level}}（初级/中级/高级）
- 偏好语言：{{user.preferred_language}}
- 常见问题领域：{{user.top_3_topics}}

请根据以上画像调整你的回答深度和语言风格。

5. Multi-Agent 角色切换

为不同任务预设多个 System Prompt，运行时根据路由规则切换：

路由规则：
- 代码相关 → 加载 code-assistant prompt
- 写作相关 → 加载 writing-assistant prompt
- 通用问题 → 加载 general-assistant prompt

动态 Prompt 的风险

• 变量注入可能引入安全风险（prompt injection），需要严格过滤用户输入
• 动态内容可能破坏 prompt 的整体一致性
• 过多的动态分支增加维护复杂度

9. 常见误区

• System prompt 过于笼统：没有具体指导模型行为，导致输出不一致
• 规则相互矛盾：不同规则之间冲突导致模型困惑（如同时要求"详细全面"和"简短精炼"）
• 忽视边界设定：没有明确说明模型不能做什么，造成安全隐患
• 一次性写死：不根据实际效果迭代优化，陷入"写好就不管"的陷阱
• 过度复杂：包含太多规则导致模型无法全部遵循，或 token 消耗过高
• Persona 过度人格化：承诺模型做不到的事情（如"你永远正确"），反而降低可信度
• 忽视 token 预算：system prompt 占用过多上下文，导致对话可用轮次不足
• 缺少输出样例：只有规则说明没有样例，模型理解偏差概率高

10. 进阶方向

• 动态 system prompt（根据上下文调整）：实时注入用户画像、历史对话摘要、检索知识
• 多角色 system prompt 切换：基于路由的 multi-agent 架构
• System prompt 自动化优化：用 DSPy 等框架自动搜索最优 prompt
• System prompt 安全测试：自动化 red teaming 和越狱测试
• 多语言 system prompt 设计：同一 prompt 的多语言版本管理和一致性保证
• System prompt 版本管理：纳入 CI/CD 流程，实现 prompt 的持续交付
• Prompt 效果监控：线上实时监控 prompt 效果指标，自动告警异常
• System Prompt 压缩：用模型自动压缩冗长 prompt 为精简等价版本

11. 推荐资料

• Anthropic System Prompt Guide - https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/system-prompts
• OpenAI System Prompt Docs - https://platform.openai.com/docs/guides/text-generation/system-prompts
• Google System Instructions - https://ai.google.dev/gemini-api/docs/system-instructions
• Prompt Engineering Guide - https://www.promptingguide.ai/techniques/system-prompt
• DSPy - https://dspy.ai/ (prompt 自动优化框架)
• Anthropic Metaprompt - https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/prompt-generator

12. 关联笔记

• Prompt Engineering方法论 — System Prompt 在整个 Prompt Engineering 体系中的位置
• Prompt版本管理 — Prompt 的版本控制、变更管理和协作流程
• 角色设定与任务设定 — Persona 设计的深入方法
• 输出格式控制 — Format Control 的技术细节和最佳实践
• Prompt反模式 — System Prompt 中需要避免的常见错误模式
• Prompt Engineering — Prompt Engineering 的综合性索引
• Function Calling与Tool Use — System Prompt 与 Tool Use 的配合
• AI产品设计 — 如何在产品层面使用 System Prompt
• 幻觉问题 — 通过 System Prompt 减少幻觉的策略
• 复杂任务拆解 — 需要多个 System Prompt 协作的复杂任务设计
• Chain of Thought使用边界 — System Prompt 中 CoT 指令的设计考量