企业官网建设流程全解析

Dify 企业级实验（10）：知识库持续更新闭环——数据飞轮怎么转起来？

Dify 实验系列 · 企业级 10/12 | 实验编号：DIFY-104-10
基于 Dify 1.16.1 实测（2026-08）

1. 业务场景

先讲一个我们实际遇到的场景。

知识库上线那天不是结束，是开始。每周都有新文档：产品更新、FAQ 积累、售后案例——直接丢进知识库？

我们第一次接这类需求时，第一反应也是「入库不就是调个 API」。真正动手才发现——脏文档一旦入库，检索质量整体下滑：用户问什么都答非所问，知识库从「资产」变成「负担」。入库之前必须有一道门禁，验证之后才允许生效。

知识库不是「建一次就完」，而是持续进化的资产。

这不是个例。任何 RAG 项目交付后都是这个模式：知识库不更新会死，乱更新会烂。

2. 场景痛点

这个流程的痛点，在知识库维护者和用户身上体现得最直接：

• 脏文档入库：过短、无标题、无具体内容的文档混进来，检索质量整体下滑，一粒老鼠屎坏一锅汤。
• 答非所问：检索质量下降，用户问什么都答不对，信任崩塌，再好的模型也救不回来。
• 索引未完成就生效：新文档入库后立刻问，检索不到，用户以为系统坏了。
• 未命中问题流失：用户问不到的内容没人收集，知识库不进化，永远停在上线那天。

本质上，知识库的价值不在「建」，在「持续进化的能力」——入库有门禁、验证后才生效、反馈能回写。

3. 方案：为什么是质量门禁 + 反馈回写

Dify 的 HTTP 节点直接调知识库 API（create_by_text），配合 code 节点做质量门禁，正好组成数据飞轮。选它的理由：

• 门禁前置：完整性/格式/自包含三维评分，<80 拒绝并回原因——脏文档在入库前被拦下；
• 验证后上线：先 create_by_text 等索引完成，再 hit-testing 验证后才算生效；
• 反馈回写：用户未命中提问记录下来，生成新条目，下一轮入库生效——飞轮转起来。

这篇文章我们就用它搭一套「知识库数据飞轮」：入库应用 + 问答应用。

4. 整体架构

两个应用：入库 workflow + 问答 workflow。

链路很清晰：清洗 → 质量门禁 → 入库（create_by_text）→ 检索验证；问答侧未命中反馈回写，形成闭环。门禁前置是这条链的关键设计。

5. 模块设计

5.1 入库开始变量

-variable:title# 文本，必填，文档标题-variable:content# 段落，必填，文档内容（最长 10000）-variable:base_url# 文本，必填，Dify 服务地址

5.2 质量门禁 cd_gate

defmain(title:str,content:str)->dict:importre text=contentor""# 完整性 40：长度score_complete=40iflen(text)>=150else(20iflen(text)>=80else0)# 格式 30：含 markdown 标题score_format=30ifre.search(r"^#{1,3} ",text,re.M)else(15iftext.count("\n")>=3else0)# 自包含 30：含具体数字/规格/明确陈述has_specific=bool(re.search(r"\d+",text))orany(kintextforkin["支持","可以","是","提供","需"])score_self=30ifhas_specificelse10score=score_complete+score_format+score_self valid="true"ifscore>=80else"false"reasons=[]ifscore_complete<40:reasons.append("内容过短（<200字）")ifscore_format<30:reasons.append("缺少标题结构")ifscore_self<30:reasons.append("缺少具体规格/明确陈述")return{"score":str(score),"valid":valid,"reasons":"；".join(reasons)ifreasonselse"质量合格","summary":f"标题：{titleor'无'}| 评分{score}/100"}

5.3 入库载荷组装 cd_body 与提交 http_kb

JSON body 用 code 节点组装（http 节点里直接写 JSON 字符串易错）：

defmain(title:str,content:str)->dict:importjson payload={"name":titleor"untitled.md","text":contentor"","indexing_technique":"high_quality","process_rule":{"mode":"custom","rules":{"pre_processing_rules":[{"id":"remove_extra_spaces","enabled":True}],"segmentation":{"separator":"\n\n","max_tokens":500}}}}return{"payload":json.dumps(payload,ensure_ascii=False)}

url:"{{#start.base_url#}}/v1/datasets/dfac575f-2490-4e1f-b730-76ccc8463c23/document/create_by_text"method:POSTbody:"{{#cd_body.payload#}}"# JSON 字符串，Content-Type: application/json

5.4 问答应用

kb 节点选知识库（召回 top_k=3）；cd_ctx 拼[1] 内容引用块；lm 系统提示词强制「基于知识库内容回答，引用来源编号 [1][2]，知识库没有的内容直接说明未找到，不要编造」。

6. 运行验证

7. 实战坑

8. 实验文档及源码获取

• 实验文档（完整操作步骤）：DIFY-104-10：知识库持续更新闭环——数据飞轮.md
• 源码一（入库应用）：dify104_10_01_文档入库.yml
• 源码二（问答应用）：dify104_10_02_知识库问答.yml
• 源码目录：dify-104/dsl

文章聚焦核心配置与采坑点；实验的完整分步操作（节点搭建/参数表/调试指引）见实验文档原文。

下一篇：Dify 企业级实验（11）：企业 API 工具化——如何把客户系统封装成 Dify 工具？

📚 更多实战记录见我的博客：鱼日先生

💬 你在这个实验的场景里踩过什么坑？欢迎评论区分享你的实战经验。