简介《DeepSeek等大模型工具使用手册》是厦门大学大数据教学团队林子老师打造的一份以科普报告与实战案例相结合的入门级实操PPT面向高校师生与职场新手帮助读者从零理解AIGC并快速上手DeepSeek、豆包、Kimi、即梦AI等主流工具。资源共1个文件为173页完整PPT整体大小8.47MB结构清晰适合作课堂教学或自学跟练的配套材料。目前已有70人学习。内容按“概述—实践”主线展开先简要讲解AIGC与大模型的关系、核心技术和发展脉络再分别覆盖文本、图片、语音、视频四类AIGC应用实践并进一步介绍AIGC辅助编程和AI搜索的使用方法案例贴近真实场景操作路径具体。通过本套PPT可系统掌握提示词编写、内容生成、工具调用与效果评估等关键环节适合希望将大模型工具快速落地到学习、办公和创作场景的读者。1. 173 页 PPT 的含金量为什么叫“使用手册”而不是“大模型科普”拿到一份 173 页的《DeepSeek 等大模型工具使用手册.pptx》很多人第一反应是“这么多页我哪有时间看”于是要么收藏吃灰要么从头翻到尾最后一页都没记住。我读完目录后的判断正好反过来这份材料的价值不在页数而在“手册”两个字。它不是科普大模型能干什么而是告诉使用者提示词怎么写、参数往哪调、API 怎么接、模型怎么部署遇到问题该回翻哪一节。换句话说这是一份给“干活的人”看的工具书适合三类读者刚接触大模型、想先把聊天和提示词跑通的新手准备把 DeepSeek API 接进业务的后端或产品以及正在评估企业大模型私有化部署、Ollama 与 vLLM 选型的技术负责人。如果你带着这些诉求去翻它会比多数视频教程更耐看因为视频是线性的而手册型 PPT 天生适合跳读和反复查证。2. 用 PPT 做学习地图把“173 页”拆成三条路径和一份检查清单我拿到任何一本厚手册第一件事都不是从头读而是先确认它的组织方式。PPTX 文件的好处是页面之间可以随意跳转也方便用笔记软件打标签天然适合当工具书来查。麻烦在于173 页是线性地排下来了但学习不是线性的。你不可能一个周末把提示词、API、私有化部署全吃透硬啃的结果是每一章都“见过”一上手还是不知道从哪开始。正确做法是先把它当成一个能力矩阵再看自己缺哪一块只挑相关章节动手练。下面是我一般会采用的三条路径按读者背景区分。2.1 手册型 PPT 为什么比视频教程更适合复盘教程视频是线性的讲完一个主题就翻篇你想回看某个参数只能拖进度条PPT 可以任意跳页、搜索关键词、在旁边做批注特别适合“带着问题来查”的学习方式。我一般会把 173 页当成四五个独立主题提示词与输出、上下文长度、API 接入、本地部署与微调准备。每次只看一个主题看完立刻做一件事比如改一个 Prompt或者调一次接口。这也是我会反复推荐手册类资料的原因资料读不完多数不是因为时间少而是因为按顺序读前面欠的债越来越多越读越心虚。手册型 PPT 的正确用法是当字典不是当小说。你可以只翻“上下文长度”一节解决眼前的问题而不必先读完前面 100 页。另一个容易忽略的点是这类手册通常更新很快DeepSeek 等大模型的功能和参数经常变化看纸质版或下载后不更新的 PPT 意义不大对照官方文档一起看才是做笔记的正确姿势。2.2 三条路径先用起来、再接 API、再做私有化部署我把初学者通常分成三条路径分别对应不同的落地目标避免“什么都学但什么都没学会”。路径一先用起来适合不太写代码、但天天用聊天界面的人。目标是能在 DeepSeek 聊天窗口里稳定得到自己想要的结果而不是偶尔灵光一现。做法是把一条真实业务问题写周报、审合同、做会议纪要拆成三步先写一个带角色的 Prompt跑一次再按任务边界和输出格式修改最后连续测 5 句挑出最差的一次分析是角色、边界还是格式出了问题。这一步走完你才算真正理解了手册里提示词章节的核心。路径二接入 DeepSeek API适合后端和产品。目标是让程序调用模型而不是在聊天界面手动输入。需要确认四个信息调用地址、模型名、密钥、是否流式返回。常见做法是先写一个后端代理或者用 Dify 这类编排工具接入先用少量请求验证效果再决定要不要上更重的方案。这里的关键不是背参数而是理解一次请求从发起到返回的完整链路。路径三把模型部署到自己的环境适合架构师和运维。目标是在企业内网跑通一个可用的大模型服务。路径一般是先用 Ollama 在单机验证模型效果再切换到 vLLM 支撑生产并发最后用 Dify 把模型接进业务。如果后续遇到知识过时或输出格式问题再考虑走 RAG 和微调而不是一上来就训练模型。很多人被技术社区里的部署教程带着走先花一周搭环境结果业务场景还没验证方向就偏了。2.3 一份 12 项检查清单直接勾着学把三条路径再往下拆就是一张可以照着打勾的检查清单。我建议把这张表存进笔记软件每完成一项就写一句验证结果。注意验收标准不是“我看完了”而是“我能复现”。模块验收标准对应手册板块提示词能说清角色、任务边界、输出格式三要素并完成一次改写提示词章节上下文能估算一段中文文本约占多少 token解释上下文长度的含义上下文长度参数分别调一次 temperature 和 top_p观察回答风格变化参数说明鉴权能说出 api_key 应放在请求头而不是 URL 里API 接入API 调用调用一次 DeepSeek API成功解析返回内容API 接入流式输出能区分 stream 开和关时返回结果的差异API 接入异常处理能处理 401、429、超时三类常见错误排查章节本地部署用 Ollama 拉起一个开源模型并成功对话本地部署部署选型能说明 Ollama 与 vLLM 的适用边界生产部署RAG给模型追加一段外部知识验证回答是否引用了资料应用编排数据标注能做 10 条干净、格式统一的微调样例微调准备验收场景为每个模块设计一个最小 Demo 并跑通应用案例这张表不需要一次做完。每条路径完成三到四项就已经比“从头到尾看一遍”有效得多。我自己的习惯是每学一个新板块就在表里加一行验收标准每行对应一个动手动作。这样做的好处是下次再打开这份 PPT你很清楚自己要看哪一节而不是重新翻一遍目录。3. 提示词与上下文五个参数决定回答质量新手最常问的问题是为什么同样的 Prompt别人跑出来像专家我跑出来像复读机。差别往往不在“话术”本身而在几个参数上。手册的提示词章节通常会把 temperature、top_p、max_tokens、presence_penalty、frequency_penalty 放在一起讲但真正排错的时候顺序比数量重要。先用最简单的一组参数跑通再逐个调整才能知道每个参数到底影响了什么。3.1 temperature 与 top_p先理解采样再动手调大模型每次生成都是在概率分布里做采样。temperature 越大分布越平坦输出更多样越小越倾向选高概率词。top_p 则是只保留累积概率最高的部分比如设定 0.9就是在概率质量的前 90% 里选词。两者都在控制“随机性”但作用位置不同所以调参时一次只动一个否则出了问题很难定位是哪一个造成的。我一般会把 top_p 固定为 0.9只调整 temperature。不同任务有不同推荐区间客服问答这类要求一致性的场景temperature 建议在 0.3 左右代码生成和 JSON 输出建议更低0.1 到 0.2因为格式错误比创意不足更致命创意写作可以把温度拉到 0.7 到 0.8让文字有更多变化。下面这张参数表可以直接抄任务场景temperaturetop_p说明客服问答 / 常规对话0.30.9回答稳定保留少量变化代码生成 / 结构化输出0.20.8降低语法错误和随机性创意写作 / 头脑风暴0.80.9输出更多样但要人工筛选很多人把 temperature 设成 0以为这样就能“永不出错”但实测同一个 Prompt 连问三次结果还是可能不一样。模型内部还有采样机制不是把温度拉到最低就能锁死输出。要获得真正稳定的业务输出必须依赖输出格式约束比如要求 JSON 结构、固定模板或枚举值。这点在后面的避坑章节还会专门展开。3.2 max_tokens 与上下文长度截断是性能杀手max_tokens 限制的是单次输出的 token 数不是输入长度。上下文长度决定的是一次请求里最多能放多少输入。这里最容易翻车的是“上下文越长越好”的错觉。大模型官方宣称的长上下文是上限不是建议值。如果每次都把上下文塞满模型需要处理的 token 太多耗时和费用都会明显上升输出端预留空间不足长答案还会被悄悄截断。常见做法是把输入控制在上下文窗口的 60% 到 70%输出留 30% 到 40%。比如模型窗口是 8K单次请求输入控制在 5K 到 6K token输出留到 2K 到 3K。别把整份合同直接丢进去先切段再调用。这里有一个经验换算中文大概 1 个汉字对应 1 到 2 个 token不同分词器有差异最稳妥的办法是用官方 tokenizer 实测而不是相信网上“1 汉字等于 1 token”的笼统说法。如果在对接 DeepSeek API 时发现回复总是一半就断了先看是不是 max_tokens 太小。另一个隐蔽问题是有些模型参数里同时有 max_tokens 和 max_completion_tokens名字相似但语义不同填错位置会导致不生效。手册里如果没写清楚就以官方文档的字段说明为准不要照抄旧项目的请求体。3.3 提示词模板角色、边界、输出格式缺一不可这里给一个可以直接抄走的通用模板注意它不是万能咒语而是帮助你把需求说清楚你是负责某个角色的专家。任务用一句话说清要做什么。限制明确不能做的事比如不要编造数据、不要输出多余内容。输出格式指定是标题加要点还是 JSON 或 Markdown。如果信息不足先提问不要直接猜测。模板的核心不是背下来而是理解四个部分为什么存在。角色限制语气边界限制行为输出格式让结果更容易被程序解析“信息不足先提问”可以减少幻觉。命令越是具体模型越不容易自由发挥。很多人从技术社区复制 Prompt 模板直接拿业务数据去跑发现结果不对其实问题不在模型而在模板里的角色和边界根本没改成自己的场景。负面指令的写法也有讲究。“不要输出多余内容”经常被模型当成可忽略的建议“输出 JSON不包含 Markdown 代码块标记”就要具体得多模型更容易遵循。如果你想让模型输出“是或否”就写“只回答是或者否”而不是“不要解释太多”。这些细节就是把同一个模型用出不同效果的原因。4. 从 DeepSeek API 到私有化部署一条可复现的落地路径对多数团队来说从“用大模型聊天”到“把大模型做进产品”第一步是接 API第二步才是考虑私有化部署。顺序不要反很多团队先花大量时间搭环境业务效果反而没验证等到真要上线时才发现方向选错了。正确路径是先用 API 验证能力再按数据合规和成本要求决定是否私有化最后才考虑用 vLLM 或 Ollama 这类工具去承载服务。4.1 接入 DeepSeek API先确认四个字段接入 DeepSeek API 之前把下面四个字段搞清楚能少走很多弯路字段说明常见坑base_url接口地址前缀通常要写到 /v1 这一层少一个斜杠或版本号不对直接 404model模型标识以官方文档实际存在的名字为准填了社区里流传的昵称接口直接报错api_key密钥放 URL 参数里会被日志泄露应放请求头stream是否流式返回关闭时只有一次性 JSON打开时要处理连续 chunk实际接入步骤我一般按四步走先到控制台创建 key权限范围收窄到当前项目再按手册里的示例发一次最小请求确认返回正常然后打开 stream观察响应方式的变化最后把请求体里的 temperature、max_tokens 按上一章的参数经验设置。这里要提醒一句key 千万不要放到 URL 里更不要提交到公开仓库。日志里打码是基本操作否则一次误操作就能让整个团队的额度被刷爆。如果你不想从零写代码常见做法是用 Dify 这类工具接入 DeepSeek API把模型供应商的 base_url 和 key 填好再创建应用。这种方式对产品原型和内部工具尤其合适因为它把模型接入、应用编排、日志查看都集中在一起。等业务稳定了再决定要不要把模型换成私有化部署。4.2 本地部署Ollama 起步vLLM 上生产企业选择大模型私有化部署通常是为了让数据不出内网或者为了长期成本可控。但“本地能跑”和“生产可用”完全不是一回事。个人验证时用 Ollama 很舒服运行一个模型标签就能在命令行里对话但它的定位是快速验证不是高并发服务。等到要支撑多个用户、多个应用同时调用就要换 vLLM 这类引擎或者在前方加一层队列和负载均衡。下面是一张部署选型表可以直接对着做决策方式典型用途经验参数取舍Ollama个人验证、内网试用7B 级模型建议 16GB 左右显存起步量化后再看上手快并发能力弱vLLM生产 API、多用户并发先压测再上线注意 batch 与显存上限吞吐高配置成本高Dify编排 RAG、Agent、工作流模型接入后做权限隔离与日志审计不提升模型速度但省接入时间本机验证时Ollama 能帮你快速确定一个模型是否满足业务但生产环境我一般会建议用 vLLM 起一个 OpenAI 兼容服务这样应用层改动很小。常见架构是vLLM 负责模型推理Dify 负责把模型接进业务外部 API 密钥统一管理内网服务之间走独立网关。如果你看到技术社区里有人推荐某个部署方案不要直接照抄先问一句我的业务是内部工具还是对外服务并发大概多少数据能不能出内网。这三个答案不同选型完全不同。4.3 先 RAG 再微调私有化部署的功能优先级团队最容易犯的错是一拿到模型就要微调。实际上模型回答过时通常是因为没给它最新知识这个用 RAG 解决而不是微调回答格式不统一用 Prompt 和结构化输出约束就能解决只有上述手段都试过手头积累了足够多的真实样例才值得碰微调。微调适合固定语风、固定输出字段、领域术语对齐不适合“让模型变聪明”。这里有一张决策表能帮你在“要不要微调”这个问题上快速收敛问题现象首选手段知识过时或缺少内部资料RAG先解决知识来源输出格式不稳定Prompt 结构化输出约束语气/风格不像自己团队收集样例走微调推理能力不够换更大模型而不是微调如果确定要微调数据准备工作比模型训练更花时间。不要拿原始聊天记录直接喂进去先做去重、清洗、字段统一标签口径要一致否则模型学到的是噪音。手册里的“微调实战”章节通常会强调先做一批数据标注样例我建议从 10 条开始而不是一上来就整理上万条。先把一条数据的输入输出结构定义好再考虑规模化。5. 避坑把手册照搬进生产环境的 5 条踩坑记录以下这些坑不是手册写错了而是把“单点验证”时得到的经验直接搬进生产环境后暴露出来的问题。每一类我都遇到过列出来至少能帮你省几天排查时间。5.1 调参阶段的三个“看起来对了”的坑第一条temperature 调到 0业务输出仍然不稳定。现象是同一个 Prompt 连问三次JSON 结构两次对一次错偶发字段丢失。原因是大模型的采样机制不只看 temperature输出格式没有约束才是主因。解决方法是先要求输出固定模板或结构再调温度参数必要时用 API 里的结构化输出能力而不是继续往下压温度。第二条max_tokens 调大后回复完整了费用和耗时也涨了。现象是响应时间明显变长账单上的 token 消耗翻倍。原因是你确实给了模型写更长的空间但业务根本不需要那么长模型就会把多余的话也补上。解决方法是先定义输出长度上限比如“回复不超过 200 字”或“只返回 5 条建议”再按这个预期设置 max_tokens给一个稍有余量的值即可。第三条presence_penalty 和 frequency_penalty 同时调回答开始飘。现象是回答啰嗦、跑题甚至不断引入新概念。原因是一个参数在鼓励引入新话题另一个在压制重复同时调会让采样目标互相拉扯。解决方法是默认不碰这两个参数只有当模型严重复读时才调 frequency_penalty并且一次只调整一个。5.2 部署与数据阶段的两个隐形问题第四条Ollama 默认配置直接扛线上并发。现象是用户一多就开始排队、超时日志里全是连接超时和限流错误。原因是 Ollama 的定位是快速验证不是高并发服务默认没有针对多请求做优化。解决方法是先做一次简单压测明确它的并发上限生产流量交给 vLLM或者在前端加队列和限流避免把单机拖垮。第五条RAG 切块太大召回质量反而下降。现象是检索出来的片段太长模型回答里既有有用信息又夹着大量无关描述。原因是整篇文档直接入库语义太杂查询时匹配到的内容不可控。解决方法是按章节或段落切块单块控制在几百 token 左右同时把同义词和不同问法加进查询扩展而不是只做字面匹配。RAG 的坑多数不在模型而在数据清洗和切块策略。6. 让手册变成生产力用“验收场景”验证你会不会用我看厚资料的习惯是不追求全部读完而是把每个章节变成一个验收场景跑通了才算看过。这套方法是从前翻车翻出来的以前拿到 173 页的资料总想从头看完结果记了一堆概念真正上手还是不会。后来改成“读完一节做一件最小的事”反而吸收得更快。下面五个验收场景可以直接拿来检验自己是否掌握了这份手册的核心第一给客服系统写一个 200 字内的 Prompt连续 5 次输出都符合固定格式第二调用一次 DeepSeek API能从错误码判断问题出在鉴权、限流还是模型名错误第三在一台无外网的机器上用本地部署的大模型完成问答第四给模型追加一段外部知识确认它能引用资料而不是自己编第五整理 10 条格式统一的数据标注样例能被微调脚本直接读取。五个场景对应提示词、API、部署、RAG、微调准备正好覆盖手册的主要模块。我个人的做法是每次只验收一个点比如这周只解决“输出格式不稳定”下周再解决“本地服务并发”。验收失败时回头翻手册对应章节找到原因再改而不是把参数全试一遍。这个方法听起来慢但每解决一个问题就能沉淀一条经验下次换模型、换项目时都能复用。现在再打开这份 PPT我不会从头翻起而是先想清楚今天要验收哪个场景再直接翻到最需要那一节。资料的价值不在于页数多而在于能不能从中抽出可复现的操作。希望这份工具手册也能帮到你让你下一次打开它时不再是被动阅读而是主动解决问题。本文还有配套的精品资源点击获取