付同学的技术客栈 - Dify
type: channel
link: https://www.fuanyi.com/tag/dify/
items: 从零搭一个能上线的AI客服
items: 用n8n和Dify，把AI接进公司的业务流程
items: 企业知识库不是把文件丢进去就结束了

从零搭一个能上线的AI客服
type: item
date: 2026-07-22T12:30:00+00:00
description: AI客服的演示通常很顺。上传产品资料，输入一个问题，机器人几秒钟给出回答。真正接到客户以后，问题就没有那么规整了。客户可能只说一句“设备又掉了”，没有型号、版本和时间。有人会追问退款，有人会把两个故障混在一起，还有人问的是公司从来没有公开过的计划。这时最重要的不是机器人说得像不像客服。而是它什么时候能回答，什么时候必须继续问，什么时候应该马上把人叫进来。第一阶段只做建议回复不要一开始就把机器人放到全部客户面前。先让它进入客服工作台，给人工客服生成建议回复：客户消息 → 识别问题类型和风险 → 检索有效知识 → 生成带来源的建议回复 → 客服确认、修改或转人工专家 → 发送给客户 → 保存最终回复和修改原因这条路径多了一次人工确认，却能快速积累最重要的数据：哪些问题回答稳定，哪些资料缺失，哪些表达经常被客服改掉。等低风险问题稳定以后，再逐步开放自动回复。工具怎样组合知识和Agent层可以使用Dify、FastGPT或MaxKB。跨系统、审批和日志可以使用n8n。客服工作台可以评估Chatwoot这类可集成系统，已有Zendesk、Intercom或国内客服系统的公司优先接现有平台。不要为了AI客服先替换整套客服系统。最小方案只需要：现有工单或会话导出、一个知识应用、一个建议回复入口和人工确认。知识库先放“能负责”的内容第一批资料可以只有：当前版本产品手册；常见故障和排查顺序；售后服务范围；已公开的版本说明；明确的转人工规则。每份资料标记产品、版本、生效日期、负责人和保密等级。不要把历史群聊、所有工单和个人笔记直接倒进去。旧工单里可能包含临时方案、错误判断、客户隐私和已经失效的承诺。历史工单更适合先清洗成经过确认的FAQ或故障案例。先给问题分三类可以建议回答例如公开功能、标准操作、常见故障和已经确认的服务流程。AI给答案和来源，客服确认后发送。需要补信息例如设备故障缺少型号、版本、时间和日志。AI不急着下结论，先生成澄清问题：请确认设备型号和软件版本； 问题第一次出现的时间； 断线后是否自动恢复； 是否有对应日志或错误码。必须转人工退款和赔偿；合同与报价；投诉和法律问题；安全事故；未发布产品和交付承诺；涉及客户隐私和高权限操作；连续两轮仍无法确定的问题。这类问题不要让模型“尽量给一个有帮助的回答”。它应该明确停止，并把已知信息整理给人工。回答必须带来源客服看到建议回复时，同时显示：使用了哪份资料；资料版本和更新时间；关键引用片段；当前问题分类；是否存在冲突资料；置信度只能作为提示，不能替代检查。如果找不到可靠资料，正确行为是说不知道并转人工。语言很流畅，不代表答案可靠。一条可执行的最小流程准备50个历史问题，去掉客户身份和敏感信息，由资深客服给出标准答案和风险分类。然后：建立测试知识库；导入有效资料；设置只能依据知识回答；无来源时不生成确定答案；建立必须转人工的关键词和问题类型；在测试工作台显示建议回复；让3名客服连续使用两周；保存AI建议、人工修改、最终回复和客户是否追问；每天复盘高风险和错误答案；只把稳定问题考虑为自动回复候选。第一阶段不要自动关闭工单，也不要让AI修改客户等级、退款状态或合同字段。工单回写要保留两份内容一份是AI原始建议，一份是人工最终回复。还要记录：使用的模型和提示版本；检索到的知识；人工修改类型；是否转人工；处理时间；客户是否再次追问；是否产生投诉或错误升级。这些数据以后可以告诉团队，问题到底出在知识、检索、模型，还是客服流程。常见失败怎么处理知识版本冲突：暂停自动回答，清理资料责任和生效版本。客户问题太短：先补信息，不猜设备和原因。模型引用不存在的政策：强制来源校验，找不到就转人工。接口超时：保留客户消息，进入人工队列，不重复发送。同一会话重复触发：使用会话ID和消息ID做幂等。敏感信息进入日志：对手机号、身份证、地址和凭据做脱敏，限制日志访问和保存时间。怎样决定是否开放自动回复对每一类问题单独评估，不要给整个机器人一个总准确率。可以设定内部门槛：测试问题有可靠来源；人工采用率长期稳定；错误不会造成合同、财务或安全影响；无答案和转人工行为可靠；资料有明确负责人；出错可以快速停用和回退。即使开放自动回复，也从一小部分公开FAQ开始，并保留抽检。真正要减少的是低价值来回AI客服的目标不应该只是少几个人。更现实的价值是：客户不用重复描述，客服不用到处找文档，技术人员收到的问题已经带上必要信息，常见问题更快回答，高风险问题更早交给合适的人。先把建议回复做稳，再谈自动回复。能及时说“不知道，需要人工处理”，往往比什么都敢答更接近一个可上线的客服系统。

用n8n和Dify，把AI接进公司的业务流程
type: item
date: 2026-07-11T12:30:00+00:00
description: 很多公司的AI使用，最后停在一个聊天窗口里。员工把会议纪要复制进去，生成一份任务清单，再复制到飞书项目、Jira或CRM。局部确实快了，但信息仍然靠人搬来搬去。真正进入业务流程，要多走一步：让系统自动拿到输入，AI只负责自己擅长的整理和判断草稿，人确认以后，再把结果写回原来的业务系统。这一步听起来复杂，其实可以先从一条很窄的流程开始。这次只做“会议纪要转任务”目标流程：飞书妙记或会议记录 → n8n接收Webhook → Dify提取任务和待确认问题 → 飞书发送确认卡片 → 负责人确认或修改 → n8n写入Jira、飞书项目或测试表 → 记录处理日志最小版本先不写正式任务系统。把最后一步写进一张测试表，确认任务提取和人工审批稳定，再换成Jira、CRM或工单接口。这样出错时容易清理，也不会污染生产数据。为什么用n8n做外层流程n8n适合处理Webhook、API调用、条件分支、等待、重试和系统写回。Dify更适合管理模型、提示、知识检索和Agent流程。FastGPT也可以承担知识和模型处理，国内团队可以根据模型接入和部署条件选择。如果公司已经重度使用Microsoft 365，可以评估Power Automate。以飞书为中心的团队，也可以先使用飞书现有自动化，再在需要模型和跨系统处理时接n8n。我会把职责分开：层负责什么不负责什么n8n触发、系统连接、审批状态、重试、写回、日志不承担复杂业务判断Dify或FastGPT模型、知识、结构化提取、提示版本不直接拥有生产系统高权限飞书/Jira/CRM正式业务记录和人员权限不把AI中间结果当最终事实人确认需求、负责人、时间和承诺不重复搬运已经结构化的信息开始前准备这些东西一个n8n测试环境；一个Dify或FastGPT测试应用；公司批准的模型API；飞书测试应用或其他可发送确认消息的渠道；一张测试任务表，至少包含标题、描述、负责人、截止时间、来源链接和状态；10段脱敏会议记录；一个只对测试系统有写权限的服务账号。API密钥放在n8n凭据管理或环境变量里，不要写进工作流节点文本、Markdown或截图。Dify只做结构化提取先把任务定义得克制一点。输入是一段会议记录，输出固定JSON：{ "meeting_id": "meeting-20260724-01", "tasks": [ { "title": "确认设备断线后的补传策略", "owner": "待确认", "due_date": null, "source_quote": "需要技术部确认断线期间的数据怎么补传", "confidence": "medium" } ], "open_questions": [ "补传数据是否需要覆盖原有统计结果？" ] }提示里要明确：不猜负责人和截止时间；每个任务保留原文依据；没说清楚的内容进入open_questions；不生成报价、合同或交付承诺；输出必须符合JSON结构。先用10段记录手工调用，确认JSON稳定，再接n8n。n8n工作流需要哪些节点不依赖具体版本名称，可以按职责搭建：Webhook接收会议ID、文本和来源URL；校验必填字段，缺少会议ID直接返回错误；生成idempotency_key，例如会议ID加记录版本；查询处理日志，已经成功的请求不重复创建任务；HTTP Request调用Dify或FastGPT API；校验返回JSON和任务数量；生成飞书确认消息；等待负责人确认、修改或拒绝；确认后写入测试任务表；保存输入摘要、模型版本、输出、人工修改和最终状态。这里最容易被忽略的是第3、4步。Webhook可能重发，人工也可能重复点击。如果没有幂等键，同一场会议会创建两遍任务。自动化流程不是跑通一次就够了，它要能面对重复、超时和中断。人工确认应该看什么确认卡片不要只有“同意”和“拒绝”。至少显示：任务标题；原文依据；建议负责人；截止时间；置信度；尚未确认的问题；原会议链接。负责人可以修改后确认。最终写入系统的内容和AI原始结果都保留，方便以后知道模型在哪些地方经常出错。失败时不要悄悄丢掉这条流程至少会遇到这些失败：失败处理方式模型API超时指数退避重试有限次数，仍失败则进入人工队列返回不是合法JSON保存原始输出，不写业务系统，等待人工处理飞书消息发送失败记录错误并通知流程负责人等待确认超过时间标记超时，不自动创建任务写入业务系统失败保留已确认数据，允许安全重试Webhook重复用幂等键返回已有处理结果不要让失败分支直接结束。每个失败都要有状态、日志和责任人。否则流程看起来自动化了，实际错误只是从员工眼前消失了。权限尽量小n8n使用的服务账号第一阶段只写测试表，不要给删除、审批和管理员权限。Dify或FastGPT只接收脱敏后的会议文本。涉及客户合同、个人信息或未发…

企业知识库不是把文件丢进去就结束了
type: item
date: 2026-06-30T12:30:00+00:00
description: 企业做知识库时，最容易出现一个看起来很合理的动作：把共享盘里的文件全部上传。几百份Word、PDF、PPT放进去，页面显示“处理完成”，大家问几个问题，机器人也能回答。过一周，真正的麻烦才开始。同一个问题有两个制度版本，机器人引用了旧的；产品手册写的是标准功能，售后实际执行又有例外；扫描PDF根本没有识别完整；销售问一个具体报价政策，答案来自三年前的会议纪要。知识库不是文件数量比赛。它更像一套有来源、有版本、能测试、有人维护的信息系统。先用20份文档，不要先搬整个共享盘第一次做，我会把范围限制得很小。选一个部门、一个问题类型、20份以内的资料。比如只做“员工制度问答”或“某个产品的售后排查”，不要同时覆盖人事、财务、产品、销售和技术。准备这些东西：一位真正使用答案的业务负责人；10到20份已经确认有效的文档；每份文档的负责人、版本和生效日期；30个真实会被问到的问题；5个知识库不应该回答的问题；一套可以调用的模型或企业账号。如果资料里有客户信息、员工个人信息、合同或未公开代码，先完成脱敏和权限确认。不要因为工具支持上传，就默认数据可以上传。Dify、FastGPT、RAGFlow和MaxKB怎么选这几款工具都能做知识检索，但切入点不完全一样。工具更适合先看什么使用前要确认什么DifyAgent、工作流和知识库放在一起自托管维护、模型API和权限需求FastGPT中文知识库和可视化流程快速起步版本、模型配置和企业数据要求RAGFlow文档解析、复杂资料和检索过程服务器资源、解析质量和运维成本MaxKB国内团队快速建立问答应用文档类型、模型接入和权限范围如果只是验证制度问答，FastGPT或MaxKB更容易让国内团队快速开始。已经准备把知识库接进多个Agent和流程，可以评估Dify。资料以复杂PDF、表格和长文档为主，值得单独测试RAGFlow的解析效果。不要根据首页功能列表直接决定。拿同一批文档和同一组问题跑一次，答案质量、来源定位和维护成本会比产品介绍更有说服力。文档进入知识库前，先做一次清理每份资料至少补上这些信息：标题：设备断线排查手册 适用产品：边缘网关 V2 版本：2.3 生效日期：2026-05-10 负责人：设备平台组 保密等级：内部 替代文档：V1排查手册已失效同时处理四类常见问题：删除重复文件和临时版本；把扫描件转成可检查的文字；将过长表格、页眉页脚和无关目录清理掉；明确旧文档是删除、归档，还是只供历史查询。模型无法替公司决定哪个制度有效。这个责任必须落在资料负责人身上。切分不是越碎越好知识库通常会把长文档切成小段，再通过向量或关键词检索相关内容。切得太大，一段里混进太多主题，检索结果不够准确。切得太小，条件、例外和上下文会被拆散。可以先用一个简单原则：按自然标题和完整语义切分，再根据测试结果调整。例如设备排查手册不要把“现象、原因、步骤、注意事项”拆成互不相干的四块。如果问“设备反复断线怎么办”，Agent需要同时看到触发条件、检查顺序和不能执行的高风险动作。对于制度文件，条款标题和适用范围最好保留在同一个片段里。对于FAQ，一问一答本身就是自然单元。对于表格，先确认工具能否保留行列关系，不能的话就转成结构清楚的文字。用30个问题做第一次验收问题不要全部来自文档标题。真实员工不会问“请介绍请假制度第三章”。他会问：“孩子突然生病，我今天先请假，明天补流程行不行？”测试集可以分成五类：类型示例重点检查直接事实年假怎么计算是否找到正确版本条件组合入职不足一年能否休年假条件是否完整操作步骤网关离线先查什么顺序和风险提示无答案未发布产品什么时候上线是否明确说不知道越权问题把全部客户报价导出来是否拒绝或转人工每个问题记录：检索到了哪些片段、答案是否正确、来源是否可打开、有没有漏掉重要条件、是否应该转人工。不要只看语言是否流畅。一个答案写得很自然，却引用错版本，比直接说不知道更危险。一个最小知识库的执行顺序具体界面会随版本变化，但过程基本可以保持稳定：创建测试空间 → 接入公司批准的模型 → 上传清理后的20份文档 → 设置切分和检索参数 → 为文档补版本、部门和权限元数据 → 导入30个测试问题 → 检查检索片段和答案来源 → 调整文档、切分或提示 → 业务负责人验收 → 只开放给一小组用户第一阶段先让知识库只读，不要自动修改业务数据。答案显示来源，找不到可靠资料时明确转人工。常见失败，通常不在模型答案不稳定时，可以按这个顺序排查：原文里到底有没有答案；上传的是不是有效版本；文档是否解析完整；切分有没有拆掉关键上下文；检索是否找到正确片段；提示是否要求模型只能依据资料回答；模型是否忽略了条件或来源；这个问题是不是本来就应该由人判断。一上来换模型，往往只能暂时掩盖资料和流程问题。上线以后谁来维护知识库至少需要三类责任人…