企业官网建设流程全解析

简介：面向医疗信息化从业者与AI技术决策者的一份实战文档，聚焦DeepSeek在医疗场景中的私有化落地路径。文档共30页，以体系化目录展开：从私有化部署环境搭建（服务器选择、操作系统与深度学习框架安装），到病历文本清洗、分词、特征工程；从基于DeepSeek编码器的结构化分析模型构建与训练评估，到诊断辅助功能实现、医学知识图谱引入、结果可视化与性能调优；并专章讨论医疗数据加密存储、脱敏与访问控制等安全隐私方案，最后通过完整实战案例展示应用效果与优化启示。压缩包内包含1个PDF文件，大小约2MB，目录结构完整，便于按章节对照学习。已有123人浏览学习，适合正在探索大模型辅助病历结构化、智能诊断或私有化部署的工程师参考。

1. 医疗场景为什么绕不开 DeepSeek 私有化部署：数据不出域是刚需

一家三甲医院的信息科想用大模型做病历结构化，第一反应往往是调在线 API。但病历一进公网，后面全是事：患者主诉、既往史、用药记录属于敏感数据，医院层面根本不会批准上传。于是“DeepSeek私有化部署”成了这类项目的默认起点——把模型装进院内 GPU 服务器，让病历数据只在医院内部流转，再通过统一服务接口完成结构化分析和诊断辅助。这个方案适合医院信息科、临床科研团队，以及做医疗 AI 落地的厂商。但别急着买机器，真正的难点不在把模型跑起来，而在跑起来之后如何保证结构化质量稳定、诊断建议可溯源。这篇就按我自己的落地路径，把选型、部署、抽取、检索和排错完整讲一遍。

2. 模型选型与本地化部署：vLLM 跑通 DeepSeek 的内网最小闭环

2.1 选哪个规格：显存预算、并发上限与量化档位的取舍

DeepSeek 开源模型有多个尺寸，医疗私有化场景一般不会一上来就上最大参数量，而是从 7B 到 32B 这个区间选。选择依据很简单：先数一下院内能腾出几张卡，再算你要的并发和精度。权重显存可以按“参数量 × 精度字节数 × 1.2”粗估，7B 模型用 BF16 大概需要 14GB 显存，FP8 能压到 7GB 左右。如果只是给科室做病历结构化，7B 到 14B 的量化模型就能跑；如果还要做诊断辅助、挂载知识库做长文本推理，我会优先保证 32GB 以上显存，给 KV Cache 留够空间。

这里有个容易被忽略的问题：模型的 KV Cache 会随并发和输入长度暴涨。同样是 7B 模型，单卡 24GB 跑 4K 上下文能支撑 8 路并发，把上下文拉到 32K 后并发直接掉到 2 路。所以选型时不能只看权重能不能塞进显存，还要留给推理状态足够的余量。医疗病历虽然单条通常不超过 2000 字，但加上系统提示词、结构化模板和 few-shot 示例，实际 token 消耗会翻两三倍。

量化档位方面，我的习惯是医疗场景至少用 BF16 或 FP8。AWQ 和 GPTQ 虽然能把 7B 压到 4bit，跑起来确实省显存，但病历抽取任务对字段值的完整度要求很高，低比特量化在长文本生成尾部容易出现字词丢失，这在结构化场景里是致命的。宁可少开几路并发，也别在精度上冒险。多卡环境则用张量并行把一个大模型切到两张卡上跑，吞吐比跑两个小模型更稳。

2.2 用 vLLM 拉起 OpenAI 兼容服务：一条命令背后的参数

私有化部署 DeepSeek 的常见做法是用 vLLM 起一个 OpenAI 兼容的 HTTP 服务，这样上层业务代码可以无缝对接，后续换模型也不动接口。我的最小启动命令长这样，模型路径按你实际存放位置改：

python -m vllm.entrypoints.openai.api_server \ --model /data/models/deepseek-7b-chat \ --served-model-name deepseek-medical \ --max-model-len 8192 \ --gpu-memory-utilization 0.92 \ --dtype bfloat16 \ --tensor-parallel-size 1 \ --port 8000

--served-model-name是给上层业务看的模型别名，建议固定成一个内部名，别让前端直接依赖具体模型版本；--max-model-len 8192是单条请求允许的最大长度，病历结构化场景 8K 基本够用，太长会显著降低并发；--gpu-memory-utilization 0.92表示 vLLM 可以用掉单卡 92% 的显存，剩下留给驱动和监控，不要拉满到 0.98，运行时容易 OOM。--tensor-parallel-size在多卡时设为卡数，单卡不动。

启动后先用 curl 验证服务是否可用，这一步能排除端口、防火墙和模型加载三类问题：

curl http://127.0.0.1:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "deepseek-medical", "messages": [ {"role": "system", "content": "你是病历结构化助手。"}, {"role": "user", "content": "患者因胸痛3天入院。"} ], "temperature": 0.1, "max_tokens": 512 }'

vLLM 的接口完全兼容 OpenAI 格式，temperature在病历抽取任务里我固定设 0.1 或 0，宁可输出保守一点也不能让它自由发挥；max_tokens控制单次生成上限，抽取任务不需要太长，给 512 足够。如果返回里带"finish_reason": "length"，说明截断了，得加大 max_tokens 或检查是不是提示词设计把输出窗口挤占了。这里补充一句，企业大模型私有化部署的常见坑是把推理服务和业务服务混在一台机器上，建议 GPU 服务器只跑 vLLM，业务侧单独一台 CPU 机器做请求转发和数据预处理。

2.3 权重获取与加载：离线内网环境怎么做模型落地

医院内网通常与互联网隔离，模型权重不能直接在内网机器上拉取。常见的做法是在一台有联网下载权限的机器上把模型下载完整，再通过合规的移动介质拷进内网。DeepSeek 的权重在 ModelScope 和 Hugging Face 都有托管，国内网络环境下 ModelScope 更稳定一些。下载时要注意把整个模型目录拿全，包括config.json、分词器文件、safetensors分片权重和模板配置文件，缺了任何一个 vLLM 都可能加载失败。

# 在可联网的下载机上执行 pip install modelscope modelscope download --model deepseek-ai/DeepSeek-7B-Chat --local_dir /data/models/deepseek-7b-chat

下载完成后别急着拷走，先做两件事：一是核对权重文件完整性，确认safetensors文件的字节数与源端一致；二是解压后看目录结构里有没有 README 或配置说明。很多团队提权时只拷了权重分片，漏了tokenizer_config.json，结果 vLLM 启动报“tokenizer file not found”，这类问题排查起来相当耗时。拷入内网后，模型文件建议放在 SSD 或本地磁盘，不要放在机械硬盘阵列上，vLLM 加载分片权重时读盘速度会直接影响冷启动时间。

加载完成后打开日志看一眼有没有“CUDA out of memory”或“Unable to load model”字样。前者说明显存估算失误，需要降--gpu-memory-utilization或换更小模型；后者八成是模型目录不完整，对照源端逐个补文件即可。这一步看着琐碎，但内网环境每补一次文件就得重新走一遍拷贝流程，所以第一次务必检查全。

2.4 API 接入与超时配置：让 HIS 前端调用不卡死

vLLM 服务跑起来后，业务系统通过 HTTP 调用。这里要特别注意超时设置：病历抽取不是单 token 短生成，一条长病历在低配 GPU 上可能要跑几十秒，前端请求超时设成 5 秒或 10 秒必然批量失败。我一般把连接超时设 10 秒，读取超时设 120 秒，并让调用端做异步化处理，避免一个慢请求把整个线程池拖垮。

from openai import OpenAI client = OpenAI( base_url="http://192.168.1.20:8000/v1", api_key="internal-placeholder", timeout=120.0, ) resp = client.chat.completions.create( model="deepseek-medical", messages=[ {"role": "system", "content": "你是病历结构化助手，只输出JSON。"}, {"role": "user", "content": "请提取以下病历的主诉、现病史和既往史。病历：……"} ], temperature=0.0, max_tokens=1024, ) print(resp.choices[0].message.content)

base_url指向 vLLM 的/v1路径，api_key随便填一个占位符，vLLM 默认不校验密钥，但保留这个参数能让代码无缝迁移到云端 API。timeout=120.0是 socket 层面的整体超时，比只设连接超时更保险。如果业务量上来后发现请求排队严重，优先调整 vLLM 的并发参数而不是盲目加服务器——先把--max-num-seqs调高以增加批处理容量，同时观察显卡利用率，利用率已到 95% 以上再加机器才有意义。

3. 病历结构化分析：从半页主诉到可查询的 JSON Schema

3.1 结构化不只要抽取：为什么直接投喂大模型会翻车

很多团队第一次试跑时，直接把病历原文塞给模型说“把主诉、现病史、既往史抽出来”，模型确实会输出一段像模像样的文字，但绝不是你想要的稳定结构。它会自行发明字段名，会把“无高血压史”抽成“高血压史：无”，会把时间描述从“三天前”改成“2025年3月”，每个字段的粒度全凭模型当天心情。这种输出在 demo 阶段看不出问题，一旦要做批量统计或对接电子病历系统，字段对不上就是数据事故。

病历结构化分析的本质是信息抽取加语义归一，模型的作用是理解文本和定位实体，最后的输出必须套进一个预定义的 JSON Schema。DeepSeek 的 API 支持response_format参数来约束输出为 JSON 对象，vLLM 也兼容这一特性。我在实践中会把 Schema 完整写进系统提示词，并在用户提示词最后加一句“严格按照上述JSON格式输出，不要输出任何其他内容”，双保险比只靠一个参数稳定得多。

3.2 主诉、现病史、既往史抽取：一套可复用的 Prompt 模板

下面这套模板是我在多个科室跑过的版本，覆盖主诉、现病史、既往史、过敏史、用药史五个核心模块。注意几个设计细节：字段说明里写清“没有就填 null”，避免模型为凑字段编造内容；时间描述保留原文语义，不做绝对日期换算；否定词单独成字段，这是医疗记录里最容易出错的地方。

system_prompt = """ 你是医疗病历结构化助手。你的任务是从病历文本中抽取结构化信息，严格输出JSON，不要输出任何解释。 输出Schema如下： { "主诉": { "症状": "string", "持续时间": "string", "否定词": "string | null" }, "现病史": { "起病情况": "string", "症状演变": "string", "诊疗经过": "string | null" }, "既往史": { "慢性病": "string[]", "手术史": "string[]", "过敏史": "string[]", "否定表述": "string[]" } } 字段要求： 1. 否定词单独抽取，如"无胸痛"填"无"。 2. 未提及的字段填null或空数组。 3. 时间描述保留原文，如"3天前"。 """ user_prompt = "病历原文：{record_text}\n请严格按照上述Schema输出JSON。" response = client.chat.completions.create( model="deepseek-medical", messages=[ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_prompt} ], temperature=0.0, response_format={"type": "json_object"}, max_tokens=2048, )

response_format={"type": "json_object"}让 vLLM 在解码阶段优先输出合法 JSON，能挡掉大部分格式错误。temperature=0.0保证同一份病历每次抽取结果一致，这对后面的人工复核很重要——如果模型每次输出都不一样的字段值，复核人员根本没法定位是模型问题还是病历问题。提示词里的“否定表述”单独成数组，是刻意为之，模型直接抽取时经常把“否认高血压、糖尿病”拆成两个阳性诊断，单独列一个字段能显著降低这种错误。

3.3 结构化输出的校验与归一层：JSON 修复和编码映射

模型输出拿回来后不能直接入库，先要过一层校验。我见过太多项目在“模型输出偶尔合法”上面赌运气，结果跑批到一半被一条截断的 JSON 打断。校验逻辑分三步：先json.loads解析，解析失败就进入修复流程；解析成功后检查每个字段是否满足 Schema 要求，比如数组字段必须是数组、字符串字段不能是嵌套对象；最后做术语归一化。

import json import re def fix_json_output(raw: str) -> dict: # 第一步：剥离代码块标记和前后杂质 raw = re.sub(r"```json|```", "", raw).strip() try: return json.loads(raw) except json.JSONDecodeError: # 第二步：截断场景，尝试找到最后一个完整大括号 last_brace = raw.rfind("}") if last_brace != -1: return json.loads(raw[:last_brace + 1]) # 第三步：兜底交给模型重试 raise ValueError("JSON无法自动修复，需要重试")

fix_json_output这个函数处理的是两种高频故障：一是模型输出前后带了 markdown 代码块标记，这在直接调用 vLLM 时偶尔出现；二是生成中途被max_tokens截断，JSON 只有一个开头，rfind("}")能切到最后一个完整大括号，把残缺字段的尾巴丢掉。如果这两步都失败，不要硬解析，把原文和模型输出一起抛回，让模型重新抽取一次。

归一层做的是医学文本的标准化映射。同一份病历里“DM”“糖尿病”“2型糖尿病”可能指同一个诊断，直接按字符串存会让后续统计完全失真。常见做法是维护一张别名表，模型输出的字段值都先过这张表再入库。药品同样如此，“拜唐苹”和“阿卡波糖”是同一成分，诊断辅助场景如果不知道这一点，检索阶段会漏掉关键证据。

3.4 批量病历回填：异步任务与断点续跑

单个接口调通之后，真正的体力活是把 HIS 系统导出的几千份历史病历批量跑完。批量任务不能用一个 for 循环同步请求，一是单条请求可能耗时几十秒，二是 vLLM 在高并发下偶发连接断开，没有失败重试机制的话跑到一半就得从头再来。我的做法是把任务拆成“读病历、调模型、校验、写结果”四步，每条病历的结果独立落盘，任务进度记录在单独的 state 文件里，断点续跑时跳过已完成条目。

import json from pathlib import Path records_dir = Path("/data/records") output_dir = Path("/data/output") output_dir.mkdir(exist_ok=True) for record_path in records_dir.glob("*.txt"): output_path = output_dir / f"{record_path.stem}.json" if output_path.exists(): continue # 已完成，跳过 record_text = record_path.read_text(encoding="utf-8") raw = call_llm(record_text) try: result = fix_json_output(raw) except ValueError: result = {"error": "parse_failed", "raw": raw} output_path.write_text(json.dumps(result, ensure_ascii=False), encoding="utf-8") continue output_path.write_text(json.dumps(result, ensure_ascii=False), encoding="utf-8") print(f"processed: {record_path.name}")

这个脚本的核心是“一病历一文件”和“存在即跳过”。前者让单条失败不影响整体；后者保证任何时候中断，重跑只会处理未完成的病历，不用维护复杂的任务队列系统。call_llm函数内部要包一层异常捕获，连接超时、服务重启这类错误应该让它抛出来，让主循环记录失败文件清单，而不是让整个批次崩溃。等到几千份病历全部跑完，再把单文件结果聚合成一张大表，供后续统计分析使用。

注意：批量抽取时如果发现失败率超过 5%，先停下手动看几条，大概率是病历文本格式问题，比如扫描件 OCR 出来的残段或编码混乱，这类数据人工处理比硬喂模型更高效。

4. 诊断辅助落地：RAG 挂载院内知识库，而不是让模型裸答

4.1 诊断辅助为什么不直接裸问答：知识边界和幻觉风险

诊断辅助和病历结构化是两种完全不同的任务。结构化是“从文本里抽信息”，模型只要忠实原文就不会出大错；诊断辅助是“给出医学判断”，模型训练时的知识截止时间、通用医学知识库的覆盖度都满足不了院内规范，一旦它自信地编造一个不存在的药物相互作用，后果没人担得起。所以在医疗场景里，诊断辅助的常见做法是 RAG，也就是先检索再生成：把院内诊疗指南、药典、既往典型病案切块建索引，用户提问时先从库里召回相关内容，再让模型基于召回内容作答。

为什么不能靠微调解决？微调适合让模型学习某种输出风格或固定流程，但医学知识是持续更新的，院内指南每修订一版，微调模型就得重新训练一轮，成本和时间都不现实。RAG 的知识更新只需要替换索引库里的文档，今天换指南，明天检索到的就是新内容。另一个考虑是可溯源性：诊断辅助输出必须能说明“依据来自哪本指南第几章”，RAG 天然带有来源文档的位置信息，微调模型给不出这个证据链。

4.2 院内知识库怎么切块：段落粒度决定检索质量

知识库切块是 RAG 里最影响效果的一环，也是最容易被忽略的一环。很多教程教人按固定 token 数切块，比如每 500 字一块，这在医学文档上行不通——药品说明书的“用法用量”和“禁忌”可能在同一段里连续出现，硬切会把“一次2片”和“肝功能不全者禁用”分到两个块里，检索时只命中前半句，模型就会漏掉禁忌信息。

我的做法是结构化切块：优先按文档的原有层级切，比如指南的“章节—小节—段落”三级结构；段落过长时再按语义边界二次切分，确保每个块的内容自包含。切块后给每块打上元数据标签，包括来源文件名、章节路径、药品名称或疾病名称，这些标签在检索时会参与匹配。

4.3 辅助诊断输出规范：鉴别诊断清单与证据标注

RAG 服务的输出不能是自由文本，必须套一个固定的结构。我在项目里把诊断辅助的输出定义为三块：鉴别诊断列表、推荐检查项目、证据来源。鉴别诊断列表按可能性排序，每条都要给出理由；推荐检查项目要说明“为什么查”；证据来源必须指向知识库中的具体文档块。如果模型从检索结果中找不到足够支撑，就输出“当前知识库不足以支持判断，请结合临床进一步检查”，搭配一个明确的拒答机制。

def build_diagnosis_prompt(query: str, retrieved_chunks: list) -> str: context = "\n\n".join( f"[来源：{chunk['source']}，章节：{chunk['section']}]\n{chunk['text']}" for chunk in retrieved_chunks ) return f""" 基于以下检索到的资料回答问题。如果资料不足以支撑结论，直接说“证据不足”，不要自行推断。 检索资料： {context} 用户问题：{query} 请按以下JSON格式输出： {{ "鉴别诊断": [{{"诊断": "string", "理由": "string", "可能性": "高|中|低"}}], "推荐检查": ["string"], "证据来源": ["string"], "结论": "string" }} """

这个提示词有几个关键约束：证据不足是一个强制出口，模型无法在检索资料里找到论据时必须在结论里明确说明，而不是含糊带过；每条鉴别诊断必须带可能性等级，让医生快速判断模型置信度；证据来源直接从 retrieved chunks 里带出来，前端展示时可以做成可点击的引用链接，医生点进去看原文，这是诊断辅助能不能被临床接受的分水岭。模型输出的 JSON 同样过一遍上一章的fix_json_output，把"可能性"字段做白名单校验，不是“高/中/低”的值一律置为“中”，防止模型输出“80%”这类无法对齐的表述。

4.4 权限与审计：谁在什么上下文里调用模型

诊断辅助上线后，权限控制比抽取服务更紧。院内系统通常按角色划分调用等级：门诊医生可以查常见病鉴别诊断和用药禁忌，住院医生可以查诊疗指南和典型病案，进修医生只能看脱敏后的知识库内容，科研人员只能批量跑病历结构化，不能碰诊断辅助。这个矩阵要在接入层做，而不是在模型层做——vLLM 本身没有用户体系，接口只认请求不认人。

审计方面，每条诊断辅助请求要记录“科室、操作者、病历号、输入查询、模型输出、检索命中的文档块”。这些日志一方面用于事后追溯，万一出现误诊投诉，能还原模型当时依据了什么；另一方面用来持续优化系统，翻看日志时经常能发现某些科室的检索命中率特别低，原因往往是知识库里没覆盖该科室的病种，后续补文档就知道往哪个方向补。RAG 系统的知识库永远在迭代，而迭代的依据全靠审计日志。

注意：诊断辅助的定位是“辅助工具”，任何输出都应由医生确认后才写入诊疗记录。系统提示词和前端界面都要明确标注“本结果仅供参考，不作为直接诊断依据”，这不是免责，是基本功。

5. DeepSeek 病历结构化与诊断辅助避坑记录：从 JSON 翻车到大模型幻觉

5.1 病历文本 GBK 乱码导致抽取字段全空

现象：批量跑历史病历，部分文件抽取结果全是空字段，打开原文一看，中文变成了“锟斤拷”一类乱码。原因：HIS 系统导出的病历是 GBK 或 GB18030 编码，而 Python 脚本统一按 UTF-8 读取，解码失败后文本全是替换字符，模型自然抽不出任何有效信息。解决：读文件时先检测编码，检测不到就按 GB18030 兜底，入库前统一转成 UTF-8。另外还要清掉原文里的控制字符和 OCR 残留的换行符，这些字符会让模型把一句完整的主诉拆成两段。

from pathlib import Path raw = Path(record_path).read_bytes() for encoding in ("utf-8", "gb18030", "big5"): try: text = raw.decode(encoding) break except UnicodeDecodeError: continue

5.2 长病历截断丢关键既往史

现象：结构化结果里主诉和现病史完整，既往史只有一条“无”，但原文里明显写了三年前胃癌手术史。原因：max-model-len设成了 4096，病历原文 1800 字，加上 system prompt 和 few-shot 示例后 token 数超限，vLLM 从头部截断输入，既往史正好落在截断区。解决：先把max-model-len提到 8192，并精简 system prompt——few-shot 示例保留两个就够，别把模板写成小论文。对超过 6000 token 的超长病历，先按“入院记录、手术记录、出院小结”切段分别抽取，再合并结果。

5.3 JSON 输出不合法：比想象中更频繁

现象：线上跑批时偶发json.JSONDecodeError，错误信息显示字段值里混入了未转义的双引号，或数组中间少了逗号。原因：虽然设置了response_format，但量化模型或长输出场景下，解码器仍然可能生成结构不完整的 JSON；另外病历原文里的特殊字符，比如药品名带引号、检查结果里的 ± 号，会被模型原样放进 JSON 字符串里，导致解析失败。解决：前端先调用fix_json_output做自动修复，修复不了就把原文和错误输出一起丢回模型重试一次，一般能救回八成；再不行才转人工处理，别让单条坏数据阻塞整个批次。

5.4 本地私有化模型与在线大模型效果差异

现象：同一套病历结构化提示词，在线 API 跑出来的完整率 95%，本地 7B 模型只有 82%，主要集中在两个问题：否定词识别漏项、时间描述被错误归一化。原因：模型尺寸减小后，对复杂指令的遵循能力下降，尤其是“否定词单独成字段”这种反直觉指令，小模型经常漏执行。解决：与其纠结模型能力，不如把任务拆简单——在提示词里给一个完整例子，让模型照着填；同时把结构化任务从“一次性输出全部字段”拆成“先抽主诉和现病史，再抽既往史和过敏史”，单次任务越小，小模型完成度越高。如果拆完还差，再考虑换更大的模型或升级到 FP8 精度。

5.5 模型编造诊疗建议和用药禁忌

现象：诊断辅助测试时，模型对“老年高血压合并糖尿病”给出“首选 β 受体阻滞剂”的建议，但检索知识库里根本没有这一条，是模型沿用训练记忆在自由发挥。原因：RAG 的上下文窗口里虽然有检索资料，但模型训练时的医学知识会“漏”进生成过程，当检索资料不直接覆盖用户问题时，模型宁愿自己编一个答案也不肯说不知道。解决：在提示词里明确“只能基于检索资料回答”，并加上强制拒答出口；更硬的手段是做输出校验——对“推荐检查”“诊断结论”这类字段，比对是否能在检索命中的文档块里找到关键词，找不到就整体置为“证据不足”。这一招虽然粗暴，但能拦住大部分幻觉输出，保住诊断辅助的下限。

6. 上线前必须做的验证与一个进阶技巧：用影子模式跑两周再切换

结构化服务和诊断辅助开发完，别急着让医生直接使用。我通常先做一个线下验证：从目标科室随机抽 50 份历史病历，把模型结构化结果和人工填写的电子病历字段逐项比对，统计“主诉抽取准确率”“既往史完整率”“否定词误判率”三个核心指标。准确率达不到 95% 的不上线，不是开玩笑，病历字段错了，后面所有统计分析都是错的。

验证通过后的进阶做法是开“影子模式”：诊断辅助真实接收医生的问题，但结果只发给研发团队，不进临床流程。跑两周，拿模型输出和医生实际诊断作对照，看模型的鉴别诊断列表里有没有漏掉最终确诊方向。这个阶段最能暴露知识库的覆盖短板——影子模式里经常发现某些罕见病的检索召回为空，这时候去补文档，比上线后被医生投诉再补从容得多。

我最早一次上线只测了 JSON 合法率，没测字段完整率，结果主诉看着都对，既往史里的化疗方案漏了一半，后来才知道问题出在长文本截断。现在每逢新科室上线，我都先跑一遍字段级比对，再开两周影子模式，确认没有明显漏诊倾向后才给医生开放权限。这个流程多花两周时间，但换来的是临床端的基本信任。希望帮到你。

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