企业官网建设流程全解析

简介：《DeepSeek应用手册》是一份面向深度学习与自然语言处理实践者的入门到进阶参考文档，适合希望系统掌握DeepSeek使用技巧、API集成与私有数据接入的开发者、研究人员及内容工作者。手册围绕多模型协同、文件上传、联网搜索、常用指令集与万能提问模板展开，并延伸到Cherry Studio、Ollama、Chatbox等工具的API与本地化部署路径，同时解释参数规模、max_seq_len、hidden_size等配置项及蒸馏技术、思维链、Qwen与Llama差异等背景知识。整包仅含1个docx文件，大小约207KB，便于检索与随身查阅；内容按使用技巧、使用场景、私有数据集和基础知识组织，兼顾操作指引与概念梳理。目前已有287人学习，适合需要快速建立DeepSeek应用框架、对照配置参数或在本地与远程环境中接入私有知识库的读者查漏补缺。

1. 从聊天框到私有机房：这份 DeepSeek 应用手册能省掉哪些弯路

DeepSeek 应用手册这四个字，很多人第一反应是又一个提示词合集。真拆开看，它更像一张从「聊天框」走到「私有机房」的路线图：前半段讲 R1 和 V3 怎么拆开用、联网什么时候开、文件怎么丢；后半段直接进 API 集成建知识库、Ollama 本地跑、LoRA 微调、KTransformers 把 671B 塞进 24G 显存。适合的人群很明确——手里已经有 API key，或者机房里躺着一张 4090，却始终没把模型接进业务流程的开发者。下面按指令层、数据层、参数层、部署层四段拆，每一步都给到能直接抄的命令和参数，新手照着走能跑通，熟手能直接跳到参数边界和踩坑那几节。

2. 三段式协同与斜杠指令：把 R1 和 V3 拆开用的具体写法

2.1 为什么是 R1 拆框架、V3 出稿、R1 回炉

同一个问题丢给 R1 和 V3，体感差别很大：R1 回得慢，但结构清楚、会主动补边界条件；V3 出字快，一段话几秒钟就铺开，但遇到多步推理容易跳步。根子在于输出 token 的构成——R1 会先把问题拆成若干步写出思维链，再给结论，输出长度往往是普通对话的两三倍；V3 没有这段思维链，首 token 快、单位时间产出高。把这两类模型的特性对上任务，就有了手册里的三段式：结构设计交给 R1，长文扩写交给 V3，最后再让 R1 做一次挑错。

我一般会把三段的边界卡得很死。第一段只要框架，明确写「只给标题，不要正文」，防止 R1 一上来就写三千字；第二段把框架原样喂给 V3，要求按节扩写，温度调高一点让措辞不那么僵；第三段把初稿丢回 R1，只让它找参数矛盾和逻辑跳跃，不要重写全文。三段跑下来，总耗时通常比全程用 R1 少一半，成稿质量又比全程 V3 高一截。

import os from openai import OpenAI # 用环境变量接密钥和服务地址，避免把凭据写死在脚本里 client = OpenAI( api_key=os.environ["DEEPSEEK_API_KEY"], base_url=os.environ["DEEPSEEK_BASE_URL"], # 兼容 OpenAI 协议的服务地址 ) R1 = os.environ.get("MODEL_R1", "deepseek-reasoner") # 带思维链的推理模型 V3 = os.environ.get("MODEL_V3", "deepseek-chat") # 通用对话模型 def ask(model: str, prompt: str, temperature: float = 0.7, max_tokens: int = 2048) -> str: resp = client.chat.completions.create( model=model, messages=[{"role": "user", "content": prompt}], temperature=temperature, # 推理和检查用低温，扩写用高温 max_tokens=max_tokens, # R1 的思维链也计入输出，要留够 ) return resp.choices[0].message.content # 第一段：R1 只出框架，明确禁止展开 outline = ask( R1, "我要写一份面向运维的私有化部署方案，先只给一级和二级标题框架，不要正文，不超过 12 个标题。", temperature=0.3, ) # 第二段：V3 按框架扩写，速度优先 draft = ask( V3, f"按下面的框架逐节扩写，每节 150 字左右，保留标题层级：\n{outline}", temperature=0.8, max_tokens=4096, ) # 第三段：R1 回炉，只挑错不重写 review = ask( R1, f"下面是一份部署方案初稿。逐条检查参数是否自相矛盾、步骤是否有遗漏，" f"按「问题 / 位置 / 修改建议」三列输出，不要重写全文：\n{draft}", temperature=0.2, )

逻辑上，temperature在三段里的取值是有讲究的：第一段和第三段需要模型收敛，0.2 到 0.3 就够；第二段是扩写，0.8 左右能让措辞不那么模板化。max_tokens在 R1 那两段要特别留意，思维链会吃掉不少额度，设小了会出现「想到一半被截断」的情况，这时候/续写指令就派上用场了。

常见误用有两种。一是让 R1 一口气写五千字长文，结果又慢又容易断，还贵；二是让 V3 做多步推理，中间步骤经常被悄悄跳过，看着通顺，结论却是错的。把任务按「结构化」和「量产化」分开，这两类问题基本就消失了。

提示：部分兼容层会忽略temperature字段，甚至不认 system 角色。约束条件最好直接写进 user 内容里，别指望参数生效。

2.2 五个斜杠指令：本质是提示词展开，不是模型魔法

手册里列的/续写、/简化、/举例、/步骤、/检查，很多人以为是模型内置的能力。实际用下来，它们更像客户端层面的快捷替换——你敲一个短词，工具把它展开成一段完整提示词再发出去。理解这一点很重要：如果客户端不解析，模型看到的就是字面上的「/步骤」三个字，回答自然是懵的。

最稳的做法是本地先展开再发送，不依赖客户端支持：

SLASH = { "/续写": "上一条回答被截断了，请从断点继续，不要重复已经输出的内容。", "/简化": "把上面的内容改写成非专业读者能读懂的话，保留关键数字和结论。", "/举例": "针对上面的每条结论，各给一个可以运行的真实例子，代码要带注释。", "/步骤": "把上面的方案拆成按顺序执行的步骤，每步写清输入、动作、预期输出。", "/检查": "逐条检查上面的内容，标出事实错误、参数矛盾和逻辑跳跃，并给出修正。", } def expand(text: str) -> str: # 长指令优先替换，避免 /续写 被 /续 之类的短词误伤 for key in sorted(SLASH, key=len, reverse=True): text = text.replace(key, SLASH[key]) return text

这段替换逻辑里，按 key 长度倒序是个小细节：如果以后加了/续写完整版这类更长的指令，短词先替换会把长词拆坏。手册里给的两个练习——「/步骤 如何用手机拍摄美食照片」和「请解释量子计算，然后 /简化」——用意也在这里：前者验证步骤拆解，后者验证同一段内容在简化前后的信息密度差异。跑一遍就能直观感受到，指令的价值不在「神奇」，而在「把一句模糊的话固定成一套明确的输出要求」。

2.3 万能提问模板与文件上传的取舍

手册给的模板是「背景 + 需求 + 约束条件」，约束条件可省。这个结构看着朴素，实际能解决大部分「答得太泛」的问题。对比一下：「怎样提高英语水平」得到的是泛泛而谈；「我家小孩读初一，怎样提高他的英语水平，不需要考虑口语问题」得到的方案会具体到词汇量和语法专项。背景决定了模型的先验从哪来，约束决定了它往哪个方向收。

上传文件这块，四类格式的支持程度差别不小。纯文本和 Markdown 最省心，结构清晰、解析无损；Excel 适合带表头的数据，模型能读懂行列关系；图片走的是多模态通道，适合截图、票据、手写笔记；PDF 是最容易翻车的——带文字层的还行，扫描件解析出来常常是空白或者乱序文本。我一般的做法是：能拿到原始 docx 就不要导 PDF，非要给 PDF 就先做一遍 OCR，确认文字能选中再上传。

2.4 联网搜索：三个开启时机和一套固定问法

联网开关不是越多越好。查询最新消息、需要实时数据、验证信息准确性，这三种场景不开联网基本拿不到对的答案；反过来，让模型解释一个概念、改写一段文案、做逻辑推演，开联网只会拖慢速度，还可能把不相关的网页内容混进来。

开启之后还有两步不能省。一是明确提出「需要最新信息」，并在问题里带上时间范围，比如「最近三个月」；二是要求给出来源，方便自己回查。我常用的固定问法是：「请检索最近三个月内的公开资料，回答下面的问题，每条结论后面标注来源和时间，找不到来源的直接说没有。」这句话一加，胡编的概率会明显下降。手册里提到的实时数据分析属于更靠后的玩法，基础篇先把这三步走顺，后面接数据管道才有意义。

3. 私有知识库的三条路：Cherry Studio、Ollama、Chatbox 的边界与 API 集成步骤

3.1 三条路的边界：先想清楚数据能不能出网

API 集成、本地部署、远程调用，这三条路不是新旧关系，而是适用场景不同。选错路的代价很大：数据敏感的业务走了 API，合规上过不去；显存不够的机器硬上本地 32B，跑一半 OOM；团队共用一台机器却每人本地拉一份模型，磁盘先炸。

判断顺序我一般是这样：先问数据能不能出网，不能就排除 API；再看本机显存够不够跑目标规模，不够就走远程；最后才考虑易用性。这个顺序反了，后面一定要返工。

3.2 API 方式：Cherry Studio 建库的五步

这条路的核心是把「模型」和「资料」分开：模型走服务商的 API，资料留在本地客户端里做检索。步骤不复杂，但每一步都有容易忽略的点。

1. 下载安装 Cherry Studio，在设置里填入 API key 和服务地址。地址填兼容 OpenAI 协议的那个，不要填网页版地址。
2. 新建知识库，命名按业务来，比如「售后FAQ」「内部规范」，不要都叫「知识库1」。
3. 上传文件。优先 docx、md、xlsx，尽量别用 PDF，尤其是扫描件。
4. 等待切分和向量化完成，检查切分出来的片段是否通顺，有没有整段乱码。
5. 对话时手动勾选对应的知识库。这一步最容易忘，勾了和没勾的回答完全是两回事。

文件格式这块值得单独说一句。PDF 的版面信息在解析时经常丢，双栏排版会变成左右交错的两段话，表格会变成一堆没有列名的数字。真要用 PDF，先确认能用鼠标选中文字，选不中的就是扫描件，得先 OCR。Excel 反而好用，表头清楚、行列关系明确，模型读出来的数据不容易错位。

3.3 本地方式：Ollama 拉模型 + Chatbox 接入

本地路线的第一步是确认硬件。R1 的蒸馏版按参数量分了好几档，显存需求差别很大，先看清楚再拉，不然几十 GB 下载完发现跑不动。

# 先看显卡显存，确认能放下多大的模型 nvidia-smi --query-gpu=memory.total --format=csv # 拉取指定规模的蒸馏版，默认走 Q4 量化 ollama pull deepseek-r1:32b # 确认模型已经落地，顺便看体积 ollama list # 前台启动，监听所有网卡，方便内网其他机器连 OLLAMA_HOST=0.0.0.0:11434 ollama serve

ollama pull后面的标签决定了模型规模和量化等级，32b指的是 320 亿参数的蒸馏版，Q4 量化后权重在 20GB 上下，加上 KV cache，24G 显存的卡跑起来刚好，上下文开太大还是会紧张。OLLAMA_HOST默认是127.0.0.1，只允许本机访问，改成0.0.0.0才能被内网其他机器连上，这个改动只在当前会话生效，重启就没了，想持久化得改服务配置。

拉完模型之后装 Chatbox，在设置里选 Ollama 作为提供方，地址填http://127.0.0.1:11434，模型列表里会出现刚才拉的版本，选中即可。如果 Chatbox 和 Ollama 不在同一台机器，地址要换成服务器的内网 IP。

3.4 远程方式：改环境变量，别改代码

远程路线的本质是把 Ollama 从「只监听本机」改成「监听内网」，再让 Chatbox 连过去。Linux 上改 systemd 配置是最稳妥的做法，比每次启动前手敲环境变量可靠。

# 用 drop-in 方式覆盖服务配置，不动原始 unit 文件 sudo systemctl edit ollama.service

[Service] # 监听所有网卡，端口保持默认 Environment="OLLAMA_HOST=0.0.0.0:11434" # 浏览器端跨域访问需要，纯 API 调用可以不加 Environment="OLLAMA_ORIGINS=*"

# 重载配置并重启 sudo systemctl daemon-reload sudo systemctl restart ollama # 从另一台机器验证连通性 curl http://192.168.1.10:11434/api/tags

OLLAMA_HOST决定监听地址，OLLAMA_ORIGINS决定哪些来源能跨域访问，后者在 Chatbox 这类带界面的客户端里经常是连不上的真正原因。改完之后一定要用curl从另一台机器验一次，能看到模型列表才算通。Windows 上对应的是setx OLLAMA_HOST "0.0.0.0:11434"，设完要重启 Ollama 进程才生效。防火墙和端口放行这类事，改完配置第一件事就是查，别等到客户端报超时才回头找。

3.5 分块与检索参数：知识库效果的分水岭

很多人以为知识库效果差是模型不行，实际上大半问题出在切分。块太大，检索命中一整页，关键句被无关内容稀释；块太小，上下文断裂，模型拿到半句话也答不上来。我一般用下面这组起步参数，再按文档类型微调。

调整的顺序是：先看切分片段本身通不通顺，再看召回的是不是相关段落，最后才动 top_k 和阈值。跳过前两步直接调参数，往往越调越乱。

4. 参数与选型：1.5B 到 671B 的显存账、CoT 与蒸馏

4.1 参数量 B 到底意味着什么

模型名字后面的1.5B、7B、32B，B 是 billion，指的是参数个数，1.5B 就是 15 亿个参数。这个数字直接决定两件事：权重占多少存储，推理要多少显存。粗算方法是参数量乘以每个参数的字节数——FP16 每参数 2 字节，Q4 量化每参数约 0.5 字节，再留出 KV cache 和框架开销的余量。

这张表是估算，不是精确值。同样是 7B，词表大小、层数、是否用 GQA 都会让实际占用差出几个 GB。选型时按表往下压一档更保险，比如 24G 卡跑

本文还有配套的精品资源，点击获取