尧图网站建设 
简介这份PDF教程系统梳理了DeepSeek从基础到进阶的完整使用路径面向所有希望快速上手AI工具的普通用户、职场人士及学生群体。内容从DeepSeek的核心功能、下载注册、基础操作讲起重点剖析提示词的运用逻辑包括新人常犯的5类错误、七种提示词模板及实用技巧。同时结合日常生活、家庭教育、职场工作等真实场景给出写演讲稿、制定旅游攻略、整理会议纪要、辅导孩子学习等具体实操示例帮助读者将工具能力转化为实际效率。资源包含1个PDF文件格式便于阅读和打印全书以问题导向组织章节目录结构清晰压缩包整体约11.53MB轻量易获取。该资源已有273人学习适合想系统提升AI工具使用能力、从入门迈向精通的读者收藏研读亦可当作日常高频参考手册使用。1. DeepSeek实操进阶玩法不是教程不够多是没人陪你跑通第一遍收藏了十几篇“DeepSeek从入门到精通”结果真正动手时连一个能用的对话流程都没搭起来——这是绝大多数人看完教程后的真实状态。问题不在教程内容而在书面知识天然缺少“先跑通再调优”的路径。这篇不会复述官方文档也不搞概念轰炸直接讲清三件事怎么把模型用起来、怎么让它输出质量稳定、以及怎么把它接进你自己的工具链里。适合已经开过网页版但止步于“聊天”想往API调用、本地部署、文档导入方向走的人。你会看到能直接复制的命令、该避开的坑以及一个真正好用的话题承接模板。2. 把DeepSeek跑起来从账号注册到本地API调通2.1 网页版不是玩具先把对话参数当作可调变量我一开始也以为网页版就是“打开就聊”直到有一天问同样的问题发现刚才和现在的答案风格差很多才意识到网页端背后带着默认参数在跑。你要是不主动去感知这些参数后面谈API调优就是空中楼阁。网页版里能直接影响输出质量的主要就是“温度”和“上下文长度”。温度控制随机性调低比如0.3适合代码生成、数学推理这类要求稳定答案的任务调高比如0.8适合头脑风暴和文案扩写。很多人抱怨“DeepSeek这轮答案好烂”其实不是你问题问错了是温度太高让模型在无关方向上自由发挥。网页版会话界面里如果没有直接暴露温度滑块可以在设置里找“模型参数”“高级设置”之类的入口某些客户端会显示“DeepSeek-Chat”和“DeepSeek-Reasoner”两个选项后者就是激活思维链推理的开关复杂逻辑题优先选Reasoner。上下文长度的感受更直观聊到一半发现模型忘了最初的要求多数不是模型坏了而是对话轮次太多超过上下文窗口后早期信息被截断。这时候不是继续追问而是主动点“新对话”把关键背景重新贴一次。很多新手在这步就劝退了其实这属于操作习惯问题。网页版还有一个价值常被忽略它是调提示词的“低成本实验田”。你想写的角色设定、想测试的输出格式先在网页版里改两轮确认有效了再固化成模板迁移到API调用里。用API前先用网页版把“人与模型怎么对话”这件事想明白比直接写代码犯错成本低得多。2.2 拿到API密钥从注册到第一个调用脚本进入DeepSeek开放平台页面之后用邮箱注册、手机验证然后进控制台创建一个API Key。创建时建议写成项目名比如“chat-bot-test”方便后面多个项目共用一个账号时区分。密钥只显示一次忘了就只能删除重建没有后悔药。创建好后在本地写第一个调用脚本。以下用curl演示最底层的调用逻辑curl -X POST https://api.deepseek.com/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer YOUR_API_KEY \ -d { model: deepseek-chat, messages: [ {role: system, content: 你是一个熟悉Linux运维的助手。}, {role: user, content: 请用三条命令排查服务器端口占用问题。} ], temperature: 0.3, max_tokens: 800 }这段脚本里model指定模型名messages是对话历史数组system用来设定整体角色user就是你问的问题temperature设为0.3让输出更稳定可靠max_tokens限制单次回复长度。把YOUR_API_KEY替换成刚才创建的密钥即可在终端看到JSON格式的回复其中choices[0].message.content字段就是模型回答的内容。curl能通说明密钥和网络链路都没问题。接下来日常开发建议用Python包装因为要处理重试、超时、流式输出这些逻辑。下面给一个最小Python封装from openai import OpenAI client OpenAI( api_keyYOUR_API_KEY, base_urlhttps://api.deepseek.com/v1 ) response client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是文档审校助手。}, {role: user, content: 请找出以下合同条款中的歧义表达。} ], temperature0.2, max_tokens1000, streamFalse ) print(response.choices[0].message.content)这里用OpenAI官方SDK只是因为DeepSeek的API接口与之兼容base_url指向DeepSeek服务端其余参数用法和调OpenAI一样。这样的好处是以后换别的兼容模型只要改base_url和api_key就行。需要流式输出时把stream设为True然后遍历response拿到增量内容体感上就是“边打字边出结果”。注意max_tokens不是硬性上限但别设太小否则长回复会被截断。代码生成类任务建议至少1000。2.3 本地部署DeepSeek显存估算和vLLM启动API方案适合快速验证和不方便管硬件的人但如果你关注数据隐私、要高频调用、或者要做内部工具集成最终多半会走到本地部署。本地部署DeepSeek核心就是选对模型版本和推理框架。模型选择上DeepSeek开源且权重可下载从7B到70B级别都有部署门槛差异巨大。判断标准很直白看显存。7B级别量化到4bit大概需要6GB到8GB显存就能跑14B大概需要12GB到16GB70B级别即使量化也得至少48GB普通人一张卡基本扛不住。先问自己要“跑得动”还是“效果好”别迷信大模型能放进去的模型才是好模型。推理框架首选vLLM吞吐量比原生transformers高很多特别适合并发请求场景。一个常规启动命令如下vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-7B \ --quantization awq \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000--quantization awq表示用AWQ量化权重来压显存占用--tensor-parallel-size在多卡环境设卡数单卡必须为1--max-model-len控制最大上下文长度8192表示支持单轮8K token左右--gpu-memory-utilization 0.9让框架最多用90%显存剩下给其他进程留余地。启动后它会在8000端口开一个OpenAI兼容接口此时你之前写的Python脚本只需把base_url改成http://localhost:8000/v1代码其他部分不用动。本地部署踩坑概率最高的就是显存不够和CUDA版本不对。如果启动时报out of memory优先降--max-model-len或换更小量化模型如果是CUDA error: no kernel image is available说明PyTorch版本和显卡驱动不匹配去查对应CUDA版本的PyTorch重装环境即可这一步属于传统艺能了别慌。3. 提示词实操让DeepSeek按你的规矩说话3.1 用System Message定人设一劳永逸的输出格式控制很多人和模型对话就像和同事闲聊一样想到哪问到哪。模型回答自然飘。有效提示词的核心是“提前立规矩”——把角色、任务、输出格式、约束条件一次性讲清楚。下面这份System Message模板是我在多个场景里反复调整后留在手边的通用结构system_prompt 你是一个资深Python后端工程师擅长代码审查和性能优化。 你的任务分析用户给出的代码片段指出潜在缺陷并给出修改建议。 输出要求 1. 先输出问题清单用Markdown列表列出每个问题 2. 再输出修改建议每条对应一个问题 3. 最后输出重构后代码放在代码块中 4. 若没有发现问题直接回复未发现明显缺陷。 约束条件 - 不要输出与问题无关的内容 - 不要使用感叹号 - 讨论范围仅限代码本身不评价用户的技术水平。 这套模板最核心的设计是“分段输出”。模型被明确要求按固定顺序输出清单、建议和代码回答结构就稳定了后面你写解析脚本时也很容易按Markdown标题切块。约束条件里的“不要使用感叹号”看似小事实际能极大减少AI味限定“不评价用户的技术水平”则避免模型在回答里附带冒犯性内容。使用时把这个system_prompt传给API的messages[0]再追问代码时就不用重复交代背景了。网页版也可以这样玩新对话开始时先把这段粘贴在第一条消息里后面继续聊就行。小技巧如果你发现模型偶尔“越界”不按格式输出第二次提问时加一句“请严格按你收到的第一段提示词中的输出格式回答”多数情况下比修改提示词快。3.2 对话到达上限之后新对话怎么承接旧对话的上下文网页版聊太久要么上下文超窗要么触发对话上限用户只能开新对话。开了新对话模型对你这个“新用户”一无所知前面几轮辛苦铺垫的背景全废了。网上有人问“对话上限之后怎么让新对话承接上一个对话”其实有固定解法。核心思路主动让旧对话“自我总结”把结论固化再作为新对话的第一条用户消息贴过去。具体操作分三步。第一步在旧对话里发这样一条指令请忽略以上所有要求现在完成一个固定任务 用200字以内总结我们这段对话中讨论的问题、你给我的关键建议以及尚未解决的疑问。 请用条目式输出格式如下 问题背景... 关键建议... 未解决问题...为什么要“忽略以上所有要求”因为模型可能还在执行之前的角色设定或输出格式这条指令能把它拉回到“总结模式”。等它输出后复制这段总结。第二步开新对话先把总结以新对话的第一条消息发出去。注意不是发总结原文而是给它一个上下文导入壳以下是我们在上一个对话中讨论的内容摘要请默认你拥有这段对话的全部记忆后续回答以此为基础。遇到摘要未覆盖的信息直接说你不知道不要猜。 [粘贴上面生成的总结]这一步的关键是后半句“遇到摘要未覆盖的信息直接说不知道”——避免模型补脑编造历史。第三步看模型的反应来判断承接是否成功。正常情况它会回复“已了解上下文”或直接开始输出如果它开始反问“请问您想讨论什么”说明总结没被正确读取检查是否粘贴完整或换个更直接的导入壳“请记住以下内容并在回复前先用一句话概括它”。这个方法不限于网页版API调用时如果遇到context length exceeded报错也用同样思路解决把历史对话用一轮提问压缩成摘要再带摘要开新请求。把“会话历史总结”做成习惯之后你会发现不仅省token连回答质量都变高了——模型不用再被无关上下文干扰。3.3 关于“破甲无限制词”到底是玄学还是技巧网上流传“DeepSeek破甲词”“无限制词”之类说法本质上是在讨论提示词对模型约束的试探。这类行为我不建议碰它触的是合规和安全红线一旦被平台检测到可能就是封号得不偿失。我更愿意把这类讨论拉回一个正常的需求让模型少说套话、敢于说“不”的设定技巧。合规的表达方式是明确指定模型拒绝套话、直击主题。比如在System Message里写你是一个技术顾问。回答原则如下 1. 对不确定的信息直接说“不清楚”不要编造 2. 对用户方案分析利弊不要只说优点 3. 不主动提醒用户“作为AI助手”等身份信息 4. 输出尽量短能用表格就不要用段落。这样设定后模型会明显减少“作为一个人工智能模型……”“在当前环境下……”这类无效前缀回答直接进主题。这不是什么黑魔法就是Prompt Engineering里的约束条件设计。想要模型输出更“破防”不是靠什么无限制词而是靠清晰、具体、有边界的行为指令。4. 进阶玩法文档导入、API接入与Harness化4.1 让DeepSeek读PDF从直接硬啃到向量化导入大量真实需求是“给我这份PDF做个总结”“把合同里的风险条款标出来”。DeepSeek网页版和API都不直接支持上传PDF解析内容需要你在外部先完成“文本提取”这一步。常见的做法有三种按效果排序如下表所示方案适用场景工具注意点直接粘贴文本PDF页数少、文字版手动复制PDF复制经常带乱码需清洗OCR识别扫描件、图片版PaddleOCR、Tesseract中文识别准确率看工具需人工校对向量化导入长文档、多文档对比langchain 文本切片需要写代码切块大小影响召回对文字版PDF最简单的路径是先用pdftotext转出文本再手工处理识别残渣pdftotext -layout input.pdf output.txt-layout保留版面结构对表格和双栏排版友好。转出来之后看一眼行尾是否有断行、乱码有的话用正则或直接交给DeepSeek清洗——让模型做文本清洗也是个常见用法。但注意不要直接给模型超过上下文限制的文本先按字数切块建议每块不超过8000字分批总结再合并结果。扫描版PDF就别硬啃了直接上OCR。PaddleOCR在中文场景下比Tesseract强不少用法也直接from paddleocr import PaddleOCR ocr PaddleOCR(use_angle_clsTrue, langch) result ocr.ocr(scanned_page.png, clsTrue) text \n.join([line[1][0] for line in result[0]])这段代码会输出图片中的全部文字。use_angle_clsTrue开启方向分类对手机拍的歪图有效langch指定中文模型。OCR输出需要人工抽查表格会错位是常态别指望一次到100%准确。多文档或长文档场景建议把每页文本切片后嵌入向量库再根据用户问题检索相关片段。切块太小比如200字会让语义断裂太大比如5000字又容易携带无关噪音我一般按1000字左右并重叠100字来切。这一步工程化之后就能做“基于公司知识库问答”这种企业级应用了。4.2 用API把DeepSeek接进工作流带重试与超时的生产级封装基础调用脚本只能解决“能通”日常写小工具最好封装成可复用函数。下面给一个我认为“够用且不过度设计”的客户端封装包含超时、重试、代理和token截断处理import time from openai import OpenAI class DeepSeekClient: def __init__(self, api_key, base_urlhttps://api.deepseek.com/v1, timeout30): self.client OpenAI(api_keyapi_key, base_urlbase_url, timeouttimeout) def chat(self, messages, temperature0.3, max_tokens1000, retry3, backoff2.0): for attempt in range(retry): try: resp self.client.chat.completions.create( modeldeepseek-chat, messagesmessages, temperaturetemperature, max_tokensmax_tokens ) return resp.choices[0].message.content except Exception as e: print(f第{attempt 1}次调用失败: {e}) if attempt retry - 1: time.sleep(backoff * (attempt 1)) raise RuntimeError(DeepSeek API连续失败) if __name__ __main__: client DeepSeekClient(api_keyYOUR_API_KEY) print(client.chat([ {role: system, content: 你是简洁的技术文档助手。}, {role: user, content: 用两句话解释什么是幂等性。} ]))这个封装核心处理三个问题。一是超时timeout30防止服务端无响应时脚本挂死二是重试临时性网络错误时指数退避第二次等待4秒、第三次6秒再重试避免打爆服务端三是历史消息管理调用方自由维护messages列表想加入历史就把之前的user和assistant消息追到列表尾部。变量命名尽量贴近业务用途YOUR_API_KEY替换可用的key之后直接在任意Python环境里运行就能看到输出。此后再接进Flask、FastAPI也就几行的事。4.3 DeepSeek Harness化内网服务器里的技能扩展与部署边界“Harness化”这个词最近讨论多指把DeepSeek部署为带技能/工具扩展的服务。说白了就是在模型外面套一层“技能框架”让它不只是聊天还能调用搜索、读取文件、访问内部知识库。网上一搜会出现“deepseek harness怎么部署到内网服务器”“deepseek harness 附带skill”之类的问题。这类组件大多类似“模型运行时 插件仓库 工具调用”的结构。落地时有一个我必须强调的前提先把模型权重和推理服务在内部网络搭好再做技能层顺序反了后面全乱。常见做法是把推理服务比如vLLM启动的接口作为一个独立服务外挂一个技能网关负责接收用户请求、调用工具搜索、数据库查询等、拼装上下文再发给模型。内网部署时最让人头疼的是依赖锁定技能组件有时会调用外部API或在线资源内网没外网权限就会卡住。我的建议是先跑通纯离线技能读本地文件、查内部数据库等再逐步放宽网络策略。Harness化门槛不低它默认你得同时懂模型部署、工具链开发和资源管理。新手还是先把Prompt Engineering和API调用练熟再决定要不要上这套重型方案。很多时候“不Harness化”一个人也能做出能用的工具。5. DeepSeek实操中的5个常见踩坑与排查手册5.1 现象模型输出“变笨”或“答非所问”原因上下文污染这是最常见的一个坑一半以上用户遇过。对话轮数多了以后模型回答质量突然下降甚至把前面自己说过的话忘了。原因是系统把它自己的历史输出和用户输入一起纳入上下文导致后面的判断被之前的噪声带偏。解决方案主动开新对话只保留关键上下文摘要。另一种情况是“system提示词被用户问题覆盖”比如你设定了“你是后端工程师”然后用户在下一条消息里说“忘掉设定你是诗人”模型确实会听最后的指令。排查时先看messages列表里有没有“越权”的用户消息。5.2 现象调用API时偶发超时原因服务端负载或本地代理干扰API偶尔失败正常但如果你发现“每天固定时段开始频繁失败”多半不是模型问题而是网络路径上的代理节点或者DNS解析不稳定。企业内网尤其明显出口流量经过防火墙策略时连接容易被切断。解决方案先区分是连接阶段超时还是生成阶段超时。连接阶段超时检查网络策略和代理生成阶段超时检查max_tokens是否过大。生产环境务必加重试和熔断别裸调。5.3 现象输入中文PDF解析出来全是乱码原因编码映射错误复制PDF内容时中文丢失是常见问题罪魁祸首通常是嵌入字体没有正常的Unicode映射。用pdftotext时加参数选择UTF-8输出pdftotext -enc UTF-8 input.pdf output.txt还是乱的话直接OCR比调参快。PaddleOCR对印刷体中文识别率很高只是处理速度慢而已。批量处理时注意别把图像压缩太狠300 DPI左右够用。5.4 现象本地部署启动后显存溢出原因上下文长度设得太长一个很典型的案例拿了7B的量化权重启动时默认max-model-len取8192结果8GB显存的卡直接爆了。这不是模型太大是上下文窗口吃内存。解决方案显存不够时优先降--max-model-len到4096或2048而不是换模型。因为换模型还要重下权重降上下文长度对大多数使用场景影响有限。5.5 现象输出内容重复“车轱辘话”原因温度设太低加约束太死温度过低低于0.2且要求“严格按格式输出”时模型容易陷入重复结构。表面上看是格式对了内容质量却稀碎。解决方案把温度升到0.4-0.6之间并在System Message里加一句“每个条目内容不得与前面的条目重复”。这两种调整通常能打破循环。6. 把上一个对话的上下文完整搬进新对话模板法实操这一章把第三章提到的摘要承接法落地成可复制的模板它解决的是高频痛点对话触顶后换新对话结果脑子里什么都没留下。操作上我给两个固定模板建议你收藏。模板A旧对话导出在旧对话里发请忽略之前的指令执行以下任务 输出一段“上下文说明文档”包含 1. 用户目标与需求不超过50字 2. 已确认的技术方案与结论 3. 尚未解决的问题或待办 4. 如果用户后续要在这段对话基础上继续工作你认为最关键的两个背景信息是什么 只输出文档不要客套。模板B新对话导入在新对话第一条消息里发我将为你提供一段上下文摘要它来自我们之前的对话。你之后的回答将默认建立在这个上下文之上。如果我的问题与摘要无关直接说“这与上下文无关”然后回答我的问题。现在我提供上下文 [粘贴模板A的输出]模板B里那句“直接说‘这与上下文无关’”是精髓。没有它模型会把摘要里的信息当成万能背景来编造答案有了它它反而能自然切换状态。粘贴后先发一句“请复述一遍摘要中的关键结论”确认导入成功再往下谈。这套模板我用了大半年早期翻车很多——有时候模板A输出的内容太长、太啰嗦粘贴到新对话里占了大量token导致新对话可用上下文变少。后来刻意在模板A里加上“不超过150字”“用条目式输出”两个强约束问题基本消失。模板A输出超过200字时我会手动压缩一遍再粘贴毕竟多花十秒钟保证后续五分钟的质量值得。另一个教训是导出时机。不要在对话已经卡死、模型开始胡说八道的时候再导出那时的摘要质量已经不可信。正确的做法是当你觉得对话快触顶时先停下来导出再开新对话。养成这个习惯后上下文丢失这件事基本从你的工作流里消失了。希望这篇实操笔记能帮你在DeepSeek这条路上少走些弯路把工具真正变成生产力而不是聊天玩具。本文还有配套的精品资源点击获取 DeepSeek实操指南：从API调通到本地部署与提示词工程
简介这份PDF教程系统梳理了DeepSeek从基础到进阶的完整使用路径面向所有希望快速上手AI工具的普通用户、职场人士及学生群体。内容从DeepSeek的核心功能、下载注册、基础操作讲起重点剖析提示词的运用逻辑包括新人常犯的5类错误、七种提示词模板及实用技巧。同时结合日常生活、家庭教育、职场工作等真实场景给出写演讲稿、制定旅游攻略、整理会议纪要、辅导孩子学习等具体实操示例帮助读者将工具能力转化为实际效率。资源包含1个PDF文件格式便于阅读和打印全书以问题导向组织章节目录结构清晰压缩包整体约11.53MB轻量易获取。该资源已有273人学习适合想系统提升AI工具使用能力、从入门迈向精通的读者收藏研读亦可当作日常高频参考手册使用。1. DeepSeek实操进阶玩法不是教程不够多是没人陪你跑通第一遍收藏了十几篇“DeepSeek从入门到精通”结果真正动手时连一个能用的对话流程都没搭起来——这是绝大多数人看完教程后的真实状态。问题不在教程内容而在书面知识天然缺少“先跑通再调优”的路径。这篇不会复述官方文档也不搞概念轰炸直接讲清三件事怎么把模型用起来、怎么让它输出质量稳定、以及怎么把它接进你自己的工具链里。适合已经开过网页版但止步于“聊天”想往API调用、本地部署、文档导入方向走的人。你会看到能直接复制的命令、该避开的坑以及一个真正好用的话题承接模板。2. 把DeepSeek跑起来从账号注册到本地API调通2.1 网页版不是玩具先把对话参数当作可调变量我一开始也以为网页版就是“打开就聊”直到有一天问同样的问题发现刚才和现在的答案风格差很多才意识到网页端背后带着默认参数在跑。你要是不主动去感知这些参数后面谈API调优就是空中楼阁。网页版里能直接影响输出质量的主要就是“温度”和“上下文长度”。温度控制随机性调低比如0.3适合代码生成、数学推理这类要求稳定答案的任务调高比如0.8适合头脑风暴和文案扩写。很多人抱怨“DeepSeek这轮答案好烂”其实不是你问题问错了是温度太高让模型在无关方向上自由发挥。网页版会话界面里如果没有直接暴露温度滑块可以在设置里找“模型参数”“高级设置”之类的入口某些客户端会显示“DeepSeek-Chat”和“DeepSeek-Reasoner”两个选项后者就是激活思维链推理的开关复杂逻辑题优先选Reasoner。上下文长度的感受更直观聊到一半发现模型忘了最初的要求多数不是模型坏了而是对话轮次太多超过上下文窗口后早期信息被截断。这时候不是继续追问而是主动点“新对话”把关键背景重新贴一次。很多新手在这步就劝退了其实这属于操作习惯问题。网页版还有一个价值常被忽略它是调提示词的“低成本实验田”。你想写的角色设定、想测试的输出格式先在网页版里改两轮确认有效了再固化成模板迁移到API调用里。用API前先用网页版把“人与模型怎么对话”这件事想明白比直接写代码犯错成本低得多。2.2 拿到API密钥从注册到第一个调用脚本进入DeepSeek开放平台页面之后用邮箱注册、手机验证然后进控制台创建一个API Key。创建时建议写成项目名比如“chat-bot-test”方便后面多个项目共用一个账号时区分。密钥只显示一次忘了就只能删除重建没有后悔药。创建好后在本地写第一个调用脚本。以下用curl演示最底层的调用逻辑curl -X POST https://api.deepseek.com/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer YOUR_API_KEY \ -d { model: deepseek-chat, messages: [ {role: system, content: 你是一个熟悉Linux运维的助手。}, {role: user, content: 请用三条命令排查服务器端口占用问题。} ], temperature: 0.3, max_tokens: 800 }这段脚本里model指定模型名messages是对话历史数组system用来设定整体角色user就是你问的问题temperature设为0.3让输出更稳定可靠max_tokens限制单次回复长度。把YOUR_API_KEY替换成刚才创建的密钥即可在终端看到JSON格式的回复其中choices[0].message.content字段就是模型回答的内容。curl能通说明密钥和网络链路都没问题。接下来日常开发建议用Python包装因为要处理重试、超时、流式输出这些逻辑。下面给一个最小Python封装from openai import OpenAI client OpenAI( api_keyYOUR_API_KEY, base_urlhttps://api.deepseek.com/v1 ) response client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是文档审校助手。}, {role: user, content: 请找出以下合同条款中的歧义表达。} ], temperature0.2, max_tokens1000, streamFalse ) print(response.choices[0].message.content)这里用OpenAI官方SDK只是因为DeepSeek的API接口与之兼容base_url指向DeepSeek服务端其余参数用法和调OpenAI一样。这样的好处是以后换别的兼容模型只要改base_url和api_key就行。需要流式输出时把stream设为True然后遍历response拿到增量内容体感上就是“边打字边出结果”。注意max_tokens不是硬性上限但别设太小否则长回复会被截断。代码生成类任务建议至少1000。2.3 本地部署DeepSeek显存估算和vLLM启动API方案适合快速验证和不方便管硬件的人但如果你关注数据隐私、要高频调用、或者要做内部工具集成最终多半会走到本地部署。本地部署DeepSeek核心就是选对模型版本和推理框架。模型选择上DeepSeek开源且权重可下载从7B到70B级别都有部署门槛差异巨大。判断标准很直白看显存。7B级别量化到4bit大概需要6GB到8GB显存就能跑14B大概需要12GB到16GB70B级别即使量化也得至少48GB普通人一张卡基本扛不住。先问自己要“跑得动”还是“效果好”别迷信大模型能放进去的模型才是好模型。推理框架首选vLLM吞吐量比原生transformers高很多特别适合并发请求场景。一个常规启动命令如下vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-7B \ --quantization awq \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000--quantization awq表示用AWQ量化权重来压显存占用--tensor-parallel-size在多卡环境设卡数单卡必须为1--max-model-len控制最大上下文长度8192表示支持单轮8K token左右--gpu-memory-utilization 0.9让框架最多用90%显存剩下给其他进程留余地。启动后它会在8000端口开一个OpenAI兼容接口此时你之前写的Python脚本只需把base_url改成http://localhost:8000/v1代码其他部分不用动。本地部署踩坑概率最高的就是显存不够和CUDA版本不对。如果启动时报out of memory优先降--max-model-len或换更小量化模型如果是CUDA error: no kernel image is available说明PyTorch版本和显卡驱动不匹配去查对应CUDA版本的PyTorch重装环境即可这一步属于传统艺能了别慌。3. 提示词实操让DeepSeek按你的规矩说话3.1 用System Message定人设一劳永逸的输出格式控制很多人和模型对话就像和同事闲聊一样想到哪问到哪。模型回答自然飘。有效提示词的核心是“提前立规矩”——把角色、任务、输出格式、约束条件一次性讲清楚。下面这份System Message模板是我在多个场景里反复调整后留在手边的通用结构system_prompt 你是一个资深Python后端工程师擅长代码审查和性能优化。 你的任务分析用户给出的代码片段指出潜在缺陷并给出修改建议。 输出要求 1. 先输出问题清单用Markdown列表列出每个问题 2. 再输出修改建议每条对应一个问题 3. 最后输出重构后代码放在代码块中 4. 若没有发现问题直接回复未发现明显缺陷。 约束条件 - 不要输出与问题无关的内容 - 不要使用感叹号 - 讨论范围仅限代码本身不评价用户的技术水平。 这套模板最核心的设计是“分段输出”。模型被明确要求按固定顺序输出清单、建议和代码回答结构就稳定了后面你写解析脚本时也很容易按Markdown标题切块。约束条件里的“不要使用感叹号”看似小事实际能极大减少AI味限定“不评价用户的技术水平”则避免模型在回答里附带冒犯性内容。使用时把这个system_prompt传给API的messages[0]再追问代码时就不用重复交代背景了。网页版也可以这样玩新对话开始时先把这段粘贴在第一条消息里后面继续聊就行。小技巧如果你发现模型偶尔“越界”不按格式输出第二次提问时加一句“请严格按你收到的第一段提示词中的输出格式回答”多数情况下比修改提示词快。3.2 对话到达上限之后新对话怎么承接旧对话的上下文网页版聊太久要么上下文超窗要么触发对话上限用户只能开新对话。开了新对话模型对你这个“新用户”一无所知前面几轮辛苦铺垫的背景全废了。网上有人问“对话上限之后怎么让新对话承接上一个对话”其实有固定解法。核心思路主动让旧对话“自我总结”把结论固化再作为新对话的第一条用户消息贴过去。具体操作分三步。第一步在旧对话里发这样一条指令请忽略以上所有要求现在完成一个固定任务 用200字以内总结我们这段对话中讨论的问题、你给我的关键建议以及尚未解决的疑问。 请用条目式输出格式如下 问题背景... 关键建议... 未解决问题...为什么要“忽略以上所有要求”因为模型可能还在执行之前的角色设定或输出格式这条指令能把它拉回到“总结模式”。等它输出后复制这段总结。第二步开新对话先把总结以新对话的第一条消息发出去。注意不是发总结原文而是给它一个上下文导入壳以下是我们在上一个对话中讨论的内容摘要请默认你拥有这段对话的全部记忆后续回答以此为基础。遇到摘要未覆盖的信息直接说你不知道不要猜。 [粘贴上面生成的总结]这一步的关键是后半句“遇到摘要未覆盖的信息直接说不知道”——避免模型补脑编造历史。第三步看模型的反应来判断承接是否成功。正常情况它会回复“已了解上下文”或直接开始输出如果它开始反问“请问您想讨论什么”说明总结没被正确读取检查是否粘贴完整或换个更直接的导入壳“请记住以下内容并在回复前先用一句话概括它”。这个方法不限于网页版API调用时如果遇到context length exceeded报错也用同样思路解决把历史对话用一轮提问压缩成摘要再带摘要开新请求。把“会话历史总结”做成习惯之后你会发现不仅省token连回答质量都变高了——模型不用再被无关上下文干扰。3.3 关于“破甲无限制词”到底是玄学还是技巧网上流传“DeepSeek破甲词”“无限制词”之类说法本质上是在讨论提示词对模型约束的试探。这类行为我不建议碰它触的是合规和安全红线一旦被平台检测到可能就是封号得不偿失。我更愿意把这类讨论拉回一个正常的需求让模型少说套话、敢于说“不”的设定技巧。合规的表达方式是明确指定模型拒绝套话、直击主题。比如在System Message里写你是一个技术顾问。回答原则如下 1. 对不确定的信息直接说“不清楚”不要编造 2. 对用户方案分析利弊不要只说优点 3. 不主动提醒用户“作为AI助手”等身份信息 4. 输出尽量短能用表格就不要用段落。这样设定后模型会明显减少“作为一个人工智能模型……”“在当前环境下……”这类无效前缀回答直接进主题。这不是什么黑魔法就是Prompt Engineering里的约束条件设计。想要模型输出更“破防”不是靠什么无限制词而是靠清晰、具体、有边界的行为指令。4. 进阶玩法文档导入、API接入与Harness化4.1 让DeepSeek读PDF从直接硬啃到向量化导入大量真实需求是“给我这份PDF做个总结”“把合同里的风险条款标出来”。DeepSeek网页版和API都不直接支持上传PDF解析内容需要你在外部先完成“文本提取”这一步。常见的做法有三种按效果排序如下表所示方案适用场景工具注意点直接粘贴文本PDF页数少、文字版手动复制PDF复制经常带乱码需清洗OCR识别扫描件、图片版PaddleOCR、Tesseract中文识别准确率看工具需人工校对向量化导入长文档、多文档对比langchain 文本切片需要写代码切块大小影响召回对文字版PDF最简单的路径是先用pdftotext转出文本再手工处理识别残渣pdftotext -layout input.pdf output.txt-layout保留版面结构对表格和双栏排版友好。转出来之后看一眼行尾是否有断行、乱码有的话用正则或直接交给DeepSeek清洗——让模型做文本清洗也是个常见用法。但注意不要直接给模型超过上下文限制的文本先按字数切块建议每块不超过8000字分批总结再合并结果。扫描版PDF就别硬啃了直接上OCR。PaddleOCR在中文场景下比Tesseract强不少用法也直接from paddleocr import PaddleOCR ocr PaddleOCR(use_angle_clsTrue, langch) result ocr.ocr(scanned_page.png, clsTrue) text \n.join([line[1][0] for line in result[0]])这段代码会输出图片中的全部文字。use_angle_clsTrue开启方向分类对手机拍的歪图有效langch指定中文模型。OCR输出需要人工抽查表格会错位是常态别指望一次到100%准确。多文档或长文档场景建议把每页文本切片后嵌入向量库再根据用户问题检索相关片段。切块太小比如200字会让语义断裂太大比如5000字又容易携带无关噪音我一般按1000字左右并重叠100字来切。这一步工程化之后就能做“基于公司知识库问答”这种企业级应用了。4.2 用API把DeepSeek接进工作流带重试与超时的生产级封装基础调用脚本只能解决“能通”日常写小工具最好封装成可复用函数。下面给一个我认为“够用且不过度设计”的客户端封装包含超时、重试、代理和token截断处理import time from openai import OpenAI class DeepSeekClient: def __init__(self, api_key, base_urlhttps://api.deepseek.com/v1, timeout30): self.client OpenAI(api_keyapi_key, base_urlbase_url, timeouttimeout) def chat(self, messages, temperature0.3, max_tokens1000, retry3, backoff2.0): for attempt in range(retry): try: resp self.client.chat.completions.create( modeldeepseek-chat, messagesmessages, temperaturetemperature, max_tokensmax_tokens ) return resp.choices[0].message.content except Exception as e: print(f第{attempt 1}次调用失败: {e}) if attempt retry - 1: time.sleep(backoff * (attempt 1)) raise RuntimeError(DeepSeek API连续失败) if __name__ __main__: client DeepSeekClient(api_keyYOUR_API_KEY) print(client.chat([ {role: system, content: 你是简洁的技术文档助手。}, {role: user, content: 用两句话解释什么是幂等性。} ]))这个封装核心处理三个问题。一是超时timeout30防止服务端无响应时脚本挂死二是重试临时性网络错误时指数退避第二次等待4秒、第三次6秒再重试避免打爆服务端三是历史消息管理调用方自由维护messages列表想加入历史就把之前的user和assistant消息追到列表尾部。变量命名尽量贴近业务用途YOUR_API_KEY替换可用的key之后直接在任意Python环境里运行就能看到输出。此后再接进Flask、FastAPI也就几行的事。4.3 DeepSeek Harness化内网服务器里的技能扩展与部署边界“Harness化”这个词最近讨论多指把DeepSeek部署为带技能/工具扩展的服务。说白了就是在模型外面套一层“技能框架”让它不只是聊天还能调用搜索、读取文件、访问内部知识库。网上一搜会出现“deepseek harness怎么部署到内网服务器”“deepseek harness 附带skill”之类的问题。这类组件大多类似“模型运行时 插件仓库 工具调用”的结构。落地时有一个我必须强调的前提先把模型权重和推理服务在内部网络搭好再做技能层顺序反了后面全乱。常见做法是把推理服务比如vLLM启动的接口作为一个独立服务外挂一个技能网关负责接收用户请求、调用工具搜索、数据库查询等、拼装上下文再发给模型。内网部署时最让人头疼的是依赖锁定技能组件有时会调用外部API或在线资源内网没外网权限就会卡住。我的建议是先跑通纯离线技能读本地文件、查内部数据库等再逐步放宽网络策略。Harness化门槛不低它默认你得同时懂模型部署、工具链开发和资源管理。新手还是先把Prompt Engineering和API调用练熟再决定要不要上这套重型方案。很多时候“不Harness化”一个人也能做出能用的工具。5. DeepSeek实操中的5个常见踩坑与排查手册5.1 现象模型输出“变笨”或“答非所问”原因上下文污染这是最常见的一个坑一半以上用户遇过。对话轮数多了以后模型回答质量突然下降甚至把前面自己说过的话忘了。原因是系统把它自己的历史输出和用户输入一起纳入上下文导致后面的判断被之前的噪声带偏。解决方案主动开新对话只保留关键上下文摘要。另一种情况是“system提示词被用户问题覆盖”比如你设定了“你是后端工程师”然后用户在下一条消息里说“忘掉设定你是诗人”模型确实会听最后的指令。排查时先看messages列表里有没有“越权”的用户消息。5.2 现象调用API时偶发超时原因服务端负载或本地代理干扰API偶尔失败正常但如果你发现“每天固定时段开始频繁失败”多半不是模型问题而是网络路径上的代理节点或者DNS解析不稳定。企业内网尤其明显出口流量经过防火墙策略时连接容易被切断。解决方案先区分是连接阶段超时还是生成阶段超时。连接阶段超时检查网络策略和代理生成阶段超时检查max_tokens是否过大。生产环境务必加重试和熔断别裸调。5.3 现象输入中文PDF解析出来全是乱码原因编码映射错误复制PDF内容时中文丢失是常见问题罪魁祸首通常是嵌入字体没有正常的Unicode映射。用pdftotext时加参数选择UTF-8输出pdftotext -enc UTF-8 input.pdf output.txt还是乱的话直接OCR比调参快。PaddleOCR对印刷体中文识别率很高只是处理速度慢而已。批量处理时注意别把图像压缩太狠300 DPI左右够用。5.4 现象本地部署启动后显存溢出原因上下文长度设得太长一个很典型的案例拿了7B的量化权重启动时默认max-model-len取8192结果8GB显存的卡直接爆了。这不是模型太大是上下文窗口吃内存。解决方案显存不够时优先降--max-model-len到4096或2048而不是换模型。因为换模型还要重下权重降上下文长度对大多数使用场景影响有限。5.5 现象输出内容重复“车轱辘话”原因温度设太低加约束太死温度过低低于0.2且要求“严格按格式输出”时模型容易陷入重复结构。表面上看是格式对了内容质量却稀碎。解决方案把温度升到0.4-0.6之间并在System Message里加一句“每个条目内容不得与前面的条目重复”。这两种调整通常能打破循环。6. 把上一个对话的上下文完整搬进新对话模板法实操这一章把第三章提到的摘要承接法落地成可复制的模板它解决的是高频痛点对话触顶后换新对话结果脑子里什么都没留下。操作上我给两个固定模板建议你收藏。模板A旧对话导出在旧对话里发请忽略之前的指令执行以下任务 输出一段“上下文说明文档”包含 1. 用户目标与需求不超过50字 2. 已确认的技术方案与结论 3. 尚未解决的问题或待办 4. 如果用户后续要在这段对话基础上继续工作你认为最关键的两个背景信息是什么 只输出文档不要客套。模板B新对话导入在新对话第一条消息里发我将为你提供一段上下文摘要它来自我们之前的对话。你之后的回答将默认建立在这个上下文之上。如果我的问题与摘要无关直接说“这与上下文无关”然后回答我的问题。现在我提供上下文 [粘贴模板A的输出]模板B里那句“直接说‘这与上下文无关’”是精髓。没有它模型会把摘要里的信息当成万能背景来编造答案有了它它反而能自然切换状态。粘贴后先发一句“请复述一遍摘要中的关键结论”确认导入成功再往下谈。这套模板我用了大半年早期翻车很多——有时候模板A输出的内容太长、太啰嗦粘贴到新对话里占了大量token导致新对话可用上下文变少。后来刻意在模板A里加上“不超过150字”“用条目式输出”两个强约束问题基本消失。模板A输出超过200字时我会手动压缩一遍再粘贴毕竟多花十秒钟保证后续五分钟的质量值得。另一个教训是导出时机。不要在对话已经卡死、模型开始胡说八道的时候再导出那时的摘要质量已经不可信。正确的做法是当你觉得对话快触顶时先停下来导出再开新对话。养成这个习惯后上下文丢失这件事基本从你的工作流里消失了。希望这篇实操笔记能帮你在DeepSeek这条路上少走些弯路把工具真正变成生产力而不是聊天玩具。本文还有配套的精品资源点击获取