企业官网建设流程全解析

简介：2025年厦门大学林子雨副教授团队发布《DeepSeek大模型赋能高校教学和科研》专题报告，以122页PPT形式系统梳理人工智能与大模型知识体系，面向高校师生、科研人员及希望掌握AI工具的学习者，帮助建立从基础概念到实际应用的完整认知。报告内容覆盖人工智能发展简史、图灵测试、达特茅斯会议及未来五阶段，重点讲解大模型的概念、发展历程与典型产品（如GPT系列、阿里M6），并深入讨论高校本地部署DeepSeek、AIGC应用与基于大模型的智能体实践。同时结合高校科研和教学场景，展示AI在提高科研效率、优化教学方法方面的具体做法与案例。资源为单个pptx演示文稿，大小约45.07MB，内容结构清晰、图文并茂，适合用作教学课件、自学材料或校内培训参考。目前已有356人学习浏览，对正在探索DeepSeek及大模型赋能教育的研究者与教师颇具参考价值。

1. 为什么这份“DeepSeek赋能高校”方案值得逐页抠

期末答疑课上，几十个学生排着队问同一段报错；实验室里，研究生花两天找训练脚本的 bug——这类消耗在高校里每天都在发生，处理方式却还停留在二十年前。这份 122 页的演示方案把 DeepSeek 大模型在高校教学和科研里怎么用讲得很系统，但真动手就会发现，问题根本不在模型能不能跑，而在怎么把能力拆进备课、答疑、文献整理、代码调试这些具体流程里。它适合三类人：带课想减负的老师、被杂活吞掉时间的研究生，以及想把 AI 变成院系基础设施的信息化负责人。看懂这份材料不难，难的是把它落成一套能长期运转的东西，下面就把这条线拆开。

2. DeepSeek 进高校的第一步：部署选型、硬件边界与最小启动命令

2.1 先选模式：API 调用还是本地私有化部署

高校场景第一个特殊点是数据边界。学生作业、未公开发表的论文、实验原始数据，这些都不能随便出域。API 模式调用门槛低，按量付费，注册就能用，但请求体里带着完整 prompt，数据流向校外；本地私有化部署需要一次性硬件投入，数据不出内网，权限自己管。到了 2025 年这个节点，开源模型的推理能力已经稳定在可用水平，本地部署不再是小众玩法。

我一般这样建议：个人试用、通识课演示、学生人数少的场景，直接走 API；涉及成绩、作业互评、未发表成果、批量学生数据的场景，老老实实本地部署。还有一条容易被忽略的成本线——API 按 token 计费，一个班 80 人、一门课 16 周、每周一次答疑，累计 token 量很可观，算完账会发现本地部署反而不贵。

选定模式之后再选模型体量，这才是第一个真正的决策点。

2.2 本地部署的最小命令：从服务启动到第一条回复

先看显卡再选模型，这是我每次部署的第一条军规。驱动版本和 CUDA 版本是否匹配，决定了后面所有坑的总源头。用nvidia-smi确认显存和驱动，再决定拉哪个体量的模型。教学和科研场景里，14B 量化版是性价比最高的起点，写代码、改 prompt、整理文本都够用；显存低于 16GB 就退到 8B 附近，效果差距主要体现在长文本和复杂推理上。

# 1. 先确认显存与驱动，这是后面所有部署判断的依据 nvidia-smi # 2. 用 ollama 拉取并运行 DeepSeek-R1 蒸馏版 14B # --keepalive 控制模型驻留时间，避免用完不释放显存 ollama run deepseek-r1:14b --keepalive 30m

--keepalive 30m的意思是模型在最后一条请求结束后继续驻留 30 分钟再释放。教学场景里学生提问是突发的，驻留时间太短会导致每次请求都要重新加载模型，头几条回复慢到让人怀疑服务挂了；驻留太长又占着显存不放，并发一高反而容易 OOM。30 分钟是教务场景的折中值。

ollama 适合单人调试和课程演示，但要做院系级共享，我一般换成 vLLM 起一个 OpenAI 兼容服务，端口统一走 8000：

# 用 vLLM 起 OpenAI 兼容服务，port 8000 给上层应用统一调用 python -m vllm.entrypoints.openai.api_server \ --model deepseek-ai/DeepSeek-R1-Distill-Qwen-14B \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000

--tensor-parallel-size 1是务实配置，单卡不切分；只有多卡机器才改成 2 或 4，切分后通信开销会吃掉一部分性能。--max-model-len 8192控制上下文长度，这里的取舍在 2.3 节展开。--gpu-memory-utilization 0.9给推理框架留 10% 余量，防止显存波动直接 OOM。启动日志里看到Uvicorn running on http://0.0.0.0:8000就说明服务起来了。

服务起来后，用一段极简 Python 脚本验证连通性。注意，这个脚本用的是原生requests，不依赖特定 SDK，在任何有 Python 3.8+ 的环境里都能跑：

import requests def chat_once(prompt, temperature=0.3, base_url="http://127.0.0.1:8000/v1"): """向本地推理服务发一次对话请求，base_url 指向 vLLM 或 ollama 的兼容端点""" payload = { "model": "deepseek-r1:14b", # 必须与启动时的模型标识一致 "messages": [{"role": "user", "content": prompt}], "temperature": temperature, "max_tokens": 1024, "stream": False, } resp = requests.post(f"{base_url}/chat/completions", json=payload, timeout=180) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"] if __name__ == "__main__": print(chat_once("用一句话说明梯度下降的作用"))

timeout=180不是随手写的。14B 模型在冷启动后第一条请求通常要 20 到 60 秒，复杂推理任务更久，默认超时 30 秒必然翻车。max_tokens=1024控制单次回复上限，调试和答疑场景足够了，但注意它和上下文长度是两回事。

2.3 显存、上下文与并发：一张表算清楚边界

显存是第一个门槛，上下文和并发是第二个。很多人以为显存够装模型就能跑，实际max-model-len越大，KV cache 占显存越多，能够支撑的并发就越低。gpu-memory-utilization 0.9这种参数只能缓解，不能解决物理上限。

并发教学场景里，我一般把max-model-len压到 4096 到 8192 之间，把并发限制在 3 到 5。这个区间里，14B 模型能同时支撑一个班的学生提问，又不会因为上下文太长把显存吃满。如果一定要长上下文，就把并发降下来；如果一定要高并发，就接受更短的上下文。这两个参数在显存面前是零和博弈，没有白赚的配置。

3. 把 DeepSeek 接进教学日常：备课、答疑与批改的三个落点

3.1 智能备课：用固定模板把大纲变成讲义草稿

备课场景里，模型最大的价值不是直接生成课件，而是把大纲扩展成可修改的讲义草稿。这里的关键不是提示词写多花哨，而是把输出结构钉死。课程大纲、授课时长、听众层次、输出章节，这四个要素写进模板，每次调用得到同构的结果，后面的人工修改成本才最低。

def build_lecture_prompt(topic, minutes=45, level="本科二年级"): """生成讲义草稿的结构化提示词，temperature 调低以保证教材语言风格""" system = "你是高校教师助理，负责把章节大纲扩展为可讲授的讲义草稿。" user_prompt = f"""主题：{topic} 授课时长：{minutes}分钟 听众：{level} 请严格按以下结构输出： 1. 教学目标（3-5条，可量化） 2. 知识树（先给主干，再给分支） 3. 课堂互动问题（每15分钟至少1个） 4. 随堂练习（含参考答案） 原则：先给框架，再补细节；专业术语口径保持一致；不确定的内容标注[待核对]。""" return system, user_prompt

temperature=0.3是备课场景的推荐值。调高了，同一份大纲每次生成的风格都不一样，术语使用会飘；调低了，输出会比较干，但胜在稳定。备课素材稳定比文采重要。[待核对]这个占位符是给自己留的检查点——模型生成的任何事实性内容，默认不可信，标注出来方便人工复核。

拿到草稿后，人工二次加工要做三件事：按本校课时结构校准长度，把示例替换成本课程的真实案例，最后查一遍术语口径是否和教材一致。模型只负责初稿，这个定位要清楚，它替你省的是从空白页开始的时间，不是判断的时间。

提示：把课程大纲、教材目录作为 system 内容的一部分传进去，生成结果会更贴近你的课。这一步效果远比微调模型明显。

3.2 答疑助手：把报错信息变成学习入口

上机课和作业答疑是高校里消耗最大的场景。学生贴一段报错截图，老师要重复解释同一个知识点。常见的做法是训练一个「先分析、后建议、不直接给答案」的答疑助手，把每次提问沉淀成可复用的学习记录。

import requests def debug_code_error(code: str, error_trace: str) -> str: """把学生代码和报错拼成调试对话，约束模型先讲原因再给建议""" prompt = f"""学生提交的代码如下： {code} 报错信息如下： {error_trace} 请按三部分回答： 1. 直接原因（用一句话说清） 2. 背后的知识点（对应课程哪个章节） 3. 修复建议（不要直接给完整代码，给思路和关键片段） 如果报错信息不足以判断，明确说“信息不足”，不要猜。""" payload = { "model": "deepseek-r1:14b", "messages": [{"role": "user", "content": prompt}], "temperature": 0.3, "max_tokens": 1024, "stream": False, } resp = requests.post("http://127.0.0.1:8000/v1/chat/completions", json=payload, timeout=180) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"]

temperature=0.3在这里的意思是让模型尽量收敛到符合教材口径的解释，而不是每次都换一种说法。max_tokens=1024限制回答长度，防止模型把一段话扩展成一篇小作文，学生在长文本里反而找不到重点。

「不要直接给完整代码」这个约束是最关键的一行。答疑助手的定位是引导思考，不是代写。实际使用时我发现，模型在遵守这个约束的情况下，给出的关键片段反而更精准——因为它要解释思路，而不是堆代码。

3.3 批改初筛：让评分维度量化，少让模型自由发挥

作业批改是另一个高频场景。模型做主观题初筛可行，但前提是评分标准必须量化。用「每点几分」代替「回答得不错」，模型才能给出稳定可复核的评分。这里我一般会把评分标准写进 prompt，并要求输出格式固定为三行：得分、分点给分理由、需要补习的知识点。

def grading_prompt(question, rubric, answer): """构造批改提示词，rubric 必须是可量化的评分细则""" return f"""按以下评分标准批改作业。 题目：{question} 评分标准： {rubric} 学生作答： {answer} 输出格式（严格三行）： 第一行：得分（总分/rubric中的满分） 第二行：分点给分理由（对应rubric的每一条） 第三行：需要补习的知识点（最多3个） 如果学生的答案包含标准答案未覆盖但正确的思路，单独标注'[额外加分项]'。"""

量化评分标准的威力在于，它能暴露模型瞎给分的倾向。给分理由必须对应 rubric 的每一条，凡是答不出「为什么给这个分」的情况，都说明模型在凭感觉打分。这类初筛结果只能作为助教参考，最终分数必须人工复核——不是不信任模型，而是给分这件事涉及学生权益，人工裁决权不能交给机器。

批改场景有一个参数特别值得调：max_tokens控制在 512 左右就够了。批改不需要长篇大论，反而是短输出更便于机器提取结果和人工快速核对。

4. DeepSeek 在科研场景的三种用法：文献、数据与实验日志

4.1 文献调研：让模型做材料轮转，把筛选判断留给自己

科研场景里最常见的误区是让大模型直接写文献综述。模型没见过原文，它只会根据训练数据里的印象编一个符合学术格式的答案，参考文献列表很可能是假的。正确的用法是让模型做「预检索」——把模糊的研究问题扩展成多组检索词，真正进数据库检索和筛选的是人。

def expand_keywords(seed_query, topn=15): """把宽泛的研究问题扩展为可组合的检索词，输出给主流文献数据库使用""" prompt = f"""我的研究问题是：{seed_query} 请生成 {topn} 个可用于数据库检索的关键词，按三组输出： 1. 主题词：直接描述研究对象 2. 方法词：常见研究方法和技术路线 3. 场景词：限定应用场景或数据类型的词 每组内部可包含中英文、同义词、上下位词，不要解释，直接列词。""" payload = { "model": "deepseek-r1:14b", "messages": [{"role": "user", "content": prompt}], "temperature": 0.7, "max_tokens": 1024, } resp = requests.post("http://127.0.0.1:8000/v1/chat/completions", json=payload, timeout=180) return resp.json()["choices"][0]["message"]["content"]

temperature=0.7在文献场景里比 0.3 合适。检索词扩展需要一定的发散性，太低的温度会让同义词覆盖不全。这一条和教学场景的参数取向正好相反——同一个模型，不同场景要换参数，这是很多人忽略的细节。

用扩展出来的关键词做数据库检索后，下一步才轮到模型出场：把检索到的摘要批量喂给模型，让它按「研究对象、方法、结论、局限」整理成结构化笔记。注意这个顺序不能颠倒——先有真实文献，再让模型整理；而不是让模型生成文献列表。后一种做法在检索场景里基本就是学术事故。

4.2 实验日志：把散落的原始记录汇总成结构化日报

实验记录是科研场景里最杂的活。每天的数据、参数、异常分散在多个 txt、md 和聊天记录里，整理起来费时间，不整理又容易丢关键信息。常见做法是写一个脚本，把文件夹里的原始记录分段读出来，交给模型按时间线做结构化汇总。

import os, requests def build_log_prompt(paths): """读取多个实验日志文件，截断后拼接为一条汇总请求""" chunks = [] for p in paths: with open(p, encoding="utf-8", errors="ignore") as f: text = f.read() chunks.append(f"### 文件 {os.path.basename(p)}\n{text[:2000]}") return ("以下是几天的实验原始记录。请按时间线汇总：每天做了什么、" "出现哪些异常、参数变化、下一步建议。" "只使用原始记录里出现的信息，不要补充你没有看到的内容。\n\n" + "\n--- 分隔符 ---\n".join(chunks)) def summarize_logs(paths): prompt = build_log_prompt(paths) payload = { "model": "deepseek-r1:14b", "messages": [{"role": "user", "content": prompt}], "temperature": 0.2, "max_tokens": 2048, } resp = requests.post("http://127.0.0.1:8000/v1/chat/completions", json=payload, timeout=300) return resp.json()["choices"][0]["message"]["content"]

text[:2000]这个截断不是随手写的。每个文件只取前 2000 字符，能保证多个文件拼接后不超出上下文窗口，也给模型留出生成答案的空间。代价是文件中间部分可能被截掉，所以脚本适合「每天记录很短、按天命名」的日志场景；如果是动辄上万字的实验报告，先把每个文件切片再分批处理。

temperature=0.2在这里比 0.3 还低，因为实验汇总要求忠实于原始记录，不允许模型发挥。「不要补充你没有看到的内容」这句话几乎能减掉一半幻觉问题——模型确实会试图补全缺失信息，把这个约束写进 prompt 比调参更管用。

4.3 训练日志分析：让模型做参数级排查

科研里跑深度学习训练，最烦的是日志堆成山却看不出问题。loss 震荡、梯度爆炸、学习率不合理，这些判断有经验的工程师扫一眼就知道，但每跑一轮都人工扫不现实。模型可以承担初次排查：把训练日志切片喂进去，让它按固定维度分析。

def analyze_training_log(log_text, tail_n=150): """分析训练日志，tail_n控制只取日志末尾指定行数""" lines = log_text.strip().splitlines()[-tail_n:] tail = "\n".join(lines) prompt = f"""以下是训练日志的最后 {tail_n} 行。请分析： 1. loss 整体趋势（收敛/震荡/发散） 2. 是否存在 NaN 或 Inf 3. 学习率设置是否合理（结合 loss 变化判断） 4. 下一步最该调整的参数 只基于日志内容判断，日志里没有的信息不要推断。 {tail}""" payload = { "model": "deepseek-r1:14b", "messages": [{"role": "user", "content": prompt}], "temperature": 0.3, "max_tokens": 1024, } resp = requests.post("http://127.0.0.1:8000/v1/chat/completions", json=payload, timeout=180) return resp.json()["choices"][0]["message"]["content"]

只取末尾 150 行是一个很实用的经验。loss 发散或梯度异常往往在日志的后半段才出现，开头几千行的正常记录只会稀释模型的注意力，还可能把上下文窗口挤爆。参数调优提示词里加一条「日志里没有的信息不要推断」，比反复叮嘱「要准确」有效得多。

这个功能的定位是「第一道排查」，不是最终诊断。模型说大概率是学习率问题，你还要自己看一眼曲线确认。但它能把你从逐行翻日志里解放出来，尤其是深夜挂着训练、第二天一早要出结论的场景，价值非常直接。

5. DeepSeek 进高校的 5 个常见坑：现象、原因与解决

5.1 模型答得头头是道，引用文献却一篇都查不到

现象：让模型做文献综述，它给出了完整的参考文献列表，格式规范，标题也像真的，但逐篇去数据库检索，一篇都找不到。原因：模型是概率生成器，不是检索器。它知道「一篇文献长什么样」，于是补全了一个长得像文献但不存在的东西。解决：禁止模型生成参考文献，改为「给材料再整理」——只让模型基于粘进 prompt 的真实摘要做归纳，参考文献列表由人从检索结果里生成。

5.2 本地部署单卡能跑，并发一高就 OOM

现象：自己调试时一切正常，学生一拥而入，服务直接崩，报错显示 CUDA out of memory。原因：推理时 KV cache 随并发线性增长，显存被吃满，max-model-len越大，每个并发请求占的显存越高。解决：把并发限制在 3 到 5，压max-model-len，同时开启流式输出。靠加显存解决问题当然可以，但教务场景里控制并发比堆硬件好落地得多。

5.3 模型输出风格漂移，不同老师用出来像两个产品

现象：同一个模型，有老师拿到的讲义是教科书风格，有老师拿到的是口语化大纲，放在同一个课程组里很不协调。原因：开发者没有统一提示词口径，每个老师都按自己的习惯写 system prompt，模型执行的是不同的「人设」。解决：由课程组统一维护一份 Prompt 模板库，把「教材风格、按大纲扩展、不补充事实性内容」写死，所有老师共用入口。这是工程管理问题，不是模型问题。

5.4 学生直接拿模型答案交作业，教学环节失效

现象：作业雷同率上升，学生对基础概念的掌握反而下降。原因：答疑助手的设计里没有「过程约束」——它只给了修复建议，没要求学生记录自己的思考过程。解决：把作业改成过程提交制。要求提交三个文件：提问记录、修改草稿、最终答案。答疑助手保留提问历史，任课教师可以快速看到学生是从「完全不会」到「自己改对」，还是直接拿了答案交差。技术本身不是问题，任务设计才是。

5.5 换台机器就翻车，环境依赖比模型本身还折腾

现象：在 A 机器上部署成功，换到 B 机器后，CUDA 版本不匹配、驱动太旧、依赖库冲突，一整天都耗在环境上。原因：推理框架对 CUDA、驱动、Python 版本都有要求，每台机器的环境差异会埋雷。解决：用容器固定环境。把推理服务和模型路径打包进容器镜像，换机器只需要有 NVIDIA 驱动和 Docker 运行时。这里的关键是镜像标签要锁版本，别用 latest——latest 会在某次拉取时突然变化，让一次成功的部署变得不可复现。

# 固定推理环境，避免换机器就翻车 docker run --gpus all -p 8000:8000 \ -v /data/models:/models \ --name deepseek-lab \ 你的推理镜像名:锁定版本 \ --model /models/DeepSeek-R1-Distill-Qwen-14B

--gpus all把 GPU 透传给容器，-v /data/models:/models把模型文件挂载进容器，避免镜像体积过大。锁定版本是部署纪律：镜像的 tag 一旦确定，就不要随意改动，除非你有完整的回归验证流程。

6. 把 DeepSeek 变成院系级基础设施的三个动作

6.1 统一网关，让所有调用走同一个入口

散落在各老师本地的调用，既看不到用量，也没法限流，更没法统计成本。常见做法是在院系服务器上统一起一个服务，所有请求走同一地址，第 2 章里 vLLM 的启动命令就是这个入口。在这个基础上加一层简单的调用日志，记录时间、用户、token 量，就能回答两个问题：资源用在哪了，什么时候该扩容。

6.2 把提示词模板收进仓库，按课程维护

这是投入产出比最高的动作。把第 3、4 章里的备课、答疑、批改、日志分析四类提示词收进一个模板仓库，用版本管理，每改一句话就升一个版本。换模型、换参数、学生反馈变差，都能回溯是哪一次改动导致的。模板库做到一定程度，比换一个更大的模型更值钱——它沉淀的是你所在机构的专业课知识。

6.3 建一个小规模回归验证集

换模型或调参之前，先跑一遍验证集。准备 30 道往年题和对应答案，按关键词匹配算通过率，粗略快速；想要更可靠，就人工打分。每次模型版本更新、参数调整，都拿这套题集过一遍，用数字决定要不要换，而不是凭感觉。

def eval_ta(judge_prompt, cases, keyword_key="keyword"): """极简回归验证：用关键词命中率粗评模型改版前后的效果""" hits = 0 for c in cases: answer = chat_once(judge_prompt + c["question"]) if c[keyword_key] in answer: hits += 1 return hits / len(cases)

这 30 道题的验证集是底线，不是最优。有精力就扩到 100 道，覆盖错误类型、知识点、格式合规三个维度。模型是底座，真正决定效果的是把它约束在课程边界里的这套工程动作。我现在每建一门课，会先录三份「风格样本」——让模型分别回答一道基础题、一道综合题、一道开放性题目，人工校准一轮后再给课程用。后面版本怎么换，都以这三份样本做基准。希望帮到你。

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