从去年底开始，我把手头几个大模型相关的小项目全部迁到了一个固定组合上：Dify 做应用编排，DeepSeek 做模型底座。说实话，之前直接拿裸接口开发 AI 功能的日子有点磨人——每接一个新场景，提示词要重新调，上下文要自己管，流式输出要自己拼，连做个最简单的对话机器人也得写几百行胶水代码。换成 Dify 之后，这些大部分变成了界面操作，模型侧我统一走 DeepSeek 的 API，从部署平台到发布一个能实际使用的知识库问答应用，全程没写多少业务代码。这篇我就把整套流程完整拆开：先说为什么要这么选，再说怎么装、怎么配，最后用一个知识库问答助手和一个小型工作流做实战演示，把我踩过的坑也一并列出来。如果你正准备从零搭大模型应用，或者想给团队找一个省心的应用开发底座，这篇值得存下来慢慢看。

1. 为什么是这对组合：工具的定位与选型逻辑

1.1 Dify 解决了应用开发的哪一层问题

大模型应用开发看起来简单，真正做起来，重复劳动多到让人崩溃。直接调用模型接口只是第一步，后面还跟着一堆事：得设计提示词并管理版本，得处理多轮对话时的历史记录，得上手一套向量数据库来搞知识库检索，得自己做日志和 Token 统计，最后还得给应用写个前端界面。这些工作每个单独做都不难，难的是每个应用都要重做一遍。我见过不少团队，做第一个原型花了三天，做第二个同类原型又花了三天，时间全耗在重复搭架子上。

Dify 的核心价值就是把这一层通用能力抽出来了。它是一个开源的大模型应用开发平台，用大白话说，就是把“提示词编排、上下文管理、知识库检索、工作流编排、Agent 工具调用、日志监控”这些能力做成了可视化模块。你不需要从零写会话管理逻辑，不用自己维护向量索引，直接在界面上配置一个聊天助手，挂上知识库，把模型接好，一个应用就跑起来了。打个不准确的比方：以前是每次想吃饭都得自己买菜、洗菜、开火，Dify 相当于提供了一个中央厨房，菜还是你做，但备菜和调味料不用每次都从头折腾。

我选它还有一个很现实的原因：开源且支持私有化部署。应用里的对话数据、知识库文档都放在自己服务器上，不会因为某个第三方平台的策略变化就突然用不了。这一点对很多把数据安全看得很重的场景来说，基本是一票决定项。

1.2 DeepSeek 作为模型底座的优势

模型底座我选了 DeepSeek，原因有三：第一是接口简单，它对外提供的是标准的对话补全接口，和目前主流模型 API 的调用方式一致，Dify 这类平台都能直接对接，不需要特殊适配；第二是中文效果和综合能力在同级别模型里非常能打，尤其在知识问答、文本整理、逻辑分析这些日常应用场景上，表现足够稳定；第三是成本优势明显，同样是跑一个知识库问答机器人，Token 消耗费用比很多同档模型低一大截，这对个人开发者和中小团队特别友好。

DeepSeek 实际使用时分两个模型：deepseek-chat和deepseek-reasoner。前者是通用对话模型，适合绝大多数日常场景，响应快、成本低；后者是推理增强模型，适合数学、逻辑推理、复杂问题拆解这类任务，但响应时间更长，费用也更高。我在 Dify 里通常默认用deepseek-chat，只有遇到需要深度推理的任务才临时切到deepseek-reasoner。

还有一点很省事：DeepSeek 是直接通过 API 提供服务的，不需要自己部署模型、不用买显卡。你只要拿到 API Key，把它填到 Dify 的模型供应商配置里，整个应用的模型能力就通了。后续如果觉得模型不合适，Dify 里可以随时切换，不一定非得绑死在某一款上。

1.3 组合的边界：适合什么，不适合什么

这套组合最适合的场景，我总结下来是这几类：企业内部知识库问答、客服辅助回复、文档内容整理与生成、日常工作流自动化、教学和快速原型验证。它的核心优势是开发速度快、维护成本低、模型切换灵活。比如我做过一个产品说明书问答机器人，从建知识库到上线 Web 应用，整个过程不到半小时，这在以前是难以想象的。

但它也有边界。如果你要做的应用需要深层定制模型推理逻辑，或者要完全绕过平台框架自己控制每一个环节，那 Dify 这种平台反而会碍手碍脚。另外，如果你的目标用户量非常大，对接口延迟和并发有极苛刻的要求，那么像 Dify 这种多功能平台会有一定的性能开销，你得单独评估架构。不过对于大多数中小型应用来说，这套组合的性能完全够用。先跑起来验证业务价值，等真到了瓶颈再谈定制，这是更务实的路径。

2. 从零部署：准备一台机器，把 Dify 跑起来

2.1 部署前要准备的事

Dify 本身是一套前后端加中间件的容器组合，官方推荐用容器编排方式部署。所以第一步不是装 Dify，而是准备环境和依赖。

机器方面，我的经验是：最低配置 2 核 CPU、4G 内存、40G 磁盘，能跑起来，但打开界面和上传文档时会明显感觉吃力。推荐 4 核 CPU、8G 内存、50G 以上磁盘，这个配置可以同时支撑 Dify 平台、向量数据库和几个并发对话的稳定运行。如果你手头只有一台配置一般的云主机，也不用急着升级，先跑通流程，再按实际负载扩容。

软件环境需要准备：一个 Linux 操作系统（我建议用常见的主流发行版），以及 Docker 和 Docker Compose 插件。Dify 的所有组件都通过镜像运行，宿主环境只需要把 Docker 装好即可。Windows 和 macOS 也能跑，但如果你用的是 Docker Desktop，文件挂载、端口映射和资源限制方面会遇到一些额外的坑，作为生产环境我还是推荐 Linux。

还有一点容易被忽略：Dify 默认占用 80 端口。如果你的机器上已经有其他 Web 服务占用了 80，部署前就得想好端口改到多少，不然后面启动一定会冲突。

2.2 实际部署流程

部署过程其实很短，核心几条命令就能完成，但有几个细节值得拎出来说。

先从官方仓库把代码拉到服务器上。如果网络条件一般，镜像拉取确实会耗费一些时间，耐心等待即可，这是整个部署过程中最耗时的一步。

git clone <Dify官方仓库地址> cd <仓库目录>/docker

进入 docker 目录后，第一步是复制环境变量模板。

cp .env.example .env

这个.env文件是 Dify 部署的集中配置入口，里面条目很多，但真正需要立刻改的只有几个：SECRET_KEY用于数据加密，建议用随机字符串生成器生成一串足够复杂的内容；数据库密码POSTGRES_PASSWORD等默认密码项，正式环境务必改掉；EXPOSE_NGINX_PORT定义外部访问端口，默认 80，如果 80 被占用就改成其他可用端口。

改完配置，直接启动：

docker compose up -d

第一次执行会拉取大量镜像，包括后端 API 服务、前端页面、数据库、缓存、向量数据库等组件，时间取决于服务器带宽，快则几分钟，慢则十几分钟。启动完成后看下容器状态：

docker compose ps

看到所有服务状态是 healthy 或 running 之后，打开浏览器访问http://服务器IP:端口，页面能正常加载就算部署成功。第一次访问会让你注册账号，第一个注册的账号会自动成为管理员，记得把账号信息保管好。

2.3 刚装完建议做的三件配置

部署成功只是开始，有三件小事我建议在正式使用前就做好。

第一，确认管理员账号权限。Dify 里管理员可以管理模型供应商、成员权限、系统设置。如果你是团队使用，建议管理员账号不要日常混用，给成员分配单独账号，按角色控制权限。

第二，备份策略。Dify 的数据都存在容器的数据卷里，包括用户、应用配置、知识库索引等。我的做法是定期对数据卷做备份，备份前先停掉相关容器，避免数据不一致。真出问题的时候，一份完整的卷备份能让你少熬好几个通宵。

第三，SSL 和域名。如果这个平台要面向公网正式使用，别裸用 IP 加端口，建议配一个域名并挂上 HTTPS 证书。这个可以不急着部署初期做，但应该在规划里。我自己吃过亏，应用上线了才发现页面加载和 API 调用因为证书问题在移动端频频报错，最后返工。

3. 把 DeepSeek 接进来：模型供应商配置

3.1 获取 API Key 的常规步骤

Dify 本身只是平台框架，不内置模型能力，所以部署好之后，第一件事就是把 DeepSeek 接进来。整个过程分两步：先在 DeepSeek 开放平台拿到 API Key，再回到 Dify 里把供应商配上。

在 DeepSeek 开放平台注册账号之后，进入控制台，创建一个新的 API Key，生成出来是一串以sk-开头的字符串。创建的时候要注意：有些平台只在创建时完整展示一次 Key，之后就无法再查看，只能重新生成。所以拿到 Key 立刻存到自己的密码管理工具里，别直接贴在聊天记录或代码仓库里，这个东西就相当于你账户的钱包钥匙。

按需充值这一步同样重要，API 是按 Token 用量扣费的，账户余额不足会直接导致调用失败。我的建议是先充一小笔钱，用测试应用跑几天，根据实际消耗估算成本，再决定后续预算。养成看用量详情的习惯，避免月底突然发现钱不够用。

拿到 Key 之后，建议先用一个最简单的请求在命令行里验证一下 Key 是否可用，再拿到 Dify 里去配。这样可以区分是“Key 的问题”还是“平台配置的问题”，排查起来省很多事。验证方式不需要复杂，直接向兼容对话接口发起一次最小请求，看到正常返回文本内容就说明 Key 没问题。

3.2 在 Dify 中添加 DeepSeek 供应商

进入 Dify 工作台，打开“设置”里的“模型供应商”页面，在供应商列表里找到 DeepSeek，点击添加，填入上面拿到的 API Key，保存。这时候 DeepSeek 会出现在“已添加的供应商”列表里，但注意，只是添加了供应商，还没有添加具体模型实例。

接下来要为 DeepSeek 添加模型。通常需要填写模型名称、模型类型和参数配置。模型名称最关键，要填对：deepseek-chat代表通用对话模型，deepseek-reasoner代表推理增强模型。模型类型选择对话（Chat）类型，不要选文本补全类型，DeepSeek 对外提供的是标准对话补全接口。

我用之前，几个关键参数会这样设置：

• 温度（temperature）：默认值即可，deepseek-reasoner对温度不敏感，官方也建议用默认；
• 最大 Token 输出：按应用需要设置，一般知识问答类应用不用拉太大；
• 上下文长度：保持默认支持范围，推理类模型上下文窗口较大，但实际使用时要留出给回复生成的余量。

两个模型的用途我用下来是这样划分的，简单整理了一个表：

3.3 别忘了配一个 Embedding 模型

这一步很多人第一次用会踩坑：DeepSeek 目前只提供大模型对话接口，不提供向量化（Embedding）接口。而 Dify 的知识库要工作，必须把文档切块后转成向量存到向量数据库里，所以你还得额外配置一个 Embedding 模型，否则知识库功能根本跑不起来。

如果你手头已经有其他可用的 Embedding API，直接填进 Dify 就行。如果没有，有几个常见方案：一是用 Dify 支持的某个向量化供应商，注册一个能用的 Key 填进去；二是在你自己的服务器上部署一个开源的中文 Embedding 模型，然后通过一个兼容对话接口格式的本地服务暴露出来，再在 Dify 里以自定义供应商的方式接入。第二种方案的好处是数据完全不出内网，适合对数据安全要求高的项目。

另外还有一类可选模型叫重排序（Rerank）模型。知识库检索时，先向量召回一批相关片段，再用重排序模型对结果做精修排序，可以明显提升回答质量。初期可以不用配，等发现检索结果不准时再加，加了之后通常有明显的效果提升。

配置完成之后，在模型供应商页面应该能看到三类模型的状态：对话模型有deepseek-chat或deepseek-reasoner，Embedding 模型可用，Rerank 模型可选。到这一步，平台的模型底座就算真正搭完了。

4. 从零实战：构建一个知识库问答助手

4.1 新建应用：类型和编排方式怎么选

模型配好了，就该做一个真实能用的应用了。最常见的入门实战项目就是知识库问答助手：你扔给它一批文档，它基于这些文档内容回答用户问题，不编造、不跑题。

在 Dify 工作台点击“创建应用”，会看到几个应用类型：聊天助手、文本生成、Agent、工作流等。第一次做建议选“聊天助手”，这是最贴合问答场景的模板。创建之后，进入编排页面，你会看到两种编排方式：基础编排和 Chatflow。

基础编排适合极简场景，就是一个单入口单出口的提示词编排，所有逻辑都写在一条提示词里。但我不建议第一次就直接用基础编排，推荐选 Chatflow。Chatflow 以可拖拽的节点流形式组织应用逻辑，每个环节都看得见摸得着：用户在开始节点输入问题，中间走知识检索、模型处理等节点，最后在结束节点输出答案。它的优势是后续扩展能力极强，想加条件分支、工具调用都很方便，而且排查问题的时候能看到每个节点的输入输出，非常直观。

4.2 搭建知识库：文档上传、分段、索引

知识库是问答助手的地基。回到工作台，进入“知识库”模块，创建一个新的数据集。

创建完成后，上传你的资料文档。Dify 支持常见文本格式，比如 PDF、Word、Markdown、TXT 等。这里有个实用建议：文档内容如果有大量表格、图片、复杂排版，解析后的效果可能不太理想，最好先转成干净的 Markdown 或纯文本再上传。我自己处理产品手册时，都会先做一轮格式整理，后续检索准确率高很多。

上传完成后进入分段设置。Dify 会把长文档按规则切成一个个片段，每个片段在检索时作为一个独立结果。两个关键参数：分段长度和分段重叠。默认分段长度是 500 Token，重叠是 50 Token。中文场景我会把分段长度调小一点，大概在 200 到 300 Token，因为中文信息密度高，切片太大会导致每个片段内混入多个主题，检索召回时容易答非所问。分段重叠的作用是防止关键内容刚好被切断，保留一点重叠是值得的。

接着选择索引方式：高质量索引会调用 Embedding 模型生成向量，检索更准确，但产生向量化费用；经济索引走关键词匹配，不花向量化费用，但中文场景下效果一般。我建议正式应用都选高质量索引，这也是前面为什么要配 Embedding 模型的原因。

配置完成保存后，数据集会进入索引处理状态，处理完成后状态变为可用，知识库就建好了。

4.3 Chatflow 编排：知识检索加 LLM

回到应用的编辑页面，在 Chatflow 画布上编排流程。第一次打开时应该已经默认生成了开始节点和结束节点，中间是空的，我们的任务是把检索和模型推理串起来。

开始节点里，默认有一个用户输入变量（通常是sys.query），这个就是用户发来的问题。你需要确认它存在，后面所有环节都靠它驱动。

添加一个“知识检索”节点。在节点配置里选择刚才建好的数据集，设置召回数量（TopK），默认是 3，初期可以保持默认。还有一个 Score 阈值，用于过滤相似度过低的片段。我的经验是阈值先不要设太高，比如先设 0.3 左右，等观察了实际检索效果再逐步调高，以免把一些有用的结果全过滤掉。

接着添加一个“LLM”节点。在这个节点里选择模型为deepseek-chat，然后把系统提示词写清楚。知识库问答的提示词有一个关键原则：必须强制模型只能基于检索内容回答。我常用的提示词模板是这样：

你是企业内部知识库助手。请严格根据“知识检索”节点提供的内容回答用户问题。 如果提供的资料里没有相关信息，明确回答“知识库中暂未找到相关内容”， 不要编造，不要使用你自己的常识补充。

注意：在 LLM 节点的提示词编辑框里，可以通过引用变量的方式把知识检索节点的输出“塞”进提示词。具体位置是在提示词编辑框找到上下文变量引用，把检索结果变量插入进去。这一步如果漏了，模型根本看不到知识库内容，后面的回答就会变成自由发挥。

最后把 LLM 节点的输出接到结束节点，结束节点的输出变量设为 LLM 节点的答案，一个完整的问答链路就通了。点右上角的“运行”按钮，输入一个问题测试，能看到整条链路的运行过程和最终答案。

4.4 发布：Web App 和 API 调用

应用编排调试通过之后，接下来是发布。Dify 支持把应用直接发布成一个 Web 应用，得到一个分享链接。你可以把这个链接发给同事、客户，也可以把它嵌入到公司内部系统的页面里。我实测下来，从发布到分享链接可用只要几秒钟，非常适合快速验证。

如果你的产品是一个独立系统，需要把问答能力集成进来，那就走 API 方式。在应用“访问 API”页面创建 API 密钥，然后调用对话接口。Python 调用示例大致长这样：

import requests api_key = "app-你的应用密钥" url = "http://你的Dify地址/chat-messages" headers = { "Authorization": f"Bearer {api_key}", "Content-Type": "application/json" } payload = { "inputs": {}, "query": "产品的保修期是多久？", "response_mode": "blocking", "conversation_id": "" } resp = requests.post(url, json=payload, headers=headers) print(resp.json())

这种方式返回的标准结构里包含回答内容、会话 ID、消息 ID。把会话 ID 存下来，用户下一次提问时传回来，就能保持多轮对话上下文。我迁移接入时，整个过程只改了几处参数和解析逻辑，接口兼容性做得相当省心。

5. 再进一步：用工作流编排做一个有逻辑的 Agent

5.1 工作流节点到底怎么理解

知识库问答助手解决的是“回答问题”这一件事，但真实业务往往需要更复杂的逻辑：先判断意图，再走不同分支，必要时调用外部工具。这就是工作流真正发挥作用的地方。

Dify 的工作流可以想象成一条流水线，每个节点就是一个工位。数据从开始节点流入，经过一个个工位加工，最后从结束节点输出。常用的节点有这些：

• LLM：调用大模型，负责推理、生成、分类等；
• 知识检索：从数据集检索相关内容；
• 条件分支：根据变量值走向不同分支；
• 代码执行：跑一段 Python 或 Node.js 代码，做数据加工；
• HTTP 请求：调用外部 API，把结果带回来给流程使用；
• 模板转换：把变量拼成一段新的文本；
• 变量赋值：把一个节点的结果赋值给新变量，供后续节点使用。

理解工作流最好的方式，是把它当成一张流程图来设计。先理顺业务逻辑，再画节点，最后再配置每个节点的参数。大部分新手的问题是反过来：先堆节点，再看那能不能跑通，结果节点一多，流程就乱了。

5.2 示例：一个带意图判断的智能客服流程

我做一个简单的示例来说明。假设我们要做一个智能客服机器人，它接收用户消息后，先判断用户属于“产品咨询”“售后问题”还是“闲聊”，然后分别处理：产品咨询走知识库检索后回答，售后问题给出售后话术并把记录写入外部系统，闲聊直接用模型自由回复。

流程设计是这样的： 开始节点接收用户输入，传给第一个 LLM 节点，这个 LLM 节点的任务是做意图分类，系统提示词要求它只输出一个分类标签，比如product、after_sale、chat。然后把输出结果传给条件分支节点，根据标签走三条路径。

产品咨询路径就是上一节的知识库问答链路：接知识检索节点，再接 LLM 节点，让模型基于检索结果回答。售后路径可以直接接一个 LLM 节点，输出售后处理标准话术，同时接一个 HTTP 请求节点，把用户问题写入售后工单系统的 API。闲聊路径就直接接一个 LLM 节点，自由对话。

这个流程做完，你实际上就拥有了一个带基础 Agent 能力的小应用：它能判断意图、调知识库、调外部系统，再汇总结果给用户。特别适合内部客服、售前助手这类场景。整个配置过程都是拖拽完成，不需要写后端代码。

5.3 调试技巧：从节点输入看到运行记录

工作流比单链路复杂，调试方法就更重要。我用下来的三条经验可以分享。

第一，善用画布的“运行预览”。每执行一次，每个节点都会记录自己的输入输出，点开任意节点就能看到这个环节到底收到了什么、输出了什么。问题出在哪个节点，基本一眼就能定位。比如知识检索节点明明有结果，但最终回答里没体现，问题通常出在 LLM 节点是否引用了检索结果变量上。

第二，善用应用日志。正式发布后，每个用户的交互都会产生运行记录，里面包含调用模型、Token 消耗、响应耗时等关键信息。遇到线上问题，我通常优先看日志而不是猜。日志也直接反映了每一轮对话花了多少钱，这对成本管理至关重要。

第三，调试时把变量名写规范。Chatflow 里变量一多，会分不清谁是谁。我的习惯是每个节点输出变量名都用语义化的名字，比如knowledge_results、intent_label、final_answer，宁可多敲几个字符，也不要全用node_1、node_2这种，不然调试到后期会非常痛苦。

6. 实战中的常见问题和避坑清单

6.1 部署相关：起不来、打不开、反复重启

部署阶段最常见的问题，就是容器起不来或者界面打不开。我的排查顺序固定是：先执行docker compose ps看容器状态，再看对应容器的日志，然后才是改配置重启。

端口占用是最容易碰到的问题。Dify 默认用 80 端口，只要机器上有其他 Web 服务，就会冲突。解决办法是修改.env里的EXPOSE_NGINX_PORT，改成比如 8080，然后重新执行docker compose up -d，让配置生效。改端口时要注意，改完之后访问地址要带上新端口号。

另一个高频问题是容器反复重启，多半是配置参数不对，比如密码强度不够、密钥格式不合法。这就要看容器日志定位，不要盲目重装。重装 Dify 很便宜，但重装后如果没备份数据，之前配的应用、知识库全部清零，那代价就大了。

6.2 模型调用相关：Key 无效、限流、超时

模型调用的问题更多是集中在接入阶段。配置 DeepSeek 之后，如果状态一直显示不可用，先检查 API Key 是不是复制完整了，有没有多空格、少字符。再检查模型名称是不是写对了，deepseek-chat和deepseek-reasoner这两个标识是敏感词，拼写错一个都连不上。

请求返回 401 或 403，基本都是认证问题，也就是 Key 本身失效或者没有写入正确。返回 429 则是触发限流，常见原因是同一时间并发请求太多，或者账户余额不足。这时候查看账户用量和余额比反复重试有意义得多。

还有一个容易被忽略的坑：deepseek-reasoner因为要做深度推理，响应耗时比deepseek-chat长不少。如果你在应用里设置了较短的超时时间，可能经常遇到“请求超时”的假故障。解决思路很直接：这类推理模型的超时时间放宽，或者默认都用deepseek-chat，只在确实需要推理的任务上切到 reasoner。

6.3 数据与检索相关：回答不准、引用不到

知识库问答效果不好，九成问题出在检索环节，而不是模型环节。如果模型回答看起来像“编的”，先检查知识检索节点返回了什么，很可能根本没召回相关片段。排查顺序是：数据集状态是否可用，Embedding 模型是否配置成功，分段大小是否合理，TopK 是否太低。

如果检索到了内容但模型不引用，那就是提示词的问题。提示词里必须清清楚楚写明“只能根据给定资料回答”，同时确认知识检索节点的输出真的被引用进了 LLM 节点的提示词变量里。这一步我在实战中反复踩过，最后总结成一个检查习惯：每次编排完，先点开 LLM 节点看看变量引用是否存在。

如果检索结果杂而乱，建议给知识库增加重排序模型，或者调低 Score 阈值、调大 TopK。中英文夹杂的场景下，Embedding 选择也会明显影响结果，选一个中文语料训练好的模型，准确率提升是肉眼可见的。

6.4 性能与成本：别等账单爆了才想起来看

平台跑起来很简单，但性能和成本需要持续关注。deepseek-reasoner虽然能力强，但 Token 消耗和响应时间都高于deepseek-chat。我的习惯是给每个应用在模型节点上明确选择默认模型，不让用户随意切到推理模型，路径上的每一步都在可控范围内。

知识库文档量级大了之后，向量数据库的存储占用和检索延迟都会上升。这时候要定期清理已经过期或重复的数据集，控制上传文档的总量。再就是关注 Embedding 调用量，批量上传文档时会产生大量向量化请求，这些都是真实费用。把上传高峰分散开，既能避免限流，也能让账单更平滑。

最后，定期看应用日志里的 Token 统计，了解每天的真实消耗。Dify 自带日志里能看到每轮对话的模型用量，这个数据是成本决策的第一手依据。我见过不少项目，功能做得挺好，最后死在了没有成本意识上，这其实是可以提前避免的。

这套组合我用了大半年，最大的体会是：把精力从“怎么接模型”转到“业务怎么做”上之后，产出效率完全不一样。现在团队同事提一个新需求，我基本当天就能把可交互的原型丢给他们试用，改完流程再上线，整个周期被压缩到了以前难以想象的长度。

最后再分享一个我个人的使用习惯：Dify 里建好的高质量提示词和成熟工作流，别散落在各个应用里，定期整理成团队内部的模板。新项目直接基于模板复制一份，改改数据集和参数就能用。这种复利效应，用半年之后感受会特别明显。如果你也刚开始搭这套组合，建议先从一个小范围的知识库问答入手，跑通之后再逐步加工作流和工具调用。这个路径是最平滑、也最能建立信心的走法。