企业官网建设流程全解析

各位开发者朋友们好，今天我们来聊一个最近在 AI 工程圈被频繁提及的热词：DeepSeek Harness。如果你最近关注技术社区、开源项目或者 AI 应用开发讨论，大概率会看到这个组合词。很多人的第一反应是：DeepSeek 我听过，是一个很火的大语言模型，但 DeepSeek Harness 又是什么？是新的模型系列？是一个开发框架？还是一个特定仓库的名字？

带着这些疑问，本文会从概念、背景、核心组成、实战用法和排错思路几个维度展开。无论你是刚接触大模型应用开发的新手，还是准备在业务中引入大模型能力的后端工程师，这篇文章都能帮你建立一个相对完整的认知框架。同时，我也会给出可以直接运行的代码示例和工程落地的建议。

1. DeepSeek Harness 到底是什么

先看一个容易混淆的点：DeepSeek 和 DeepSeek Harness 并不是同一个层面的东西。

1.1 DeepSeek 是什么

DeepSeek 是由深度求索公司推出的开源大语言模型系列。它在国内外开发者社区中关注度很高，主要有几个原因：

• 模型权重开源，开发者可以自行下载部署。
• 推理成本相对较低，性价比突出。
• 在代码生成、数学推理、中文理解等任务上表现优秀。
• 提供了与 OpenAI 兼容的 API 接口，迁移成本低。

也就是说，DeepSeek 是“模型”本身。你可以通过官方 API 调用它，也可以在本地用推理框架加载它的权重。

1.2 Harness 是什么

Harness 这个词在英文中直译是“马具、挽具”，引申含义是“驾驭、控制”。在软件工程领域，Harness 通常指一套围绕核心组件构建的“控制层”或“测试载体”。

举几个熟悉的例子：

• 在测试领域，test harness指的是测试框架和脚本的集合，用来驱动被测代码执行并验证结果。
• 在 Kubernetes 生态中，chaos harness指故障注入工具，用来主动制造异常以验证系统韧性。
• 在机器学习领域，eval harness指模型评估框架，比如 OpenAI Evals、lm-evaluation-harness，用来批量跑评测任务。

所以，Harness 的本质是：把某个底层能力包装成更易于控制、测量、维护的工程化工具。

1.3 合在一起怎么理解

DeepSeek Harness 并不是 DeepSeek 官方发布的一个独立产品名称，而是在社区实践中逐渐形成的一种统称。它通常指：

• 围绕 DeepSeek 模型构建的开发工具链。
• 将 DeepSeek 接入业务系统的工程封装。
• 对 DeepSeek 模型进行评测、微调、推理加速的控制框架。
• 以 DeepSeek 为底层模型的 Agent 应用运行载体。

简单说，DeepSeek Harness 是“驾驭 DeepSeek 模型的工程化层”。它让开发者不用直接面对原始模型接口的复杂性，而是通过一个中间层完成提示词管理、模型调用、结果解析、错误重试、日志追踪等横切关注点。

1.4 它解决什么痛点

实际业务中直接调用大模型 API 往往不复杂，但一旦进入生产环境，问题就变多了：

• 提示词散落在业务代码里，改起来麻烦。
• 模型返回的结构不稳定，解析逻辑容易出错。
• 不同业务场景需要不同的温度参数、最大 Token 数、超时时间。
• API 调用出现限流、超时、网络波动时缺少优雅降级策略。
• 缺少统一的日志和链路追踪，问题定位困难。
• 模型版本升级后，回归验证成本高。

DeepSeek Harness 这类工程层存在的意义，就是把这些横切关注点统一收拢起来，让业务开发人员只关心“输入什么、得到什么”，而不用为每个项目重复处理模型接入的脏活累活。

2. 为什么突然火了

2.1 时间线背景

DeepSeek 模型本身在 2024 年底到 2025 年初经历了一轮爆发。DeepSeek-V3 发布后，社区惊叹于它的训练成本和性能表现；随后 DeepSeek-R1 推理模型的发布更是引发了全球范围的关注。开源权重、MIT 协议、低成本推理，这几个标签叠加在一起，让大量开发者开始尝试把 DeepSeek 接入自己的项目。

随之而来的是一大批周边工程需求：有人需要做模型评测，有人需要接 API，有人需要私有化部署，有人需要让模型回复稳定 JSON 结构。当这类需求集中爆发时，围绕 DeepSeek 的“Harness 层”工具自然就成了社区关注焦点。

2.2 开源与本地部署的催化

很多开发者选择 DeepSeek 是因为它支持本地部署。但本地部署意味着你需要自己处理以下问题：

• 模型量化选型。
• 推理服务部署（如 vLLM、Ollama）。
• 显存和并发量的规划。
• 与现有代码库的集成。

这些问题单靠模型本身解决不了，需要工程化工具来支撑。因此，当越来越多人尝试本地部署 DeepSeek 时，他们需要一个可靠的 Harness 层来标准化调用流程。

2.3 Agent 应用的兴起

2025 年 AI 应用的一个重要趋势是 Agent 化。开发者开始不满足于“问一句答一句”，而是希望大模型能调用工具、规划步骤、读写文件、访问数据库。Multi-Agent 框架如雨后春笋般出现。

而 Agent 应用对底层模型的调用稳定性要求极高。模型的一次非结构化输出就可能导致整个 Agent 链路崩溃。所以，围绕 DeepSeek 构建工具调用层、结构化输出层、任务编排层，就成了一种刚需。

2.4 社区效应与话题聚合

还有一个不可忽视的因素是社区效应。当一个话题在 GitHub、技术社区、短视频平台被反复讨论时，它会形成自我强化的热度。很多开发者并不是真的需要一个全新的框架，而是被“大家都在讨论”的氛围带动，开始关注和实践。热度一旦起来，相关教程、模板、开源项目会快速涌现，进一步降低上手门槛，形成正循环。

说到底，DeepSeek Harness 火起来，本质上是因为：底层模型足够好用且开源，大家开始认真思考如何把模型能力工程化、产品化。工程化需求是真实存在的，而 Harness 恰好站在这个需求的核心位置。

3. 环境准备与版本说明

在进入代码环节之前，先梳理一下环境依赖。

3.1 基础环境

本文示例以 Python 为主要语言，核心依赖如下：

• Python 3.10 或更高版本（建议 3.10+，新版本特性兼容更好）。
• openaiPython SDK（DeepSeek API 兼容 OpenAI 协议）。
• python-dotenv用于管理环境变量。
• 可选的pydantic用于结构化输出校验。
• 可选的typing-extensions用于类型标注。

示例项目结构如下：

deepseek-harness-demo/ ├── .env ├── requirements.txt ├── harness/ │ ├── __init__.py │ ├── client.py │ ├── prompt.py │ ├── response.py │ └── exception.py ├── examples/ │ ├── basic_call.py │ ├── structured_output.py │ └── agent_tool.py └── README.md

3.2 安装依赖

建议创建虚拟环境后安装：

python -m venv .venr source .venr/bin/activate # Windows 下执行 .venr\Scripts\activate pip install openai python-dotenv pydantic

requirements.txt可以这样写：

openai>=1.40.0 python-dotenv>=1.0.1 pydantic>=2.7.0

这里需要说明：版本号只是参考，具体以你安装时的最新稳定版为准。如果你使用的是国内镜像源，安装时指定镜像即可。

3.3 获取 API Key 或本地服务地址

DeepSeek 使用方式有两种：

一是官方 API 方式。你需要去 DeepSeek 开放平台创建 API Key。环境变量示例：

DEEPSEEK_API_KEY=sk-xxxxxxxxxxxxxxxx DEEPSEEK_BASE_URL=https://api.deepseek.com

二是本地部署方式。你可以通过 Ollama、vLLM 等工具在本地加载 DeepSeek 模型。本地部署时不需要 API Key，但需要一个本地服务地址，例如http://localhost:11434。

两种方式在代码层面的调用逻辑可以保持一致，只是base_url和api_key不同。这也是 Harness 层能统一封装的基础。

4. 核心组成与设计思路

一个标准的 DeepSeek Harness 通常包含几个核心模块。下面逐一拆分说明。

4.1 客户端封装模块

客户端模块负责管理模型 API 的连接。它不应该在业务代码里重复构造，而应该全局复用。

# 文件路径：harness/client.py import os from openai import OpenAI from dotenv import load_dotenv load_dotenv() class DeepSeekClient: def __init__(self): self.api_key = os.getenv("DEEPSEEK_API_KEY") self.base_url = os.getenv("DEEPSEEK_BASE_URL", "https://api.deepseek.com") self.timeout = int(os.getenv("DEEPSEEK_TIMEOUT", "60")) self.max_retries = int(os.getenv("DEEPSEEK_MAX_RETRIES", "3")) self.client = OpenAI( api_key=self.api_key, base_url=self.base_url, timeout=self.timeout, max_retries=self.max_retries )

这里有几个设计要点：

• 通过.env文件管理 Key，避免写死在代码里。
• timeout和max_retries可配置，防止网络抖动影响业务。
• OpenAI客户端的base_url被替换成 DeepSeek 的接口地址，实现协议兼容。

4.2 提示词管理模块

提示词是决定大模型输出质量的关键因素之一。Harness 层应该把提示词当作“可以被管理和迭代的资源”，而不是散落在字符串拼接中。

# 文件路径：harness/prompt.py from string import Template class PromptManager: def __init__(self): self.templates = {} def register(self, name: str, template: str): self.templates[name] = Template(template) def render(self, name: str, **kwargs) -> str: if name not in self.templates: raise KeyError(f"Prompt template '{name}' not found") return self.templates[name].safe_substitute(**kwargs) # 使用示例 prompt_manager = PromptManager() prompt_manager.register( "code_review", """你是一名资深代码评审专家。请针对以下代码提出改进建议。 代码： $code 请从正确性、可读性、性能三个维度的回答。""" ) rendered_prompt = prompt_manager.render( "code_review", code="def add(a, b):\n return a + b" )

注意：这里使用string.Template而不是 f-string，原因是可以把模板和渲染逻辑分离。后续如果切换到jinja2这类更强大的模板引擎，接口也不需要改动。

4.3 响应解析与结构化输出模块

大模型的返回结果默认是自然语言，但在工程化场景中，我们希望得到结构化数据。常见的做法有三种：

第一种，在提示词中要求模型返回 JSON。

第二种，使用工具调用（Function Calling）协议。DeepSeek 支持 OpenAI 兼容的工具调用格式。

第三种，在代码层面对响应结果做数据校验。

一个完整的 Harness 层最好同时支持这三种方式。以 JSON 输出为例：

# 文件路径：harness/response.py import json from typing import Any, Dict, Optional class ResponseParser: @staticmethod def parse_json(text: str) -> Dict[str, Any]: """从模型回复中提取并解析 JSON 对象。""" # 去掉 markdown 代码块标记 cleaned = text.strip() if cleaned.startswith("```"): lines = cleaned.split("\n") lines = lines[1:] cleaned = "\n".join(lines) if cleaned.endswith("```"): cleaned = cleaned[:-3] try: return json.loads(cleaned.strip()) except json.JSONDecodeError: # 尝试截取第一个 { 到最后一个 } 之间的内容 start = cleaned.find("{") end = cleaned.rfind("}") if start >= 0 and end > start: return json.loads(cleaned[start:end + 1]) raise ValueError("无法从模型输出中解析 JSON")

为什么要做这么复杂的解析？因为实际调用中，模型经常会在 JSON 前后加解释性文字，或者用 Markdown 代码块包裹。解析模块需要有一定的容错能力。

4.4 异常处理模块

大模型 API 调用常见的异常包括：认证失败、余额不足、限流、上下文长度超限、模型服务不可用等。Harness 层应该定义统一的异常体系，方便上层捕获和处理。

# 文件路径：harness/exception.py class DeepSeekHarnessError(Exception): """Harness 基础异常。""" class AuthenticationError(DeepSeekHarnessError): """API Key 无效或认证失败。""" class RateLimitError(DeepSeekHarnessError): """请求频率超出限制。""" class ContextLengthError(DeepSeekHarnessError): """输入上下文超过模型限制。""" class ServiceUnavailableError(DeepSeekHarnessError): """模型服务不可用。"""

在客户端封装时，应该把 SDK 抛出的底层异常映射成 Harness 自定义异常。这样业务代码中不需要直接依赖 OpenAI SDK 的异常类型，后续换底层模型时改动面更小。

5. 完整实战案例：搭建一个极简 DeepSeek Harness

这一节我们不走太复杂的设计，而是从零搭建一个能用的、可扩展的 DeepSeek Harness，并用它完成三个任务：

• 基础对话。
• 结构化 JSON 输出。
• 一个简单的工具调用。

5.1 创建项目骨架

新建项目目录和虚拟环境：

mkdir deepseek-harness-demo cd deepseek-harness-demo python -m venv .venv source .venv/bin/activate pip install openai python-dotenv pydantic

创建.env文件：

DEEPSEEK_API_KEY=sk-your-api-key-here DEEPSEEK_BASE_URL=https://api.deepseek.com DEEPSEEK_MODEL=deepseek-chat

注意：如果你是通过本地 Ollama 部署，DEEPSEEK_BASE_URL可以改成http://localhost:11434/v1，模型名称改成实际拉取的模型名，例如deepseek-r1:7b。这点我们后面会再展开。

5.2 编写 Harness 核心类

先实现一个统一的“完成方法”，把提示词管理、客户端调用、异常映射、日志输出串起来。

# 文件路径：harness/core.py import logging from typing import Any, Dict, List, Optional from .client import DeepSeekClient from .exception import DeepSeekHarnessError logger = logging.getLogger(__name__) class DeepSeekHarness: def __init__(self): self.client_wrapper = DeepSeekClient() def chat( self, messages: List[Dict[str, str]], temperature: float = 0.7, max_tokens: int = 2048, response_format: Optional[Dict[str, str]] = None, ) -> str: """执行一次聊天补全，返回模型文本回复。""" model = self.client_wrapper.model params: Dict[str, Any] = { "model": model, "messages": messages, "temperature": temperature, "max_tokens": max_tokens, } if response_format: params["response_format"] = response_format response = self.client_wrapper.client.chat.completions.create(**params) content = response.choices[0].message.content if not content: raise DeepSeekHarnessError("模型返回了空内容") return content

注意上面的代码中引用了client_wrapper.model，需要在DeepSeekClient中补充：

# 文件路径：harness/client.py 补充字段 self.model = os.getenv("DEEPSEEK_MODEL", "deepseek-chat")

同时补一个最基础的日志记录能力：

# 文件路径：harness/core.py 补充 import time def chat_with_log(self, messages, **kwargs): start_time = time.time() try: result = self.chat(messages, **kwargs) elapsed = time.time() - start_time logger.info("DeepSeek call succeeded, elapsed=%.2fs, tokens=%d", elapsed, len(result)) return result except Exception as exc: logger.exception("DeepSeek call failed: %s", exc) raise

5.3 示例一：基础对话

现在写一个最基础的调用示例：

# 文件路径：examples/basic_call.py import sys import os sys.path.insert(0, os.path.abspath(os.path.join(os.path.dirname(__file__), ".."))) from harness.core import DeepSeekHarness def main(): harness = DeepSeekHarness() messages = [ {"role": "system", "content": "你是一名擅长用简洁语言解释复杂概念的技术专家。"}, {"role": "user", "content": "请用三句话解释什么是大语言模型。"} ] reply = harness.chat_with_log(messages, temperature=0.3) print("模型回复：") print(reply) if __name__ == "__main__": main()

运行：

python examples/basic_call.py

预期输出：一段关于大语言模型的简介，会根据模型版本不同有一定差异。

这里解释几个参数的作用：

• temperature=0.3：降低随机性，让输出更稳定，适合解释性和知识性任务。
• max_tokens=2048：限制最大输出长度，防止模型“说个没完”或产生非常长的回答。

5.4 示例二：结构化 JSON 输出

现在让模型返回一个合法的 JSON。这里用到 DeepSeek API 的response_format参数，它和 OpenAI 的 JSON Mode 类似。

# 文件路径：examples/structured_output.py import sys import os import json sys.path.insert(0, os.path.abspath(os.path.join(os.path.dirname(__file__), ".."))) from harness.core import DeepSeekHarness def main(): harness = DeepSeekHarness() messages = [ {"role": "system", "content": "你是一个数据抽取助手。请从用户输入中抽取结构化信息，并只输出 JSON 对象，不要输出任何解释。"}, {"role": "user", "content": "张三，28岁，就职于深圳某科技公司，职位是后端开发工程师。"} ] reply = harness.chat_with_log( messages, temperature=0.0, response_format={"type": "json_object"} ) parsed = json.loads(reply) print("解析后的 JSON：") print(json.dumps(parsed, ensure_ascii=False, indent=2)) if __name__ == "__main__": main()

运行后预期会输出类似：

解析后的 JSON： { "姓名": "张三", "年龄": 28, "城市": "深圳", "职位": "后端开发工程师" }

如果模型返回的 JSON 不合法，可以结合上一节的ResponseParser做容错。在实际生产项目中，建议再叠加pydantic模型做字段校验，用已有的验证函数结构化重试。

5.5 示例三：简单工具调用

工具调用（Function Calling）是大模型应用从“聊天机器人”走向“Agent”的关键能力。DeepSeek 支持 OpenAI 兼容的工具调用协议。

下面实现一个查询“当前时间”的工具调用。

# 文件路径：examples/agent_tool.py import sys import os import datetime sys.path.insert(0, os.path.abspath(os.path.join(os.path.dirname(__file__), ".."))) from openai import OpenAI from dotenv import load_dotenv load_dotenv() def get_current_time() -> str: return datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S") tools = [ { "type": "function", "function": { "name": "get_current_time", "description": "获取当前系统日期和时间", "parameters": { "type": "object", "properties": {}, "required": [] } } } ] def main(): client = OpenAI( api_key=os.getenv("DEEPSEEK_API_KEY"), base_url=os.getenv("DEEPSEEK_BASE_URL", "https://api.deepseek.com") ) messages = [ {"role": "user", "content": "现在几点了？"} ] response = client.chat.completions.create( model=os.getenv("DEEPSEEK_MODEL", "deepseek-chat"), messages=messages, tools=tools, tool_choice="auto", ) message = response.choices[0].message if message.tool_calls: tool_call = message.tool_calls[0] print("模型请求调用工具：", tool_call.function.name) result = get_current_time() messages.append(message) messages.append({ "role": "tool", "tool_call_id": tool_call.id, "content": result }) final_response = client.chat.completions.create( model=os.getenv("DEEPSEEK_MODEL", "deepseek-chat"), messages=messages, ) print("最终回复：", final_response.choices[0].message.content) else: print("模型直接回复：", message.content) if __name__ == "__main__": main()

这个示例展示的是一个最简的“一次工具往返”。真实 Agent 系统需要处理多轮工具调用、并发工具调度、错误恢复等，但核心协议是一样的。

5.6 本地模型接入

如果你的场景是私有化部署，不希望将数据发送到云端 API，可以通过 Ollama 实现。

启动 Ollama 后，拉取模型：

ollama pull deepseek-r1:7b

启动服务后修改.env：

DEEPSEEK_BASE_URL=http://localhost:11434/v1 DEEPSEEK_MODEL=deepseek-r1:7b DEEPSEEK_API_KEY=ollama

Ollama 的/v1接口兼容 OpenAI 协议，所以上面所有代码都可以复用，不需要改逻辑。这是 Harness 设计带来的便利：底层模型可以在云端 API 和本地部署之间切换，只要接口协议一致，上层代码基本不动。

6. 常见问题与排查思路

在实际使用 DeepSeek Harness 的过程中，大家最常遇到的问题我整理成了表格，方便直接对照排查。

6.1 环境变量不生效

很多新手第一坑是.env文件没有加载成功。排查顺序：

1. 确认项目根目录下有.env文件。
2. 确认代码中调用了load_dotenv()。
3. 在代码中打印os.getenv("DEEPSEEK_API_KEY")看是否有值。
4. 留意.env文件命名，不要写成.env.txt或者.env.local。

6.2 API 调用超时

大模型接口响应时间波动较大，特别是在模型负载高的时段。建议：

• 设置timeout为 60 秒以上。
• 为重要请求开启max_retries。
• 把超时和重试参数放入配置中心或环境变量，方便动态调整。

6.3 模型输出不稳定

即使是同一个提示词，模型也可能在不同时间给出不一致的结果。这不一定是你代码的问题，而是大模型的固有概率性质。缓解方式：

• 降低temperature到 0 或 0.1。
• 在提示词中明确给出输出格式示例。
• 使用response_format限制输出结构。
• 对关键业务字段做校验，不满足条件时自动重试。

6.4 本地部署显存不足

运行 7B 模型也需要一定显存。如果显存不够，可以尝试：

• 使用 4-bit 量化版本。
• 减小max_tokens。
• 换用更小的模型。
• 使用 CPU 推理加小批量策略，但速度会更慢。

7. 最佳实践与工程建议

7.1 用 Harness 层隔离底层模型

不要直接在业务代码里调用 OpenAI SDK。哪怕你觉得 DeepSeek 的接口够简单，也要包一层。原因很简单：模型的接口协议可能变化，模型本身可能切换，直接耦合会放大变化成本。通过 Harness 层做一个统一出口，未来无论换模型还是调整参数，都只改动一个文件。

7.2 提示词也要做版本管理

提示词是你产品的隐形成本中心。建议：

• 把提示词模板独立存放，用代码管理工具跟踪变更。
• 为提示词命名时加上版本后缀，如code_review_v2。
• 变更提示词后，在测试环境做回归对比。

7.3 日志和可观测性

每次模型调用都应该记录：

• 请求时间和耗时。
• 模型名称和参数。
• 输入 token 数和输出 token 数。
• 错误类型和重试次数。
• 调用方业务标识。

没有日志的 AI 应用，线上排查问题会非常痛苦。建议把日志接入统一日志平台，并结合链路追踪。

7.4 安全与合规边界

涉及用户敏感数据时要注意：

• 不要直接拼接未脱敏的隐私信息进提示词。
• 明确告知用户数据会发送至第三方模型服务。
• 本地部署模式更适合对数据出境有要求的企业场景。
• 不要依赖模型输出直接执行生产环境的危险操作。即便只是演示代码，也应在真实系统中增加人工审批环节。
• 对模型输出中可能包含的指令注入要有所防备。例如，如果模型返回“删除数据库”之类的文本，你不能直接当作命令执行。

7.5 成本控制

大模型 API 按 token 计费，成本控制要从几个维度入手：

• 对系统提示词做瘦身，减少固定 token 消耗。
• 历史消息做滑动窗口，而不是无限累积。
• 对长文档做分段处理，避免全文塞入上下文。
• 建立请求量监控，及时发现异常调用。

7.6 测试策略

AI 应用的测试不能只靠“人眼验证”。建议：

• 准备一组固定输入用例，做自动回归。
• 对结构化输出做 schema 校验。
• 对断言类输出做关键词匹配或语义相似度判断。
• 在 CI 中接入模型调用集成测试，但要控制调用次数，避免测试成本飙升。

8. 总结与下一步

本文围绕 DeepSeek Harness 展开了系统梳理。你需要记住几个核心结论：

第一，DeepSeek Harness 不是某个神秘框架或官方新模型，而是“围绕 DeepSeek 模型的工程化封装层”的一种社区统称。它的核心价值是把模型接入、提示词管理、响应解析、异常处理、日志追踪等横切点统一收归到一个稳定层。

第二，DeepSeek 突然火起来的原因是多方面的。模型本身的开源与高性价比、本地部署诉求、Agent 应用爆发、社区话题聚合效应共同推动了热度。而热度背后真实的需求是工程化落地，Harness 恰好切中了这个需求。

第三，实战层面，通过一个最小 Harness，我们可以用很低的成本实现基础对话、JSON 结构化输出和工具调用。而且这套封装可以在云端 API 与本地部署之间无缝切换，这恰好体现了 Harness 层存在的意义。

如果你下一步想继续深入，可以从这些方向入手：

• 学习更完整的评测框架，比如 lm-evaluation-harness，了解如何量化评估模型能力。
• 深入研究 Agent 框架，尝试把 DeepSeek 接入 RAG 或 Multi-Agent 编排系统。
• 研究提示词工程的系统方法，包括 Few-shot、Chain-of-Thought、结构化输出模板设计。
• 学习部署层面的知识，比如 vLLM、TensorRT-LLM、量化推理和并发调优。

实际项目中，优先关注三个风险：模型输出不稳导致业务异常、调用成本失控、敏感数据泄露风险。这三个问题如果能在一开始就在架构层面考虑清楚，后续维护会轻松很多。

如果你在跟着本文搭建的过程中遇到问题，可以先对照常见问题表格排查。环境相关的问题大部分可以通过检查版本、环境变量和参数格式解决；模型输出相关问题则需要通过提示词迭代和结构化约束来缓解。希望这篇教程对你有帮助。