Dify 是 AI 应用搭建 SaaS，主要场景：文本信息处理的生产力提升

  • 自动化工作流提升个人生产力
  • AI 应用开发者低门槛搭建原型，加速完成 POC 验证，团队内对齐 AI 能力边界和效果
  • 细分场景搭建 AI 应用

展开详细说明：

  • 个人：规则明确重复性的事务工作，比如表格字段加工、数据标注、日报转发，通过自动化来提高效率减少人工错误；但很多现有工作流自动化产品加 AI，会覆盖这部分场景
  • AI 应用初创团队、独立开发者：低门槛搭建原型和上线，快速完成 POC 验证，完成团队对 AI 应用能力边界和效果对齐
  • 有 IT 资源但不强的公司：零售、医疗、制造业，细分场景或节点搭建 AI 应用，客服机器人、客户评价分析、知识问答助手

Dify 类产品目前边界：相比用 SaaS 或软件，无明显优势

  • 卡点：
    • toB 业务 100% 准确：LLM 生成有幻觉，尤其是文本生成节点
    • LLM 和其 API 处理延时难以商用（通过模型本地部署解决）
    • 不够灵活、无法实现业务流程闭环，比如无法根据 webhook 触发、定时任务
    • 复杂外部环境交互，难以实现授权和认证更新
  • 编排效率和体验
    • 非技术同学使用门槛：复杂任务、代码节点、复杂输入输出格式转化
    • 节点和工作流的调试效率

对于研发能力较强的团队，比如直接用 LLM API 灵活可控，高效调试。而用 Dify 交付 toB AI 应用，需要研发和业务团队配合；Dify 现在用户分为公司内研发和业务团队，分别视角：

  • 对于不懂技术的业务团队，Dify 痛点在于：
    • 可以通过学习 Dify 来实现：复杂工作流的编排学习成本高，具体分为：
      • 业务 SOP 抽象
      • 程序逻辑：循环、if-else、分支、参数输入和输出
      • LLM 知识：什么任务选什么模型最合适
    • 难以通过学习 Dify 来实现有技术门槛的事情：
      • 数据转换和抽取需要代码定制实现
      • LMM 推理和 API 延时通过工程优化实现
      • 拖拽式编排和普通 prompt engineering，难以降低 token 成本
      • 工作流批量处理大规模数据时候的耗时和性能，需要研发参与优化

Dify 产品经理会怎么优化？

方向：

产品：

  • 团队协作、RABC 权限管理、连通企业数据和工作流，闭环完成业务操作
  • 增加集成数量（n8n 有 1000 多个集成）、工作流模版和引导

运营：

  • 输出并推广更多工程上的优秀实践
  • 从社区挖掘和推广更多好的工作流模版

使用体验优化记录：

  • 每个节点调试有明确反馈：成功、失败和失败原因；Coze HTTP 请求节点没有反馈；Dify Python 代码节点报错看不懂
  • 交付结果的验收、评估和调试如何提升效率：
    • 每个节点的数据可以长久储存，方便整体 workflow 结果不行，对节点调试；
    • Workflow 级别结果对比

Dify 或者泛 AI 应用产品，交付物现在适合什么场景：

任务价值高任务价值低
容错度高创意内容生成个人工作助手
容错度低医疗、金融、法律？

任务价值高，比如大于 1 美金，容错度也高；任务价值低、容错度低的场景不适合 AI 应用

哪里有任务价值高但容错度高的场景啊，创意内容生成呢？

标注场景：切入点锐利

  • 数据加工（标注、清洗）属于规则和流程简单的业务，静态编排：节点和路径都提前确定，多为顺序和并行执行
  • 内部工具：数据格式定义清晰，第一步开始就是结构化数据，无需复杂抽取和转换，也无需和外部系统交互

Dify 的交付物作为 Agent，如何评估自主或智能程度？

  • Agent 定义为自主感知环境、规划决策、调用工具、基于结果持续迭代的智能体。Dify 如果只根据写死的任务编排，不切换工具，就不是 Agent；如果某个搜索任务中循环思考，切换搜索关键词，也不是自主 Agent，因为 Loop 节点也是人工编排背后代码写死的
  • 如果将编排分为节点动态和路径动态两个维度，Dify 的交付物这么看：

    • 静态编排（并行或串行）：节点和路径都固定

    • 动态程序编排（LLM router）：节点固定、路径不固定

    • 自主编排：节点和路径都不固定

      节点动态路径动态
      静态编排❌❌
      程序动态编排❌✅
      自主编排✅✅