企业官网建设流程全解析

1. 为什么我最终选了Dify，而不是直接调API

1.1 Dify在LLMOps链路中的位置

先说结论：如果你只是想跑通一个“调用大模型API返回结果”的Demo，那你确实不需要Dify，一个Python脚本就够了。但当你开始认真做一个要交付给业务方使用的AI应用时，你会发现事情远没有这么简单——Prompt怎么版本化管理？模型换了怎么平滑切换？知识库怎么灌数据？用户问了问题怎么追踪整个链路？多人协作时怎么保证大家改的是同一套配置？

这些问题都属于“LLMOps”的范畴，也就是大模型应用从开发到上线的全流程运维。Dify在这个链路里的定位非常明确：它是一个开源的、可视化的LLMOps平台，把模型管理、Prompt编排、知识库、Agent、工作流这几大块全部收拢到一个统一界面里。你不需要自己从零搭一套管理后台，也不用在代码里硬编码各种模型配置。

我自己的经历是，早期做过一个基于LangChain的客服问答系统，代码写到后面越来越痛苦：Prompt改了要发版，知识库更新要重跑脚本，日志散落在各个服务里，出了问题根本定位不到是哪一层出错。后来我把整个系统迁移到Dify上，最直观的感受是——大部分原来需要写代码的逻辑，现在通过拖拽节点就能完成，而且每一步的输入输出都有迹可循。

1.2 用Dify还是自己写代码：我的决策依据

我见过不少团队在“用现成平台”和“自己写框架”之间反复纠结，这里分享一个我实践下来的判断标准：

• 如果你的核心业务逻辑依赖高度定制化的前后端代码，且LLM只是其中一环——比如你做一个视频剪辑软件，AI只是其中一个字幕生成功能，那直接用API更合适。
• 如果你的应用本质上是“对话/内容生成为主”，且需要反复调Prompt、换模型、加知识——比如客服机器人、文档问答、内容审核助手、报告生成器，那Dify这类平台能帮你省掉大量体力活。
• 如果你担心平台锁定——Dify是开源项目，社区版可以本地部署，数据都在自己手里，这个问题基本不存在。

我自己最终的决策是：核心应用跑在Dify上，周边定制功能通过API网关调用Dify的服务化接口。这样既拿到了平台的可视化编排能力，又没有失去代码扩展的自由度，两者互补。

2. 部署与模型接入：先把“地基”打稳

2.1 Docker Compose部署：我踩过的三个坑

Dify官方推荐用Docker Compose方式部署，这也是最省心的路径。docker compose up -d拉起来之后，默认会启动API服务、Worker、Web前端、PostgreSQL、Redis、Nginx、Weaviate（或Qdrant）等一组容器。

第一个坑是端口冲突。默认配置里Nginx监听80和443端口，如果你的服务器上已经跑了别的Web服务，启动会直接失败。解决方案很简单，在.env文件里改端口映射，比如把80:80改成8080:80。

第二个坑是磁盘空间。向量数据库在索引大量文档时会占用不少空间，再加上容器镜像本身，建议至少预留30GB以上。我在一台只有20GB磁盘的测试机上跑过一次，索引到一半直接写满，整个知识库重建，非常肉疼。

第三个坑是WSL2的内存限制。如果你是在Windows上用Docker Desktop跑Dify，默认WSL2可能只分配了不到2GB内存。本地同时跑Ollama和Dify的多个容器，很容易OOM。建议在.wslconfig里把memory调到8GB以上，这个配置文件在C:\Users\<用户名>\.wslconfig。

2.2 Ollama还是vLLM：本地模型接入的两个档位

Dify的模型接入非常灵活，云端API（OpenAI格式、DeepSeek、Qwen、Claude等）和本地推理服务都支持。对于想跑本地模型的场景，主要选型是Ollama和vLLM这两个。

我的建议是：开发测试阶段无脑选Ollama，它能把模型管理这件事变得像装App一样简单。ollama pull qwen2.5:7b拉一个模型下来，然后在Dify的“设置→模型供应商→Ollama”里填上Base URL（默认http://localhost:11434）和模型名称，就能开始对话了。

等应用要真正上线、并发上来了，再考虑上vLLM。vLLM的一大优势是吞吐量，它通过PagedAttention机制把显存利用率拉满，普通显卡也能获得远高于Ollama的推理速度。不过代价是部署复杂度高不少，需要自己准备模型权重文件，可能还要处理Tokenizer的兼容问题。

2.3 云端API与本地模型如何选型

实际项目中，我不建议把所有任务都绑在同一个模型上。Dify支持在应用、工作流的每个LLM节点里单独指定模型供应商和模型名称，这是一个非常好的特性，意味着你可以做“模型路由”。

我自己的一个客服问答应用是这样分配的：

• 意图识别用本地Qwen2.5-7B，速度快，省成本，这类任务对推理能力要求不高；
• 正式答案生成用云端DeepSeek或Qwen-Max，质量稳定，能处理复杂指令；
• 知识库Embedding用BGE-M3这类专用向量模型，而不是用对话模型做Embedding。

这么做的好处是成本和效果能同时兼顾。你要是所有请求都走云端大模型，一个月下来的API账单会非常难看；但你要是所有请求都走本地小模型，问答质量可能又过不了关。根据任务复杂度分配合适的模型，是生产级应用的基本功。

3. Prompt工程在Dify里的落地方式

3.1 不要把Prompt编排页当普通文本框用

很多人第一次打开Dify的编排页面，会觉得这不就是个Prompt编辑器吗？填个系统提示词，填个用户提示词，完事了。其实不是这样。Dify的编排页是一个结构化的Prompt组装环境，它把Prompt拆成了几个互相独立的部分：系统提示词（System）、用户提示词（User）、上下文（Context）、变量（Variables）、对话开场白（Opening Statement）、建议问题（Suggested Questions）。

理解这几个部分的协作关系，才是真正的Dify式Prompt工程。系统提示词里写角色和全局规则；用户提示词里定义具体任务和输出格式；上下文里注入知识库检索结果；变量里放用户输入或上游节点的输出。每一块都可以单独迭代，互不干扰。

3.2 变量、上下文与模板语法：Dify的Prompt三段论

Dify里有一套轻量的模板语法，核心是{{#...#}}形式的内置变量和{{自定义变量}}形式的用户变量。我用得最多的几个内置变量：

• {{#context#}}：自动注入知识库检索到的文本片段，做RAG应用时必用；
• {{#query#}}：引用当前这一轮会话的用户输入；
• {{#history#}}：引用多轮对话历史。

一个典型的RAG提示词模板长这样：

你是企业的智能客服助手，请基于【知识库上下文】回答用户问题。 【知识库上下文】 {{#context#}} 【用户问题】 {{#query#}} 回答要求： 1. 如果上下文中没有相关信息，明确告知用户“当前知识库中未找到相关内容”，不要编造； 2. 用简洁、口语化的中文回答； 3. 在回答末尾附上引用来源的文档名称。

这里关键的一点是：不要试图让模型自己“记住”知识库里的内容，而是通过上下文变量把检索结果显式喂给它。你在系统提示词里写再多“你要懂公司的报销制度”，不如在上下文里实实在在放两段报销制度的原文。

实践中我还发现一个容易忽略的点：用户提示词和系统提示词的分工。系统提示词适合放那些“无论用户问什么都要遵守”的规则，用户提示词适合放“和当前这次具体请求相关的任务描述”。Dify在构造完整Prompt时会把这两部分拼起来发给模型，如果你把任务步骤放在系统提示词里，遇到模型对格式要求敏感的场景，容易导致输出不稳定。

3.3 少样本示例与思维链：提高输出质量的实战写法

Prompt工程方法论很多，但我在Dify里落地时，真正高频见效的只有两招：少样本示例（Few-shot）和思维链（Chain-of-Thought）。

少样本示例指的是在提示词里给模型几个输入输出的对照样本。比如我要做一个工单分类器，不会只写“请把用户工单分为网络故障、账号问题、计费问题、其他”，而是会给出具体样本：

工单：“公司电脑连不上WIFI，一直提示无Internet访问” 分类：网络故障 工单：“登录后台提示密码错误，重置也没用” 分类：账号问题 工单：“这个月账单多扣了50元” 分类：计费问题 工单：“如何修改部门名称” 分类：其他

实测下来，给了这类样本之后，分类准确率能从80%左右提升到95%以上。原因很简单：大模型对“格式示例”的模仿能力远强于“抽象规则”的理解能力。

思维链则是针对复杂推理任务，在提示词里要求模型“先思考，再回答”。在Dify里落地时，我通常会加一句“请先逐步分析用户问题中涉及的关键要素，再给出最终结论”，这比直接问效果要好得多。不过要注意，思维链会增加Token消耗，只对真正需要推理的任务使用，不要让每个回答都走一遍。

3.4 对话开场白与建议问题的配置细节

Dify编排页里还有两个经常被忽略的模块：对话开场白和推荐问题。

对话开场白是用户进入应用后看到的默认消息。这个字段不是摆设，它有实际的工程价值——开场白决定了用户对应用能力的预期。比如你写“这里是企业IT服务台，支持账号、网络、邮箱、资费等问题咨询”，用户就会带着明确的问题来咨询；你要是留空，用户可能会问一些完全超出边界的问题，反而增加系统的处理压力。

推荐问题则是系统自动生成的追问列表，我一般会配置2到4个与业务强相关的问题，比如“如何申请新电脑”“忘记密码怎么办”。这能有效引导用户提问方向，让对话从一开始就落在知识库覆盖范围内。

4. 知识库流水线：让应用拥有领域记忆

4.1 分段、索引与检索：一次完整的入库链路

知识库是大模型应用的“长期记忆”。没有知识库，模型只能靠自己的训练数据回答问题；有了知识库，模型才能针对你的私有文档和数据做问答。Dify的知识库本质上是一条完整的RAG流水线，我习惯把它拆成四个环节：导入→分段→索引→检索。

导入环节支持TXT、Markdown、PDF、DOCX、HTML、Excel等常见格式，我实测下来PDF的解析质量依赖文件本身的清晰度，扫描版PDF基本不可用，建议提前转成文本或Markdown再导入。

分段环节是关键中的关键。Dify提供自动分段、自定义分段和父子分段三种模式。自动分段适合内容结构清晰的说明文档；自定义分段适合每个文档有自己的章节结构；父子分段适合既有长文又有明细清单的复杂文档——父级存储为上下文，子级存储为检索单元，能提高召回精度。

索引环节分为“高质量”和“经济”两类。高质量模式调用嵌入模型生成本文向量，经济模式仅做关键词索引。知识问答场景下，高质量模式是唯一靠谱的选择，经济模式基本只适合用来自测功能。

检索环节支持向量检索、全文检索、混合检索。我的实测经验是，中文场景下混合检索效果最稳。原因是中文表达中同义词和语序变化非常多，纯向量检索可能漏掉关键词完全一致、但语义相近的文档；纯全文检索又无法理解“没带电脑”和“忘记携带办公设备”其实是同一个意思。混合检索取两者所长，效果明显更好。

4.2 分段参数与Embedding模型的选择建议

很多人调知识库时只关心“为什么搜不到”，其实问题往往出在分段策略上。我实测下来，通用文档采用单段500-800个字符、重叠50-100个字符的效果较稳。分段太大，检索回来的是一个“大杂烩”，关键词被稀释；分段太小，语义不完整，检索精度也差。

重叠字符的作用在于：即使检索点落在段落的边缘，也能通过重叠部分把完整的语义带出来。这个参数很多人不重视，但它对检索质量的提升非常明显。

Embedding模型的选择对中文RAG影响巨大。Dify内置了多种本地嵌入模型，也支持云端Embedding API。我在多组实验中发现，BGE-M3在中文语义匹配上表现突出，特别是处理长文本时效果稳定。如果完全依赖云端模型，OpenAI的text-embedding-3-large效果好但成本高，国产模型的性价比更高。

4.3 结构化数据导入到Dify：直接喂知识库，还是写库？

关于热词里提到的“Dify把外部结构化数据导入存储到数据库”，我专门验证过两条路径，结论很明确：要区分数据的使用方式。

如果业务数据是用来做“语义查找”的——比如规章制度、产品说明、FAQ清单，那应该导入知识库，走上面说的RAG流水线。Dify的知识库API支持程序化批量创建文档和分段，可以写脚本把数据库表或Excel内容转成结构化文本批量入库。

但如果你要的是“精确查询”——比如查某个订单号的物流状态、查某个员工的账号权限，那不应该放进知识库。因为RAG的本质是近似匹配，它返回的是语义相近的片段，而不是精确的记录。这种场景的正确做法是：在工作流里用代码节点或HTTP请求节点直连业务数据库，把查询结果动态注入Prompt，让模型基于真实数据生成回答。

我自己在实际项目中就是因为一开始没想清楚这个区别，把所有数据都灌进了知识库，结果查询订单状态时模型给出了格式正确但数值错误的答案。后来把精确查询全部改走数据库接口，语义问答走知识库，问题才彻底解决。

5. 从Chatbot到工作流：把LLM放进业务流程

5.1 为什么单节点对话不够用

单纯的对话应用（指Dify里的Chatbot类型）适合“有问必答”的场景，但它有个天然缺陷：所有逻辑都在一个LLM Node里完成，模型既要理解用户意图，又要检索知识，还要组织回答，一旦任务复杂，输出质量就会下降。

生产场景里更常见的是有固定流程的任务：先收集输入，再做判断，然后走不同分支，最后调用外部系统。这类任务需要的是“工作流”而非“对话”。Dify将工作流分为两种形态：

• Chatflow：带会话记忆的多轮对话流程，适合客服助手等需要上下文理解的场景；
• Workflow：单次执行的自动化任务，适合内容生成、数据处理等不要多轮对话的场景。

我在搭建应用时第一件事就是先想清楚——这个应用本质上是对话还是任务？选错了形态，后面的编排会非常别扭。

5.2 工作流核心节点拆解：我用得最多的六个节点

Dify的工作流节点很多，但真正高频使用的其实就那么几个，逐个说下用途和心得：

开始节点：定义整个流程的输入参数。建议把所有外部输入都显式声明在这里，比如“用户问题”“用户ID”“工单类型”，方便下游节点引用。

LLM节点：工作流里可以放多个LLM节点，每个节点独立配置模型和提示词。这是实现“任务拆分”的核心手段。

知识检索节点：指定知识库，自动召回相关文档片段。注意这个节点只负责检索，不负责生成答案，检索结果通过{{#result#}}引用。

条件分支节点（IF/ELSE）：根据变量值走不同分支，比如“若工单类型为网络故障，检索网络知识库，否则检索账号知识库”。

代码节点：允许写Python代码做文本处理、数据清洗、格式转换。代码节点是解耦逻辑的关键，例如从一段长文本中提取JSON字段，或者把日期格式统一。

HTTP请求节点：调用外部系统API，这是让工作流接入企业业务系统的关键桥梁。

5.3 完整示例：工单自动分类+知识检索+生成回复草稿

以我之前做的一个“IT服务台工单助手”为例，完整走一遍工作流编排：

1. 开始节点：接收用户的工单提交内容，参数为ticket_content（用户问题）、ticket_type（用户自选的工单分类）。
2. LLM节点1（分类）：用本地Qwen2.5-7B，提示词让模型基于工单内容重新判断分类，返回“网络故障/账号问题/计费问题/其他”四种之一，输出到变量category。
3. 条件分支：根据category的不同值，路由到不同的知识库检索节点。
4. 知识检索节点：从对应知识库召回5段相关文档，输出到context变量。
5. LLM节点2（生成回复）：用云端DeepSeek，输入为ticket_content、category、context，提示词要求生成一段面向用户的人工客服式回复草稿。
6. 代码节点：检查回复草稿的长度，若超过300字则截断并附上“如需更多帮助请联系人工客服，工单号IT-20250001”。
7. HTTP请求节点：把最终回复和工单分类写入企业内部工单系统。
8. 结束节点：把回复草稿返回给前端展示。

这个流程跑通后，工单回复的生成时间从人工处理的十几分钟压缩到了十几秒，而且分类准确率稳定在90%以上。工作流的本质是把不可控的LLM行为约束在一个可控的业务框架里——每一个环节的输出都有人校验，每一个分支都是有明确规则的。

5.4 工作流调试的经验：先把每个节点单独跑通

工作流节点一多，出错时定位问题会变得困难。我的经验是：永远不要等到整个流程全建好再调试。

正确做法是每个节点配置完成后，先用“运行”按钮单独跑一次，确认输入输出符合预期，再连线到下游。Dify的运行面板会展示每个节点的输入输出详情，这比靠眼查日志强太多了。

另一个常见问题是数据类型不匹配。比如代码节点返回的是对象，下一个节点的变量引用里按字符串拼接，就会导致生成内容里出现“undefined”或“[object Object]”。遇到这类问题，回到代码节点，把返回值强制转换成JSON字符串或者用模板转换节点做一次类型整理即可。

6. Agent节点：让模型自己决定调用什么工具

6.1 Dify的Agent与工作流的边界在哪里

很多初学者会把Agent和工作流搞混，或者认为Agent比工作流高级。其实两者定位完全不同：

• 工作流是确定性的工程逻辑——你预先设计好路径，每一步固定执行；
• Agent是模型自主决策的推理逻辑——你给它一批工具，它根据用户意图自行决定调用哪些工具以及调用的顺序。

在Dify里，Agent不是工作流的替代品，而是工作流中的一个节点类型。你可以在一个Chatflow里同时混用LLM节点和Agent节点，上游LLM负责预处理，Agent负责需要工具调用的部分，下游再根据Agent的结果做后处理。

我自己的判断标准是：如果这个环节工具调用的组合方式是否在有限种可枚举的范围内，如果可枚举就用工作流，不可枚举才用Agent。Agent的灵活性是优势也是风险，你无法保证它每次都会按预想路线走，所以在生产环境中要尽量缩小Agent的决策范围。

6.2 工具参数约束：实测验证过的关键点

在Dify里给Agent配工具时，我发现有一个决定成败的细节——工具描述和参数Schema质量。

模型在决定是否调用工具时，依赖的是工具的名称和描述，而不是工具的代码实现。描述写得太简单，模型可能把“查天气的工具”当成“查日历的工具”来用；参数约束不严格，模型可能把字符串传给一个期望整数的字段，导致工具执行失败。

一个有效工具参数的JSON Schema基本长这样：

{ "type": "object", "properties": { "city": { "type": "string", "description": "要查询天气的城市，例如：北京、上海" }, "date": { "type": "string", "description": "查询日期，格式YYYY-MM-DD，默认今天" } }, "required": ["city"] }

描述长度要够，但又不能啰嗦。我建议把“这个工具能干什么”“输入参数的含义”“如果参数缺失的兜底策略”都写清楚，模型的选择就会稳定很多。

6.3 什么样的模型适合跑Agent推理

Agent对模型的要求比普通对话高得多，因为模型必须正确理解工具列表、自主规划调用顺序、并从错误调用中恢复。实测下来，Function Calling能力强的模型在Agent场景中效果远好于通用对话模型。

如果用的是云端模型，DeepSeek、Qwen-Max、Claude都具备较好的工具调用能力；如果跑本地模型，Qwen2.5系列在工具调用上表现不错，但小参数模型（7B以下）在复杂多步骤任务上仍然容易出错。我给本地Agent场景的最低配置建议是14B以上模型，7B模型更适合做单一分类或关键词抽取这类子任务。

7. 生产环境避坑：SSL、多租户、数据导入与版本升级

7.1 SSL错误的完整排查链路

热词里有“Dify ssl错误”，这个坑我也踩过。现象通常是：应用在HTTP环境下一切正常，配置了HTTPS反向代理后，出现证书相关的报错，或者调用某些模型API时频繁连接失败。

完整的排查链路应该是：

1. 先确认Dify自身的架构：Dify默认自带一个Nginx容器，负责前端静态资源和API反向代理。如果你又在外面套了一层Nginx或Caddy，就需要留意两层代理之间的协议一致性。
2. 检查反向代理是否透传了正确的协议头：外层Nginx把容器的HTTP转成HTTPS时，需要设置X-Forwarded-Proto等请求头，否则Dify内部会认为请求还是HTTP，生成的回调地址可能是http://。
3. 检查模型API的证书状态：Dify调用模型供应商API时，如果模型服务走的是HTTPS自签名证书，需要确认Dify容器内能信任该证书，否则会报SSL相关的握手错误。
4. 检查容器时间是否准确：这个很少人想到，但容器系统时间偏差会导致证书校验失败，特别是重启过宿主机但没有重启容器的场景。

我遇到的实际案例是外层代理没有设置X-Forwarded-Proto，导致Dify应用内生成的回调URL全部是HTTP，部分功能在HTTPS页面下被浏览器拦截。解决方式是反向代理配置中显式加上协议头字段。

7.2 社区版多租户：1.10版本前后的差异

“Dify社区版1.10多租户”是热词里的高频关键词，说明很多团队在用社区版时都被多租户问题卡过。

在1.10版本之前，Dify社区版并非严格意义上的多租户架构。虽然可以注册多个账号，但每个账号的模型配置、知识库、应用是隔离的，缺少一个“管理员统一管理所有租户”的视角。这意味着如果你想给不同部门分配独立的模型Key、API配额和知识库空间，社区版会非常吃力。

1.10版本之后，多租户能力有明显增强。如果你需要做租户级隔离，建议升级到新版本，并在部署时重点测试：租户间的应用权限隔离、知识库隔离、模型Key隔离、API调用配额这几项。

如果你已经在生产环境使用旧版本，且没有升级计划，有一个折中方案：用Dify的服务化API层做隔离，为每个租户分配独立的API Key，在业务系统侧维护租户与Key的映射关系，从应用入口统一管控。

7.3 版本升级的实操经验：Windows环境下的那些坑

Dify的版本迭代速度很快，热门功能（如多租户、新节点类型、模型管理优化）都是在更新中逐步加入的。长期不升级容易错过关键能力，但升级本身有风险。我分享一套实测过的升级流程：

1. 备份数据目录：重点备份PostgreSQL的数据卷和向量数据库的数据卷。用docker compose启动时这些数据卷一般挂载在./volumes目录下，直接复制整个目录即可。
2. 查看升级说明：不同版本之间可能有数据库迁移脚本，先阅读官方Release Notes确认是否有破坏性变更。
3. 拉取最新镜像并重启：在docker-compose文件所在目录执行docker compose pull，然后docker compose up -d。
4. 验证关键功能：登录后台，确认应用列表、知识库、模型供应商配置都在；发起几条测试对话确认LLM能正常响应。

Windows环境下的特殊点在于Docker Desktop本身。如果你用的是旧版Docker Desktop，建议先升级到新版并切换到WSL2后端，否则文件挂载性能和稳定性都会出问题。升级后如果容器一直重启，多半是.env文件里的版本号与镜像版本不匹配，检查一下dify镜像的tag是否和.env里的版本一致。

7.4 把外部结构化数据导入Dify数据库的正确姿势

围绕“dify把外部结构化数据导入存储到数据库”这个需求，我强调一下正确姿势——不要直接操作Dify的PostgreSQL或向量数据库来导入数据，原因很简单：Dify内部有自己的元数据结构，直接写库极易导致数据不一致，而且后续版本升级时很可能因为数据结构变更而出错。

最稳定的路径是走API。Dify提供两类API：知识库API用于批量创建文档和分段，应用服务API用于向应用发送消息获取回复。你可以写一段Python或Java脚本，读取Excel/数据库表，转成Markdown文本，循环调用知识库API入库。

import requests API_KEY = "dataset-xxxxx" BASE_URL = "https://your-dify.example.com/v1" # 创建文档并上传分段 headers = { "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json" } # 假设你已经创建好了知识库，拿到dataset_id payload = { "name": "2025年Q1财务制度", "text": "这里是分段内容，将文件内容分割后逐个上传", "indexing_technique": "high_quality", "process_rule": { "mode": "custom", "rules": { "pre_processing_rules": [ {"id": "remove_extra_spaces", "enabled": True}, {"id": "remove_urls_emails", "enabled": False} ], "segmentation": { "seg separator": "\n\n", "max tokens": 800, "chunk overlap": 100 } } } } resp = requests.post( f"{BASE_URL}/datasets/{dataset_id}/document/create_by_text", headers=headers, json=payload ) print(resp.json())

注意上传请求里指定的process_rule要与后台分段配置保持一致，避免入库效果和预览不一致。批量上传时建议加一个限速，避免API压力过大导致请求失败。

8. 最后聊聊我的几条实战心得

Dify这套平台我用了一年多，从最初的简单Chatbot到现在的多应用、多知识库、多工作流的生产环境，沉淀下来几条个人体会，分享给准备入手的同学。

第一，Prompt不是一次性写出来的，而是一轮轮调出来的。不要指望在编排页里写一个完美的系统提示词就万事大吉。先让它跑起来，收集真实用户的提问，然后不断补边界案例、补少样本示例、调整输出约束。Dify的版本管理功能派得上大用场，每次修改前建议发布一个新版本，出现问题可以随时回滚。

第二，知识库的维护比搭建更费精力。知识库上线只是开始，后续的文档更新、过期内容清理、高质量分段调整，才是保证回答质量的关键。我建议set一个定期维护节奏，每周花半小时看看知识库里有没有新增文档需要入库、有没有过期内容需要下架。

第三，可观测性一定要从一开始就重视。Dify应用详情页能看到每次对话的完整链路，包括每个节点的输入输出、耗时的Token消耗。我几乎每天都在用这个功能排查线上问题。你可以在应用设置里开启日志保存，这样即使应用发布后，也能回溯到某一次具体对话的完整推理过程。

第四，不要被“AI自动搞定一切”的说法带偏。生产级应用的核心是确定性。该用工作流就用工作流，把Agent的决策范围尽量缩小；该接数据库就接数据库，不要把精确查询都推给知识库。这里的取舍经验，往往比模型本身的能力更影响最终效果。

如果你正准备搭建一个真实落地的大模型应用，我建议从一个小而具体的场景切入，比如“把某个FAQ知识库变成问答机器人”或者“把某个工单分类流程自动化”，在一个可控的范围内完整走一遍Prompt设计、知识库搭建、工作流编排、生产部署的全流程。跑通了这条链路之后，再往多知识库、多租户、多Agent的方向扩展，会顺利很多。