小糖元Dify实战记录：从Prompt工程到把AI工作流真正跑进生产
先讲一件我最近遇到的事。团队接了一个企业客户的需求：把他们的产品手册、售后工单历史记录和内部SOP全部丢给大模型，做一个能自动回答客户问题、还能自动把工单分级转派的"智能客服"。按我以前的习惯，这种活儿我会直接用LangChain写调度代码，接一个向量库，再写一堆Prompt模板和异常处理，光是把RAG链路跑通就得两三天。但这次客户给的时间非常紧，从立项到演示只有一周，我临时改用Dify搭了一套，结果从部署到工作流跑通只花了不到两天。这篇博文就是我把Dify从Prompt工程一路做到生产级AI工作流的完整复盘。
这篇文章适合谁看？如果你正准备做AI应用开发，或者已经在用Dify但只停留在搭一个聊天机器人Demo、还没真正接触工作流编排、知识库RAG和发布上线的阶段，那这篇文章应该能帮你省掉不少我踩过的坑。内容里没有太多花哨的理论，基本全是我自己动手跑过的步骤、改过的配置、踩过的雷。
1. Dify到底是什么：先解决"为什么是它"的问题
1.1 Dify在AI应用开发里扮演的角色
先聊一个概念：LLMOps。这词听着唬人，其实类比传统开发里的DevOps就很好理解。以前我们开发一个业务系统，要管代码、数据库、部署、日志、监控。到了大模型应用时代，除了这些，你还要管Prompt模板、Token消耗、上下文窗口、模型版本、知识库召回、幻觉控制……如果全靠自己从零造轮子，工作量会非常惊人。
Dify做的事情，就是把这一整套LLMOps里最重复、最通用的部分做成了一套可视化平台。你在界面上可以完成：接入模型、编排Prompt、搭建知识库、设计工作流、发布成网页应用或API服务。它不是一个简单的"拿OpenAI的Key套个聊天框"的Demo生成器，而是一个比较完整的AI应用开发底座。
我自己的体会是，Dify真正解决的是"Dev和Ops之间的协作成本"。以前我写一个RAG应用，代码全在一台开发机里，业务同学想看效果只能对着截图，想调一个Prompt得等我改代码。用了Dify之后，业务同学自己就能在界面上改Prompt、调参数、看日志，我只负责把复杂的工作流和外部系统对接搭好。
1.2 和LangChain、Coze这些方案放在一起比
很多人会纠结选型，我也被问过很多次"Dify和LangChain哪个好"、"Dify和扣子（Coze）哪个好"。我自己的回答是：它们根本不是一个赛道的东西，但你也不能完全不做对比。
| 方案 | 形态 | 适合场景 | 我的真实感受 |
|---|---|---|---|
| LangChain | Python代码框架 | 需要深度定制、有专职算法或后端工程师的团队 | 灵活但工程量大，RAG链路、日志、监控全要自己搭，迭代慢 |
| Coze（扣子） | 云端SaaS平台 | 快速做Demo、个人玩、依赖平台生态 | 上手极快，但私有化部署受限，企业数据出域这一关就过不去 |
| 自研代码 | 任意 | 大厂或特殊监管需求 | 最灵活也最费人，一个AI应用没有3个月起不来 |
| Dify | 开源可私有化部署的LLMOps平台 | 中小企业、企业服务团队，既要效率又要可控 | 开箱即用度高，可视化编排降低了协作门槛，同时保留了API和代码节点作为出口 |
再补充一句，LangChain和Dify其实不是二选一的关系。你可以用Dify做应用层的编排，把复杂逻辑通过代码节点、HTTP请求节点暴露出去，而且Dify本身也有API，你可以把Dify当成一个"大模型应用后端"来用，前端还是你自己的业务系统。这样既省了从零开发的精力，又不会把自己锁死在某个平台上。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 本地部署与版本选择：先把地基打稳
2.1 服务器配置与部署方式
Dify是开源项目，官方建议用Docker Compose部署。我自己的经验是：如果只是开发测试，4核8G的云服务器勉强能跑，但一旦上了知识库和工作流，建议还是老老实实8核16G起步。因为你跑的不只是Dify本体，还有它的PostgreSQL、Redis、Weaviate或Qdrant向量数据库，这些家伙加起来内存占用很可观。如果还要在同一台机器上跑本地大模型，那16G内存只够玩7B~14B的小模型，想跑更大参数的模型就得单独搞推理服务器。
部署本身倒不复杂：
bash复制git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env
docker compose up -d
国内服务器拉Docker镜像慢的问题比较常见，这个不展开细说，通用的做法是给Docker配置镜像加速器，或者用代理拉取。这里提醒一个坑：如果服务器之前装过老版本Dify，直接docker compose up -d容易遇到容器名冲突或数据库连接失败，建议先docker compose down清理旧容器，再启动新的。
Windows环境下的部署也有不少人问。Dify官方其实支持在Windows上用Docker Desktop跑，但前提是装好WSL2。纯Windows不带WSL2的Docker Desktop会有文件挂载和网络模式的各种奇怪问题。我见到的比较稳妥的路子是：Windows 11 + WSL2（Ubuntu 22.04） + Docker Desktop，然后在WSL2内部执行上面那几条命令，把数据目录也放到WSL2的文件系统里，别放在/mnt/c下面——否则文件读写性能会明显变慢，生产环境尤其不能这么干。
2.2 版本选择与升级：社区版1.10多租户和1.17.x的变化
版本选择上，Dify分社区版和云服务。社区版免费、可私有化部署，但以前企业用户最头疼的一个点是"多租户"能力弱。直到社区版1.10之后，多租户这个话题才真正热起来，它意味着你可以相对清晰地在同一个Dify实例里给不同团队或不同项目做空间隔离。1.17.x是目前比较新的系列，每次更新主要在模型接入方式、工作流节点、Agent能力上做增强，具体到1.17.1的更新细节，建议直接去看官方Release Notes，我这里不背数据。
升级这件事我踩过坑。以前我图省事，直接在服务器上git pull然后重启，结果数据库迁移脚本没跑全，页面直接报500。正确的升级流程应该是：
- 先备份数据库和数据目录（PostgreSQL做pg_dump，挂载目录整个复制一份）；
git pull拉最新代码；- 对比
.env.example和当前.env，把新增的环境变量补上； docker compose down；docker compose pull拉新镜像；docker compose up -d；- 观察容器日志，确认数据库迁移任务跑完、web容器正常监听端口。
升级后一定要去"设置-模型供应商"页面确认模型配置还在，如果发现某些模型"消失了"，多半是平台对模型供应商的配置格式做了调整，重新填一遍Key一般就能恢复。
2.3 模型接入：API模型和本地模型的配置思路
Dify支持很多模型供应商，OpenAI、Anthropic、通义、Kimi、DeepSeek这类API模型都能直接填Key接入。但这里有一个容易搞混的点：Dify把模型分成对话模型、Embedding模型、Rerank模型三类，配置时必须分开填。
比如你做知识库问答，对话模型用DeepSeek或通义千问，Embedding模型用OpenAI的text-embedding-3-small或本地的bge-m3，Rerank模型如果需要再单独配一个。三类模型缺一不可，缺了Embedding，知识库的文档压根没法写入向量索引；缺了Rerank，召回精度会打折扣。
本地模型的话，Ollama是最快的入门方式。ollama pull qwen2.5:7b之后，在Dify的模型供应商里选Ollama，填上服务器IP和端口就能用。但Ollama的并发能力比较弱，如果生产环境需要支撑较高并发，建议用vLLM部署一个兼容OpenAI协议的服务，然后在Dify里按"OpenAI-API兼容"的方式接入。我自己现在生产环境的做法就是：推理用vLLM起一个Qwen2.5-32B，Embedding用bge-m3，整体链路在一台带两张4090的推理机上跑，Dify本体放在另一台业务服务器上，两边解耦，方便单独扩容。
3. Prompt工程在Dify里的正确打开方式
3.1 为什么"把ChatGPT的Prompt直接粘进来"行不通
不少新手拿到Dify，第一件事就是把以前在ChatGPT里调好的Prompt整段粘进系统指令（PROMPT_TEMPLATE）里，结果发现效果完全不是那么回事。原因在于：Dify里的Prompt不是一段孤立的文字，而是模板化的"系统指令+用户输入+上下文检索结果+对话历史"的复合体。
比如你在ChatGPT里写"你是一个客服助手，请根据以下内容回答问题：……"这种把参考内容直接写死在Prompt里的方式，到了Dify里，知识库内容是动态检索出来的，你根本不知道用户每一次提问时检索到的片段是什么，所以必须用变量去引用。如果把参考内容写死，那模型永远只能回答你写死的那些话，知识库白接。
还有一个更实际的问题：直接粘大段Prompt容易让上下文窗口爆炸。Dify的Prompt最终会拼上知识库召回的片段、对话历史、用户输入，如果你在系统指令里堆了一堆跟当前任务无关的文字，每次调用都会浪费大量Token，而且模型容易"迷失"在过长的上下文里，反而答非所问。
3.2 Dify Prompt编排的结构化思路：变量、上下文和记忆压缩
在Dify里编排Prompt，我建议按"角色设定-任务说明-输出约束-引用方式"四层结构来写系统指令。角色设定告诉模型他是谁，这一点很重要。任务说明要具体到"做什么"和"不做什么"，"不要编造知识库中不存在的信息"这句话要写进去，而且要放在靠前的位置。输出约束要可执行，比如"用Markdown有序列表回答"、"如果无法回答，直接回复'我没有找到相关信息'"。
最关键的是变量引用。Dify里最常用的变量有这么几个：
{{#context#}}：知识库检索结果的聚合上下文，有知识库的Chatflow/Agent里必须用它；{{query}}：用户的当前输入；{{conversation}}：对话历史，可以控制是"全部带入"还是"只带最近N轮"；{{sys.files}}：用户上传的文件内容。
我的经验是，写系统指令时不用把知识库片段复制进来，只需要明确告诉模型"请优先参考{{#context#}}中的内容进行回答"。系统指令里的文字本质上是一份"行为准则"，而{{#context#}}才是"参考材料"，两者分离，模型的表现会稳定很多。
对话历史的处理也值得单独说一下。Dify支持设置"对话记忆"的轮数，如果每轮都把全部历史带进上下文，多轮会话后Token消耗会直线上升。我一般建议普通客服场景保留6~8轮对话记忆，再配合"消息摘要"功能，让模型把更早的历史压缩成一段摘要，既不会丢失之前的意图，也能控制成本。
3.3 一个可复用的Prompt模板示例
下面这个模板是我做"企业FAQ智能客服"时一直沿用的基础版，你可以直接复制到Dify的LLM节点里改改就能用。
text复制你是公司的智能客服助手，名字叫"小D"。
你的主要任务是回答用户关于产品功能、使用方法和售后政策的问题。
回答时请严格遵守以下规则：
1. 只依据下方{{#context#}}中的内容回答，禁止编造任何知识库中不存在的细节。
2. 如果{{#context#}}中没有相关内容，请直接回复"抱歉，这个问题我暂时无法回答，建议你转人工客服或拨打400-xxx-xxxx"。
3. 如果用户的问题涉及价格、优惠券，请提醒用户以官网最新活动为准。
4. 回答使用简洁的口语化中文，控制在200字以内。
5. 涉及操作步骤时，使用有序列表分步说明。
以下是可供参考的对话历史：
{{#conversation#}}
以下是知识库检索到的参考内容：
{{#context#}}
用户的问题是：{{#query#}}
这里要特别强调温度参数。FAQ客服场景我建议把温度调到0.2~0.3，温度太高模型容易自由发挥，把仅有的知识库内容用自己的话"重写"一遍，越写越偏。如果是创意类写作场景再调高到0.7以上。
4. 知识库的搭建与RAG流水线：让模型"懂"你的私有数据
4.1 分段大小怎么选：chunk的学问
把文档传进Dify知识库时，系统会让你选择分段模式。默认是按固定长度分段，但这里面的门道比看上去要多。
分段太小（比如128字符），每段的语义不完整，检索时容易召回一堆碎片，拼接起来语无伦次；分段太大（比如1024字符），一段里包含多个主题，检索的精确度下降，而且如果知识库整体很大，向量检索时容易召回到一些"半相关"的内容。我在实践中摸索出来的经验值：产品说明书、制度文档这类结构化文本，分段大小设在512~768比较合适；FAQ类短文本，每一条FAQ本身就是一个独立段落，用256左右就行。
Dify还支持"父子分段"模式，父分段保留完整上下文，子分段做精确匹配。这个功能在处理长文档时很香：子分段负责跟用户问题做向量匹配，找到之后再返回给模型时用父分段的内容，既保住了语义完整性，也提升了命中率。我用下来觉得，文档超过20页或者内容结构复杂的场景，强烈建议开父子分段。
另外"自定义分段"也很重要。如果文档本身有明确的章节结构，比如1.1、1.2这种标题，用自定义分隔符按标题切分，效果会远好于纯按字数硬切。Dify支持自定义分隔符，把\n## 、\n### 这种Markdown标题语法加进去，分段质量会明显提升。
4.2 Embedding模型选型：API还是本地
Embedding这一步决定了"向量化"的质量。很多人在模型选型上不够重视Embedding，觉得随便用一个就行，结果检索质量上不去，问题出在向量上而不是上游Prompt上。
API方式里，OpenAI的text-embedding-3-small综合表现均衡，智谱、通义的Embedding模型在中文场景下也不差。本地方式我推荐bge-m3，它在中文语义理解上很能打，而且参数量适中，CPU也能跑，只是速度慢一些，GPU机器上完全没问题。如果你对数据安全有要求、不能把文档内容发到外部API，那bge-m3是目前比较稳妥的选择。
还有一个容易被忽略的是Rerank模型。向量召回说的是"语义相似"，但语义相似不一定等于"答案正确"。比如用户问"怎么开发票"，知识库里有一段讲"发票类型有哪些"，这段在语义上很接近，但用户真正需要的是"开发票的步骤"。Rerank模型的作用就是对向量召回的多条结果做一次精细的排序，把真正能回答问题的那一段顶到前面去。Dify的知识库支持配置Rerank模型，我强烈建议有条件就加上，检索精度提升非常明显。实测下来，不加Rerank时Top3命中率可能只有60%，加了之后能到80%以上。
4.3 检索质量调优的实测经验
我踩过最典型的一个坑，是把一份公司制度PDF传进去之后，问答质量惨不忍睹。查了半天发现，那份PDF里的表格被分段切得七零八落，检索命中的全是残缺的表格片段。
解决办法是分两步：第一步，把PDF转成Word或Markdown，人工检查一遍表格结构，把表格转成更适合检索的文本形式；第二步，上传后用Dify的"召回测试"功能逐条验证。做召回测试时，我会拿20~30条真实用户问题去检索，重点看两个指标：命中的片段是否真的包含答案、答案片段在结果中的排名是否足够靠前。这两项过关了，问答效果基本就有了上限保障。
Dify的召回参数里有TopK和Score阈值两个关键项。TopK控制返回几个片段，默认一般是3，但如果你发现答案经常被截断或信息不全，可以考虑调到5；Score阈值控制"低于多少分就不要了"，这个值需要根据你选的Embedding模型来调，不同模型打分的分布区间差异很大。我的做法是先用较低阈值（比如0.2）跑一轮，记录命中的Score分布，再找一个能过滤掉明显不相关内容的分界值。
多个知识库之间也可以设置召回优先级。比如你把产品手册和售后工单分别建了两个知识库，用户问"某个报错怎么解决"，应该优先从售后工单库召回；问"某个参数怎么配置"，应该优先从产品手册库召回。Dify的"知识检索"节点支持多知识库配置并设置权重，这个功能在复杂业务场景里非常实用。
5. 从对话机器人到生产级AI工作流：核心编排思路
5.1 工作流节点不是摆设：谁在什么场景用
Dify的工作流编排是我认为它最能打的一部分。它把一次AI应用的完整处理过程拆成一个有向图，每个节点做一件明确的事。刚开始你可能不习惯，觉得"我明明可以一个Prompt搞定，为什么要拆这么多节点"——这个问题我一开始也有，后来发现，拆节点真正的价值在于：让AI的处理过程变得可观测、可干预、可回退。
比如"条件分支"节点，可以实现"如果用户的问题是售后类，就走售后流程；如果是售前咨询，就走售前流程"，这在纯Prompt里是很难稳定实现的，模型经常自作主张。又比如"代码执行"节点，可以在流程中插入Python代码处理数据，处理日期格式、调API签名、清洗字符串这类模型不擅长或不能做的事，都由代码节点干完再喂给模型。
我的经验是，当一个流程里有两个以上的业务规则分支，或者有外部系统调用时，就必须用工作流拆节点，不能硬塞进一个LLM节点里让模型"自己判断"。
5.2 一个完整案例：工单分类+知识库检索+回复生成+企微通知
我拿最近给客户做的一个"智能工单处理工作流"举例，这个案例完整覆盖了Dify工作流的核心节点。
需求是这样：客户的企业微信群每天收到大量员工IT报障消息，之前全靠人工在群里回复和转派。我们做了一个AI机器人，实现自动接收消息、判断问题类型、检索知识库、生成回复，如果知识库没有答案就调用ITSM系统的API自动创建工单。
工作流节点这样编排：
| 节点 | 作用 | 关键设置 |
|---|---|---|
| 开始 | 接收用户输入，比如"我的OA账号登不上去了" | 定义输入变量query |
| LLM节点（意图识别） | 把问题分类为密码重置/网络故障/软件安装/其他 | 要求输出JSON格式，temperature设为0 |
| 条件分支（IF/ELSE） | 根据意图识别结果走不同分支 | 判断意图 == "password"等 |
| 知识检索 | 在IT知识库中检索解决方案 | TopK=3，开启Rerank |
| LLM节点（答案生成） | 基于知识库片段生成用户可直接操作的回复 | 引用{{#context#}}，限定200字 |
| 条件分支2 | 判断知识库是否命中有效答案 | 用代码节点检查检索结果是否为空 |
| HTTP请求节点 | 调用ITSM系统API创建工单 | 传工单标题、描述、优先级 |
| 模板转换 | 把回复包装成企业微信机器人支持的Markdown格式 | 拼接标题、正文、时间戳 |
| 结束 | 返回最终回复 | 用{{#sys.files#}}支持用户上传截图 |
这套流程里我想特别说一下"意图识别"这个节点的好处。以前用单LLM节点直接回答时，模型经常把"我的OA账号登不上去了"理解成"账号密码问题"就直接开始给重置密码的教程，但实际上用户可能只是网络不通。把意图识别独立成一个节点后，模型先做分类，再走对应的处理分支，逻辑清楚多了。而且意图识别结果也方便做数据分析，看看到底哪类工单最多，这些都是可以量化的运营价值。
HTTP请求节点要注意的是鉴权。很多内部ITSM系统要求请求头里带签名，签名算法一般是用AppSecret对时间戳和请求体做HMAC。Dify的HTTP请求节点支持自定义请求头和代码节点，我的做法是：先用一个代码节点计算签名，再用变量传进HTTP请求节点。
5.3 代码节点和迭代节点：模型做不了的事，代码来兜底
大模型不是万能的，最典型的短板是精确计算和结构化处理。比如客户要求"工单超过48小时未解决就升级优先级"，这种时间计算你用Prompt让模型做，它十有八九会算错。正确做法是加一个代码执行节点：
python复制from datetime import datetime, timedelta
created_at = datetime.fromisoformat(args["created_at"])
now = datetime.now()
hours = (now - created_at).total_seconds() / 3600
if hours > 48:
priority = "P1"
elif hours > 24:
priority = "P2"
else:
priority = "P3"
return {"priority": priority, "hours": round(hours, 1)}
再比如"迭代"节点，它非常适合处理列表型数据。接一个"根据产品名批量查询库存并生成报价"的需求，如果纯靠LLM生成，模型记不住多个产品的库存数量；先通过HTTP请求节点批量拿到库存JSON，用代码节点解析，再喂给LLM生成报价单，每一步都可控可查。
我自己在落地过程中的体会是：能用代码节点的就不用LLM，能用规则判断的就不用条件分支硬猜。 AI工作流的核心价值不是让模型干所有事，而是让模型干它擅长的事，把不擅长的、容易出错的环节用确定性代码兜住，这才是生产级和Demo级的根本区别。
6. 走向生产环境：性能、监控、多租户与成本控制
6.1 并发与性能优化
Dify本身的架构是前后端分离，前端跑在Nginx里，后端是Flask API，数据库用PostgreSQL，缓存用Redis。在小并发（几十个人同时用）场景下，Dify默认配置完全扛得住，瓶颈一般不在Dify，而在模型API的响应速度。
如果用户量上来，我建议做三件事。第一，把PostgreSQL和Redis挂到独立机器上，别跟Dify本体抢资源；第二，给Web服务至少开两个副本，Dify的docker-compose.yaml里支持scale操作，用docker compose up --scale api=2 -d这种命令就能扩副本；第三，在Nginx层加缓存，对知识库检索结果做短时间缓存，因为同一个问题短时间内被反复问的概率很高——但要注意缓存时间不能太长，知识库更新后缓存里的旧答案会继续返回。Dify API层面还支持限流，可以在应用设置里为每个应用配置速率上限，防止个别用户刷爆Token。
还有一个很多人忽略的点：知识库向量检索是CPU密集操作，如果配置了本地Embedding，检索时CPU会飙升。建议把向量数据库单独部署到一台机器，或者至少在资源充足的主机上运行，别和API服务抢CPU。
6.2 多租户与权限管理
社区版1.10之后，多租户能力是企业用户最关心的更新之一。在Dify里，每一个"工作空间"（Workspace）就是一套独立的租户环境，不同空间的模型配置、知识库、应用、成员完全隔离。我现在的做法是：每个客户项目建一个独立的Workspace，客户A看不到客户B的任何数据和配置。这样做的好处不只是数据隔离，运营层面也很方便，每个工作空间可以独立统计数据、独立管理成员权限。
成员角色方面，Dify区分了Owner（所有者）、Admin（管理员）、Editor（编辑者）、Normal（普通成员）几档。Owner负责全局配置和账单管理，Admin可以管理成员和所有应用，Editor只能编辑自己权限范围内的应用，Normal一般只用来查看或使用。给客户开账号时，我一般只给Editor或Normal权限，避免客户误操作改到核心配置。
有一点需要提醒：多租户虽然能做数据隔离，但它不是"多租户SaaS"的完整方案。如果你的目标是让外部客户直接注册使用你的产品，那还需要在应用层做一层账号系统和权限校验的对接，经常要用到Dify的API密钥来做应用级鉴权。
6.3 Token成本与观测：让每一次调用都花得明白
大模型应用上线后，流量和成本是成正比的。我一个客户的客服机器人上线一个月，Token费用比预期的多了一倍多，查了半天发现是"无效检索"太多——用户问的问题知识库里根本没有答案，但流程还是每次都把Top3召回片段全部喂给模型。优化方案很简单：设置Score阈值，低于0.3的召回结果直接视为"未命中"，走兜底话术，不再浪费Token去理解无关内容。
Dify的"日志与标注"模块是成本分析的重要入口。每一轮对话都会记录模型消耗的Token数量、模型名称、延迟和调用时间，按应用维度可以统计出"哪个应用最烧钱"、"哪个时间段并发最高"、"哪类问题频繁触发失败"。我每次做上线后的第一轮优化，都是先拉日志看数据，而不是凭感觉改Prompt。
最后提一下"观测"这件事。Dify自带日志对于排查单次对话质量够用，但生产环境我建议把日志接入外部监控平台，用Dify的API或Webhook把每轮对话的输入、输出、Token消耗推到日志中心，配合告警规则做预算预警。Token成本这种东西，一旦出了问题，几天就能烧掉一笔不小的钱，提前设好预算线非常重要。
7. 我的实操心得与一些建议
整个项目跑下来，最想说的体会是：Dify不是一个"给小白的玩具"，也不是一个"万能的神器"。它是一个把LLMOps里最通用的苦力活做好了、让你专注业务逻辑本身的平台。但它的上限，取决于你往里面填的内容质量和对业务流程的理解深度。我见过有人用Dify五分钟搭一个聊天机器人发朋友圈，也见过有人用Dify搭出支撑整个客服团队的自动化系统，差距不在工具，在于有没有把"规则、数据、模型"三者真正结合起来。
有几个小经验分享给后来者。第一，先从一个极小场景跑通全流程比什么都重要，比如先做一个只有20条FAQ的知识库问答，再逐步加工作流和外部系统，一上来就搭复杂工作流容易把自己绕晕。第二，多利用"发布为API"的方式，让Dify嵌到你们已有的业务系统里，而不是强迫用户去用Dify自带的网页，这个设计思路上线后你会感谢自己。第三，上线前一定开Debug模式留足日志，最好每轮请求响应都存一份，方便出问题时做回归对比，这比任何测试都管用。
最后再分享一个我在多个项目里反复用的小技巧：在Dify的LLM节点里，系统指令末尾永远加一句"如果你不确定，请直接告诉我你不确定的原因"。这一句话能省掉你大量的追问和吐槽，也能让用户对回答产生合理的信任预期。大模型应用真正的成熟标志，不是它什么都能答，而是它知道自己什么不能答。