上周三下午，运营同事抱着一堆用户反馈来找我，说“能不能让AI自动回复这些常见问题？”我瞥了一眼表格，大概有六十多条，全是“怎么改密码”“退款多久到账”“发票怎么开”之类的重复问题。按老办法，要么写死关键词规则，要么接个大模型API然后自己写上下文管理——两件事都够烦的。那天刚好刷到GitHub热榜上Dify又冲到了前十，之前一直听说它是个低代码AI应用平台，但没真正用过。我决定花一个下午试试，结果这一试，直接把我原计划两天的活儿压缩到了三个小时。

我是怎么用它搭出一个客服助手的

Dify的定位很清晰：把LLM应用开发里的那些脏活累活——模型接入、Prompt编排、知识库切分、日志追踪——全部用可视化方式包掉。你不需要写一堆FastAPI路由来维护对话状态，也不需要自己折腾向量数据库的召回参数。

我先在本地用Docker跑起了社区版：

git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env
docker compose up -d

第一次启动会拉一堆镜像，我等了大概五分钟。打开http://localhost/install，设置管理员账号，然后就进入了主界面。说实话，第一眼的感觉是“这玩意儿怎么这么像那种企业级低代码平台”，左侧是应用列表，中间是画布，右侧是配置面板。但真正开始操作后，我发现它的抽象层次很舒服——它不会逼你从零搭一条工作流，而是给你预设了“聊天助手”“文本生成”“Agent”“工作流”这几种模板。

我选的是“聊天助手”里的“支持知识库”模板。然后做了这几件事：

  • 把运营那份表格导出成CSV，转成Markdown格式，上传到“知识库”里，让它自动分段并做向量化。
  • 选了一个Embedding模型（我用的OpenAI的text-embedding-3-small，不过Dify也支持本地模型），然后在“模型供应商”里填好API Key。
  • 在Prompt编排界面，把系统提示词改成“你是一个电商平台的客服助手，回答要简洁，不确定时请转人工”。
  • 把“知识库检索”组件连接到LLM节点，设置召回数量为3，相似度阈值0.5。

全程没有写一行后端代码，鼠标拖拽就完成了。然后我在右上角点“发布”，拿到了一个API地址和密钥。那些需要自动回复的场景，我直接用Python调一下接口就行：

import requests

url = "http://localhost/v1/chat-messages"
headers = {
    "Authorization": "Bearer app-xxx",
    "Content-Type": "application/json"
}
payload = {
    "inputs": {},
    "query": "我退款申请提交三天了，怎么还没到账？",
    "response_mode": "streaming",
    "conversation_id": ""
}
r = requests.post(url, json=payload, headers=headers, stream=True)
for line in r.iter_lines():
    if line:
        print(line.decode("utf-8"))

响应是流式的，Dify会把答案一段一段吐出来。我试了几个问题，回答质量比我想象中高——它能把知识库里的退款政策条款引用出来，并且给出一句“通常1-3个工作日，若超过请提供订单号我们为您加急”。这已经达到运营同事的基本要求了。

好用在哪：三个让我惊喜的点

第一个惊喜是知识库的召回调试实在太方便了。以前做RAG，我得先写脚本把文档切块，然后调embedding，再算cosine距离，最后还得肉眼检查有没有召回错。Dify把这一整个链路封装成了一个“检索测试”窗口。我可以在界面里直接输入一个问题，看到召回出来的片段以及相似度分数。如果发现某段切分太碎，我直接修改分段规则，重新向量化，整个过程不用一分钟。

第二个惊喜是变量和流程的分明。它支持定义对话变量，比如用户手机的号码、订单ID。这些变量可以在输入节点采集，也可以由模型在对话过程中抽取出来存进去。这对我后面做“查询订单状态”功能特别有用——我不用在代码里维护session级别的状态，Dify已经帮我处理了。

第三个惊喜是日志和标注功能不是摆设。应用发布后，在“日志”页面能看到每一次对话的完整输入、输出、模型消耗、延迟。更狠的是，你可以直接在日志里给某条回答点“赞”或“踩”，然后把标注结果加入“数据集”作为few-shot示例。这相当于内置了一个最简单的强化学习闭环，对非算法团队来说非常实用。

【我遇到的坑】

当然，如果你以为Dify零坑，那是我没说实话。我遇到的最大的坑是知识库召回质量跟分段方式强相关。默认分段是按照固定字符数硬切的，我的CSV转成的Markdown表格一长串，结果被切得乱七八糟。比如退款政策里“1-3个工作日”被切到上一段的末尾，导致模型回答时经常引用错误信息。后来我手动改成按“###”标题切分，才有所好转。这个调参过程并不智能，全靠经验和运气。

第二个坑是工作流编排里的“迭代”节点比想象中难用。我本来想做一个多轮追问的客服流程，需要把用户问题拆分成几个子问题分别检索再汇总。Dify的迭代节点必须在数组变量上运行，但数组的构造又需要代码节点。我被迫写了一段JavaScript去组装数组，虽然支持，但“低代码”的体验在这一步破功了。

第三个坑是权限和多人协作做得比较粗。社区版里所有登录用户都是管理员，没有只读权限。我让前端同事帮忙调一下提示词，结果他手一抖把整个应用的工作流改崩了，还保存了。后来我只能靠手动备份JSON导出来恢复。如果你要团队协作，最好提前定好“只有一个人能改配置”的规矩。

和竞品比：Dify vs Coze vs LangFlow

我也用过字节的Coze和开源的LangFlow，所以简单说说感受。

Coze对国内用户更友好，插件生态丰富，尤其是字节系的产品都打通了，比如飞书、抖音。但它有两个我不太喜欢的地方：一是编排是在云端进行的，免费版限流得厉害；二是版本管理很弱，改完了想回滚只能手动复制提示词。Dify社区版可以本地部署，数据完全在自己手里，而且它有“发布版本”的概念，发布之前可以对比不同版本的Prompt。

LangFlow则更偏程序员向，它的节点连线方式很灵活，但默认界面太丑，而且学习曲线陡峭，你对“消息”“数据”“参数”的理解不够深的话，很容易连线连成一团乱麻。Dify抽象得更规整，更像是“给业务人员准备的工具”。当然，Dify也有缺点——它的自定义插件开发门槛比LangFlow高，如果你想写一个全新的工具节点，需要按照它的Plugin规范写Python代码，文档还不够完善。

如果你的团队里全是工程师，选LangFlow没问题；如果团队里有运营或产品，Dify会是更稳妥的协作基础。

什么场景适合用Dify

我总结一下，以下场景你可以无脑上Dify：

  • 你要做一个内部知识库问答机器人，或者企业客服助手，每天处理大量重复问题。
  • 你想快速验证一个AI应用的想法，比如“让AI总结工单”“让AI从合同里提取关键字段”，但又不想花两周时间搭建后端管道。
  • 你需要对接多个模型供应商，比如GPT、Claude、通义千问，而且希望随时切换，不被任何一家云厂商绑定。
  • 你想给业务团队一个可以自己调Prompt和知识库的“后台”，而不是每次改个提示词都要来找研发。

反过来，如果你的应用需求特别复杂——比如需要实时流式计算、需要对接上百个第三方系统、需要精细到内存级别的优化——Dify就不太合适。它不是给你当通用后端用的，它更适合做“AI应用的操作系统”，而不是“业务系统里的一个模块”。

最后的结论

我原来对低代码AI平台有些偏见，总觉得那是“给不会写代码的人准备的玩具”。但这次用Dify真实地搭了一个客服助手后，我的看法变了。它真正厉害的地方，不是“拖拽生成一个聊天机器人”，而是把RAG、Agent、工作流、模型管理、日志这些繁琐的工程细节，做到了“够用的抽象”。我依然需要写些胶水代码去对接业务系统，但我不需要再操心对话状态、上下文长度、向量化切分这些重复劳动了。

最后给点实在的建议：如果你要尝试Dify，最好先花半天时间看官方文档，重点理解“知识库分段”和“变量作用域”这两个概念。别急着连外部工具，先用内置组件把核心链路跑通。还有，记得每天备份应用配置——别问我为什么。

至于那个客服助手，现在已经在我们公司内部试运行了。运营同事反馈说，至少一半的重复问题不用人工回复了，而我只花了三个小时。这个投资回报率，值得你亲自试一试。