企业官网建设流程全解析

简介：这份122页的PPT由厦门大学大数据教学团队出品，系统讲解DeepSeek大模型在高校教学与科研中的落地路径，适合高校师生、教育信息化工作者以及希望系统了解大模型应用的初学者。内容覆盖人工智能发展简史、人工智能思维、大模型概念与发展历程、高校本地部署方案、AIGC实践与智能体案例，并重点展示AI赋能科研效率提升和教学方法优化的具体场景，兼顾科普性与技术深度。资源为单个pptx文件，约45.07MB，图文结合，目录清晰，便于按模块研读或直接用于培训分享。目前已有356人学习下载，对希望快速建立大模型认知框架、探索高校本地部署与教学科研应用的读者具有较高参考价值，既能了解从图灵测试到达特茅斯会议的人工智能演进脉络，也可获得可落地的部署思路与课堂应用示例。

1. DeepSeek大模型落地高校：这份122页PPT到底能解决什么

拿到这份关于DeepSeek大模型赋能高校教学和科研的122页PPT时，我第一反应是：终于有人把“大模型进校园”这件事从头到尾讲透了。它不是那种只堆概念的通识课件，而是从1950年图灵测试讲到高校本地部署DeepSeek，再到AIGC应用、智能体搭建和AI赋能科研教学，逻辑线非常完整。很多一线教师和科研人员真正卡住的地方，恰恰不是“DeepSeek是什么”，而是“我该怎么在自己的课堂或课题组里把它用起来”。这份报告给的正是从认知到落地的中间层。适合的人群也很明确：高校教师、教学管理人员、科研团队负责人，以及想在校内搭一套大模型教学环境的实验员。

2. 从图灵测试到大语言模型：读报告先抓住这条主线

2.1 人工智能简史三条线：测试基准、学科诞生、阶段划分

报告的第一部分用了比较大的篇幅回顾人工智能发展简史，很多人觉得这种内容“知道就行”，但我建议你仔细看，因为它埋了三条非常重要的线。

第一条线是图灵测试。1950年，图灵发表了那篇被称为人工智能开山之作的论文，核心问题就一句话：“机器能思考吗？”为了回答这个问题，他设计了一个可执行的判定方案：测试者在与被测的人和机器隔离的情况下随意提问，如果机器让平均每个测试者做出超过30%的误判，就认为机器具有人类智能。这个测试的巧妙之处在于，它把“智能”从哲学问题变成了可量化、可操作的实验标准。直到今天，大模型评测里大量使用的“人工盲评”方法，本质上还是图灵测试的变体。

第二条线是达特茅斯会议。1956年，在美国达特茅斯举办的夏季研讨会上，“人工智能”这个词首次被提出，这次会议后来被认定为人工智能作为独立学科的起点。读这个部分时要注意一个细节：当时与会者讨论的很多问题，比如自然语言处理、机器学习、神经网络，今天回头看全是后来大模型的技术前身。换句话说，大模型不是凭空冒出来的，它是在一条长达七十年的技术主线上积累出来的。

第三条线是发展阶段划分。报告中把人工智能的发展划分成六个阶段，并单独提了未来人工智能发展的五个阶段。这里值得关注的是，它把“阶段”作为理解AI发展节奏的框架，而不是简单罗列年份。我自己的体会是，当你面对“要不要现在投入做AI+教学”这类问题时，阶段框架能帮你判断：现在处在从“专用AI”走向“通用AI”的转折点，投入的窗口期是很明确的。

2.2 大模型的分类框架：按模态与按层级

报告中关于大模型分类的部分，是我建议高校从业者重点看的第二个内容，因为它直接影响到选型。

从模态维度看，大模型分为语言大模型、视觉大模型和多模态大模型。语言大模型比如GPT系列、DeepSeek，处理的是文本数据，典型能力是自然语言理解和生成。视觉大模型用于图像分类、目标检测、人脸识别等CV任务。多模态大模型则同时处理文本、图像、音频，典型就是DALL-E这样能文生图的模型。对高校教学场景来说，语言大模型是最快能落地到课堂的，因为文本交互的门槛最低，不需要额外搭建图像或音频处理流水线。

从应用层级看，大模型又分为L0通用大模型、L1行业大模型、L2垂直大模型三层。一句话概括：L0相当于“通识教育”，在大量无标注数据上训练，形成举一反三的泛化能力；L1是针对特定行业做预训练或微调，比如法律、医疗，相当于“行业专家”；L2是针对具体任务调优，相当于“岗位熟手”。这个分层对学校的意义在于：高校不需要从零训练一个L0模型，更常见的路径是选一个成熟的L0底座，然后用校内数据做L1或L2的微调，或者直接用提示词工程适配教学任务。

2.3 大模型为什么“大”：参数、数据、算力的三角博弈

关于“大模型为什么大”，报告给出了非常直观的定义：大模型是参数数量庞大、训练数据量大、计算资源需求高的人工智能模型。这三个“大”不是并列关系，而是一个相互制约的三角。

参数规模决定模型容量的上限。报告中引用了一些公开数据：GPT-3在2020年发布时参数规模是1750亿，GPT-4的参数规模达到1.8万亿，而2021年发布的一个M6模型参数量甚至达到10万亿量级。注意，参数量每增加一个数量级，训练所需的数据量和计算量往往要增加更多，而不是线性增长。

训练数据量决定模型在多大范围内能学到规律。这也是为什么大模型具有很强的迁移性：一次训练完成后，学到的知识和模式可以迁移到不同任务上，无需重新训练。这一特性对高校非常友好，因为教学场景里任务五花八门，不可能每个任务都训练一个模型。

计算资源需求则是很多高校落地时最先面临的现实问题。报告中重点提到了本地部署DeepSeek，这里的核心矛盾就在于算力。后面第3章我会专门展开显存估算和部署流程，这里先记住一个结论：不要一上来就追求满血版本，要根据自己的硬件条件选择合适的模型规模。

这一部分还讲了大模型与人工智能的包含关系：人工智能包含机器学习，机器学习包含深度学习，深度学习可以采用预训练模型，预训练模型再细化到预训练大模型和预训练大语言模型。这个嵌套关系如果搞不清楚，后面做技术选型时很容易被各种概念绕晕。

3. 高校本地部署DeepSeek：显存估算、部署命令与验证三步走

3.1 部署前先算账：模型规模、显存占用和教学场景怎么匹配

很多高校团队拿到DeepSeek后的第一反应是“先下载个最大的模型跑起来”，结果往往是等了几小时下载完成，一加载就显存溢出，程序直接崩溃。这一步跨得太大，我强烈建议部署前先算一笔账。

显存估算有一个经验公式：模型所需显存约等于参数量乘以精度对应的字节数，再乘一个约1.2的系数。FP16精度下每个参数占2字节，INT8占1字节，INT4量化后大约占0.5字节。以7B量级的模型为例，FP16精度大约需要14GB显存，INT8约7GB，INT4量化后约4GB。这里说的都是推理所需的显存，如果要微调训练，显存需求通常还要再乘以3到4倍。

我整理了一份粗略的选型参考表，可以覆盖大多数教学演示场景：

这里还要考虑一个非常实际的场景维度。如果你的目的是课堂上做实时演示，那响应速度优先，选量化后的较小模型够了；如果目的是科研实验或批量处理文本，那吞吐量优先，可以选更大模型但要做好排队和异步处理；如果只是想让老师和学生体验功能，我建议直接用本地小模型加上API云端大模型混合使用，本地小模型防断网，云端大模型做高质量生成，这是目前高校里比较务实的架构。

3.2 本地部署实操：安装、拉模型、启动服务

明确了模型规模后，实际操作有两条路线：一条是用Ollama这类现成工具快速跑起来，另一条是自己写推理脚本加载模型。对高校环境来说，我一般建议先走Ollama路线，它把模型下载、量化、服务封装都做好了，能省掉很多填坑时间。

以下是常见的部署流程：

# 在Linux服务器上安装Ollama curl -fsSL https://ollama.com/install.sh | sh # 拉取适合教学演示的轻量级模型，模型名以本地实际拉取的标签为准 ollama pull deepseek-r1:7b # 直接交互式运行，验证模型是否可用 ollama run deepseek-r1:7b

先解释一下命令做了什么。第一行是下载Ollama的安装脚本并执行，它会自动安装依赖并配置好服务。第二行从模型仓库拉取DeepSeek的轻量级版本，下载时间取决于网络环境。第三行是进入交互式对话界面，你可以在终端里直接输入问题看输出效果。如果这一步能正常回复，说明模型本身没问题，接下来要做的是把服务暴露成API供外部调用。

# 查看已拉取的模型列表，确认模型名和大小 ollama list # 启动API服务并放到后台运行 nohup ollama serve > /tmp/ollama.log 2>&1 &

这里的参数和操作有几个关键点。ollama list会显示本地所有模型，我一般用它确认模型是否完整下载，对应的大小也写在里面。nohup和&组合的含义是让服务在后台持续运行，即使关闭终端也不中断，日志输出到/tmp/ollama.log。建议你部署后顺手执行一次tail -f /tmp/ollama.log，观察启动日志里有没有报错。Ollama默认监听在localhost:11434，所以后面所有的API调用请求都发到这个地址。

3.3 部署后的验证：对话测试与API调用

服务启动后，很多人习惯直接在终端里聊天验证，但这样只验证了交互界面，没验证API链路。我一般会先发一个最简单的请求：

# 通过API发送一次生成请求，确认服务正常响应 curl http://localhost:11434/api/generate \ -d '{"model":"deepseek-r1:7b","prompt":"请用一句话介绍大模型","stream":false}'

请求体里model指定使用的模型名称，prompt是输入文本，stream设为false表示完整生成后再返回结果，而不是边生成边流式输出。如果看到返回内容中包含"response":"..."字段，说明API链路是通的。

接下来用Python调用做更细的验证：

import requests payload = { "model": "deepseek-r1:7b", "prompt": "本地部署大模型需要注意什么？", "stream": False } resp = requests.post("http://localhost:11434/api/generate", json=payload, timeout=120) data = resp.json() print(data["response"])

这段代码相比curl多了两个关键设计：timeout=120是因为大模型生成长文本耗时可能超过默认超时时间，提前设置不会被卡死；resp.json()把返回结果解析成字典，方便提取和后续处理。我建议你用这种方式写一个最简单的测试脚本，将来接入课堂系统时直接复用。

验证完接口后，还有一件事值得做：记录一次生成过程的性能指标。ollama ps可以看到当前模型占用的显存和内存，对比一下和3.1节估算的数值是否一致。如果实际占用远高于估算值，说明服务端或模型加载方式有问题，需要检查是否存在多进程重复加载。

4. AIGC与教学智能体：把报告里的案例变成可运行的代码

4.1 AIGC在高校场景的四个切入位置

报告里关于AIGC应用与实践的部分，列举了大量高校场景案例。我梳理了一下，真正可落地的切入点主要集中在四个位置：课件生成、习题生成与批改、文献阅读辅助、程序设计辅助。这四个场景有一个共同特征：任务边界清晰，输入输出都是文本，不需要复杂的多模态处理，非常适合用现有大模型直接支撑。

以习题生成举例，你要做的不是写一个复杂的系统，而是设计一套高质量的提示词。同样一个模型，提示词不同，输出质量可以差出几个档次。我常用的模板结构分四层：

四个部分缺一不可，少了角色设定，模型容易给出通用的教科书式内容；少了输出格式，结果就很难接进你的教学管理系统。这个思路可以平移到论文摘要改写、实验报告批改等场景里。

4.2 做一个课程助教智能体：对接DeepSeek本地服务

报告里专门提到了基于大模型的智能体，这是AIGC应用的一个升级方向。智能体和单次问答的区别在于：它不是一个问一个答，而是带上了系统级的人设、记忆和工具能力。这里先做一个最小可用的课程助教智能体，核心就是把系统提示词注入对话流程。

from openai import OpenAI # 指向本地Ollama提供OpenAI兼容接口 client = OpenAI( base_url="http://localhost:11434/v1", api_key="ollama" # 本地服务不校验key，占位即可 ) def ask_course_assistant(subject, question): messages = [ { "role": "system", "content": f"你是{subject}课程的助教，回答时先给结论再给解释，必要时给出代码示例。" }, { "role": "user", "content": question } ] response = client.chat.completions.create( model="deepseek-r1:7b", messages=messages, temperature=0.3, max_tokens=500 ) return response.choices[0].message.content print(ask_course_assistant("操作系统", "进程和线程的区别是什么？"))

这段代码里的参数值得逐一说明。base_url指向localhost:11434/v1，因为本地服务提供了OpenAI兼容接口，你可以直接复用熟悉的SDK；api_key填ollama只是占位符，本地服务不校验密钥。temperature=0.3是温度参数，值越低回答越稳定、越保守，适合教学场景，如果要产生创造性内容可以调到0.7以上但稳定性会下降。max_tokens=500限制单次输出的最大长度，防止生成过长内容拖慢响应。system角色承载人设，user角色承载问题，这种结构是智能体的基本骨架。

4.3 给智能体加上“讲义记忆”：最小可用的RAG方案

课程助教只靠预训练知识有一个明显问题：它不熟悉你自己的讲义、评分标准和课程大纲。解决方案就是RAG，也就是检索增强生成。核心思路是先把讲义切片并向量化，用户提问时先从切片库里检索相关内容，再把这些内容连同问题一起交给大模型回答。

from langchain_community.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter # 加载课程讲义文本 loader = TextLoader("data/course_notes.txt", encoding="utf-8") docs = loader.load() # 按中文语义边界切块，避免把一句话切碎 splitter = RecursiveCharacterTextSplitter( chunk_size=400, chunk_overlap=80, separators=["\n\n", "\n", "。", "！", "？", "；", " "] ) chunks = splitter.split_documents(docs) print(f"切分后文本块数量: {len(chunks)}")

这里最值得关注的是separators参数。默认的分隔符主要针对英文，遇到中文文本会直接把句子拦腰截断，检索效果很差。我把它调整成优先按段落、再按句号、感叹号、问号、分号和空格切分，这样每个文本块基本保持一个完整语义单元。chunk_size=400表示每个块大约400字，chunk_overlap=80表示相邻块之间保留80字重叠，目的是防止检索时信息恰好被切分截断导致上下文丢失。

RAG的检索效果取决于切片质量和向量化模型，这没有太多玄学成分，只要边界切得对，检索命中率会明显上升。这一步跑通了，课程助教就不再是“什么都懂但不知道你课堂规矩”的通用模型，而是带有课程上下文的教学工具。

5. 避坑指南：DeepSeek进校园最常见的五个翻车现场

5.1 模型下载失败或服务启动崩溃

现象：ollama pull执行到一半卡住，或者下载完成后执行ollama run，终端直接闪退没有报错。

原因：绝大多数情况是网络连接不稳定导致模型文件下载不完整；另外也可能是磁盘分区格式不兼容，比如某些FAT32分区不支持超过4GB的大文件，模型文件虽然显示下载完成实际上已经损坏。

解决：先执行ollama list查看模型状态，如果大小异常或显示不完整，删除后重新拉取。磁盘格式问题可以切换到ext4或NTFS分区，把Ollama模型存放目录设置到对应位置后再重试。启动崩溃时，先执行ollama serve不放到后台，直接看前台日志输出，报错信息一般会直接告诉你是文件缺失还是驱动问题。血泪教训是：千万别在磁盘满了的情况下强行拉模型，系统会报假“下载完成”然后运行失败，先把磁盘清理出模型体积两倍以上的空间再操作。

5.2 显存统计看起来够，一加载就OOM

现象：用nvidia-smi看还剩20GB显存，模型估算只要14GB，结果一加载就报CUDA out of memory。

原因：显存估算公式只算了模型权重，但推理时还有KV Cache、激活值、CUDA上下文等额外开销。另外，如果你同时跑了浏览器、桌面环境或其他GPU应用，显存并不会全部被DeepSeek独占。

解决：把估算结果乘以2作为安全余量。20GB可用显存，只跑7B FP16模型比较勉强，优先用INT8或INT4量化版。也可以在启动服务前关掉不必要的GUI程序，释放显存。我一般会先跑nvidia-smi确认没有残留的僵尸进程占着显存，再启动服务，然后用ollama ps观察实际占用，这个习惯让我少踩了很多次OOM坑。

5.3 问答质量不稳定，同一问题两种回答

现象：同一个问题问两次，一次回答准确详实，一次回答明显偏差，甚至出现事实性错误。

原因：大模型生成有随机性，直接原因是temperature参数偏高；更深层原因是提示词没有约束清楚，模型每次采样时可选路径过大。

解决：教学类问答把temperature降到0.2到0.3之间；同时提示词里增加“如果信息不确定，请说明”，让模型在拿不准时显式表明不确定。如果输出仍然不稳定，检查提示词里的任务说明是否有歧义，比如“分析一下”就是典型的模糊指令，我一般会改成“请从三个角度分析，并给出你的结论依据”。

5.4 提示词素材分块不合理，检索效果很差

现象：RAG检索出来的文本块和问题完全不相关，或者相关内容被几个文本块割裂成碎片。

原因：切片时用了默认的英文分隔符，中文文本被不当截断；或者chunk_size设得过大，导致一个块里混入了多个主题。

解决：按第4.3节的方式调整separators，用句号和分号做边界；chunk_size根据实际内容类型调整，如果讲义里知识点密集，建议降到300字左右，如果教材大段叙事，可以放宽到500字。还有一个必须做的检查：随机挑3到5个用户问题，手动检索一遍对应的文本块，看检索结果是否合理，不要只看整体准确率。

5.5 学生同时用AI交作业，教学评价失效

现象：一批作业代码结构相似、表达风格一致、错误点不自然，明显不是学生独立完成的。

原因：这是AI普及后高校教学必然面对的问题，不是DeepSeek本身的缺陷，而是评价机制没有同步升级。

解决：我的做法不是禁用AI，而是把“人机分工”写进评分标准。作业要求里明确标注哪些环节必须独立完成，哪些环节允许AI辅助，并在评分维度里加入“口头答辩”环节，随机让学生解释自己作业里的关键实现。如果解释不清，视为AI代做。另一个有效做法是设计过程性任务，要求提交多个版本，从初稿到终稿的变化过程比只看结果更容易判断真实能力。

6. 检验“AI思维”的一线技巧：三周人机对比练习模板

报告第二部分提到“人工智能思维”，核心是三层能力：了解AI基础运行模式、具备区分人和机器的能力、懂得如何运用人工智能协作。问题是，“了解”和“协作”怎么检验？我在一线课堂里试过很多方法，效果最直接、成本最低的是三周人机对比练习。

第一周，让每位学生选一个课后题目，分别用自己独立回答和AI辅助回答两种方式完成，然后整理出一份对比记录。第二周，把全班对比记录汇总，挑出差异最大的10个案例，让学生分析差异出现的原因：是信息检索能力的差异，是推理路径的差异，还是表达方式的差异。第三周，让每个学生基于前两周的分析，写一段“人机协作分工方案”，说明哪些步骤应该交给AI，哪些必须自己完成。

这个练习的价值在于它把“AI思维”变成了可观察、可评价的行为。看一个人是否建立了正确的AI认知，不是听他复述概念，而是看他在具体任务中是否知道什么时候信任机器、什么时候不能信。

实际执行时有一个很有效的评价工具，就是下面这张观察表：

后面我每次带新班或新团队做AI工具落地，都会强制走一遍这三周人机对比练习，并且要求先完成观察表再动手部署系统。它并不是什么高深技术，但它能把大家从“AI什么都能做”和“AI完全不可信”两个极端拉回到一个可用的中间位置。希望这个模板对你也有帮助，哪怕只做第一周的人机对比，你也会发现很多原本以为掌握了的AI能力，其实根本没真正掌握。

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