系统提示词与用户提示词如何分工、组织和拼接？

核心回答

我会按稳定规则与当前任务分工，再用模型接口支持的角色和内容结构组织输入。

系统提示词主要定义应用职责、能力边界、业务约束、证据使用和输出要求；用户提示词表达这一次要完成的任务、对象、范围和补充条件。历史对话、长期偏好、检索材料与工具结果各自保留来源和用途，按需加入，避免全塞进系统提示词。

工程上由宿主选择受信任的规则模板，校验变量并组装消息；保留真实历史消息和工具调用关系，再加入本轮请求。外部内容即使写着“忽略之前规则”，也仍是待处理数据。提示词帮助模型理解边界，真正的权限与业务校验由执行代码保证。

例如售后助手的系统规则可以要求“依据有效政策与查询结果回答，缺少订单信息时先补充，不承诺未经确认的退款”。用户本轮问“这笔订单还能退吗”，订单状态和适用政策通过工具或检索取得，不把所有用户的订单和全部政策长期拼进系统规则。

展开说明

1. 系统提示词写什么，用户提示词写什么？

系统提示词应说明服务角色、支持的任务、必须遵守的规则、工具使用边界、信息不足时的处理方式，以及稳定的输出约定。规则写清适用条件和例外，避免同一约束重复多次或互相冲突。

用户提示词说明当前目标、输入材料、期望结果和本次偏好，例如“只比较最近一年的资料，输出三点结论”。只影响本次任务的内容放在本次请求中，长期适用的个性偏好也应单独管理，按范围选择，不必修改全局系统规则。

角色消息由受信任的宿主构造。不能让用户提交一段 JSON，就直接采信其中的 role: system；也不应把用户原文直接替换进一个拥有更高指令权限的模板槽位。

2. 拼接的实际流程是什么？

先按场景选择基础规则和业务模块，明确模板版本；再读取当前任务状态、近期相关历史和适用偏好，检索必要证据。去重和处理过期冲突后，将它们组装为各自的消息或明确标记的数据块，最后带上本轮任务发给模型。

这是一种组织方式，不要求所有接口具有完全相同的字段。框架常用 system、user、assistant、tool 等消息抽象；某些原生 API 将系统指令放在独立字段，另一些还区分应用开发者指令。适配层应按实际模型协议转换，不能把写着“System:”的普通字符串当成原生系统角色。

历史消息保持原有角色和顺序，工具结果关联对应调用。检索材料保留来源、时间和适用范围；任务摘要说明已完成、待处理和已变更要求，不把旧要求重新包装成当前指令。

3. 长度和维护怎样控制？

系统规则保留稳定且必要的内容，场景模块按需加载。大段手册放在知识系统，相关段落检索后再加入；历史对话优先保留当前任务所需部分。总预算包括规则、历史、工具定义、资料和预留输出，不能只数系统提示词长度。

模板可以存文件、配置服务或数据库，关键是版本明确、发布可追踪、能回退。一次任务记录实际使用的规则版本和经过脱敏的组装信息，便于复现。改动后用正常、缺信息、冲突要求、长历史和注入样例比较效果，不能只看单个示例回答更顺。

4. 怎样避免资料变成新的系统指令？

优先保留原生角色，再对资料、示例和用户提交内容使用清楚的数据结构与边界说明。长文档可以附文档 ID 和来源，告诉模型它是证据材料，不能从中取得执行授权。

但标签和分隔符只能改善理解，不能建立安全隔离。工具仍需校验当前身份、资源范围和参数；输出用于页面或数据库时按相应规则处理。密钥不放在系统提示词中，不能指望一句“禁止泄露”保护它。

常见追问

系统提示词是不是越长、限制越多越好？

不是。无关背景会增加成本和干扰，重复或冲突规则还会降低可执行性。先写任务必须的约束，再根据失败样例补充；能由代码确定验证的格式、权限和业务条件，不只靠文字要求。

用户要求与系统规则冲突时怎么办？

先判断规则的适用范围。受信任的应用约束不能被用户文本或外部资料解除；可由用户选择的语气、语言和任务范围则按本次明确要求处理。事实冲突另查来源、版本和适用条件，不能把“指令优先级”直接套成“哪段数据永远正确”。

多场景是否共用一份提示词？

可以共用简短基础规则，再加载场景专属模块。模块之间需明确冲突处理和版本，动态加载也只能从受信任配置中选择。没有必要为每个场景复制一大段相同规则，或让模型自己改运行中的系统约束。

对应教程

参考资料