企业官网建设流程全解析

2. 开箱之后，先别急着聊天

Dify 装好之后，浏览器打开地址，第一步不是急着建应用，而是要先走一遍初始化向导。这一步很多人觉得无所谓，随手就跳过了，实际上它对整个平台后续的使用体验影响很大。

初始化主要做三件事：

• 设置管理员账号（就是平台最高权限的超级管理员）
• 确认平台访问地址（API 回调地址和 Web 端地址）
• 初始化数据库和模型供应商配置入口（让 Dify 能够和你选的模型“对话”）

我见过有些朋友上来就乱填，结果后面改管理员邮箱都费劲，更别提 API 地址填错导致 Web 应用无法访问的问题。所以这一篇咱们把初始化这一步拆开揉碎，把里边的逻辑讲明白。

提示：Dify 初始化完成后，控制台会强制要求你配置一个模型供应商，否则你连第一个应用都没法跑起来。这不是产品设计给你添堵，而是因为后边所有对话、生成、检索，全得靠模型来“干活”。

2. 初始化向导，每一步都不是白设计的

2.1 设置管理员账号，相当于给平台配“钥匙”

首次访问 Dify 地址，会看到一个初始化引导页，第一步就是设置管理员账号。这里需要填邮箱、用户名、密码。

很多人在这一步会用默认的管理员邮箱，我建议你用自己的真实常用邮箱。原因很直白：Dify 的密码找回、日常维护通知、后续团队协作的角色管理，都跟这个邮箱绑定。设完以后不能立刻改，改起来要动数据库，特别麻烦。

密码这块也别偷懒，至少 12 位，混合大小写和符号。Dify 的管理员账号能看控制台全局配置，一旦泄露，等于把平台拱手让人。

注意：管理员账号只有一个 SAAS 化入口之外，自托管部署的 Dify，后续所有租户/团队成员的创建，都要靠管理员来操作。所以请把这一步当成“开保险箱”来对待。

2.2 平台访问地址，你填的是给“别人”看的地址

初始化第二步是设置平台访问地址。这里分两个：

• Web 界面地址：你平时登录 Dify 控制台用的地址
• API 访问地址：外部请求调用 Dify API 的地址

如果只是本地玩，填http://localhost就行。但要部署在云服务器上，这里必须填服务器的公网 IP 或域名，并且带上端口（如果是非 80 端口）。

举个实际案例。有朋友把服务部署到某云服务器，用了 Docker 启动，Dify 跑在 8080 端口。初始化时他直接填了http://localhost:8080，本地访问控制台没问题，可一旦要用 API 或接入企业微信、钉钉这类外部工具，回调地址就全失效了。最后他只能重新初始化 Dify，费了半天劲。

所以正确的做法是，初始化时直接填你对外最终要用的域名或公网地址：

http://your-server-ip:8080 # 如果有域名并做了反向代理，建议直接填： https://your-domain.com

个人经验：域名能配上就尽量配，哪怕用一个临时子域名。因为很多第三方平台集成（如飞书、钉钉）强制要求 HTTPS，而且 Dify 的 Web App 分享链接对用户来说也更友好。

2.3 初始化后的数据库验证（可选但建议做）

初始化完成后，Dify 会自动建表、迁移数据。如果用的是 Docker Compose 一键部署，通常不需要手动介入。但如果你用的是外部 PostgreSQL，建议确认一下数据是否正常写入。

docker exec -it docker-db-1 psql -U postgres -d dify # 查看主要表： \dt # 检查用户表： SELECT * FROM users LIMIT 1;

看到 admin 用户记录存在，基本说明初始化成功。这一步虽说不做也不影响日常使用，但排查问题的时候，能帮你快速确认是数据库的问题还是应用的问题。

3. 模型供应商配置，把“变速箱”接到“发动机”上

初始化完成后，控制台会引导你进入“设置”-->“模型供应商”。这里是 Dify 的灵魂所在——你后边做的每一个聊天应用、Agent、知识库问答，都要从这里选模型。

我把模型供应商理解成一个“适配层”：Dify 本身不生产模型，它只负责对接各家模型提供商的 API，让你可以在同一个界面里调用不同厂商的模型。

3.1 模型供应商到底支持哪几家？先弄清主流选择

Dify 支持的主流入门供应商包括（配置路径：右上角头像 --> 设置 --> 模型供应商）：

如果你是新手上路，我建议先用 OpenAI 或者国内服务商的模型跑通全流程，等 Dify 的编排逻辑熟悉了，再切换到更复杂的供应商。

3.2 详细配置步骤：以 OpenAI 为例

在模型供应商页面，找到 OpenAI，点击“添加”，弹出表单：

• API Key：填你自己的 Key（形如sk-xxx）。注意不是 ChatGPT 的登录密码，是 API 密钥。
• API Base URL：默认是https://api.openai.com/v1。如果你用了代理或中转服务，这里可以改成你的地址。
• 模型列表：Dify 会拉取该 Key 有权限的模型列表，你可以手动添加一个模型，比如gpt-4o、gpt-4o-mini。填入模型名称时注意不要拼错。

填完之后，点“保存”。系统会自动做一个模型可用性测试，如果 Key 无效或者网络不通，会直接报错。

# 一个典型的 Open AI 配置示意 name: OpenAI api_key: sk-xxxxxxxxxxxxx base_url: https://api.openai.com/v1 models: - name: gpt-4o-mini type: text - name: gpt-4o type: text

保存之后，还需要在“模型设置”里把默认模型指定好。比如让 Dify 的默认对话模型用gpt-4o-mini，即可享受低成本高响应的体验。

实操心得：不要把所有模型都配上去，配置太多会导致应用切换模型时选择困难，而且不同模型价格差异很大，一不小心某个月账单会飚得离谱。我一般只保留 2~3 个核心模型，分别对应低成本/高响应、高质量/高成本的场景。

3.3 国内大模型的配置，与 OpenAI 没有本质区别

国内厂商的接入大同小异，无非是填 Key 和 Endpoint。

以接入某国产大模型为例，配置界面里直接选择对应供应商，填入 API Key 后，模型列表会自动加载。Dify 已经原生支持国内主流模型服务商，而且国内 API 走的是国内网络，访问速度和稳定性反而更好。

有一点要特别注意：国内云厂商的 API Key 通常在控制台生成，有的需要先在那边“开通服务”，否则 Dify 里配置会报Invalid API Key。别问我怎么知道的，踩过坑的人都会心一笑。

3.4 本地模型与私有化部署，企业场景的进阶玩法

如果你是企业场景，或者数据必须留在本地，Dify 也支持接入本地部署的开源模型（比如通过 Ollama 或 Xinference 跑起来的本地模型）。

配置路径同样是模型供应商页面，选择 Ollama 或兼容 OpenAI 协议的本地服务。这里有两个关键点：

• 本地服务地址必须是 Dify 容器能访问到的地址，不是localhost
• 如果 Dify 和 Ollama 不在同一台机器，需要在 Ollama 设置里把监听地址改为0.0.0.0

# 启动 Ollama 并允许局域网访问 ollama serve # 修改环境变量 OLLAMA_HOST=0.0.0.0

这样 Dify 就能通过http://192.168.1.100:11434访问到本地模型了。

4. 配置完成后的系统验证，别急着建应用

模型供应商配置好之后，Dify 会显示“已用”或者“可用”状态。但我建议你先做两件事再往下走。

4.1 用调试对话测试一把

在任意应用创建界面的“调试”区域，选择刚配好的模型，发一句话。比如：

你好，介绍一下你自己。

如果模型正常返回，说明模型链路完全打通。如果报错，依次排查：

• API Key 是否错误（大部分情况是漏字符或者复制多了空格）
• 网络是否能访问模型服务商
• 余额是否充足
• 模型名称是否在当前 Key 权限范围内

4.2 把默认模型设好，避免应用创建时来回选

在“设置”->“模型供应商”->“默认模型”里，可以选择：

• 系统默认推理模型
• 系统默认 Embedding 模型
• 系统默认重排序模型

这里尤其要注意Embedding 模型。创建知识库的时候，Dify 会调用 Embedding 模型把文本转成向量。如果这个模型没配好，知识库创建和检索都会挂掉。

很多时候你对话正常，但一上传文档到知识库就报错，大概率是 Embedding 模型没配置或者 Key 权限不足。

我的建议是：

默认推理模型：gpt-4o-mini 或对应厂商最便宜的对话模型 默认 Embedding 模型：选择供应商支持的 embedding 模型（如 text-embedding-3-small） 重排序模型：如果只是入门，可以先不配，后续做 RAG 检索精度优化再配置

5. 常见问题与排查技巧实录

写几个我实际遇到过的，也是社区里问得最多的。

5.1 模型供应商显示“鉴权失败”或“模型不可用”

先检查 Key 是否复制完整。有些 Key 比较长，复制的时候容易漏中间一段。另外确认模型名是否完全匹配（大小写敏感）。遇到这种事，直接把 Key 重新复制一遍，删除重新添加，能解决一半以上的问题。

如果还不行，看一下 Dify 的运行日志：

docker logs docker-api-1 --tail 100

日志里有时候会明确告诉你 HTTP 状态码，比如 401 就是鉴权失败，429 就是限流，500 是服务端问题。

5.2 应用创建后对话无响应，但模型供应商状态正常

这个大概率是应用里的“模型”没选。建应用时，Dify 会让你选一个模型，默认可能为空。在应用编排界面右上角，把模型选择为已配置的模型即可。

5.3 Embedding 模型报错：知识库上传文档后一直处理中

症结基本都在 Embedding 模型。打开模型供应商页面，确认你选的 Embedding 模型是真正的 Embedding 类型，不能拿对话模型顶替。然后测试一下该模型的可用性。有些 Embedding 模型有并发限制，或者单次输入长度有限，传超大文档也可能失败。

5.4 想换一个厂商的模型，怎么平滑迁移

在“设置”->“模型供应商”里新增供应商，然后把应用的默认模型切换过去。Dify 的历史会话会保留，不会因为切换供应商就清空。不过知识库的向量索引是依赖 Embedding 模型生成的，如果换了不同的 Embedding 模型，原来的向量和新向量不能混用，需要重新索引。这点切记。

6. 最后一步，把系统“喂饱”：预置模型与权限管理

配置完模型供应商只是开始。要想让 Dify 真正成为生产环境可用的工具，还有几个模型层面的前置动作值得做。

6.1 预置模型和自定义模型的选择

在某大模型服务商接入时，Dify 会默认拉取它的模型列表。这时你可能会纠结，到底选预置模型还是自定义模型。

• 预置模型：Dify 帮你测试过、内置了调用参数配置，直接选就能用。优点是无脑、快捷。
• 自定义模型：你自己手动填模型名称、上下文长度、Token 限制等参数。灵活，但可能出现配置不对导致调用失败。

新手建议先挑预置模型。等你熟悉了 Dify 的模型调用机制，再手动配置自定义模型也不迟。

6.2 团队权限与模型可见性

自托管 Dify 支持创建成员并分配角色。在“成员管理”里，你可以控制谁有权访问模型供应商配置。这不仅是安全需求，也是成本控制需求——要知道，一个成员如果手滑选了最贵的模型去跑批量任务，那一晚账单蹭蹭往上涨。

建议把“模型供应商管理”权限只给管理员角色，普通成员只能使用应用，不能改模型配置。

6.3 成本观测，别让模型消耗失控

Dify 的控制台目前没有特别精细的按模型成本报表，但你可以通过模型服务商后台去看每日请求量和 Token 消耗。我给自己的团队定了一个习惯：

• 开发联调阶段，统一用最便宜的轻量模型
• 上线前再按场景切换到高精度模型，并做一轮充分的测试
• 定期检查有没有“僵尸应用”在疯狂调 API

这一条可能不是那么“技术”，但越到后期，你会发现越重要。

7. 写在最后：初始化与模型配置决定应用的上限

Dify 初始化与模型供应商配置，搞懂的人觉得简单，没搞懂的人会觉得处处都是坑。实际上整个流程就是三件事：把管理员钥匙拿好、告诉平台自己的地址、把模型引擎接上。只要这三件事顺了，后边搭建应用、编排工作流、做知识库，都会顺畅很多。

按我自己的习惯，配置完一个新的 Dify 实例后，我会拿一个只有一句话的简单应用跑通全链路：创建应用 -> 选模型 -> 对话调试 -> 发布为 Web App -> 用手机访问测试。这个流程走下来，基础配置基本就不会有大问题了。

下一篇如果没有意外的话，我会继续聊 Dify 应用创建与对话流编排的细节，包括提示词写法、上下文变量处理，以及怎么让 Agent 真正“聪明”起来。希望这轮儿入门系列对正在折腾 Dify 的你有点用。