Dify 跑不通时先按分层定位问题很多 Dify 部署不是「模型不行」而是某一层没有跑通。Dify 页面打不开、模型一直 pending、知识库上传了却搜不到、工作流导入成功但运行报错、HTTP 节点显示接口通了但业务不可用这些问题如果混在一起改很容易越改越乱。比较稳的做法是先定层再改配置。本文把常见 Dify 排错拆成 6 层。你可以按层检查每一层都有先查什么、过关标准是什么、典型现象对应哪里。1. 这篇文章解决什么适合你如果你正在经历下面任一情况docker compose up后 Dify 页面打不开或一直 502Dify 控制台能进但模型调用报错或者一直 pending文档已上传问答却「没找到」或者一本正经胡说DSL/YAML 导入成功一点运行就红HTTP 节点、Webhook、业务系统接口显示通了但实际不好用不适合你的情况只想复制一套「万能提示词」不看日志不接受改配置希望靠反复重启碰运气排错的本质是证据不是运气。2. 先看分层不要一上来就改提示词下面这张分层图可以作为排错顺序Layer5 业务系统层Webhook、HTTP 节点、回写、权限、字段映射 Layer4 编排层DSL/YAML、变量、节点顺序、条件分支 Layer3 知识库层文档、切片、索引、检索、引用约束 Layer2 模型层模型服务、API Key、Base URL、模型名、上下文 Layer1 Dify 应用层Web 控制台、工作流运行、任务队列、日志 Layer0 环境层Docker、网络、端口、存储、容器健康排查时建议从下往上如果环境没跑通先查 Docker、端口、网络和容器健康。如果 Dify 页面能打开但控制台异常继续查 Dify 日志、任务队列和运行状态。如果 Dify 控制台正常但模型调用失败继续查模型配置、Key、Base URL 和模型名。如果模型正常但知识库没效果继续查切片、索引、检索结果和回答约束。如果知识库正常但工作流运行失败继续查变量、节点、条件和导入配置。如果工作流正常但业务不可用继续查 HTTP、Webhook、字段映射、权限和回写。不要在 Layer0 没过关时改 Layer4也不要在 Layer3 没检索到片段时优化提示词。3. Layer0环境层先确认服务真的活着环境层主要看 Docker、网络、端口、磁盘、容器健康状态。常见现象现象先查再查页面打不开容器是否启动、端口是否映射正确防火墙、反向代理、域名解析页面 502后端服务是否健康网关配置、服务名、容器网络容器反复重启容器日志里的启动错误环境变量、挂载路径、权限上传文件失败存储目录是否可写磁盘空间、对象存储配置服务时好时坏CPU/内存/磁盘是否打满队列堆积、模型服务超时建议检查顺序看容器是否全部启动。看端口是否被正确监听。看容器日志是否有明确错误。看挂载目录是否存在、是否可写。看网络访问是否能从 Dify 容器打到模型容器或外部 API。过关标准页面入口可以稳定打开。关键容器不反复重启。日志里没有持续刷新的启动错误。Dify 能访问数据库、缓存、模型服务或外部 API。文件上传、临时目录、持久化目录没有权限错误。如果环境层没过关先不要改模型名、提示词或工作流。页面打不开、容器起不来逐步搭一套能验证的本地环境见从 Docker Compose 起步先搭可验证本地环境。4. Layer1Dify 应用层确认控制台和任务运行正常这一层主要看 Dify Web 控制台、运行日志、任务队列、权限和应用自身配置。很多时候 Dify 页面能打开并不代表它已经可用。比如控制台能进但运行工作流一直 pending或者创建知识库成功但后台任务没有真正完成。常见现象现象先查再查控制台能进但运行一直 pending队列服务、worker 是否启动后台任务日志、数据库连接页面操作后没有反应浏览器控制台、后端日志前后端 API 是否一致登录后权限异常用户角色、空间权限Token、会话、组织配置工作流列表加载慢数据库查询和任务队列网络代理、接口超时某些功能按钮不可用功能开关、版本差异浏览器缓存、前端构建版本建议检查顺序打开控制台确认基础页面可访问。创建一个最小测试任务看能否运行完成。查看 Dify 日志确认请求是否到达后端。查看 worker 或任务队列日志确认后台任务是否消费。检查权限、空间、组织、用户角色是否匹配。过关标准控制台能稳定打开。最小任务能从开始运行到结束。Dify 日志能看到请求进入和返回。后台任务不长期堆积。用户权限足以创建、运行、查看结果。如果 Dify 应用层没有跑通先不要把问题归因到模型或知识库。5. Layer2模型层确认模型能被正确调用模型层主要看 API Key、Base URL、模型名、上下文长度、流式输出、网络代理和限流。常见误区是模型配置界面里填了内容就以为模型通了。真正要看的是一次最小调用能不能成功返回。常见现象现象先查再查模型调用报 401/403API Key 是否正确、是否有权限账号额度、组织权限、模型授权模型调用报 404模型名是否写对Base URL 是否指向正确服务模型一直 pending模型服务是否可达网络代理、超时、队列拥堵回答突然中断上下文是否超长流式输出、网关超时同一提示词有时成功有时失败限流、并发、额度模型服务负载、重试策略建议检查顺序用最小 prompt 测一次模型调用例如只问「请回复 OK」。确认 Base URL 指向的是正确模型服务而不是前端页面地址。确认模型名与服务端暴露的模型名完全一致。确认 API Key 有当前模型的调用权限。确认 Dify 到模型服务之间的网络可达。如果使用代理或适配器单独测试代理或适配器能否返回模型列表和回答。过关标准最小 prompt 能稳定返回。错误日志里没有 401、403、404、连接超时。模型名、Base URL、Key 三者明确对应。长文本输入时有明确上下文限制或截断策略。并发调用不会全部 pending。如果模型层没过关先不要调知识库和工作流因为上层一定会跟着失败。模型一直 pending、超时或私有模型接不上见调本地 Ollama 慢或超时、将私有 LLM 模型接入 Dify。6. Layer3知识库「上传了却没用」知识库问题要拆成两种不要混着改现象先查再查检索测试就没有片段切片、索引是否完成、文档是否为空、分段是否过碎或过长检索关键词是否与文档用语一致有片段但回答像编的回答提示词是否允许「推断」是否要求「无依据就明确说不知道」和人工复核表建议固定三步可以写进团队 SOP用知识库自带的检索测试确认「问句 → 片段」是否成立。用同一批「高频 / 边界 / 风险」问题做回归表。如果是企业制度、合同、合规、风控场景宁可拒答不要漂亮的幻觉。检查顺序先看文档是否上传成功。再看索引是否完成。再看切片是否合理。再看检索测试是否能命中片段。再看回答阶段是否严格基于片段。最后再改提示词和召回参数。过关标准知识库检索测试可以命中目标片段。高频问题能稳定召回相关内容。边界问题不会强行编答案。风险问题能明确提示无依据或需要人工确认。回答能追溯到检索片段而不是只看起来合理。文档上传了却搜不到、有片段却在编、回答跑偏分别见上传文档却搜不到答案、答得像真的但没依据、回答总是跑偏先查分段召回。7. Layer4编排层确认 DSL/YAML 和变量链路没断编排层主要看工作流、节点、变量、条件分支、输入输出映射、DSL/YAML 导入结果。很多工作流导入成功不代表它能运行。导入只说明结构大致能被系统接受运行时还要看变量是否存在、节点输出是否匹配、条件是否能走到正确分支。常见现象现象先查再查DSL/YAML 导入成功运行就红报错节点和变量引用节点版本、字段类型、必填参数某个节点拿不到上游结果上游输出变量名节点顺序、分支路径条件分支总走错条件字段值和类型空值、数组、字符串比较工作流跑完但结果为空最后一层输出映射中间节点是否被跳过本地测试通生产不通环境变量和凭证模型、知识库、HTTP 地址差异建议检查顺序先定位第一个报错节点不要从最后一个现象倒推。查看这个节点依赖哪些上游变量。确认上游节点实际输出里有没有这些变量。确认字段类型是否一致例如字符串、数组、对象、数字不要混用。检查条件分支是否覆盖空值和异常值。检查最终输出是否把中间结果正确暴露给用户或下游系统。过关标准工作流能用最小输入跑完。每个关键节点都能看到明确输入和输出。条件分支能覆盖正常、空值、异常三类情况。导入环境和运行环境的变量一致。失败时能定位到具体节点而不是只看到「运行失败」。如果编排层没过关先不要改业务系统接口。因为接口可能是通的只是传过去的值不对。导入成功却跑不起来、条件分支走错、工作流跑一半失败见导入后跑不起来、条件分支走错、Workflow 跑一半就失败。8. Layer5业务系统层确认接口通不等于业务通业务系统层主要看 HTTP 节点、Webhook、字段映射、权限、回写、幂等、超时和错误处理。「接口通了」只说明网络请求可能成功不代表业务真的完成。业务系统经常会出现 200 返回但字段没写进去或者测试账号可用生产账号没有权限。常见现象现象先查再查HTTP 节点返回 200但业务没变化请求体字段映射业务系统返回内容是否表示成功Webhook 能收到但流程没继续入参格式签名、Token、事件类型回写失败字段 ID、字段类型、必填项权限、记录状态、锁定规则测试环境通生产环境失败地址、凭证、权限白名单、SSL、代理重试后产生重复数据幂等键去重逻辑、业务唯一字段建议检查顺序先确认 HTTP 请求是否真的发出。再确认请求地址、方法、Header、Body 是否符合接口要求。再确认业务系统返回内容是否表示业务成功而不是只看 HTTP 状态码。再确认字段映射是否使用真实字段 ID 或接口字段名。再确认账号权限是否能读、写、更新目标数据。最后检查重试、超时、幂等和异常分支。过关标准请求日志里能看到完整入参和返回。业务系统里能看到实际数据变化。成功和失败都有明确判断条件。字段类型匹配必填项不缺。重试不会制造重复记录。权限不足时能明确报错而不是静默失败。如果业务系统层没过关优先查字段和权限不要先怀疑模型回答质量。HTTP 调不通、接口通了业务仍不好用、要回写到业务系统见HTTP 节点调不通、API 通了系统仍不好用、Dify 给第三方当 AI 后端。按业务场景找入口工单、回访、采购见Dify 工作流场景目录。9. 常见现象对照表现象优先判断层第一件事页面打不开Layer0 环境层查容器、端口、反向代理页面 502Layer0 环境层查后端服务健康状态Dify 控制台能进但任务一直 pendingLayer1 Dify 应用层查 worker、队列、后台日志模型调用 401/403Layer2 模型层查 Key、权限、额度模型调用 404Layer2 模型层查模型名和 Base URL文档上传了但搜不到Layer3 知识库层查索引、切片、检索测试有片段但回答乱编Layer3 知识库层查回答约束和无依据拒答DSL/YAML 导入成功但运行失败Layer4 编排层查第一个报错节点和变量条件分支总走错Layer4 编排层查字段类型、空值、数组HTTP 返回 200 但业务没变化Layer5 业务系统层查业务返回体和字段映射回写失败Layer5 业务系统层查字段 ID、字段类型、权限测试通生产不通Layer5 业务系统层查生产地址、凭证、白名单10. 10 分钟验收清单如果你只是想快速判断系统现在能不能用可以按这份清单走一遍。第 1 分钟看环境容器是否全部启动页面入口是否能打开日志是否有持续启动错误第 2 分钟看 Dify控制台是否能进入最小任务是否能运行后台任务是否长期 pending第 3 分钟看模型用最小 prompt 测试模型是否返回Base URL、模型名、API Key 是否对应是否有 401、403、404、超时第 4 分钟看知识库文档是否完成索引检索测试是否命中片段高频问题是否能召回相关内容第 5 分钟看回答约束是否允许模型无依据推断是否要求无依据时明确说不知道风险类问题是否进入人工复核第 6 分钟看工作流最小输入是否能跑完第一个失败节点是谁上游输出和下游输入是否匹配第 7 分钟看变量变量名是否写对字段类型是否一致空值、数组、对象是否被正确处理第 8 分钟看业务接口HTTP 请求是否实际发出返回体是否表示业务成功业务系统里是否真的产生变化第 9 分钟看回写字段 ID 是否真实字段类型是否匹配当前账号是否有写入权限第 10 分钟看可复现性同一个最小用例能否重复成功失败时是否能定位到层和节点是否保留了日志、入参、返回和截图10 分钟内不一定能修好所有问题但应该能判断问题在哪一层。如果 10 分钟后还说不清是哪一层说明检查顺序本身需要收敛。11. 最后先定层再改配置Dify 排错最怕两件事第一页面打不开时去改提示词。第二知识库没检索到片段时去怪模型。稳定的排查方式是如果页面打不开先查环境层。如果任务不运行先查 Dify 应用层。如果模型不返回先查模型层。如果文档没命中先查知识库层。如果工作流报错先查编排层。如果接口通了但业务没变化先查业务系统层。每一层都有自己的过关标准。只有下层过关了上层排错才有意义。你真正能带走的判断很简单先定层再改配置。
Dify 跑不通时，先按分层定位问题
Dify 跑不通时先按分层定位问题很多 Dify 部署不是「模型不行」而是某一层没有跑通。Dify 页面打不开、模型一直 pending、知识库上传了却搜不到、工作流导入成功但运行报错、HTTP 节点显示接口通了但业务不可用这些问题如果混在一起改很容易越改越乱。比较稳的做法是先定层再改配置。本文把常见 Dify 排错拆成 6 层。你可以按层检查每一层都有先查什么、过关标准是什么、典型现象对应哪里。1. 这篇文章解决什么适合你如果你正在经历下面任一情况docker compose up后 Dify 页面打不开或一直 502Dify 控制台能进但模型调用报错或者一直 pending文档已上传问答却「没找到」或者一本正经胡说DSL/YAML 导入成功一点运行就红HTTP 节点、Webhook、业务系统接口显示通了但实际不好用不适合你的情况只想复制一套「万能提示词」不看日志不接受改配置希望靠反复重启碰运气排错的本质是证据不是运气。2. 先看分层不要一上来就改提示词下面这张分层图可以作为排错顺序Layer5 业务系统层Webhook、HTTP 节点、回写、权限、字段映射 Layer4 编排层DSL/YAML、变量、节点顺序、条件分支 Layer3 知识库层文档、切片、索引、检索、引用约束 Layer2 模型层模型服务、API Key、Base URL、模型名、上下文 Layer1 Dify 应用层Web 控制台、工作流运行、任务队列、日志 Layer0 环境层Docker、网络、端口、存储、容器健康排查时建议从下往上如果环境没跑通先查 Docker、端口、网络和容器健康。如果 Dify 页面能打开但控制台异常继续查 Dify 日志、任务队列和运行状态。如果 Dify 控制台正常但模型调用失败继续查模型配置、Key、Base URL 和模型名。如果模型正常但知识库没效果继续查切片、索引、检索结果和回答约束。如果知识库正常但工作流运行失败继续查变量、节点、条件和导入配置。如果工作流正常但业务不可用继续查 HTTP、Webhook、字段映射、权限和回写。不要在 Layer0 没过关时改 Layer4也不要在 Layer3 没检索到片段时优化提示词。3. Layer0环境层先确认服务真的活着环境层主要看 Docker、网络、端口、磁盘、容器健康状态。常见现象现象先查再查页面打不开容器是否启动、端口是否映射正确防火墙、反向代理、域名解析页面 502后端服务是否健康网关配置、服务名、容器网络容器反复重启容器日志里的启动错误环境变量、挂载路径、权限上传文件失败存储目录是否可写磁盘空间、对象存储配置服务时好时坏CPU/内存/磁盘是否打满队列堆积、模型服务超时建议检查顺序看容器是否全部启动。看端口是否被正确监听。看容器日志是否有明确错误。看挂载目录是否存在、是否可写。看网络访问是否能从 Dify 容器打到模型容器或外部 API。过关标准页面入口可以稳定打开。关键容器不反复重启。日志里没有持续刷新的启动错误。Dify 能访问数据库、缓存、模型服务或外部 API。文件上传、临时目录、持久化目录没有权限错误。如果环境层没过关先不要改模型名、提示词或工作流。页面打不开、容器起不来逐步搭一套能验证的本地环境见从 Docker Compose 起步先搭可验证本地环境。4. Layer1Dify 应用层确认控制台和任务运行正常这一层主要看 Dify Web 控制台、运行日志、任务队列、权限和应用自身配置。很多时候 Dify 页面能打开并不代表它已经可用。比如控制台能进但运行工作流一直 pending或者创建知识库成功但后台任务没有真正完成。常见现象现象先查再查控制台能进但运行一直 pending队列服务、worker 是否启动后台任务日志、数据库连接页面操作后没有反应浏览器控制台、后端日志前后端 API 是否一致登录后权限异常用户角色、空间权限Token、会话、组织配置工作流列表加载慢数据库查询和任务队列网络代理、接口超时某些功能按钮不可用功能开关、版本差异浏览器缓存、前端构建版本建议检查顺序打开控制台确认基础页面可访问。创建一个最小测试任务看能否运行完成。查看 Dify 日志确认请求是否到达后端。查看 worker 或任务队列日志确认后台任务是否消费。检查权限、空间、组织、用户角色是否匹配。过关标准控制台能稳定打开。最小任务能从开始运行到结束。Dify 日志能看到请求进入和返回。后台任务不长期堆积。用户权限足以创建、运行、查看结果。如果 Dify 应用层没有跑通先不要把问题归因到模型或知识库。5. Layer2模型层确认模型能被正确调用模型层主要看 API Key、Base URL、模型名、上下文长度、流式输出、网络代理和限流。常见误区是模型配置界面里填了内容就以为模型通了。真正要看的是一次最小调用能不能成功返回。常见现象现象先查再查模型调用报 401/403API Key 是否正确、是否有权限账号额度、组织权限、模型授权模型调用报 404模型名是否写对Base URL 是否指向正确服务模型一直 pending模型服务是否可达网络代理、超时、队列拥堵回答突然中断上下文是否超长流式输出、网关超时同一提示词有时成功有时失败限流、并发、额度模型服务负载、重试策略建议检查顺序用最小 prompt 测一次模型调用例如只问「请回复 OK」。确认 Base URL 指向的是正确模型服务而不是前端页面地址。确认模型名与服务端暴露的模型名完全一致。确认 API Key 有当前模型的调用权限。确认 Dify 到模型服务之间的网络可达。如果使用代理或适配器单独测试代理或适配器能否返回模型列表和回答。过关标准最小 prompt 能稳定返回。错误日志里没有 401、403、404、连接超时。模型名、Base URL、Key 三者明确对应。长文本输入时有明确上下文限制或截断策略。并发调用不会全部 pending。如果模型层没过关先不要调知识库和工作流因为上层一定会跟着失败。模型一直 pending、超时或私有模型接不上见调本地 Ollama 慢或超时、将私有 LLM 模型接入 Dify。6. Layer3知识库「上传了却没用」知识库问题要拆成两种不要混着改现象先查再查检索测试就没有片段切片、索引是否完成、文档是否为空、分段是否过碎或过长检索关键词是否与文档用语一致有片段但回答像编的回答提示词是否允许「推断」是否要求「无依据就明确说不知道」和人工复核表建议固定三步可以写进团队 SOP用知识库自带的检索测试确认「问句 → 片段」是否成立。用同一批「高频 / 边界 / 风险」问题做回归表。如果是企业制度、合同、合规、风控场景宁可拒答不要漂亮的幻觉。检查顺序先看文档是否上传成功。再看索引是否完成。再看切片是否合理。再看检索测试是否能命中片段。再看回答阶段是否严格基于片段。最后再改提示词和召回参数。过关标准知识库检索测试可以命中目标片段。高频问题能稳定召回相关内容。边界问题不会强行编答案。风险问题能明确提示无依据或需要人工确认。回答能追溯到检索片段而不是只看起来合理。文档上传了却搜不到、有片段却在编、回答跑偏分别见上传文档却搜不到答案、答得像真的但没依据、回答总是跑偏先查分段召回。7. Layer4编排层确认 DSL/YAML 和变量链路没断编排层主要看工作流、节点、变量、条件分支、输入输出映射、DSL/YAML 导入结果。很多工作流导入成功不代表它能运行。导入只说明结构大致能被系统接受运行时还要看变量是否存在、节点输出是否匹配、条件是否能走到正确分支。常见现象现象先查再查DSL/YAML 导入成功运行就红报错节点和变量引用节点版本、字段类型、必填参数某个节点拿不到上游结果上游输出变量名节点顺序、分支路径条件分支总走错条件字段值和类型空值、数组、字符串比较工作流跑完但结果为空最后一层输出映射中间节点是否被跳过本地测试通生产不通环境变量和凭证模型、知识库、HTTP 地址差异建议检查顺序先定位第一个报错节点不要从最后一个现象倒推。查看这个节点依赖哪些上游变量。确认上游节点实际输出里有没有这些变量。确认字段类型是否一致例如字符串、数组、对象、数字不要混用。检查条件分支是否覆盖空值和异常值。检查最终输出是否把中间结果正确暴露给用户或下游系统。过关标准工作流能用最小输入跑完。每个关键节点都能看到明确输入和输出。条件分支能覆盖正常、空值、异常三类情况。导入环境和运行环境的变量一致。失败时能定位到具体节点而不是只看到「运行失败」。如果编排层没过关先不要改业务系统接口。因为接口可能是通的只是传过去的值不对。导入成功却跑不起来、条件分支走错、工作流跑一半失败见导入后跑不起来、条件分支走错、Workflow 跑一半就失败。8. Layer5业务系统层确认接口通不等于业务通业务系统层主要看 HTTP 节点、Webhook、字段映射、权限、回写、幂等、超时和错误处理。「接口通了」只说明网络请求可能成功不代表业务真的完成。业务系统经常会出现 200 返回但字段没写进去或者测试账号可用生产账号没有权限。常见现象现象先查再查HTTP 节点返回 200但业务没变化请求体字段映射业务系统返回内容是否表示成功Webhook 能收到但流程没继续入参格式签名、Token、事件类型回写失败字段 ID、字段类型、必填项权限、记录状态、锁定规则测试环境通生产环境失败地址、凭证、权限白名单、SSL、代理重试后产生重复数据幂等键去重逻辑、业务唯一字段建议检查顺序先确认 HTTP 请求是否真的发出。再确认请求地址、方法、Header、Body 是否符合接口要求。再确认业务系统返回内容是否表示业务成功而不是只看 HTTP 状态码。再确认字段映射是否使用真实字段 ID 或接口字段名。再确认账号权限是否能读、写、更新目标数据。最后检查重试、超时、幂等和异常分支。过关标准请求日志里能看到完整入参和返回。业务系统里能看到实际数据变化。成功和失败都有明确判断条件。字段类型匹配必填项不缺。重试不会制造重复记录。权限不足时能明确报错而不是静默失败。如果业务系统层没过关优先查字段和权限不要先怀疑模型回答质量。HTTP 调不通、接口通了业务仍不好用、要回写到业务系统见HTTP 节点调不通、API 通了系统仍不好用、Dify 给第三方当 AI 后端。按业务场景找入口工单、回访、采购见Dify 工作流场景目录。9. 常见现象对照表现象优先判断层第一件事页面打不开Layer0 环境层查容器、端口、反向代理页面 502Layer0 环境层查后端服务健康状态Dify 控制台能进但任务一直 pendingLayer1 Dify 应用层查 worker、队列、后台日志模型调用 401/403Layer2 模型层查 Key、权限、额度模型调用 404Layer2 模型层查模型名和 Base URL文档上传了但搜不到Layer3 知识库层查索引、切片、检索测试有片段但回答乱编Layer3 知识库层查回答约束和无依据拒答DSL/YAML 导入成功但运行失败Layer4 编排层查第一个报错节点和变量条件分支总走错Layer4 编排层查字段类型、空值、数组HTTP 返回 200 但业务没变化Layer5 业务系统层查业务返回体和字段映射回写失败Layer5 业务系统层查字段 ID、字段类型、权限测试通生产不通Layer5 业务系统层查生产地址、凭证、白名单10. 10 分钟验收清单如果你只是想快速判断系统现在能不能用可以按这份清单走一遍。第 1 分钟看环境容器是否全部启动页面入口是否能打开日志是否有持续启动错误第 2 分钟看 Dify控制台是否能进入最小任务是否能运行后台任务是否长期 pending第 3 分钟看模型用最小 prompt 测试模型是否返回Base URL、模型名、API Key 是否对应是否有 401、403、404、超时第 4 分钟看知识库文档是否完成索引检索测试是否命中片段高频问题是否能召回相关内容第 5 分钟看回答约束是否允许模型无依据推断是否要求无依据时明确说不知道风险类问题是否进入人工复核第 6 分钟看工作流最小输入是否能跑完第一个失败节点是谁上游输出和下游输入是否匹配第 7 分钟看变量变量名是否写对字段类型是否一致空值、数组、对象是否被正确处理第 8 分钟看业务接口HTTP 请求是否实际发出返回体是否表示业务成功业务系统里是否真的产生变化第 9 分钟看回写字段 ID 是否真实字段类型是否匹配当前账号是否有写入权限第 10 分钟看可复现性同一个最小用例能否重复成功失败时是否能定位到层和节点是否保留了日志、入参、返回和截图10 分钟内不一定能修好所有问题但应该能判断问题在哪一层。如果 10 分钟后还说不清是哪一层说明检查顺序本身需要收敛。11. 最后先定层再改配置Dify 排错最怕两件事第一页面打不开时去改提示词。第二知识库没检索到片段时去怪模型。稳定的排查方式是如果页面打不开先查环境层。如果任务不运行先查 Dify 应用层。如果模型不返回先查模型层。如果文档没命中先查知识库层。如果工作流报错先查编排层。如果接口通了但业务没变化先查业务系统层。每一层都有自己的过关标准。只有下层过关了上层排错才有意义。你真正能带走的判断很简单先定层再改配置。