在扣子（Coze）的工作流设置中，系统提示词和用户提示词是模型节点中的关键配置项。而这两者的区别，让很多人困惑，搞不清楚不清楚到底应该如何设置，这也使得工作流的输出结果不尽人意。事实上，这两者分工明确、协同运行，共同控制大模型的输出逻辑。

因此，掌握系统提示词怎么写，用户提示词怎么写，是做好工作流，做好智能体必备的技能。

一、术语解释

1. 我们先看一下在扣子官方文档中的定义

提示词包括系统提示词和用户提示词，两者区别如下：

• 系统提示词：在构建智能体时，设置的人设与回复规则就是系统提示词，它是开发者为大语言模型设定的初始参数和行为准则，在整个对话中持续影响大模型的响应方式。通过编写系统提示词，可以为大模型设定特定的角色定位和回答规则。
• 用户提示词：在与智能体对话时，用户的输入就是用户提示词，它是用户直接向大语言模型提出的具体指示或问题，指示模型执行特定的任务或提供特定的信息。用户提示词的设置应简洁明了，以便模型能够准确理解用户的需求。

看完是不是一目了然？

既然"用户的输入就是用户提示词"，在模型中，为什么还要设置？

文档要求"用户提示词的设置应简洁明了，以便模型能够准确理解用户的需求。"在模型中设置，能约束用户的行为吗？

有没有感觉，看了文档之后，更加迷茫了？

2. 再看看扣子官方白皮书的示例

假设我们需要构建一个友好且专业的健康咨询助手，以下是设置系统提示词和用户提示词的示例：

• 系统提示词：你是一个友好且专业的健康咨询助手，专注于为用户提供基于科学和医学知识的健康建议。在回答用户的问题时，你的回答应该既专业又易于理解，同时保持语言的温和和亲和力。请确保所有建议都是基于最新的健康指南，并避免提供具体的医疗诊断。
• 用户提示词：我最近总是感到疲劳，这可能是什么原因呢？。

看完例子，清楚了吗？

也许例子能让你清楚系统提示词的写法，但对用户提示词一定是更明白了吧？

难道是写一个用户可能的问题在上面？是对用户的提示？

所以我看到，很多人做的工作流，用户提示词都是示例的 —— 还是留给用户输入吧！

于是，感觉大模型失控，达不到自己想要的效果。

下面，听我分析一下系统提示词与用户提示词的区别，以及设置的差异吧。

---

二、核心区别与功能定位

维度	系统提示词	用户提示词
角色	模型的"宪法"	任务的"触发器"
核心作用	定义身份、底层能力框架、处理规则、输出格式等全局约束	提供本次任务的具体指示和行动参数，触发具体任务执行（如"用 {{input}} 执行验证并生成答案"）

系统提示词 vs 用户提示词，是全局约束 vs 行动指示生成器

• 系统提示词 = 汽车的操作系统：
  预设驾驶规则（如限速），即使输入不同油门力度（body_data），控制逻辑不变。
• 用户提示词 = 司机的实时操作：
  根据路况（用户输入）确定踩油门力度（fat_rate），生成具体操作指令（"加速至80km/h"）。

二者本质都是初始化配置，但用户提示词通过绑定初始输入和实时解析，成为工作流中响应动态需求的核心链路。

若要修改系统级规则（如要用所有加速），是"回溯调整"（调整工作流）；用户提示词的行动效果，是"换路行驶"（改变输入）。

再理解一个功能逻辑：

1. 核心工作流程
   • 输入：用户面试问题（动态变量 {{input}}）
   • 处理：语义理解 → 知识库验证 → 内容整合 → 生成回答
   • 输出：清晰、易懂的答案
2. 相关环节从属
   • 系统提示词：定义底层能力框架（如"如何验证知识库""输出规范"）
   • 用户提示词：触发具体任务执行（如"用 {{input}} 执行验证并生成答案"）

聊聊用户提示词的作用：基于结构化变量设置行动指示

1. 意图解析
   将抽象的用户需求转化为可执行指示。
2. 对非结构化输入进行清洗 如含错别字、简写
   举例：根据`{{input}}`的语义，同时考虑用户输入错别字的情况，推测用户正确的问题，判断用户想要了解的问题
3. 任务粒度与操作调用
   • 用户提示词将结构化变量注入具体行动指示，触发模型执行动作。
     • 示例：
       基于目的地`{{destination}}`，执行以下操作：
1. 调用天气API查询当地气温；
2. 调用旅游知识库验证必去景点；
3. 生成3天行程表。
     • 作用：将全局数据（"北京"）转化为行动链（查询→验证→生成）。
4. 动态约束补充
   • 在引用变量的同时，可附加实时约束条件：
     • 示例："行程需包含历史文化景点，且每日步行距离不超过5公里"
     • 意义：在基础参数（目的地）外，用户提示词补充业务规则（景点类型、体力限制）。
5. 多变量协同控制
   • 当行动需组合多个变量时，用户提示词定义协作逻辑：
     • 示例："根据{{destination}} 和{{budget}}，推荐人均低于{{budget}} 的餐厅"
     • 技术实现：变量间逻辑关系（如计算比较）需通过提示词明确。

---

三、配置方案与依据

1. *系统提示词：定义能力框架

• 角色定位：明确模型身份（如"客服专家"而非"助手"）
• 能力边界：限定工具调用范围（例：仅当用户提供订单号时调用查询API）
• 安全护栏：制定伦理规则（例：拒绝讨论政治话题）

举例：

# 角色：面试问题解答专家
## 核心能力：
1. 基于词义理解精准匹配知识库内容
2. 整合验证结果生成结构化答案
## 输出规范：
– 语言简洁清晰，避免专业术语堆砌
– 按"核心结论→关键依据→示例补充"三段式组织内容
## 终止条件：
– 仅使用知识库已验证内容，拒绝主观臆断

为何在此配置：

• 角色与边界：定义智能体的身份（面试专家）和能力范围（仅用知识库），属于全局规则；
• 流程标准化：要求"语义理解→验证→整合"是核心能力框架，不随问题变化；
• 输出一致性：所有问题的答案需统一遵循"三段式"格式，需固化在系统层。

2. *用户提示词：触发行动执行

• 功能：基于当前输入变量生成具体操作指示。
• 开发者实践：
  • 设计时需预设变量占位符（如 {{order_id}}），但实际值由用户输入动态注入。
  • 每次请求根据变量值重组行动（如本次 order_id=123456789 → 触发物流查询）。

举例：

执行以下操作：
1. 解析问题：`{{input}}`
2. 从知识库验证相关知识点
3. 按系统规范生成答案

为何在此配置：

• 动态输入绑定：{{input}} 是用户每次提问的变量，需实时嵌入任务指令；
• 行动最小化：用户提示词只需明确"用当前问题执行系统预设流程"，无需重复规则；
• 维护便捷性：若需调整答案规则（如新增"生成对比图表"），只需修改系统提示词，用户层无需变更。

用户提示词设置要点：

• 行动明确性：
  避免模糊指令，改用可量化要求
  ✓ 正确示例：生成3个{{product}}的卖点，每点不超过25字
  ✗ 错误示例：介绍一下这个产品
• 变量全覆盖：
  确保所有行动参数均被{{}}引用 
  ✗ 若用户提示词未引用变量（如遗漏{{city}}），模型会因缺少关键参数而报错或输出无效结果。

---

四、错误配置的后果

错误方案	问题分析	典型后果
全部输入系统提示词	系统提示词冗长，且无法绑定动态变量 {{input}}	模型无法识别具体问题，输出空洞答案
全部输入用户提示词	在用户提示词定义角色（如"你作为面试专家"），导致多轮对话中角色设定被覆盖或失效	智能体行为不稳定，专业性下降

常见的用户提示词滥用的后果

若删除用户提示词，仅依靠 {{input}} 传递原始输入，会导致：

1. 意图错误识别
   • 用户输入 "取消订单" → 系统可能理解为"订单查询"而非"订单取消"API。
2. 格式错误
   • 用户输入 "订单 2025/07/28" → API 因格式错误报错。
3. 效率降低
   • 系统提示词需内置复杂解析规则（如正则表达式），降低响应速度且难以维护。

何时无需用户提示词？

仅在简单查询场景下可省略用户提示词，直接传递变量至系统提示词：

• 示例：
  系统提示词为 "回答关于{{topic}} 的定义"，用户输入 {{topic}} = "人工智能" → 输出定义。
• 局限：
  无法支持多步骤操作（如先查天气再推荐行程）。

五、双提示词工作验证表

检测项	系统提示词	用户提示词
是否明确定义角色？	✓	–
是否包含工具调用规则？	✓	✓
是否引用全部必要变量？	✓	✓
是否指定输出格式？	✓	可选

---

六、调试技巧：定位提示词失效原因

当输出不符合预期时，按此流程排查：

1. 检查变量绑定
   • 上游节点是否正确输出变量；
   • 提示词中变量名是否与上游一致（大小写敏感）
2. 验证行动逻辑
   • 用户提示词是否清晰指向操作调用（例：未写"调用API"导致模型仅文本回复）；
3. 隔离测试
   • 临时清空用户提示词，仅保留系统提示词，观察模型是否按角色响应

馃挕 高级技巧：在用户提示词中增加调试指示：

执行步骤：
1. 打印接收到的参数：{{input}}
2. 调用知识库验证

通过输出日志定位故障点 

---

七、案例说明

根据用户提出的面试问题，基于词义理解，在知识库中进行验证，将知识库中查询到的内容进行整理和分析，以清晰、易懂的方式向用户回答面试问题。

功能逻辑拆解

1. 核心工作流程
   • 输入：用户面试问题（动态变量 {{input}}）
   • 处理：语义理解 → 知识库验证 → 内容整合 → 生成回答
   • 输出：清晰、易懂的答案
2. 相关环节从属
   • 系统提示词：定义底层能力框架（如"如何验证知识库""输出规范"）
   • 用户提示词：触发具体任务执行（如"用 {{input}} 执行验证并生成答案"）

配置方案与依据

1. 系统提示词：定义能力框架

# 角色：面试问题解答专家 
## 核心能力： 
1. 基于词义理解精准匹配知识库内容 
2. 整合验证结果生成结构化答案  
## 输出规范： 
- 语言简洁清晰，避免专业术语堆砌  
- 按"核心结论→关键依据→示例补充"三段式组织内容  
## 终止条件： 
- 仅使用知识库已验证内容，拒绝主观臆断

为何在此配置：

• 角色与边界：定义智能体的身份（面试专家）和能力范围（仅用知识库），属于全局规则；
• 流程标准化：要求"语义理解→验证→整合"是核心能力框架，不随问题变化；
• 输出一致性：所有问题的答案需统一遵循"三段式"格式，需固化在系统层。

2. 用户提示词：触发行动执行

执行以下操作： 
1. 解析问题：`{{input}}`  
2. 从知识库验证相关知识点  
3. 按系统规范生成答案 

为何在此配置：

• 动态输入绑定：{{input}} 是用户每次提问的变量，需实时嵌入任务指令；
• 行动最小化：用户提示词只需明确"用当前问题执行系统预设流程"，无需重复规则；
• 维护便捷性：若需调整答案规则（如新增"生成对比图表"），只需修改系统提示词，用户层无需变更

---

八、总结：提示词的组合工作

• 系统提示词和用户提示词二者缺一不可，共同构成工作流智能体的核心逻辑。