源资料到知识库问答助手

这条流程在处理什么问题

公司内部往往散着很多文档、FAQ、操作手册和售前资料。新人入职要查，客户提问也要查，最后总会有人在群里反复翻旧文件。要做的不是一个什么都能聊的通用助手，而是一个只基于现有资料回答、回答错了还能回到原始出处的问答工具。

先用 Kimi 把资料整理出来

第一步不要急着建知识库。先把 PDF 操作手册、产品 Word 文档、FAQ 网页和内部 Wiki 页面分批交给 Kimi 处理，让它按产品功能、常见问题、操作流程、定价政策这些类别整理一遍。这样做有两个直接好处：一是能把散文件先归类，二是能先看出资料里哪里缺内容、哪里已经过时。

这一步还要顺手做一件事，就是把问题分成两类：哪些问题可以自动回答，哪些问题必须转人工。像价格例外、合同条款、退款争议这类内容，最好不要混进自动问答范围里。先把这件事写清楚，后面建知识库会省很多麻烦。

再用 NotebookLM 拿真实问题试一轮

资料整理完以后，不要马上进入 Dify。先把最核心的 10 到 15 份资料放进 NotebookLM，然后拿真实问题去问。问题最好来自平时的客服记录、售前咨询或内部同事常问的问题，而不要自己临时编一批“看起来像问题”的句子。

测试时主要看三件事：第一，回答有没有回到正确来源；第二，资料里没有写的内容，它会不会硬编；第三，同一个问题换个说法再问一次，结果会不会明显跑偏。如果这一步都不稳定，后面把它接进业务入口，只会把错误更快地送到用户面前。

然后在 Dify 里建知识库问答服务

等资料和测试结果都比较清楚以后，再去 Dify 建 Chatbot 或 Workflow。上传资料以后，先检查分段结果。Chunk Size、Chunk Overlap 和分段方式不要直接用默认值，中文长文档经常需要手动调整。明显断裂的地方要改，不然检索出来的内容和用户问题很容易对不上。

提示词也不用写得太绕。知识库问答最重要的要求只有几条：只根据检索内容回答；资料里没有的内容，直接说明暂时无法回答；不要去回答和公司产品无关的问题。把这几件事写明白，通常比加很多修饰性的规则更有用。

发布之前，最好把 NotebookLM 里已经测过的那批真实问题再跑一遍。对比一下两边回答是不是大体一致。如果 Dify 这一轮还经常答偏，问题多半不在业务入口，而还在资料或分段本身。

最后再让 n8n 接到业务入口

只有当前面的问答质量已经比较稳定，才值得把它交给 n8n 去接消息、表单、工单系统或其他业务入口。接法本身并不复杂：收到用户问题后，用 HTTP Request 调 Dify API，再根据返回结果判断是自动回复还是转人工。

这一段真正不能省的是日志和人工确认。至少要把问题、回答、是否转人工记录下来，后面才知道哪些问题最常答错，哪些内容本来就不该自动回复。如果涉及客户沟通、金额、政策解释，人工确认也最好留着，不要急着全自动。

上线以后要继续看的东西

系统上线以后，真正要盯的通常是三类问题：哪些问题最常被转人工，哪些问题回答了但答得不准，哪些本来就不该自动回答却被放过去了。看清这三类问题以后，后面的更新方向才会明确，是补资料、改分段、改提示词，还是直接把某类问题移出自动回答范围。

如果只是内部先验证可行性，做到 Kimi 整理资料，再加 NotebookLM 测试回源，已经能看出这件事值不值得继续做。等这两步结果清楚，再往 Dify 和 n8n 走，后面会省很多重复调整。