企业官网建设流程全解析

简介：DeepSeek作为国产开源大模型，用户在使用路径与模型选择上常有困惑；文档系统梳理了DeepSeek的下载与实用方法，面向从普通用户到技术开发者的不同层级，重点对比了V3与R1两款模型的能力侧重、成本差异及适用场景，帮助读者按需选型。资源为单个PDF文件，共1个文件，压缩包大小约311KB，内容精炼、可随时查阅；目前已有365人学习/浏览。资料围绕官方网页/App直用、Ollama本地部署蒸馏版、API+客户端嵌入第三方平台三类主流方案展开，既覆盖零基础用户的免费注册与对话操作，也包含注重隐私时的本地化部署选择，以及具备计算机基础用户的灵活调用方式。其中尤其对R1模型在逻辑推理、编程与数学任务上的领先表现和使用代价做了清晰说明。适合刚接触DeepSeek的人群快速上手，也可作为技术达人评估部署方案的参考，是快速掌握DeepSeek多路径使用的实用入门资料。

1. 从一份过期的 PDF 开始：DeepSeek 真正该怎么用

很多新人拿到《DeepSeek使用方法.pdf》这类文档，第一反应是照着界面截图点一遍。但等你真打开 DeepSeek 官网，会发现按钮位置、菜单名称甚至默认模型都和你手里的 PDF 对不上。更麻烦的是，PDF 里通常只讲网页对话，不碰 API 调用、本地部署和批量处理 PDF 这类真正能提升效率的场景。这篇笔记不重复那些会过期的截图，而是把 DeepSeek 从网页、API、本地部署到和 PDF 文档来回折腾的完整链路讲清楚，每个步骤都能直接照着复现。适合想把 DeepSeek 接进自己工作流的研发和运维人员，也适合刚入门、想让 AI 帮忙处理一堆 PDF 的普通用户。

2. DeepSeek 三条入口怎么选：网页、API 调用和本地部署

2.1 网页对话入口：适合临时提问和验证输出格式

最常见的用法是打开 DeepSeek 官网对话界面。注册后能直接用，不需要配环境，连续对话时它会记录上下文，可以像是聊天一样追问。网页端适合做三件事：一是体验模型能力，看看回答质量；二是调试你想在 API 里用的提示词，因为网页端能看到完整回答过程；三是处理不涉及敏感信息的一次性任务。

网页端有几个隐性限制容易忽略。对话窗口有长度上限，聊得太长会记不住开头的关键约束；服务高峰期偶尔会提示“服务器繁忙”，这是正常的，换个时间段再试就行。还有一个坑：不要在网页端贴客户提供的敏感 PDF 内容。网页对话默认会用来优化模型，如果文档里有个人信息、未公开代码，最好走本地部署或者用 API 并开启隐私保护选项。

2.2 用 API 把 DeepSeek 接进自己代码：一个最小 Python 示例

网页端再方便也没法和业务系统打通。常见的做法是用官方提供的 OpenAI 兼容接口。DeepSeek 提供了和 OpenAI Chat Completions 兼容的 API，因此可以用 openai 这个 Python 包来调用，只需要把 base_url 换成 DeepSeek 的地址，把模型名改成 deepseek-chat 或 deepseek-reasoner（推理模型）。

from openai import OpenAI client = OpenAI( api_key="sk-你自己的key", # 在官网控制台创建，不要硬编码到代码里 base_url="https://api.deepseek.com" ) resp = client.chat.completions.create( model="deepseek-chat", messages=[ {"role": "system", "content": "你是一个严谨的技术文档助手，输出条理清晰。"}, {"role": "user", "content": "把以下内容整理成三个要点：\nDeepSeek API 每分钟请求数有限制，超了会返回 429。"} ], temperature=0.3, max_tokens=1024, stream=False ) print(resp.choices[0].message.content)

代码逻辑很直接：先实例化客户端，再调用 chat.completions.create 传入消息列表和参数。messages 里 system 角色用来约束回答风格，user 是实际问题。temperature 控制随机性，做信息整理任务建议设为 0.3 以下；max_tokens 限制单次回复长度，如果内容长要调大。跑通之后，你就有了一个可以嵌入爬虫、自动报告、文档处理的入口。

这里要特别注意 key 的安全。千万不要把 api_key 写进 git 仓库，我一般用环境变量，比如在启动脚本里 export DEEPSEEK_API_KEY=xxx，代码里用 os.environ 读取。另外，DeepSeek API 账号余额不足或欠费时会返回 401 或 402 错误，第一次调试看到这类状态码先检查账号余额，别急着改代码。

2.3 本地部署与 API 的选型理由：什么时候别用网页

如果对延迟敏感、要处理大量内部文档，或者就是要让 DeepSeek 模型在你们自己的服务器上跑，那不能依赖在线 API。常见做法是用 vLLM 部署 DeepSeek 开源模型。vLLM 是一个高性能推理引擎，支持连续批处理和 PagedAttention，一旦跑起来吞吐量比原版脚本高很多，适合 24 小时在线的场景。

# 准备好一台至少 24GB 显存的 GPU 服务器，安装 vllm pip install vllm # 启动 OpenAI 兼容服务，模型名和端口可按需改 python -m vllm.entrypoints.openai.api_server \ --model deepseek-ai/DeepSeek-V2-Lite \ --served-model-name deepseek-local \ --max-model-len 16384 \ --gpu-memory-utilization 0.85 \ --port 8000

启动后，代码里只需要把 base_url 改成 http://localhost:8000/v1，model 改成 deepseek-local，就能复用上一小节的调用方式。gpu-memory-utilization 默认是 0.9，如果机器还要跑别的进程，调低到 0.8 更稳；max-model-len 决定了模型能看到的上下文长度，设太大显存不够，设太小处理长文档会截断。

选型时别只看“免费”。本地部署要有人维护、要烧电费，还要处理显存碎片和并发调度。我的判断标准是：如果每天请求量低于几千次，直接用官方 API 划算；如果要压测、要离线批处理几十万条，再搞 vLLM。网页端只适合临时问问题，不适合写进自动化流程。

3. 把 DeepSeek 的输出整理成 PDF：三种可行路径

3.1 网页对话直接打印成 PDF 的步骤

很多人需要的其实是一份“会话记录 PDF”，把 DeepSeek 的问答保存下来发给同事。网页端没有一键导出的按钮，最快的路径是浏览器打印。打开对话页，按 Ctrl+P（macOS 是 Cmd+P），目标打印机选择“另存为 PDF”，然后布局选“打印背景图形”，否则代码块底色和引用标记会消失。

这一步有个易踩的坑：对话特别长时，打印出来的 PDF 会把代码从中间断开。处理办法是在打印前手动折叠代码块，或者把长回答拆成几段分别打印。另外，DeepSeek 网页端是流式输出的，回答没结束前界面上的内容是不完整的，必须先等它完全生成完再打印，否则会丢尾巴。

如果你想得到排版更整齐的 PDF，我一般先把关键问答复制到 Markdown 编辑器，用 Typora 这类工具导出。复制时注意代码块语言标记，DeepSeek 输出的 Markdown 代码块一般带着语言名，粘贴后能保留高亮；然后设置页面边距，导出 PDF。这种方式保留了标题层级、表格和代码高亮，比浏览器直接打印干净。

3.2 用代码把 API 返回结果转成 PDF

批量处理时不可能靠人手复制。更可靠的方案是写完 API 调用后，把结果拼成 HTML，再用工具转 PDF。下面这段代码以 Markdown 文本为中间格式，先用 markdown-it-py 转 HTML，再用 weasyprint 渲染 PDF，支持中文字体。

import markdown_it from weasyprint import HTML def markdown_to_pdf(md_text: str, output_path: str, font_family: str = "Noto Sans CJK SC"): md = markdown_it.MarkdownIt("commonmark", {"html": True}) html_body = md.render(md_text) html_doc = f""" <html> <head> <meta charset="utf-8"> <style> body {{ font-family: {font_family}; font-size: 12pt; line-height: 1.6; }} pre {{ background: #f6f8fa; padding: 12px; border-radius: 6px; overflow-x: auto; }} code {{ font-family: monospace; }} table {{ border-collapse: collapse; width: 100%; }} th, td {{ border: 1px solid #ccc; padding: 6px 10px; }} </style> </head> <body>{html_body}</body> </html> """ HTML(string=html_doc).write_pdf(output_path) # 调用示例：把之前 API 返回的 content 存成 md 后转换 # markdown_to_pdf(deepseek_content, "deepseek输出.pdf")

这段代码的关键在字体。Linux 服务器上没有中文字体时，PDF 里中文全是方框，这就是 3.3 节要一起解决的坑。WeasyPrint 需要系统里有字体文件，可以安装 fonts-noto-cjk 把 Noto CJK 字体装上，也可以在 CSS 里指定一个确定存在的字体路径。如果你在 Windows 上跑，font_family 改成 "Microsoft YaHei" 就行。

参数说明：markdown_it 的 commonmark 模式已经够用，但 DeepSeek 偶尔会输出表格，建议开启 html: True 保留原始 HTML 标签；如果问答里包含图片链接，需要额外把图片 base64 化，否则 PDF 里图片是空的。这个方案适合定时生成日报、周报，也适合把一组问答结果批量打包成归档 PDF。

3.3 反过来让 DeepSeek 读 PDF：解析与转 Word 的闭环

更多时候是手头有一堆 PDF，想让 DeepSeek 总结内容。这时候得先做 PDF 解析，提取文本，再喂给 API。常见做法是使用 pdfplumber 库。如果是扫描版 PDF，需要先 OCR，这一步通常配合 PaddleOCR 或 Tesseract，不能直接用文本提取。

import pdfplumber def extract_pdf_text(path: str) -> str: all_text = [] with pdfplumber.open(path) as pdf: for page in pdf.pages: page_text = page.extract_text() if page_text: all_text.append(page_text) return "\n".join(all_text) # 提取后可以直接交给 DeepSeek 总结 txt = extract_pdf_text("年报.pdf") print(txt[:500])

extract_text 会返回当前页文本，遇到多栏排版时可能会读乱顺序，这是 pdfplumber 的固有限制。对要求不高的场景，方案是把 PDF 先转成 Word，再人工修正后交给 DeepSeek。网上那些“PDF 转 Word”的在线工具也能做，但隐私没法保证，内部文档建议用 LibreOffice 命令行：soffice --headless --convert-to docx 年报.pdf，转出的 docx 保留大部分段落结构，比直接用 pdfminer 提取的结果干净。

我处理批量 PDF 的习惯是：先抽 3 页人工看提取质量，如果文字错乱严重，就换 OCR；如果文本正常，再用前面 2.2 节的 API 逐段总结。这样能把“DFS 文本解析”这个环节从玄学变成可控流程。

4. 用 DeepSeek 批量处理 PDF 文档：提示词与参数调优

4.1 让 DeepSeek 总结 PDF 的提示词写法

提示词决定了输出是否能直接用。不要直接丢一段 PDF 文本说“帮我总结”，而是要把目标、格式、约束都写清楚。我会用下面这个模板：

你是一名资深文档分析助手。请按以下规则处理用户提供的文本： 1. 提取核心观点，输出 5 到 8 个要点，每条不超过 30 字。 2. 要点按重要性降序排列。 3. 如果文本中包含数字指标，单独列出“关键数据”一节。 4. 不要编造原文没有的信息。 5. 输出为 Markdown 格式，用有序列表。 用户文本： {这里填入从 PDF 提取的文本}

这个提示词看起来平平无奇，但每条规则都有用。第 3 条让模型把数字集中输出，方便后续核对；第 4 条能降低幻觉概率，但注意它只是约束，不是保险；第 5 条避免它输出一堆没层级的大白话。把提示词和 4.2 节的参数搭配，一次调用就能得到结构化结果。

4.2 必调参数：temperature、max_tokens 与 top_p

DeepSeek API 的参数沿用了 OpenAI 的体系，默认值适合通用对话，但批量处理 PDF 时要针对性调整。我总结了一张参数表：

temperature 调低后，模型会显得“保守”，但这是好事，处理事实性文档时一致性比创造性重要。max_tokens 是很多人不看重的参数，实际上它直接决定长文档会不会被截断。如果一次调用要输出 5000 字，max_tokens 还保持 4096 就会丢尾巴。

这里给一个配置组合：做 PDF 法律条款比对，temperature=0，top_p=0.7，presence_penalty=0；做头脑风暴或文案改写，temperature=1.2，top_p=0.9，presence_penalty=0.3。不同的任务不要共用同一套参数，API 调试的时候多试几组，找到输出质量最稳的那个点。

4.3 处理长 PDF 的分段策略与上下文窗口

PDF 动不动几十上百页，直接整篇塞给模型容易超过上下文窗口，而且长文本里模型会“忘记”前面的关键信息。常见做法是把文本分段，每段 1000 到 2000 字，段落之间有重叠，然后分别让模型总结，最后再合并成一份总报告。

def split_text(text: str, chunk_size: int = 1500, overlap: int = 200): chunks = [] start = 0 while start < len(text): end = start + chunk_size chunks.append(text[start:end]) if end >= len(text): break start = end - overlap return chunks # 给每个 chunk 调用一次 DeepSeek API，收集结果后再次调用 API 合并 chunks = split_text(extracted_text) summary_list = [] for i, chunk in enumerate(chunks): # 这里调用 2.2 节的 API 函数，传入 chunk 和 section 提示词 summary_list.append(api_summarize(chunk, section_no=i + 1)) final_prompt = "以下是分段总结结果，请合并为一份连贯的文档概述：" + "\n".join(summary_list) # merged = api_summarize(final_prompt)

分段大小不是固定的。中文一个字符大约对应 0.6 到 1 个 token，1500 字大约 900 到 1500 token，即使模型上下文有 32K，也不建议一次塞太满。overlap 的作用是防止 2.4 小节那种“一段末尾的结论被切掉”导致上下文断裂。如果文本里有图表标题或参考文献，尽量在分段时不要把表格的标题和表格内容拆开，否则模型会误解。

要注意，分段总结合并时，模型只依赖各段摘要，原始细节可能丢失。对关键数据要求高的文档，我会在每段摘要里强制要求“保留所有数字和百分比”，然后合并时再加一道“逐项核对数字是否一致”的校验提示词。

5. DeepSeek 使用避坑手册：5 个最常翻车的场景

5.1 现象：回答到一半突然截断

原因有两个：一是 max_tokens 设得太小，模型刚生成到关键结论就被截断；二是输出内容超过了模型单次最大长度限制，即使设置的 max_tokens 很大，也会在硬上限处终止。解决方法是先检查 API 回包里的 finish_reason。如果 finish_reason == "length"，说明是 max_tokens 触顶，调大参数；如果是 "stop"，是正常结束。

处理这类问题可以把长输出拆成多轮：先让模型输出第一部分，再追问“继续”。或者用流式输出，虽然不能完全避免截断，但能实时看到内容，方便判断是设置问题还是模型跑飞了。API 调用加一个重试机制，遇到截断就换更小的请求范围重新调用。

5.2 现象：API 返回 429 Too Many Requests

原因基本是并发请求数超过账号限制，或者单位时间 token 消耗量超限。DeepSeek 的限流是按账维度计算的，不是你机器上开多少线程能解决的。处理时先看控制台的速率限制说明，然后给代码加退避重试：第一次等待 1 秒，第二次 2 秒，最多重试 5 次。同时在业务侧控制并发，批量任务用线程数不超过 4，串行跑更稳。

我见过一个项目把批量任务并发调到 20，结果 1 分钟后全被限流，一个成功请求都没有。后来改成信号量控制并发为 2，配合退避重试，处理 1 万条数据只用了 40 分钟。记住，429 不是 bug，是账号太薄。别为了赶时间把并发拉满，数据没处理完还白白浪费时间。

5.3 现象：本地 vLLM 部署后显存不够直接报 OOM

原因大多是 max-model-len 设置过长或 gpu-memory-utilization 数值太高，也可能是把量化版和原版模型搞混了。先用 nvidia-smi 看显存总量，再根据模型参数量估算：7B 模型在 FP16 下大约需要 14GB 显存，加上激活值至少 20GB。vLLM 报 OOM 时优先降 max-model-len，比如从 32768 降到 8192；其次把 gpu-memory-utilization 从 0.9 调到 0.8，给 KV cache 留出余量。

还有一个常被忽略的是 model 加载格式。vLLM 默认自动选择，但如果你手动指定 dtype=float16，而模型权重原本是 bfloat16，会增加显存开销。本地部署不是非黑即白的，用 AWQ 或 GPTQ 量化版能把 7B 模型压到 8GB 以内，但精度会有轻微下降。对文本摘要类任务影响很小，可以接受。

5.4 现象：生成的 PDF 中文全部变成方框乱码

原因不是 DeepSeek 的问题，是 PDF 渲染环境里缺少中文字体。服务器端大多是精简系统镜像，没有 fonts-noto-cjk，也没有 simsun。解决方法是先执行 fc-list | grep -i "cjk" 检查字体，如果没有任何输出，就安装字体包：apt install fonts-noto-cjk，或者把 Windows 的 simhei.ttf 拷贝到 /usr/share/fonts/truetype/，然后执行 fc-cache -f。

处理后还乱码，就要检查 weasyprint 的 CSS 里 font-family 拼写。Linux 上写成 "Noto Sans CJK SC"，macOS 写成 "PingFang SC"，Windows 写成 "Microsoft YaHei"，不要统一用 “SimHei” 这种只有 Windows 认识的名字。字体这块属于玄学问题，配置好一次就能长期复用。

5.5 现象：输出内容不断重复同一句话，像死循环

原因通常是 temperature 设置太高，模型陷入了局部重复，或者 presence_penalty 太低，模型没有动力换词。解决方法是先把 temperature 降到 0.4 以下，然后把 presence_penalty 调到 0.2 到 0.3。如果还不行，检查你的消息列表是不是往 messages 里重复塞了历史输出。有的程序会把上一次模型的输出又放进 user 消息，相当于拿自己的回声继续问自己，自然容易复读。

另一个场景是 DeepSeek 网页端连续追问后开始复读，这时候点开“新对话”按钮，清空上下文再问。API 场景直接清空 messages，不要试图用对话历史去“纠正”模型复读的问题，那只会让事情更糟。

6. 从能用走向好用：把 DeepSeek 做成自动化管线的三个进阶技巧

6.1 用 Function Calling 让模型按固定格式返回数据

处理 PDF 时，与其手动解析模型的文字回答，不如直接在请求里定义工具，让模型返回结构化结果。DeepSeek API 支持 OpenAI 兼容的函数调用，把提示词里要提取的字段写成 schema，然后让模型填空。调用后从 tool_calls 参数里取 JSON，就能直接存数据库或写进报表。定义工具时参数描述要具体，比如“页码”字段写明“来自文档标注页码，未标注则不填”，这样模型不会瞎编。

6.2 维护一份自己仓库里的《DeepSeek 使用说明》

别把网上流传的 PDF 当唯一真理。我的做法是在项目仓库里放一个 docs/deepseek-usage.md，记录当前用的模型名、base_url、推荐参数、踩过的坑，每次升级后更新。这样做不是做文档表演，而是因为模型版本一变，很多参数默认值都会变。比如之前 temperature=1.0 用得好好的，升级后同样的任务偏题了，就要重新测试。把这个文件转成 PDF 或者 Markdown，团队新成员可以直接照着跑通，不用再在网上搜那些互相抄来抄去的教程。

6.3 验证输出质量的三个判断标准

自动流程跑得快，但输出质量要人工抽检。我看三个东西：一是结构和规则是否一致，有没有漏掉提示词里的要求；二是关键数据是否和原文一致，这一步可以用脚本把模型输出的数字和 PDF 原文里的数字做比对，能抓出至少一半的幻觉；三是回答有没有出现“根据上下文推测”“可能”这类模糊词，重要结论如果用了推测语气就打回重试。这三个标准形成质检清单后，才算真正把 DeepSeek 用成了生产力工具，而不是一个好看的黑匣子。

我自己的习惯是每周抽一批自动化处理过的 PDF 总结做人工复核，复核结果回填到提示词模板里。连续改上两周，输出质量就会稳定在可用水平。希望这个从“使用方法”到“生产工具”的思路能帮到你。

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