@yplam 额，哈哈，我怎么感觉自己被当成了新手开发者 ：）

用 comfyui 的都是能接受节点式工作流的。你这样人家完全可以用那个 webui

@Caitlyn 这是个好问题，我想 ComfyUI 的一大优势是提供了可编程工作流，这使得用户可以定制化开发很多特别的生图、生视频的方案。我们同样提供了基于 python 脚本的可编程工作流，这是 webui 所不具备的。

@sunxfancy 无意冒犯，只是按你上面的技术栈描述感觉完全忽略了整个系统最核心最艰辛部分的开发（实际上我认为如果能很方便地直接用 Python 实现 ComfyUI 工作流，你 UI 直接用 Gradio 都会有很多人用）

强烈建议开发，我觉得目前所有 sd 的工作方式都不是太完美的解决方案，webui 和 comfy 我更倾向于使用 comfy ，但是 comfy 确有版本管理不善的地方，而且模型库一旦积累下来动辄几个 T 的容量。大量废弃不用的模型也不易丢弃。模型存放目录也比较“野生”。不同人制作的工作流没有统一的标准，每次都要看一会才能看明白。建议优先以 flux wan 等相关模型和 lora 的支持。

之前用过一阵子 comfy ui ，当时个人最大的痛点是，comfy ui 根本不支持类似虚幻蓝图的那种自定义宏、自定义函数的定义，导致我根本没办法封装某些已经很成熟的、不太会改动的逻辑，只能一遍遍复制…… 不知道现在是不是已经支持了

@yplam 哈哈，是这样的，我描述的技术栈是我想寻找能开发这些的协作伙伴，有很多工作量很大的事情我无法独立完成，但我自己是有开发后端经验的，并且也知道怎么把这些相关 API 封装好供用户调用，你可以看一下项目的 90%都是 python 代码。我上面也说了，之后项目再成熟一些，可能再寻找其他做模型推理的合作者加入。我现在还没找，或者说也不太好找，有 SD 模型推理经验的开发者，如果你对这方面很了解，或者有知道有哪位朋友很了解并对该项目感兴趣，也欢迎跟我讲。

你的目标，有可能是成为另一款 automatic1111 这样的 webui （代码版） 入坑难度会比 comfyui 更高，使用者首先得会你的胶水语言，其他还得了解所有其他开发者定义的接口、数据类型等等。

你这个貌似只解决了工作流的编排，没有解决 ComfyUI 里节点的维护啊，这些打算怎么处理

如果能做成 dify 这样的工作流一般人就会用了，我也不会用，我不是开发