很多团队第一次做 Dify 知识库时，最容易陷入一种误判：明明已经导了文档、配了 Embedding、也跑出了回答，但实际一测试，结果却总是忽好忽坏。于是很多人开始怀疑模型、怀疑分段、怀疑参数，最后越调越乱。真正的问题，往往不是你不会做知识库，而是你一开始就把顺序做反了：该先清洗的时候急着调召回，该先做召回验证的时候又急着谈评估闭环，导致整个系统从底层就不稳。这也是为什么不少 Dify 知识库项目看起来已经“上线”，但只要真实用户一提问，就马上暴露出各种问题：答非所问、漏召回、引用不准、内容陈旧，甚至同一个问题换个问法结果就完全不同。如果你也正处在这个阶段，这篇文章我建议你先别继续盲目调参数，而是先把知识库落地的顺序理清楚。我想讲清楚一个核心判断：清洗、召回、评估不是并列动作，而是一条有先后依赖的工程链路。顺序一旦错了，后面做得越多，返工越重。一、为什么很多 Dify 知识库项目不是效果差，而是顺序错很多人做知识库时的真实流程，其实是这样的：先把一堆文档导进去发现回答不稳定，就开始改分段改完还是不稳，就去换模型还不行，再开始看是不是 prompt 写得不够细最后再