这条链路解决什么问题
公司有一堆内部文档、产品 FAQ、操作手册和售前资料，每次新人入职或客户问问题都要翻半天。想做一个问答助手——不是那种什么都能聊的通用 AI，而是一个只基于你的资料回答、回答错了能追溯来源的知识库机器人。
Kimi：先把散资料收拢成结构化的知识层
具体操作
- 打开 kimi.ai，切到 Agent 模式
- 把你的资料分批上传：PDF 操作手册、产品文档 Word、FAQ 网页链接、内部 Wiki 页面
- 给它指令："请把这些资料按 [产品功能/常见问题/操作流程/定价政策] 四个类别整理，每个类别列出核心知识点和对应的来源文档"
为什么先走这步
- 垃圾进垃圾出：如果直接把原始散文件丢进知识库，检索效果会很差。先做一轮整理，确认哪些内容有用、哪些重复、哪些过时。
- 发现资料缺口：整理的过程会暴露出"这个问题用户经常问但我们没有文档覆盖"的情况。先把缺口补上，比上线后发现回答不了更好。
- 划清边界：哪些问题可以让 AI 自动回答（产品功能、操作步骤），哪些必须转人工（退款、投诉、法律相关）。这个边界在这步就要定。
这步的产出
一份结构化的知识清单 + 一份明确的"能回答/不能回答"边界文档。
NotebookLM：用真实问题测试资料质量
具体操作
- 去 notebooklm.google.com 创建一个 Notebook
- 把整理好的核心资料（建议 10-15 份最重要的）上传进去
- 模拟用户提问，测试回答质量
测什么
拿你平时收到的真实用户问题来测，不要自己编问题：
- "你们的产品支持 XX 功能吗？" → 看它能不能从资料里找到准确答案
- "如何设置 XX？" → 看它给出的步骤是否完整
- "XX 和 YY 有什么区别？" → 看它能不能做出对比
- "退款流程是什么？" → 如果这个在你的"不能回答"列表里，看它会不会瞎编
关键细节
- 至少测 20 个真实问题：不要测 5 个觉得效果还行就进入下一步。20 个问题能覆盖更多边界情况。
- 记录失败的问题：哪些问题回答得不好？是因为资料没覆盖，还是资料写得不够清楚？根据失败记录回去补资料。
- 看引用标注：NotebookLM 的回答会标注来源。点进去确认它引用的内容是否真的支撑了它的回答。偶尔会出现"引用了但没说到点上"的情况。
这步的产出
一份测试记录：哪些问题回答准确、哪些需要补资料、哪些属于不应该回答的范围。
Dify：搭建可通过 API 调用的知识库服务
具体操作
- 登录 Dify，创建应用（选 Chatbot 或 Workflow）
- 创建知识库，上传经过前两步验证的资料
- 调分段参数：这步很关键。进入知识库设置：
- Chunk Size 建议 500-800 token（中文文档偏 500，英文偏 800）
- Chunk Overlap 设 50-100 token
- 如果文档有清晰的标题结构，选"按段落分段"
- 上传后检查分段结果，有明显断裂的手动调整
- 在编排界面拖 Knowledge Retrieval → LLM 节点，配置提示词
提示词模板建议
你是 [公司名] 的客服助手。请严格基于以下检索到的知识库内容回答用户问题。
如果知识库中没有相关信息，请回复"这个问题我暂时无法回答，建议您联系人工客服"。
不要编造信息，不要回答与 [公司名] 产品和服务无关的问题。
检索到的相关内容：
{context}
用户问题：{query}
关键细节
- 用 NotebookLM 里测过的那 20 个问题再测一遍：看 Dify 的回答质量是否和 NotebookLM 差不多。如果差距大，通常是分段参数或提示词的问题。
- 模型选择：知识库问答场景不需要最强的模型。GPT-4o-mini 或 Claude 3.5 Haiku 性价比更高，延迟也更低。
- 发布后拿到 API endpoint：这是后面 n8n 要调用的接口。
这步的产出
一个通过 API 可调用的知识库问答服务，回答质量已经用真实问题验证过。
n8n：接入业务入口
什么时候进到这步
只有当 Dify 的问答质量已经稳定，才把它接进业务流程。如果 Dify 那边还在频繁调整，这步做了也白做。
具体操作（以企业微信为例）
- 在 n8n 创建 Workflow
- 触发器：企业微信收到用户消息（通过 Webhook）
- HTTP Request 节点：调用 Dify API，传入用户问题
- IF 节点：判断回答是否包含"无法回答"或"联系人工客服"
- 如果能回答：自动回复用户
- 如果不能回答：发通知给人工客服，附上用户问题和上下文
必须配的节点
- Error Trigger：任何节点失败时发告警（至少发一条飞书/钉钉消息）。不配的话节点挂了你都不知道。
- 日志记录：每次问答写一条到 Google Sheets 或数据库，记录问题、回答、是否转人工。上线一周后看这个数据能帮你持续优化。
这步的产出
一个已经接入业务入口的问答助手，能自动回答能回答的问题，不能回答的会转人工。
上线后的持续优化
上线不是结束，是开始。每周做一次：
- 看日志里"转人工"最多的问题是哪些 → 补对应的知识库资料
- 看有没有回答了但回答不准确的案例 → 调整分段或提示词
- 看有没有不应该回答但回答了的案例 → 在提示词里加限制
精简版
如果只是在团队内部测试可行性：Kimi 整理资料 → NotebookLM 测试效果。跑通了再决定要不要上 Dify 和 n8n。
