AMZ
用户中心
FBA 与物流

Dify知识库教程：不用写太多代码，也能搭建一个RAG问答机器人

Dify 降低的是应用搭建门槛，不是知识治理门槛；真正可用的机器人要从资料、检索、提示词、测试和日志开始

公众号文章库2026/7/717 分钟阅读

Dify 降低的是应用搭建门槛，不是知识治理门槛；真正可用的机器人要从资料、检索、提示词、测试和日志开始

**摘要：**Dify搭RAG机器人

**关键词：**Dify知识库、Dify RAG、AI问答机器人、跨境客服SOP、亚马逊运营知识库

封面：Dify知识库教程：不用写太多代码，也能搭建一个RAG问答机器人

本文是「AI知识库完整教程」第 11 课。

很多团队想做机器人，最后做成了更会胡说的资料夹

跨境团队最容易出现这种场景：客服问“这个产品能不能水洗”，运营问“德国站标题能不能这样写”，新人问“退货破损怎么处理”，老板问“广告搜索词为什么要分组”。

资料其实都有：产品说明书、售后 SOP、客服话术、Listing 版本、广告复盘、Amazon 规则、内部培训文档。但它们散在飞书、网盘、Excel、聊天记录和个人电脑里。

于是团队想搭一个 AI 问答机器人。Dify 看起来很合适：可视化搭应用、能接知识库、能做工作流、能发布给团队使用。

但这里有个关键判断：Dify 降低的是应用搭建门槛，不是知识治理门槛。资料乱、版本乱、权限乱、测试不足，机器人上线后只会把混乱内容更快地说出来。

先理解 Dify 的位置：它是应用平台，不只是文件问答框

Dify 官方文档说明，Knowledge 是可集成到 AI 应用中的自有数据集合。它通过 RAG 工作：先检索相关信息，再把检索内容和用户问题一起交给 LLM，最后生成更准确、更相关、较少幻觉的回答。

这句话对应到业务，就是：员工提问，系统先查你自己的 SOP、产品资料和规则，再让模型组织答案。

Dify 的价值不只是“上传文件问问题”，而是把知识库接进应用和工作流。你可以做客服 SOP 机器人、产品资料问答、新人培训助手、售后政策查询、广告复盘助手，也可以通过 API 或 Web App 发布给不同使用者。

所以本文的重点不是教一个按钮路径，而是教一套最小可行架构：知识库怎么建、检索怎么调、工作流怎么设计、提示词怎么限制、测试怎么做、上线后怎么用日志继续改。

  • 知识库负责提供事实上下文。
  • 检索设置负责决定先找哪些内容。
  • LLM 节点负责把检索结果组织成回答。
  • Answer 节点负责把最终回复返回给用户。
  • 日志和反馈负责发现机器人答错的地方。

第一步：先选一个窄场景，不要一上来做公司万能机器人

第一个 Dify RAG 机器人，不建议做“公司知识库助手”。范围太大，资料太杂，测试题也难设计。

更好的起点是一个高频、边界清晰、资料相对稳定的场景。比如“美国站客服售后 SOP 问答”“新品 Listing 合规检查助手”“广告搜索词复盘助手”“新人上架流程问答”。

以美国站客服售后 SOP 为例，机器人只回答退货、换货、破损、迟发、尺寸争议、使用方法、保修政策这几类问题。涉及退款金额、平台争议、法律承诺、个案补偿，一律提示人工处理。

范围窄不是保守，而是为了让你能做测试、能追责、能复盘。第一版机器人能稳定回答 80 个高频问题，比一个看起来什么都会、实际经常乱答的万能助手更有商业价值。

  • 好场景：高频、边界清楚、资料来源明确、错误代价可控。
  • 坏场景：所有部门都能问、所有资料都能查、没有人工确认边界。
  • 第一个目标：让机器人解决一个岗位的一类问题。
  • 上线范围：先给内部 3 到 5 个人试用，再逐步扩大。

第二步：资料要先整理成 AI 能检索的样子

Dify Quick Create 文档说明，创建知识库要导入数据、配置 chunk、设置索引和检索，等待数据处理完成。这里最容易被忽视的是：导入之前，资料本身必须先整理。

跨境团队的 SOP 往往不是知识库格式，而是给人看的长文档。里面有旧版本、有截图、有口头规则、有例外情况，还有很多“看情况处理”。这种资料直接上传，检索结果很容易混乱。

建议把每份资料先拆成小文档：一个文档只讲一个问题，一个问题只保留当前有效版本。标题必须能被检索到，正文必须说明适用范围、操作步骤、禁止事项和人工升级条件。

比如“破损到货如何回复”不要埋在 20 页客服手册里，而要独立成文档：适用站点、适用产品、客户需要提供什么信息、第一轮回复话术、不能承诺什么、何时转主管。

  • 每份文档只回答一类问题。
  • 文档标题使用业务语言，不只用内部编号。
  • 正文保留适用站点、产品线、版本、更新时间、负责人。
  • 旧版本资料先归档，不要和新规则混在一起。
  • 敏感数据、客户信息、订单号、店铺后台截图先脱敏。

第三步：用元数据给知识库加业务筛选器

Dify Metadata 文档说明，metadata 是描述数据的数据，可以帮助查找和管理知识库内容，也可以用于过滤、组织数据、控制敏感内容和自动化工作流。

对跨境卖家来说，元数据不是技术细节，而是业务边界。很多答错不是模型不行，而是系统拿错了站点、产品线或版本。

比如同一个售后问题，美国站和德国站政策不同；同一个产品，旧款和新款配件不同；同一个广告复盘，Prime Day 前后策略不同。如果知识库没有站点、产品线、版本、有效日期，检索就可能把错误资料拿给 LLM。

建议至少设置 10 个字段：market、product_line、sku_family、document_type、version、effective_date、owner、sensitive_level、status、source_url。

  • market：US、DE、UK、JP 等站点。
  • product_line：产品线或类目。
  • document_type：SOP、FAQ、规则、产品事实、广告复盘。
  • version/status：当前有效、待审核、已归档。
  • sensitive_level：公开、内部、敏感、禁止机器人回答。

第四步：索引和检索设置，决定机器人先看到什么

很多人以为 Dify 搭机器人就是上传资料、选模型、写提示词。真正影响效果的，是检索。

Dify 的索引和检索文档说明，High Quality 索引会用 embedding 把内容块转换成向量，用语义相似度找相关内容；High Quality 模式支持 Vector Search、Full-Text Search、Hybrid Search。文档也说明，Rerank、TopK、Score Threshold 会影响返回哪些 chunk。

用卖家语言解释：Vector Search 像理解意思，适合“客户说这个杯子会不会漏”这类表达不完全匹配的问题；Full-Text Search 像关键词搜索，适合 SKU、型号、保修期、材料名、政策词；Hybrid Search 同时做语义和关键词，适合客服 SOP、产品资料、广告搜索词这类既有业务术语又有自然语言的问题。

第一版内部问答机器人，我通常建议优先测试 Hybrid Search。如果问题里经常有 SKU、站点、政策词，就提高关键词权重；如果问题表达很口语化，就提高语义权重。Rerank 能提升排序质量，但会带来额外模型成本和延迟，要根据业务价值决定。

  • Vector Search：适合用户表达多变、同义词多的问题。
  • Full-Text Search：适合型号、政策词、固定术语、SKU。
  • Hybrid Search：适合多数跨境 SOP 和客服问答。
  • TopK：返回多少候选内容，太少可能漏，太多可能混。
  • Score Threshold：低于相似度阈值的不返回，越高越保守。

第五步：最小可行工作流，不要一开始就堆节点

Dify Knowledge Retrieval 节点文档给出的典型流程很清楚：User Input 收集用户问题，Knowledge Retrieval 搜索知识库，LLM 基于问题和检索结果生成回答，Answer 返回给用户。

第一版机器人就用这个四节点流程，不要一开始堆复杂 Agent、工具调用和多轮条件分支。

等基础问答稳定后，再加 Question Classifier 或 If-Else：比如用户问价格、退款金额、平台争议、法律承诺，就直接转人工或返回固定安全话术；用户问产品使用方法，走产品知识库；用户问售后 SOP，走客服知识库。

工作流设计的原则是：能用规则挡住的风险，不要交给模型自由发挥。模型负责组织语言，不负责替公司做承诺。

  • Start/User Input：收集问题、站点、产品线、用户角色。
  • Knowledge Retrieval：按问题和元数据检索知识库。
  • LLM：只基于检索结果生成回答。
  • Answer：返回答案、来源、待确认项和人工升级提示。
  • 可选分支：敏感问题、资料缺失、资料冲突直接转人工。

第六步：LLM 节点提示词要把边界写死

RAG 机器人最怕两件事：没检索到资料时硬答；检索到冲突资料时选择性解释。

所以 LLM 节点的提示词不能只写“请根据知识库回答”。要明确：只能基于检索结果；没有来源就说资料不足；发现冲突要列出冲突；涉及退款金额、平台政策、医疗安全、法律承诺、价格和合规，必须建议人工确认。

面向客服的机器人，还要要求它输出两层内容：内部判断和可发给客户的话术。内部判断给客服看，可以说明依据和风险；客户话术必须更谨慎，不能暴露内部规则和不该公开的判断过程。

如果你只让它直接生成客户回复，风险会很高。正确做法是先让它辅助客服，再逐步把低风险问题自动化。

一份可直接放进 Dify LLM 节点的提示词

下面这份提示词适合内部客服 SOP 机器人。你可以根据产品、站点和权限要求修改。

你是内部客服 SOP 问答助手，只能基于“知识检索结果”回答。

回答规则：
1. 如果检索结果不足以回答，必须说“当前知识库没有足够资料”，并列出需要补充的资料；
2. 如果检索结果冲突，必须列出冲突来源，并建议人工确认；
3. 不得编造政策、价格、退款金额、保修承诺、法律承诺或平台规则；
4. 涉及退款金额、平台争议、医疗安全、法律风险、账号处罚、客户投诉升级，必须建议人工处理；
5. 输出必须分成四段：
   - 内部判断；
   - 依据来源；
   - 建议处理步骤；
   - 可发给客户的话术草稿；
6. 客户话术不得暴露内部判断、成本、供应商信息、账号风险或未确认政策。

用户问题：
{{query}}

知识检索结果：
{{retrieved_context}}

第七步：测试不是问几句，而是建立问题集

Dify Test Retrieval 文档说明，可以在知识库里模拟用户问题测试检索效果，并临时调整检索设置。真正上线前，至少准备 50 个测试问题。

测试题要覆盖五类：标准问题、同义表达、缺资料问题、资料冲突问题、越权问题。

比如标准问题是“客户收到破损产品怎么办”；同义表达是“杯子寄到就裂了怎么回”；缺资料问题是“澳洲站这个产品保修多久”；冲突问题是旧 SOP 和新 SOP 说法不同；越权问题是“直接承诺给客户全额退款可以吗”。

每个问题都要记录三件事：检索到了哪些 chunk、答案是否引用了正确资料、是否触发了人工升级边界。只看最终回答顺不顺，没有意义。

  • 准确率：是否找到了正确资料。
  • 召回率：有没有漏掉关键文档。
  • 边界：无资料、冲突、敏感问题是否拒答或转人工。
  • 可用性：客服看完是否知道下一步怎么做。
  • 稳定性：同类问题不同说法能否得到一致答案。

第八步：发布后靠日志持续改，不是上线就结束

Dify Logs 文档说明，应用日志会记录 Web app 或 API 中的用户交互、输入输出、响应时间、反馈和系统信息，可用于调试、理解用户行为、收集团队反馈和持续改进。

这对商用机器人非常关键。你上线后要看：哪些问题经常问、哪些回答被点踩、哪些问题检索不到、哪些回答太慢、哪些问题反复触发人工升级。

每周至少做一次日志复盘，把问题分成四类：资料缺口、切片问题、检索问题、提示词问题。

资料缺口就补文档；切片问题就重拆文档；检索问题就调 metadata、TopK、阈值和搜索策略；提示词问题就收紧回答边界。不要把所有问题都归咎于模型。

  • 资料缺口：知识库没有这类内容。
  • 切片问题：正确内容被拆散或标题不清楚。
  • 检索问题：相关 chunk 没排到前面。
  • 提示词问题：LLM 没按规则引用、拒答或转人工。
  • 权限问题：用户不该看到的内容被召回。

跨境实战：美国站客服 SOP 机器人怎么搭

假设你要给美国站客服做一个内部问答机器人，第一版目标不是自动回复客户，而是帮助客服查 SOP 和生成待审核话术。

知识库结构可以分为四个库：产品事实库、售后 SOP 库、客服话术库、平台规则和广告/运营背景库。产品事实库回答材质、尺寸、配件、使用方法；售后 SOP 库回答退换货、破损、迟发、保修；客服话术库提供内部审核过的英文回复模板；规则和运营库记录不能承诺什么、哪些问题要升级。

用户提问时，先收集站点、产品线、问题类型。Knowledge Retrieval 用 metadata 过滤 US、当前版本、对应产品线。LLM 节点输出：内部判断、依据来源、建议处理步骤、可发客户话术、必须人工确认项。

如果客户问题涉及退款金额、平台争议、医疗安全、法律承诺、超出当前 SOP 范围，机器人不直接给结论，只提示升级给主管或人工审核。

  • 第一阶段：只给客服内部试用，不直接发给客户。
  • 第二阶段：只自动化低风险、标准化、资料完整的问题。
  • 第三阶段：把日志中高频失败问题反向补进知识库。
  • 第四阶段：再考虑 API、工单系统或更复杂工作流集成。

不要误读：Dify 不是把混乱文档变聪明的魔法

Dify 能把知识库、检索、工作流和应用发布连接起来，但它不能替你完成所有管理工作。

它不能自动判断旧 SOP 是否失效，不能替你确认亚马逊政策是否适用于当前站点，不能替客服主管做补偿决定，也不能保证每一次检索都命中正确资料。

另外，日志本身也可能包含敏感对话。Dify Logs 文档提醒，日志包含完整用户对话，可能包含敏感信息，需要适当访问控制并遵守隐私法规。团队上线前要明确谁能看日志、日志保存多久、哪些字段需要脱敏。

所以，Dify 的正确位置是“可控的内部 RAG 应用平台”。它适合把已经治理过的知识，变成团队可使用的问答和工作流；它不适合替代知识治理、权限管理和人工审批。

  • 资料没清理好，不要上线。
  • 测试没覆盖真实问题，不要给一线大范围使用。
  • 涉及钱、法律、平台政策和安全承诺，不要让机器人直接决定。
  • 没有日志复盘机制，不要认为机器人会自己变好。
  • 没有权限和脱敏规则，不要上传敏感业务资料。

7 天 SOP：从 0 到 1 做一个可试用机器人

第 1 天，选一个窄场景，写清楚使用者、问题范围、不能回答什么。

第 2 天，整理 20 到 50 份高质量文档，每份文档只回答一个业务问题，并补充站点、产品线、版本、负责人。

第 3 天，创建 Dify Knowledge，配置 chunk 和索引，先用 High Quality 模式测试语义检索效果。

第 4 天，设置 metadata，做 30 个检索测试问题，观察是否能召回正确 chunk。

第 5 天，搭最小工作流：User Input、Knowledge Retrieval、LLM、Answer，并写好 LLM 节点边界提示词。

第 6 天，准备 50 个测试问题，覆盖标准、同义、缺资料、冲突和越权场景，修正文档和检索设置。

第 7 天，给 3 到 5 个内部用户试用，开启日志复盘，每周更新资料、提示词和检索策略。

可以直接复制的建项提示词

请帮我设计一个 Dify RAG 问答机器人。

使用场景：【客服SOP / 产品资料 / 新人培训 / 售后政策 / 广告复盘】
使用者：【客服 / 运营 / 广告 / 新人 / 管理者】
站点和产品线：【填写】
资料类型：【SOP、FAQ、产品说明、客服话术、广告报告、规则文档】
敏感边界：【哪些问题必须转人工，哪些资料不能上传】

请输出：
1. 第一版机器人应该回答哪些问题，不应该回答哪些问题；
2. 知识库文档结构和命名规则；
3. 必须设置的 metadata 字段；
4. Dify 工作流节点设计；
5. Knowledge Retrieval 的检索策略建议；
6. LLM 节点提示词；
7. 50 个测试问题分类；
8. 上线后的日志复盘和迭代 SOP。

明天可以照着做的清单

  • 第一个机器人只做一个窄场景，不做公司万能助手。
  • 先清理资料，再上传 Dify。
  • 每份文档标注站点、产品线、版本、负责人、有效日期。
  • 优先测试 Hybrid Search，再根据业务问题调整语义和关键词权重。
  • 准备 50 个真实测试问题，不只问 5 个样例。
  • LLM 节点必须写清无资料、资料冲突、敏感问题的回答规则。
  • 内部客服机器人先辅助员工，不要直接替客户做承诺。
  • 启用来源引用，重要答案必须能回到资料。
  • 上线后每周看日志，按资料、切片、检索、提示词四类改进。
  • 敏感资料和日志访问权限要提前定义。

结论

Dify 的商用价值，不是让你少写几行代码，而是把知识库、检索、提示词、应用发布和日志改进放进同一条业务链路。跨境团队要先把资料治理好，再让机器人上线，否则只是把旧混乱变成更快的错误回答。

资料来源