GitHub 地址:https://github.com/didi/LogicFlow
这里是官网 -> LogicFlow 官网
我目前负责的流程图开源框架,积极维护中。团队设置了 Star 考核目标,年底想上 9K ,有需要的同学可以关注一下。如果能再点下 Star 就最好啦~ 感恩的心,感恩的心,感恩的心!!!
最近很多同学做 AI 模型训练或数据清晰的流程化配置产品,像 dify 或字节的豆包相关系统,都可以用 LogicFlow 快速实现。
除了 AI 训练,我们也一直在思考流程图库在 AI 方向还能有哪些应用。
今年偶然看到 Sora 的预告视频之后就在想有没有可能实现一个「用流程图编排视频脚本,再用 AI 生成视频」的工具,帮助没有视频经验但是想做视频的朋友低成本生成视频。
但是探索了一番之后发现目前 AI 生成视频的质量不太过关...所以退而求其次先试试用流程图+AI 生成图片。于是做了个简单的 demo ,写了一篇文章分享出来,欢迎各位大佬阅读、交流。(文章指路: 从「流程编排×AI 生图小工具」看 LogicFlow 的高可定制性)
同时想借这个想法抛砖引玉,想看看大家对流程图在 AI 方向上有什么看法或应用,我们收集 idea,后续可以持续丰富项目 demo。
1
Geekerstar 41 天前
和蚂蚁那套比有什么优势
|
2
boyongjiong OP @Geekerstar 在我个人看来,我们设计的优势是灵活且易懂。X6 在设计过程中,引入的概念有点多,理解成本较高;再一个就是 X6 内部事件的实现很棒,但是难理解,如果你要看源码追踪一个问题,这个过程可能会比较痛苦。
X6 和 xyflow (原 ReactFlow )都是很不错的流程图库,我们也是在持续跟他们拉齐一些使用体验上优秀的功能。目前基本上他们可以实现的,我们也都可以实现,甚至更方便一些 这只是我自己的观点哈,欢迎对比~选择适合自己业务的那一款。 |
3
NoKey 41 天前
为啥开源这种事,还要和绩效,kpi 挂扣呢
|
4
leo108 41 天前
上一个类似的 KPI 项目已经凉了一年多了 https://github.com/alibaba/butterfly
|
5
eleganceoo 41 天前
点个,kpi 项目也晚点凉
|
6
810244966 41 天前
🌟都要设 kpi ,那就去 tb 买点把,反正是对方先流氓的
|
7
webszy 41 天前
点了
|
8
boyongjiong OP @NoKey 团队要投入资源和人力来维护这个事情呀,总得有一个考核点来评估一下今年的工作的 0.o
|
9
adeweb 41 天前
刚想吐槽 KPI 开源,发现最近项目里有在用,挺好用的,感谢开发! Star 奉上!
|
10
boyongjiong OP @leo108 因为我们负责滴滴所有的客服业务,有很多场景是通过流程图化做动态配置的,我们把沉淀的能力抽象了一下做出了这个产品,因为内部一直在广泛使用(随着智能客服的发展,产品形态也一直在变化),所以我不太认同说是一个 KPI 项目 -。-
|
11
boyongjiong OP @810244966 -。- 买还是没必要,目前只能多宣传一下,尽人事知天命哈哈哈
|
12
gouflv 41 天前 via iPhone
star 数 和团队投入的资源人力,是怎么联系在一起的,不解。
|
13
yuliuxuanke 41 天前 via Android
想结合 liteflow 做可视化
|
14
Ocyss 40 天前
看了下也是用虚拟元素来实现的 ,豆包之前没更新的时候, 节点一多就卡的要死, 然后群里也天天有人在吐槽.
这种可拖拽的为啥不能像 comfyUI 一样用 Canvas 来做? 是 Canvas 的开发调试难度比较大么 |
15
boyongjiong OP @Ocyss 我个人感觉 Canvas 实现的困难点:
1. 调试困难(没办法直接像 dom 一样查看元素,调试和定位问题比较复杂) 2. Canvas 位图的方式,缩放会导致失真,豆包这种表单节点配置内容多的时候,感觉可能会有缩放的需求,不太确定缩放后体验如何 3. Canvas 作为画布,节点中如果要定义表单项的话,我目前不确定是不是要重写一套;使用 SVG 技术路线的话,可以复用项目中像 element-ui 或 antd 组件库中的表单项,实现功能相对简单 4. 我个人感觉没办法用 css 实现样式的话,Canvas 实现起来略复杂 anvt/g6 是用 canvas 实现的,可以调研一下是否能实现豆包的这个配置(我之前的感受是,g6 比较适合大数据的展示,向 node_modules 结构这种的)。 卡顿可以试一下开启局部渲染,因为 svg 的方式就是堆 DOM ,当节点内容复杂且节点数量多的时候,理论上确实会有卡顿的感觉,我们当时测试的数据如下,可以参考一下: 加载元素: 初次渲染瓶颈: 初次渲染 2000 个节点,DOM 元素数量约为 1600 ,延迟为 500 毫秒 ,明显卡顿。 初次渲染 750 个节点&边,DOM 元素数量约为 1800 ,延迟为 500 毫秒 ,明显卡顿。 增量渲染瓶颈: 在初始化渲染后,持续增加等量节点的情况下,渲染时间上下波动,总体上呈现出逐渐增加的趋势。 交互帧率: 移动画布: 画布上有 12000 个节点,DOM 元素数量约为 108129 ,帧率降低为 30 帧。 画布上有 750 个节点&边,DOM 元素数量约为 17056 ,帧率降低为 30 帧。 缩放画布: 画布上有 1500 个节点,DOM 元素数量约为 13650 ,帧率降低为 30 帧。 画布上有 840 个节点&边,DOM 元素数量约为 18596 ,帧率降低为 30 帧。 拖动元素: 画布上有 7100 个节点,DOM 元素数量约为 64029 ,帧率降低为 30 帧。 画布上有 840 个节点&边,DOM 元素数量约为 18642 ,帧率降低为 30 帧。 |
16
boyongjiong OP @yuliuxuanke just do it. try 1 try 😄
|