Dify 应用类型怎么选？聊天助手、工作流和文本生成有什么区别？

Dify 的应用类型可以按“交互方式”和“任务复杂度”来选：需要持续对话就选聊天助手，需要一次输入一次输出就选文本生成，需要多步骤判断、调用工具或接入业务系统就选工作流，需要基于企业资料回答问题就把应用和知识库结合起来。不要只看模板名字，真正要判断的是用户怎么发起任务、结果是否需要人工确认、流程里有没有分支和外部接口。

聊天助手适合客服、内部助手、售前问答这类多轮场景，重点是上下文记忆、知识库引用和回答边界。文本生成适合文案、摘要、改写、翻译等批处理任务，输入输出结构更固定，测试成本也更低。工作流适合把“判断、检索、调用接口、生成结果”串起来，例如先识别工单类型，再查知识库，再调用 CRM，最后生成回复。

选择时可以用一个简单判断：如果用户会连续追问，优先聊天助手；如果用户只提交表单并拿结果，优先文本生成；如果中间要走条件分支、变量传递、HTTP 请求或人工审核，优先工作流。知识库不是单独的业务形态，而是很多应用的能力底座。它能提升事实准确性，但不能替代流程编排，也不能自动解决权限、更新和质量管理。

追问

聊天助手和知识库问答是不是一回事？

不是，聊天助手强调对话体验，知识库问答强调答案依据和资料检索。一个聊天助手可以接知识库，也可以不接；知识库也可以被工作流或 API 调用。取舍在于，如果业务重视连续沟通和语气，就做聊天助手；如果重视可追溯和标准答案，就把知识库配置放在核心位置。踩坑点是把所有需求都塞进聊天助手，最后既没有流程控制，也很难评估答案质量。

什么时候应该用工作流，而不是普通聊天应用？

只要任务里出现“如果……就……否则……”这类分支，工作流通常更合适。比如报销咨询要先判断城市、岗位、费用类型，再查不同规则，普通聊天应用很容易把条件混在一起。工作流的优势是可观察、可调试、可插入工具调用，缺点是搭建成本比聊天助手高。边界是简单 FAQ 不需要工作流，过度编排会让维护者被节点和变量拖住。

文本生成应用适合哪些稳定场景？

文本生成适合输入结构相对固定、输出格式明确的任务，比如商品描述、会议纪要摘要、邮件润色、关键词扩展。它的好处是容易做模板、容易批量评估，也方便接入后台系统。取舍是它不擅长多轮澄清，如果输入信息缺失，生成结果会看起来完整但事实不可靠。实际项目里最好把必填字段、输出 JSON 结构和长度限制写清楚，减少模型自由发挥。

企业内部平台选应用类型时最容易踩什么坑？

最常见的坑是先选了一个好看的模板，再反过来迁就业务流程。另一个坑是忽略权限边界，比如 HR 制度、客户资料和财务数据不能简单放进同一个知识库。应用类型只是外壳，真正决定上线质量的是数据权限、日志审计、失败兜底和人工接管。建议先画出用户入口、输入字段、数据来源、输出结果，再决定用聊天助手、文本生成还是工作流。

如果一个需求同时需要对话、知识库和接口调用，该怎么拆？

可以把聊天助手作为入口，把知识库作为事实来源，把工作流作为后台动作。用户自然提问后，系统先识别意图，再决定是直接检索回答，还是进入工作流调用接口。这样体验上像一个助手，内部却有清晰职责分层。边界是不要让模型直接决定高风险操作，涉及下单、删除、审批这类动作时，必须加确认节点或人工审核。