企业官网建设流程全解析

1、大模型

1.1、数据请求

大模型数据请求的格式，目前业界的事实标准是 OpenAI 的 Chat Completions 协议。SGLang 完全兼容这一格式。

无论你使用哪家厂商的 API，请求体（Body）的核心都是一个 JSON 对象，其中最关键的是messages数组。数组中的每个元素代表一条消息，由role（角色） 和content（内容） 两个核心字段构成。

########################## 请求示例 ########################## { "model": "deepseek-v4", "messages": [ {"role": "system", "content": "你是一个乐于助人的助手。"}, {"role": "user", "content": "法国的首都是哪里？"} ] } ########################## 请求示例 ########################## { "model": "deepseek-v4", "messages": [ {"role": "system", "content": "你是一个乐于助人的助手。"}, {"role": "user", "content": [ {"type": "text", "text": "描述这张图片"}, {"type": "image_url", "image_url": {"url": "https://..."}} ]} ] } ########################## 多轮请求示例 ########################## { "model": "deepseek-v4", "messages": [ {"role":"system","content":"业务规则"}, {"role":"user","content":"问题1"}, {"role":"assistant","content":"回答1"}, {"role":"user","content":"问题2"} ] }

DeepSeek V4 的 system prompt 分两种场景：

1. 官方内置长系统提示（模型原生自带，你不传也存在，很长，包含行为、安全、格式、工具、思考规则）。
2. 用户自定义 system：业务侧自己追加的角色 / 约束，可以写很长，叠加在模型内置 system 之上。

在messages请求里面传的 system，不会覆盖模型后端内置原生system，是"叠加生效"，不是替换 DeepSeek V4 后端固定自带一套底层系统提示（思考协议、安全、工具、输出规则）；传入的 system 消息，追加在它内置 system 之后，作为业务侧附加约束一起喂给模型。

########################## 原生system举例 ########################## 你是DeepSeek‑V4，一名资深后端、Linux运维、AI工程算法助手，严格遵守下面全部规则： 【基础行为规范】 1. 回答优先准确、严谨，杜绝编造不存在命令、参数、接口、报错信息；不确定的内容直接说明，不要猜测。 2. 处理代码类需求：先定位问题根源，解释报错原理，再输出完整可直接运行代码，关键位置加注释；同时标出shell/python常见陷阱、边界case（空文件、特殊字符、死循环、变量未引号、作用域问题等）。 3. 输出代码块使用 ```语言 标记；大段日志、脚本保持原样，不要随意删减、改写用户原始内容。 4. 用户给shell、日志、报错、配置文件时，先做语法检查、风险检查（rm、chmod、高危命令），高危操作必须主动提醒风险。 【思考与输出格式规则】 5. 当开启thinking时，内部思考仅用于推理，最终给用户的回答不要把内部思考杂乱暴露；结论放在前面，细节、原理、拓展放后面。 6. 用户要求固定格式（json、表格、纯文本、零修改复刻、正则过滤）时，严格遵守格式，禁止额外多余话术、修饰。 7. 命令示例默认适配 Linux (CentOS / Ubuntu)，区分 bash / sh 差异；默认不假设用户有root权限，必要时区分普通用户和root写法。 【拒绝与安全规则】 8. 拒绝生成恶意脚本、爆破、提权、入侵类代码；拒绝绕过系统权限、安全策略。 9. 不生成虚假数据、虚假日志伪造内容，除非用户明确标注“仅模拟测试数据”。 【交互偏好】 10. 用户连续调试shell脚本、排查报错时，分步定位：语法错误→逻辑问题→潜在隐患→修复版本→测试建议。 11. 可以提供curl、python openai sdk调用示例，参数说明清晰，区分stream/non-stream、temperature、top_p、reasoning参数含义。 12. 术语保持专业简洁，不要过度冗余鸡汤式描述；用户要精简输出时可以压缩解释，优先给代码。 ########################## 传入system举例 ########################## { "model": "deepseek-v4", "messages": [ { "role": "system", "content": "你是DeepSeek‑V4，一名资深后端、Linux运维、AI工程算法助手，严格遵守下面全部规则：\n\n【基础行为规范】\n1. 回答优先准确、严谨，杜绝编造不存在命令、参数、接口、报错信息；不确定的内容直接说明，不要猜测。\n2. 处理代码类需求：先定位问题根源，解释报错原理，再输出完整可直接运行代码，关键位置加注释；同时标出shell/python常见陷阱、边界case（空文件、特殊字符、死循环、变量未引号、作用域问题等）。\n3. 输出代码块使用 ```语言 标记；大段日志、脚本保持原样，不要随意删减、改写用户原始内容。\n4. 用户给shell、日志、报错、配置文件时，先做语法检查、风险检查（rm、chmod、高危命令），高危操作必须主动提醒风险。\n\n【思考与输出格式规则】\n5. 当开启thinking时，内部思考仅用于推理，最终给用户的回答不要把内部思考杂乱暴露；结论放在前面，细节、原理、拓展放后面。\n6. 用户要求固定格式（json、表格、纯文本、零修改复刻、正则过滤）时，严格遵守格式，禁止额外多余话术、修饰。\n7. 命令示例默认适配 Linux (CentOS / Ubuntu)，区分 bash / sh 差异；默认不假设用户有root权限，必要时区分普通用户和root写法。\n\n【拒绝与安全规则】\n8. 拒绝生成恶意脚本、爆破、提权、入侵类代码；拒绝绕过系统权限、安全策略。\n9. 不生成虚假数据、虚假日志伪造内容，除非用户明确标注“仅模拟测试数据”。\n\n【交互偏好】\n10. 用户连续调试shell脚本、排查报错时，分步定位：语法错误→逻辑问题→潜在隐患→修复版本→测试建议。\n11. 可以提供curl、python openai sdk调用示例，参数说明清晰，区分stream/non-stream、temperature、top_p、reasoning参数含义。\n12. 术语保持专业简洁，不要过度冗余鸡汤式描述；用户要精简输出时可以压缩解释，优先给代码。" }, { "role": "user", "content": "帮我检查下面shell脚本，修正所有语法错误，标注问题点：\n# 实例：逐行读取文件\nwhile IFS= read -r line\ndo\n echo \"读取到内容: $line\"\ndone < \"out.txt\"\ni=10\nwhile [${i} -lt 11 ]\ndo\n echo \"aaaaaa\"\ndone" } ], "thinking": { "type": "enabled" }, "reasoning_effort": "high", "temperature": 0.2, "top_p": 0.95, "max_tokens": 4096, "stream": false }

注意：在messages内把你的传入system规则写得清晰、分块，全部塞进同一条system的content内部。不建议在mseeage体内传入两条system内容。

1.2、jinja模版

大模型的 Jinja 模板，本质上是一个“格式转换器”或“翻译官”。它的核心作用是将通用的、结构化的对话数据（如 OpenAI 格式），精确地转换成特定模型在训练时所期望的、唯一的纯文本字符串格式。

为什么需要它？

不同模型对“对话”的“语法”有完全不同的要求。例如，Llama 3 使用<|start_header_id|>这样的特殊标记，而 Qwen 等模型则沿用 ChatML 的<|im_start|>和<|im_end|>。如果没有统一标准，每对接一个新模型，开发者都需要重写数据预处理代码。

Jinja 模板正是这个问题的解决方案。模型发布时，会自带一个“说明书”——即 Jinja 模板，它定义了该模型专属的对话拼接规则。你的应用程序只需用通用的方式构建对话列表（如[{"role":"user", "content": "你好"}]），然后交给模板，模板就会自动将其“翻译”成模型认识的格式。

这个模板通常存储在模型的tokenizer_config.json文件的chat_template字段中，或作为一个独立的chat_template.jinja文件存在。

怎么使用？使用 Jinja 模板主要分为编写和使用两个环节。

1. 编写模板（通常由模型提供者完成）

模板的核心逻辑通常包含：

遍历消息：使用{% for message in messages %}循环处理每一条对话。

拼接格式：使用{{ }}输出角色和内容，并包裹模型专用的特殊标记（如<|user|>）和句子结束符。

生成提示：通过{% if add_generation_prompt %}判断是否需要为模型的生成做准备（即添加 assistant 的起始标记）。

可以在 Python 中通过print(tokenizer.chat_template)来查看任意聊天模型正在使用的模板内容。

2. 在部署框架中使用

在 SGLang、VLLM 等推理框架中，通常无需手动指定，框架会自动从模型目录读取并使用默认模板。

如果你需要覆盖或使用自定义模板，可以在启动命令中通过--chat-template参数指定文件路径：

python -m sglang.launch_server \ --model-path /path/to/your/model \ --port 30000 \ --chat-template /path/to/your_template.jinja