企业官网建设流程全解析

Dify 应用上架门户:分享页每次回答都挂着内部流程节点?一个字段关掉

基于 Dify 1.16.x 实测(2026-08)。

1. 业务场景

把 Dify 应用做成对外 demo,是交付环节的常规动作:做一个 AI 应用,打开「分享」开关,拿到一个链接,发给客户体验,或者嵌进自己的官网门户。

我们上架了三个应用做门户 demo:一个企业 AI 助理、一个故障诊断助手、一个验收工具。每个都打开了分享链接,放在官网首页的产品卡片里,客户点进去就能试。

2. 场景痛点

客户 demo 的时候,有人提了一个问题:「为什么每次回答,下面都挂着一段『工作流过程』?」

我们一看——分享页里,每次回答的下方都显示:

Workflow Process 开始 意图分类 检索产品服务知识库 知识问答生成 回复知识问答

对开发者来说,这是「工作流过程展示」,挺酷的功能。但对客户来说,这段东西的问题很大:

• 暴露内部结构:应用内部有哪些节点、路由怎么走、叫什么名字,全部摊开给客户看
• 像半成品:客户看到的是「开始→分类→检索→生成」这种内部流水线,而不是一个干净的产品
• 专业感受损:成熟产品的对话界面,不会在回答下面挂一段内部执行过程

更要命的是:这不是个别应用的问题——三个应用全部中招。我们当时一度以为是哪个应用配置错了,逐个排查才发现,这是一个平台默认值的坑。

3. 方案:一个字段的事

查 Dify 源码后定位:分享页展示工作流过程,由一个字段控制——show_workflow_steps(是否展示工作流详情)。而这个字段在数据库里的默认值是 true。

也就是说:只要是通过 API 导入创建的应用,site(分享页)配置里没有显式写这个字段,分享页就会默认展示内部工作流过程。UI 上创建的应用可能会走 UI 默认(关闭),但 API 导入的不会自动带这个字段——默认开启,裸奔展示。

修复方法很简单:把分享页配置里的show_workflow_steps显式设为 false。

4. 整体架构:分享页配置链路

关键点:字段没写 = 用数据库默认值 = true。不是「没配置就关闭」,而是「没配置就开启」——这正是它坑的地方。

5. 关键配置

5.1 关闭分享页工作流过程展示

调用 Dify Console API 更新应用的 site 配置:

# 读取当前 site 配置(GET /apps/{app_id} 的 site 字段)# show_workflow_steps 当前值:true# 更新 site 配置:关闭工作流过程展示POST /console/api/apps/{app_id}/site Content-Type: application/json{"show_workflow_steps":false}

注意:site 配置更新端点接受POST方法(GET/PUT 会返回 405),请求体只需要带要改的字段。

5.2 修改后必须回读验证

改完一定要回读确认,不能只看请求返回 200:

GET /console/api/apps/{app_id}# 响应 site.show_workflow_steps 应变为 false

我们三个应用逐个改、逐个回读,全部从 true 变为 false。

6. 运行验证

修复后,三个应用(企业 AI 助理 / 故障诊断助手 / 静态验收中心)的分享页全部不再展示工作流过程:

• 回答区域干净了,只显示对话内容和回答
• 客户 demo 时不再看到内部节点名
• 对话功能本身不受影响——只是隐藏了过程展示

7. 实战坑表

8. 总结与适用边界

核心结论:API 导入的 Dify 应用,上架分享页前必须显式设置show_workflow_steps: false——这个字段的默认值是 true,不写就是展示内部工作流过程。对外 demo 的每一处细节都代表产品完成度,内部节点名出现在客户面前,和代码注释没删干净是一个性质的问题。

不适用/需注意:

• 如果是内部团队使用的应用,展示工作流过程反而是调试友好功能,不用关
• 这个开关只影响分享页展示,不影响应用本身的功能与数据

💬讨论区:你还遇到过哪些「API 导入应用」和「UI 创建应用」行为不一致的坑?比如默认值、字段缺失、导入后配置丢失——评论区交流一下。

如果这篇对你有帮助,点赞 + 收藏 + 关注,后续会继续更新 Dify 应用交付中的真实坑。

本文基于真实项目交付经验撰写(Dify 1.16.x 环境)。文中数据均来自我们自己的实测记录(三个应用的 site 配置核对、修改与回读验证),不构成任何平台的官方结论。