从后端出发的产品设计
从后端出发的产品设计一开始就直接面向工程优先的角度开始设计产品，首先我们先想怎么抽象状态 然后面向数据库的表结构直接开始设计，这么设计的好处是可以从工程上避免特殊的业务逻辑，避免不必要的冗余而且足够简洁，适合在一些登录流程设计，验证码流程设
TOPIC
产品设计
从事件触发来看现在的 dify
dify 当前存在 start 节点其有两个职责 其一是系统变量其二是 user input，后者简单来说就是开发者定义终端用户传值，然后开发者将placeholder （形参）用于构建函数 这么做也好理解从工程来看一个 workflow
linear 产品管理
1. linear 要置顶向下设立一系列简单的规则 2. 每一个 cycle 都要服务于一个更长期的愿景 3. 需要有一套机制清理 linear 里无人问津的issue 4. 每一个 issue 一定要有负责人 5. 我现在的产品决策不够透
关于老麦想法的初步梳理
初步印象： 老麦提出了一个很好的问题 这个问题本身有足够的价值 就是在无论是人工 workflow 还是 AI generator 的交付物从 60 分到 90 分的价值 提出了一些方法 主要是一套循环逻辑从 dsl 的生成校验到评估 已知
workflow 中的代码节点
之前代码所有的代码节点在工作流当中都是一个打替补的作用，为什么这么说，因为对于拖拉拽这些预编排组件 解决不了的灵活性问题才交给代码节点 我们可以说一个低代码平台设计的灵活性其实可以以代码节点出现的频率来决定，因为，理想情况下一个完美的工作流
插件 ide
抖音和剪映
debugging
对于 workflow 这样的产品可以认为投产前的所有测试包括编排过程都算调试， 在程序开发中往往会有开发，测试，生产的过程。 如果从头到尾让AI 生成一个脚本爬取 youtube 字幕 然后在python ide 中点击运行然后开启调试模
编码与 workflow
workflow 是一种流程的表示形式，代码也是 但是代码在过去对于人们来说意味着理解成本和学习成本，所以 zapier 的出现降低了高频应用自动化过程当中胶水代码的构建成本，dify 的出现降低了模型和工具连接还有模型和模型连接之中的胶水