知识库建完就吃灰？问题出在“建完”两个字
很多知识库，都有一个相似的开局。
项目启动时，大家很兴奋：收集资料、设计目录、迁移文件、补标签，再开一场培训，宣布“知识库正式上线”。
刚开始的一两周，访问量不错，群里也有人分享链接。
再过一段时间，新问题仍然在聊天窗口里重复出现；遇到复杂情况，大家仍然去找老员工；知识库里的文档越来越多，更新时间却停在了几个月前。
最后，它成了一个人人看过、很少人依赖的地方。
问题往往不在技术，也不在员工不爱学习。
而在于我们从一开始就把知识库当成了一个“可以建完的项目”。
知识不会在整理完成的那天停止变化
规则会调整，产品会升级，客户会提出从未见过的问题，昨天有效的方法今天可能失效。
所以，知识库真正的工作不是“把已有资料整理好”，而是持续完成一条循环：
问题出现 → 做出判断 → 采取行动 → 得到结果 → 修正知识。
WorkBuddy 的经验萃取、问答沉淀和技能蒸馏，都在强调这条闭环。因为一个没有经过结果检验的答案，最多只能算“待验证材料”。
真正有价值的知识，不是被保存过，而是被现实反复使用和校正过。
最值得沉淀的，往往不是日常文件
很多团队把“收到一份文档”当作知识入库的主要时机，却错过了更有价值的四个瞬间：
- 同一个问题再次出现时。
- 一次重要交付完成时。
- 事故、投诉或返工发生时。
- 规则、产品或流程变化时。
这些时刻都带着真实的上下文：发生了什么，当时为什么这样判断，采取了什么动作，最后结果如何。
如果只记录最终答案，例如“这次应该这样处理”，后来的人只会照抄动作，却不知道适用边界。
一个真正可复用的案例，至少应该回答五个问题：
- 当时遇到了什么问题？
- 判断的关键依据是什么？
- 采取了哪些动作？
- 结果验证了什么？
- 下次再遇到，会保留什么、改变什么？
答案告诉人怎么做，判断过程才教会人什么时候这样做。
成功案例给方法，失败案例给边界
我们天然更愿意总结成功。
一个项目做成了，大家提炼出“三步法”；一个问题解决了，马上整理成“最佳实践”。但如果没有失败样本，这套方法很可能只是一次偶然成功。
萃取经验时，最好同时找一个成功案例和一个失败案例。
成功案例帮助我们识别共同动作，失败案例帮助我们看清：少了什么条件，方法就不成立；出现什么信号，流程就应该停止；哪些判断不能机械复制。
没有反例的方法论，传播得越广，造成的误用可能越多。
每次使用，都应该给知识库留下反馈
一条知识被搜索出来，不代表它解决了问题。
使用之后，至少要留下三种反馈：
- 这次是否真正解决了问题？
- 使用者是否做了人工修正？
- 是否出现了原文没有覆盖的新例外？
如果回答有误，也不能简单写一句“AI 不准”。要继续区分：是源材料已经过期，搜索没有命中，多个来源发生冲突，还是规则本身就不完整？
原因不同，修复的位置也不同。
源材料过期，就更新事实；检索失败，就调整索引；规则不完整，就补充适用边界。只有把错误送回正确的位置，系统才会真的变好。
别把“事实”和“怎么行动”写在一起
知识库接入 AI 以后，还有一个很容易被忽略的问题。
“当前价格是多少”“最新制度怎么写”，属于业务事实；“什么时候追问用户”“什么情况必须阻断”“应该调用哪个工具”，属于 Agent 的行为规则。
两者应该分开管理、分别版本化、分别验收。
否则，为了修正一个过期数字，你可能顺手改坏一整套执行流程；为了让 AI 更积极，又可能让它在证据不足时越权给出结论。
知识告诉系统什么是真的，规则告诉系统应该怎么做。它们有关联，但不是同一件事。
不要再用“新增了多少篇”证明成绩
“本月新增 300 篇文档”听起来很忙，却不能证明知识库更有用了。
更值得关注的是：高频问题有多少能直接解决，关键结论有多少可以回到原文，过期内容多久能被发现，错误答案有多少被修正，一条经验是否在第二个场景里再次发挥作用。
文档数量衡量的是库存，复用和纠错衡量的才是价值。
一个轻量的维护节奏已经足够：每周处理新增、冲突和过期风险；每月抽查高频答案；每次重要交付或返工后，补一份案例复盘。
重点不是动作多，而是让每次真实工作都能给知识库带回一点新证据。
写在最后
如果你的知识库已经开始吃灰，不要急着再办一次“全员整理周”，也不要马上换一套更贵的工具。
先找一个刚刚发生的真实问题，把它的判断、行动、结果和修正完整走一遍，再让下一次相似问题直接受益。
知识库不是建出来的，是在一次次真实工作中，被用出来、改出来的。