DeepSeek工程化落地全指南：从本地部署到API接入的完整实战

如果你正在做 AI 应用落地，最近肯定会反复听到 DeepSeek。但真正折磨人的不是“知道它很强”，而是“怎么把它接进自己的项目里”。很多开发者卡在同一个地方：模型下载下来了，推理却总是超时；API 调用成功了，一上生产就频繁限流；本地部署跑通了，换个机器又全是依赖冲突。这篇文章要解决的，就是 DeepSeek 从“能跑”到“能稳定工程化落地”的完整链路问题。

所谓 Harness，在 AI 工程领域不是某个官方产品的专属名词，而是指把大模型接入实际业务系统时需要用到的全套工具链：模型服务化部署、API 网关、调用封装、评测验证、监控告警、成本控制。很多人以为 Harness 只是“一个封装库”，实际它是一整套工程方法论。本文会从下载安装、环境配置、模型本地部署、API 接入、工程化实战、性能调优、常见故障排查七个维度展开，全部基于可落地的操作路径，不写云里雾里的概念。

读完这篇文章，你能得到三样东西：一套完整的 DeepSeek 本地部署与 API 接入操作流程；一套生产级项目实战的代码骨架；一份可以直接拿去用的排错清单和最佳实践指南。过程中会标注关键坑点，也会给出验证方式，确保每一步都能确认是真的跑通了，而不是“看起来成功”。

1. 为什么现在必须重新理解 DeepSeek 的工程化

先给一个判断：DeepSeek 解决的不是“模型能力有没有”的问题，而是“私有化部署和低成本推理能不能兼得”的问题。过去做私有化 LLM 应用，要么选开源小模型但效果差，要么用闭源大模型 API 但数据安全、成本控制都受制于人。DeepSeek 的开源权重加高效推理架构，让这两条路第一次有了交叉点。

但开源模型不等于开箱即用。这是目前社区里最大的误区：很多人以为把模型权重下载下来、装个推理框架就能直接上线。实际操作中会遇到什么？显存不够导致加载失败；并发一高响应时间暴涨；token 计费和缓存策略没配好导致成本失控；模型输出格式不稳定导致下游解析崩溃。这些问题全部属于“工程化”范畴，而不是模型本身的问题。

从材料来看，DeepSeek 最典型的落地场景有三个：

私有化知识库问答。企业内部文档、代码库、客服话术可以被模型直接检索和生成回答，数据不出内网。

复杂任务的 Agent 编排。DeepSeek 的指令跟随能力和推理能力，适合做多步任务拆解、工具调用、结果验证。

低成本批量文本处理。内容分类、信息抽取、报告生成等不需要极低延迟的任务，用本地部署可以大幅降低单次调用成本。

这三个场景对应着三种不同的接入方式：本地私有化部署、API 网关接入、混合模式（敏感数据走本地、非敏感数据走 API）。本文会覆盖前两种的完整操作，并给出混合模式的架构建议。

2. 核心概念：Harness 到底在解决什么问题

在开始动手之前，必须先把几个概念讲清楚，否则后面的操作你会不知道为什么这么做。

大模型推理：模型根据输入的 prompt 逐 token 生成输出的过程。这个过程极其依赖 GPU 算力和显存带宽。同一个模型，用不同的推理框架、不同的量化方式、不同的 batch 配置，性能和成本可能差出数倍。

模型服务化：把模型封装成 HTTP/gRPC 接口，让业务系统通过网络调用推理能力。这是模型与业务解耦的关键一层。

量化：把模型权重的精度从 FP16/BF16 降到 INT8/INT4，换取更低的显存占用和更快的推理速度，代价是输出质量有极小概率下降。对于大多数应用场景，INT4 量化后的 DeepSeek 仍然可用。

API 网关与限流：在模型服务前面加一层，负责认证、流量控制、负载均衡和降级熔断。没有这一层，生产环境一次突发流量就能把服务打挂。

Token 计费：大模型按 token 数量计费。中文字符约占 1 到 2 个 token，英文约 0.75 个 token。估算成本时不能只看模型单价，还要看你的场景平均一次请求消耗多少 token。

Prompt 工程：通过设计提示词模板，让模型稳定输出你想要的结构化结果。在工程化项目里，这比调参更能改善实际效果。

把这些概念连起来看，Harness 的本质就清楚了：它不是某个单一工具，而是从模型权重到业务接口之间的每一层工程手段的总和。

传统没有 Harness 思维时，项目流程是这样的：

1. 模型下载到本地。
2. 写个 Python 脚本加载模型，输入 prompt 拿到输出。
3. 用 Flask 包一层 HTTP 接口。
4. 上线后发现并发一高就崩，竞态条件、内存泄漏、超时问题接踵而至。

引入 Harness 思维后，流程变成：

1. 模型下载并做量化评估。
2. 用生产级推理框架做服务化封装。
3. 在服务前面加网关层，配置限流与超时。
4. 封装统一的 SDK 给业务方调用。
5. 加上监控、日志、评测集，确保发布后能追踪效果和成本。

对比很清楚：前者是“能跑”，后者是“能上线”。这就是这篇文章要带你走完的路径。

3. 环境准备与前置条件

为了不让你在环境问题上浪费一整天，先列一个最小可行的环境清单。版本信息请以实际项目为准，本文重点演示通用思路。

3.1 硬件要求

• GPU 最低要求：NVIDIA 显卡，显存 8GB 以上（跑小尺寸量化模型），16GB 以上更稳妥。
• 推荐配置：显存 24GB 起步，可以流畅运行中等规模模型的 INT4 量化版本。
• 无 GPU 怎么办：可以走 API 模式，或者用 CPU 做纯测试，但推理速度会很慢，不建议用于生产。
• 内存建议：32GB 以上，模型加载和推理缓存都需要内存支撑。

打开任务管理器或nvidia-smi确认显存情况，再决定走本地部署还是 API 模式。

3.2 软件依赖

• 操作系统：Windows 10/11、Ubuntu 20.04 及以上均可。生产环境推荐 Linux。
• Python 版本：3.10 或更高。
• CUDA 与 cuDNN：取决于你使用的推理框架要求，以实际项目为准。
• Docker：推荐安装，可以大幅降低环境配置成本，尤其适合生产环境部署。

用下面的命令检查 Python 版本：

python --version

如果没有安装 Docker，可以参考对应系统的安装方式。Windows 用户也可以直接使用 Docker Desktop。

3.3 创建项目目录

建议把整个工程放在同一个目录下，方便管理。这里以deepseek-harness-demo为例：

mkdir deepseek-harness-demo cd deepseek-harness-demo

后续的所有配置和代码都基于这个目录展开。如果你已经有项目，完全可以复用现有结构，只需要把本文的文件放到对应位置。

4. DeepSeek 获取与本地部署

环境准备好之后，进入核心流程。这一章完成“拿到模型”和“在本地跑通一次推理”两件事。

4.1 获取模型权重

DeepSeek 模型权重在开源社区可以获取。常见的方式有两种：

1. 从 Hugging Face 直接下载。
2. 使用 modelscope 国内镜像下载，速度通常更快。

模型的精度选择建议：先选一个适合你显存大小的量化版本，跑通后再尝试更高精度版本对比效果。

4.2 安装推理依赖

本地部署建议使用transformers加accelerate的组合，这是最直接、最少黑盒的方案：

pip install torch transformers accelerate

如果你的机器支持 CUDA，确保安装的是 GPU 版 PyTorch。验证方式如下：

import torch print(torch.cuda.is_available()) print(torch.cuda.device_count()) print(torch.cuda.get_device_name(0))

如果输出True和正确的显卡名称，说明 CUDA 环境可用。

4.3 加载模型并完成首次推理

创建一个 Python 文件test_inference.py：

# 文件路径：deepseek-harness-demo/test_inference.py from transformers import AutoModelForCausalLM, AutoTokenizer model_path = "your-model-path" # 替换为你实际保存的模型路径 tokenizer = AutoTokenizer.from_pretrained(model_path) model = AutoModelForCausalLM.from_pretrained(model_path, device_map="auto") prompt = "用一句话解释什么是大模型" inputs = tokenizer(prompt, return_tensors="pt").to("cuda") outputs = model.generate(**inputs, max_new_tokens=256) print(tokenizer.decode(outputs[0], skip_special_tokens=True))

这里的关键点是device_map="auto"，它会自动把模型分配到可用的显存设备上，新手不需要手动处理显存分配。如果你的模型比较大，可以考虑使用 4bit 加载，会大幅降低显存需求。

验证方式非常简单：运行后如果模型能正常生成完整回答，说明本地推理链路已经通了。这一小步是整个工程化的地基。

5. 模型服务化：从脚本到 API 接口

本地推理跑通之后，下一步是把模型封装成可供业务系统调用的 API。如果在实际项目中，这一步往往会被很多人跳过，直接用 Flask 包一层裸接口就上了，后患很多。

5.1 为什么需要服务化

业务系统不可能直接去 import Python 代码，它们需要的是一个稳定的 HTTP 接口。服务化之后，模型和业务形成清晰边界：模型升级、推理参数调整、量化切换，都不会影响业务代码。

同时，服务化还必须解决超时、并发、连接管理这些问题。直接用裸 Flask 接口，默认是单进程的，并发能力极差。

5.2 使用 FastAPI 搭建推理服务

FastAPI 是目前最合理的方案，自带异步支持，性能好，还自动生成接口文档。

# 文件路径：deepseek-harness-demo/api_server.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel from transformers import AutoModelForCausalLM, AutoTokenizer import torch import time app = FastAPI() model_path = "your-model-path" tokenizer = AutoTokenizer.from_pretrained(model_path) model = AutoModelForCausalLM.from_pretrained(model_path, device_map="auto") class GenerateRequest(BaseModel): prompt: str max_new_tokens: int = 256 temperature: float = 0.7 @app.get("/health") def health(): return {"status": "ok"} @app.post("/v1/generate") def generate(req: GenerateRequest): start = time.time() inputs = tokenizer(req.prompt, return_tensors="pt").to("cuda") outputs = model.generate( **inputs, max_new_tokens=req.max_new_tokens, temperature=req.temperature ) text = tokenizer.decode(outputs[0], skip_special_tokens=True) return { "text": text, "time_ms": int((time.time() - start) * 1000) }

启动服务：

uvicorn api_server:app --host 0.0.0.0 --port 8000

通过健康检查确认服务已经就绪：

curl http://localhost:8000/health

预期返回：

{"status":"ok"}

这里真正容易踩坑的地方是：如果你直接把模型加载放进启动脚本，uvicorn使用多个 worker 进程时，每个进程都会加载一次模型，导致显存直接翻倍爆掉。生产环境建议使用单 worker，或使用独立推理进程配合队列。

5.3 接口设计与超时配置

在微服务架构里，下游服务的稳定性直接决定整体稳定性。生成式模型的延迟天然不稳定，短请求可能 1 秒返回，长文本生成可能需要 30 秒以上。客户端调超时如果设置不合理，会出现业务侧频繁报错。

建议：

• 同步调用超时设置到 60 秒以上。
• 长任务改异步模式，提交后轮询或回调。
• 网关层设置合理的重试策略，但要防止重复调用导致成本翻倍。

6. API 模式接入：用官方兼容接口快速集成

如果你的场景不需要本地私有化部署，或者只是想快速验证 DeepSeek 的能力，走官方 API 模式是最快的。这种方式最大的优点就是零运维：不需要管 GPU、量化、推理框架，只需要管理好 key、模型名和调用逻辑。

6.1 创建 API Key 与环境变量管理

这会涉及密钥管理，安全问题很重要：永远不要把 API Key 硬编码在代码里，更不要提交到 Git 仓库。

推荐做法：

• 本地开发使用.env文件，并加入.gitignore。
• 生产环境使用密钥管理系统或容器环境变量注入。

安装 dotenv 工具：

pip install python-dotenv

创建.env文件：

DEEPSEEK_API_KEY=你的API密钥 DEEPSEEK_BASE_URL=https://api.deepseek.com

加载环境变量：

from dotenv import load_dotenv import os load_dotenv() api_key = os.getenv("DEEPSEEK_API_KEY") base_url = os.getenv("DEEPSEEK_BASE_URL")

这样密钥就留在环境变量层，不会进入代码和版本库。

6.2 使用 OpenAI SDK 兼容接入

DeepSeek 的 API 兼容 OpenAI 接口格式，所以你可以直接使用openaiPython SDK，只需要把base_url和api_key替换掉。这让迁移成本非常低——原来是调 GPT 的应用，改配置就能换到 DeepSeek。

# 文件路径：deepseek-harness-demo/api_client.py from openai import OpenAI from dotenv import load_dotenv import os load_dotenv() client = OpenAI( api_key=os.getenv("DEEPSEEK_API_KEY"), base_url=os.getenv("DEEPSEEK_BASE_URL") ) response = client.chat.completions.create( model="deepseek-chat", messages=[ {"role": "system", "content": "你是一个严谨的技术助手。"}, {"role": "user", "content": "帮我写一个 Python 快速排序，并解释关键逻辑。"} ], temperature=0.7, max_tokens=512 ) print(response.choices[0].message.content)

运行结果是一段包含代码和解释的完整回答。这里的 model 参数以官方平台开放列表为准，上面只是示例。

这种兼容模式的价值在于，你的业务代码不需要绑定某一家模型厂商。后续想切换模型，只需要替换base_url并适配模型名即可，系统的可移植性一下就提高了。

6.3 API 调用异常处理

即使官方 API 稳定性不错，生产环境仍然必须处理异常。一个完善的调用封装要考虑四类问题：网络超时、限流、鉴权失败、响应格式异常。

from openai import OpenAI import time from tenacity import retry, stop_after_attempt, wait_random client = OpenAI( api_key="your-key", base_url="your-base-url" ) @retry(stop=stop_after_attempt(3), wait=wait_random(min=1, max=3)) def call_deepseek(prompt: str) -> str: try: response = client.chat.completions.create( model="deepseek-chat", messages=[{"role": "user", "content": prompt}], max_tokens=512 ) return response.choices[0].message.content except Exception as e: print(f"API call error: {e}") raise

注意重试策略，要看官方限流说明再配置。如果服务端明确告知是限流，可以重试；如果是鉴权失败，重试也没有意义。

6.4 成本预估与 Token 管理

API 模式最大的隐患是成本失控。一个看似简单的循环任务，如果放在生产系统里每天跑上万次，累积起来就是一笔不小开销。从工程实践看，必须做三件事：

1. 记录每次调用的 token 消耗，包括 prompt_tokens、completion_tokens、total_tokens。
2. 设置月度预算告警。
3. 对高频非实时场景走批量处理，合并请求或走本地部署。

response = client.chat.completions.create( model="deepseek-chat", messages=[{"role": "user", "content": "你好"}] ) usage = response.usage print(f"prompt tokens: {usage.prompt_tokens}") print(f"completion tokens: {usage.completion_tokens}") print(f"total tokens: {usage.total_tokens}")

把这段信息写入日志，后面做成本分析时就有据可查。

7. 工程化实战：从单个调用到完整 AI 应用系统

前面的章节解决了“能调用”的问题，这一章解决“怎么接进真实业务”的问题。以一个企业知识库问答系统为例，完整走一遍 DeepSeek 的工程化接入流程。

7.1 项目目标

构建一个内部知识库问答系统：用户提问后，系统先从向量数据库检索相关文档片段，再把片段作为上下文交给 DeepSeek 生成回答。这就是典型的 RAG 应用，也是目前 LLM 落地场景中落地价值最直接的一种。

整体流程如下：

1. 文档加载与切分。
2. 文本向量化。
3. 向量存入向量数据库。
4. 用户提问时检索相关片段。
5. 拼接 Prompt 调用 DeepSeek。
6. 返回带引用来源的回答。

这六步分别涉及不同的技术组件，DeepSeek 在其中承担最核心的生成环节。

7.2 文档索引与向量化

先安装依赖：

pip install langchain chromadb sentence-transformers

创建目录结构：

mkdir -p docs data

文档处理示例：

# 文件路径：deepseek-harness-demo/build_index.py from langchain_community.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma # 1. 加载文档 loader = TextLoader("docs/company_handbook.txt") documents = loader.load() # 2. 切分文档 text_splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=100 ) chunks = text_splitter.split_documents(documents) # 3. 向量化 embeddings = HuggingFaceEmbeddings( model_name="BAAI/bge-small-zh" ) # 4. 存入向量数据库 vectordb = Chroma.from_documents( documents=chunks, embedding=embeddings, persist_directory="data/chroma_db" ) print(f"已索引 {len(chunks)} 个文档片段")

这段代码是关键基础。切分的核心参数是chunk_size和chunk_overlap：块太大，检索精度下降；块太小，上下文信息不完整。500 字加 100 字重叠是中文场景的常用起步值，后续根据实际效果调优。

7.3 检索增强生成

写完索引构建，实现问答主流程：

# 文件路径：deepseek-harness-demo/rag_query.py from langchain_community.vectorstores import Chroma from langchain_community.embeddings import HuggingFaceEmbeddings from openai import OpenAI from dotenv import load_dotenv import os load_dotenv() embeddings = HuggingFaceEmbeddings( model_name="BAAI/bge-small-zh" ) vectordb = Chroma( persist_directory="data/chroma_db", embedding_function=embeddings ) client = OpenAI( api_key=os.getenv("DEEPSEEK_API_KEY"), base_url=os.getenv("DEEPSEEK_BASE_URL") ) def ask(question: str) -> str: docs = vectordb.similarity_search(question, k=4) context = "\n\n".join([doc.page_content for doc in docs]) prompt = f"""请基于以下资料回答问题。如果资料中没有相关信息，请直接说明未知，不要编造。 资料： {context} 问题：{question} 回答：""" response = client.chat.completions.create( model="deepseek-chat", messages=[{"role": "user", "content": prompt}], temperature=0.3, max_tokens=1024 ) return response.choices[0].message.content if __name__ == "__main__": print(ask("我们公司的年假制度是什么？"))

这里有一个很关键的工程细节：检索回 top-k 的文档数量，会直接影响回答质量。数量太少，可能丢失关键信息；数量太多，会引入噪声。先从 4 起步，根据回答质量调整。

另外，温度参数也要注意：知识库问答需要的是忠实回答，所以temperature要调低，典型值在 0.1 到 0.3 之间。如果是创意写作或头脑风暴，再考虑调到 0.7 以上。

7.4 结构化输出：让模型返回 JSON

生产级系统很少直接展示模型返回的纯文本，通常需要结构化数据，便于前端渲染和后续逻辑处理。这里需要用 JSON 输出模式。

prompt = f""" 请从以下文本中抽取三个维度的信息，并输出 JSON 格式，不要输出其他内容： - 公司名称 - 发布日期 - 主要内容 文本： {text} JSON： """ response = client.chat.completions.create( model="deepseek-chat", messages=[{"role": "user", "content": prompt}], response_format={"type": "json_object"}, temperature=0.1 ) import json result = json.loads(response.choices[0].message.content) print(result["公司名称"])

如果解析失败，建议加一个兜底重试机制。这是模型输出不稳定的常态，工程上必须有容错设计。

7.5 单元测试与回归评估

接入完成后，不能直接上线。至少要准备一份回归评估集，包含典型问题、边界问题、恶意问题。每次调整 prompt 模板、模型参数或向量库配置后，都用这份评估集验证差异。

test_cases = [ {"question": "公司年假多少天？", "keywords": ["年假"]}, {"question": "远程办公政策是什么？", "keywords": ["远程"]}, {"question": "公司食堂几点开门？", "keywords": ["未知", "没有提到"]}, ] for case in test_cases: answer = ask(case["question"]) hit = any(keyword in answer for keyword in case["keywords"]) print(f"问题：{case['question']}") print(f"回答：{answer[:80]}...") print(f"通过：{hit}\n")

这套评估集不需要一开始就很完善，但必须在项目第一天就建立起来。没有回归评估，后续任何优化都可能变成拆东墙补西墙。

8. 性能优化、成本控制与安全边界

模型接入跑通只是起点。生产环境的稳定性、成本和安全性，才是真正决定项目成败的部分。

8.1 推理性能优化

结合目前社区的主流实践，性能优化可以按照下面的优先级来考虑：

第一优先级是量化。这是性价比最高的优化手段，能把显存占用降低一半以上，推理吞吐量提升数倍。从 FP16 换到 INT4 后，模型体积明显下降，首 token 延迟也有改善。

第二优先级是并行与批处理。同一时刻有多个请求时，尽量合并进同一个 batch 推理，GPU 的利用率会显著提升。单个请求逐个处理，GPU 大部分时间都在空转。

第三优先级是缓存。高频重复的用户问题、系统提示词、文档上下文都可以做缓存层。尤其是 RAG 场景，向量检索结果可以缓存，减少重复计算。

8.2 成本控制策略

成本控制不是上线后才考虑的事，而是在架构设计阶段就要决定的。推荐三种策略：

第一，分级模型策略。简单问题走小模型，复杂推理走 DeepSeek。可以在系统里做意图分类，先判定问题难度，再路由到不同模型。

第二，Prompt 瘦身。系统提示词和示例要精简，每一轮对话都在消耗 token。同样一个任务，提示词精简 30%，成本也能下降 30%。

第三，缓存层策略。对于高频问题，直接把第一次的回答缓存到 Redis 或数据库，避免每次访问都调用模型。

8.3 安全边界与合规注意

这部分在当前 AI 工程化项目里越来越重要，必须认真对待：

数据安全：涉及隐私数据或商业机密的文本，不应传给外部 API 平台。优先使用本地私有化部署。即便使用 API，也建议进行脱敏处理。

密钥管理：API Key 绝不入库、不入日志。一旦怀疑泄露，立刻轮换。

模型幻觉控制：RAG 场景必须在 Prompt 中明确要求“资料中没有的信息要说明未知”，同时在前端 UI 给用户呈现引用来源。

权限与审计：AI 应用的访问权限必须纳入统一认证体系，所有调用记录建议留存，便于事后审计和定位问题。

输出合规：模型内容需要经过内容安全过滤后再展示给终端用户，尤其是面向公众的产品。

9. 常见问题与排查思路

排查思路有一个固定顺序：先看日志，再查配置，最后改代码。不要一上来就调模型参数，很多问题只是环境变量没加载或端口被占用。

10. 最佳实践与工程建议

经历完整的部署、接入、实测之后，最后沉淀出几条可以长期使用的工程建议。

建议一：从 API 模式起步，按需切到本地部署。除非有硬性数据安全要求，否则先用 API 快速验证业务效果。业务需求稳定后，再投入资源做私有化部署。

建议二：把模型交互封装成统一 SDK。不管底层用的是 DeepSeek API 还是本地推理服务，业务代码统一走同一个 SDK 接口。这样后续切换模型厂商，只需改 SDK 内部实现，业务代码零改动。

建议三：任何 Prompt 模板都要带版本号。Prompt 调优是持续的，模板没有版本管理，上线后很难追踪效果变化。推荐把模板放到 Git 仓库或配置中心管理。

建议四：日志记录一切关键指标。每次调用至少记录耗时、token 消耗、模型名称、请求摘要。没有这些数据，后续做成本分析和问题回溯都是盲人摸象。

建议五：建立 AI 应用监控大盘。监控三个核心指标：可用率（接口成功率）、延迟（首 token 延迟和总耗时）、成本（每日 token 消耗和费用）。这三个指标控制住了，AI 应用就基本可控。

建议六：重视失败兜底设计。模型接口一定会失败，系统必须定义当模型不可用时的降级策略，比如返回缓存结果，或者引导用户稍后重试。不能因为模型服务抖动导致整个系统不可用。

11. 总结与后续学习方向

这篇文章真正帮你理清了 DeepSeek 工程化的完整路径：从环境准备、模型下载、本地推理，到 API 接入、RAG 应用实战、性能优化、成本控制和安全边界。你最少应该已经能跑通三件事：本地加载模型并完成一次推理；用 FastAPI 把模型封装成可调用的服务；用官方 API 兼容 SDK 接入业务系统。

下一步建议按这个顺序进阶：先拿一份真实业务文档，把 RAG 代码跑起来；然后为你的场景建立一份回归评估集，记录基线效果；接着尝试量化部署，体验性能和显存的变化；最后再把监控和日志体系补上，让系统具备上线条件。

DeepSeek 这类开源大模型最大的价值在于，它把 AI 能力从“少数大厂的专属服务”变成了“每个团队都能掌握的工程资产”。但模型权重只是起点，工程化能力决定了你能否真正用好它。建议把这篇文章收藏备用，动手实践时对照着操作。如果你在部署或接入过程中遇到具体问题，欢迎在评论区描述你的环境和报错信息，一起把坑填平。