个人主观，轻喷，没有什么绝对，只是相对

持续更新

用下来的感受是 coze 用于社交，dify 用来内部构建。抛开工作流，机器人，工具，coze 最大的区别在于可以直接发布到社交媒体上。所以，coze 对操作体验上也花了不少功夫，而 dify 就专注在帮助使用者打磨工作流。coze 各个大模块之前可以联动的机制也比较多，所以侧重点各不相同。

工作流页面布局

coze 工作流就专注在当下的工作流创建过程中，怎么调，谁调了，不管。就关注当下的测试，当前的版本。Dify 则会把工作流相关的都放在一个面板里面，编排好了测试，测试记录每一次的输入删除，节点的运行情况。怎么用，直接去访问 API 里面看，别人调用的去日志里面看，再去概览里面看调用情况。除了删除，从开始到调用，到分析，一条链路都有了，也不用一直开多个页面。

节点创建&连线

这点可能更主观一点，而且跟个人习惯更有关联。

有一个很大的区别就是，coze 可以把所有你想要的节点，先拉到画布上来，再去连线。

Dify 必须要一个节点跟着一个节点，添加下一个节点后，自动创建连线。唯一能创建节点的方式就是，用替换节点。替换节点的时候，节点的左右两条线都会清掉，不过这不方便。

有些过代码的同学可能会有点感受，有些同学可能写代码是先写完设计文档再写代码，有的同学是想一步写一步(Dify 当然可以画完全局然后再去画布上操作，不过我想大部分不会这样)。先写设计文档的，知道自己有哪些模块，拉进来相关节点，就相当于是写好了一个 func 的壳。再根据业务逻辑关系，去连线走逻辑。我个人是更倾向 coze 的方式，我看得到这个工作流的全貌。

撤销动作

Dify 不能 ctrl + z，非常痛苦。上面说到的替换节点，万一替换的节点不合适，是不能回撤到之前创建的节点的。如果之前节点是配置的一个 HTTP 或者大模型节点，会崩溃的(不要问我怎么知道的)。

工作流节点连接

coze 的节点可以连接多个 next 节点，Dify 只能连接 1 个，即使能拉线到另外一个节点，原本连接的线就会自动删除。

工作流节点输入参数引用方式

在节点输入参数的引用方式上，两边都可以输入，也都是用下拉框的形式。不过 coze 上直接点击就可以出现联级下拉框，相比 Dify 要输一个 / 来说方便一点。Dify 也有直接点击的，不过大部分是要用输入的。

coze 采用联级的方式的一个好处是，如果字段很多也不会那么担心。Dify 是直接展开来，在参数很多的情况下，并且你不对节点标明的话，会很痛苦。

节点参数输出

coze 相对 Dify 来说比较友好，不过这个友好的前提是，能够在创建工具的时候，或者在 HTTP 节点的时候花点时间配置好。Dify 贴一个 openApi 的 swagger json 就行，但是输出每次都要用代码执行节点重新转出来。这点的体验上来说，coze 的会更舒服一点，而且对之后要交接或者使用的人来说很直觉。要是 Dify 维护的人换了，还得去了解一下返回来的是什么。

当然 Dify 可能考虑我就是跟对话相关，也没那么多输出的 json 字段，是我用法不太对也有可能。

开始节点

coze：String/Integer/Boolean/Number/Object/Array<String>/Array<Integer>/Array<Boolean>/Array<Number>/Array<Object>

Dify：文本/段落/下拉选项/数字

Dify 在使用的时候会受限很多

从这里来看，Dify 更倾向于使用者用来构建对话也好，或者抽取也好的纯输入的工作流。

代码节点

Dify 如果要写长一点的代码，体验感极差，就是能够展开，也就一小块的区域。coze 的代码模块至少可以在像一个代码 IDE 的地方编辑，这点 coze 的体验好些。

工作流节点

coze 可以嵌套工作流，不用重新再去写一遍，体验感极强。Dify 不好意思，请全部重来。

大模型节点

Dify 是倾向用户私有化部署使用，因此在这个节点可以配置更多的模型来调试，coze 是商用属性说以能用的大模型不多，除非嵌套自己的接口。

不过就单论大模型节点来说，coze 的大模型节点可以对数据做批处理，这个还是很方便的。

发布审批

Dify 倾向私有化，所以没有什么发布的限制。coze 是社交的，自然要对发布的东西有所管控。在内部使用的时候还是 Dify 来得自在，不过同时暴露出的问题就是 谁都可以去操作和修改，管理方面要做好。