DeepSeek R1 模型接入时，system_prompt 应放在 API 请求的 messages 数组中，角色标记为 system，主要用于设定助手行为准则或任务背景，配置方式与主流 Chat 接口一致。
先说结论：配置方式遵循标准 Chat Completion 接口规范，通过请求体中的 messages 字段传递系统指令。
- 适合：需要固定模型人设、约束输出格式或提供任务背景知识的场景。
- 先准备：确认 API Key 权限，编写简洁明确的系统指令文本。
- 验收：发送测试请求，检查模型回复是否符合系统指令设定的约束。
命令速用版
DeepSeek API 兼容主流 SDK，以下是构造请求体的核心 JSON 结构示例，可直接用于代码调试：
{
"model": "deepseek-reasoner",
"messages": [
{
"role": "system",
"content": "你是一个专业的代码助手，只输出代码片段，不包含解释文字。"
},
{
"role": "user",
"content": "写一个 Python 快速排序函数"
}
]
}注意：model 字段需根据实际接入的模型名称填写，系统提示词放在 role 为 system 的对象中。
为什么会这样
DeepSeek R1 作为推理类模型，其 API 接口设计遵循行业通用的 Chat Completion 标准。system_prompt 的本质是一条特殊的消息，它在对话开始前就定义了模型的“身份”和“规则”。
对于 R1 这类侧重逻辑推理的模型，系统提示词不仅影响最终回答的风格，还会隐式地引导模型的思考方向。但需要注意的是，系统提示词无法直接控制模型是否输出思维链（thought process），这通常由 API 参数或模型版本特性决定。
分步处理
1. 获取接入凭证
登录 DeepSeek 开放平台，创建 API Key。确保账户余额或额度充足，避免请求被拦截。
2. 构造请求数据
在代码中构建 JSON 对象。将 system_prompt 放入 messages 数组的第一个位置。建议系统指令控制在清晰简练的范围内，避免过长占用上下文窗口。
3. 发送 HTTP 请求
使用 POST 方法向 API endpoint 发送请求。Content-Type 需设置为 application/json。携带 Authorization 头，格式为 Bearer YOUR_API_KEY。
4. 处理返回结果
解析响应中的 choices 字段。注意 R1 模型可能会返回包含推理过程的内容，需根据业务需求决定是否展示给用户。
怎么验证是否生效
1. 约束性测试
在 system_prompt 中设定明确禁忌，例如“不要使用 Markdown 格式”。发送请求后，检查回复是否确实纯文本。
2. 角色一致性
设定特定人设，例如“你是一个资深医生”。询问通用问题，观察语气和专业度是否符合预期。
3. 日志检查
查看服务端日志，确认请求体中 system 消息已正确发送，且未被中间件过滤或修改。
常见坑
1. 指令冲突
避免 system_prompt 与 user 输入中的指令相互矛盾，这会导致模型困惑，输出质量下降。
2. 敏感信息泄露
不要在 system_prompt 中硬编码 API 密钥、数据库密码等敏感信息，这些内容可能出现在日志或模型输出中。
3. 忽略安全策略
系统提示词无法绕过模型内置的安全过滤机制。如果指令涉及违规内容，模型仍会拒绝回答或触发风控。
4. 上下文超限
系统提示词会计入总 Token 消耗。过长的 system_prompt 会挤压用户对话的空间，增加成本。
参考来源
- DeepSeek 开放平台，API 文档页面
- DeepSeek 官方技术博客，模型接入指南