Dify：把大模型的活儿画成一张流程图

去年帮一个做五金件的小厂搭客服。他们的售后问题翻来覆去就那几十个：型号怎么对、保修期怎么算、配件在哪买。我想着接个大模型就完了，结果第一版写完，代码里全是提示词，改一句话要翻三个文件。

第二版我换成 Dify。它不让人写代码，让人画图：左边放一个输入框，中间拉一个知识库检索，右边挂一个大模型，最后接一个回答节点。连线就是数据流。

第一次用这种东西有点不习惯，但把逻辑画出来之后，反而更容易看出哪里不对。我原本让模型先回答再查资料，画在画布上才看见顺序拧了。

它解决的核心问题不是「让 AI 好用」，是「让改 AI 的人不用读代码」。运营同事想调语气，直接在提示词节点里改；想加一条「问价格就转给销售」，拉一个条件分支。改完点发布，十分钟上线。

知识库那块把我从最麻烦的活里捞了出来。工厂的产品手册是 Word 和扫描件混在一起的，建一个知识库把文件拖进去，它自己切块、向量化。我只需要测：问某个型号的螺纹尺寸，它答得对不对。

后来的版本把工作流和对话分成了两种：一种是一次进一次出的自动化，一种能追问。插件市场里的模型、工具、扩展都是现成的，以前要自己封的接口，现在装一个就行。

代价也有。它不是装完就能用的软件，得用 Docker 起一堆容器，第一次部署能折腾半天。模型的 token 钱照花，Dify 只负责组织，不负责省钱。私有化部署能过数据关，但升级偶尔会把自定义插件搞坏。

调试也简单了。以前的日志是一串文本，出问题只能猜。现在点开一次运行记录，每个节点输出了什么、检索到哪几段、模型拿到哪些上下文，一路看下来，错在哪一步一目了然。

它也不适合所有人。只想让模型回答几个固定问题，写十行脚本调 API 更省事；团队里没人愿意维护服务器，直接买云端服务更划算。Dify 的价值在流程会变、参与的人不止一个的时候。

GitHub 上十六万星，是这类项目里最热的一个。这个数字说明的不是它功能多，是「想用 AI 但不会写代码」的人比想象中多得多。

那个客服上线跑了三个月，售后电话少了大概三成。老板问我用的什么技术，我说不清楚——在他眼里那就是一张流程图。