用飞书文档做知识库，我们踩的坑

一、我们为什么决定写下这篇“踩坑实录”

如果你现在打开我们团队的知识库，你会发现一个很有意思的现象：创建于2023年3月的主空间里，静静地躺着347个文档页面。其中，有213个页面在过去90天内的访问次数为0。有56个页面的最后更新时间停留在2023年6月，那是我们刚开通飞书知识库功能的那一周。剩下那些还在被访问的文档里，约三分之一的评论功能已经彻底沦为了“已读不回”的坟墓。

这是一个投入了15天集中搭建、前后动员了3个部门37名同事参与、并由CEO亲自站台推动的内部项目。

结果呢？我们用飞书做出来的知识库，变成了一个比Shared Drive还不如的“数字废墟”。不是骂飞书的工具不行，事实上，我至今仍然认为飞书知识库在产品设计和协同体验上是国内第一梯队。但恰恰因为工具太好用了，好到让我们产生了一种致命的幻觉：以为搭好知识库等于做好知识管理。

这个认知偏差，让我们在那15天里连踩5个大坑。每一个坑都是真金白银的时间成本，每一个坑都在内部复盘被人反复鞭尸。今天把这篇东西写出来，是因为我发现这两年有太多团队在飞书、语雀、Notion、Confluence之间反复横跳，本质上是把“工具选型”当成了知识管理的全部工作。而真正决定一个知识库死活的因素，从来不在功能说明书里。

二、核心结论先说清楚

如果你只想带走一句话，那就是：飞书文档和知识库解决的是“效率工具”问题，而知识管理解决的是“组织行为”问题。用效率工具去解决组织行为问题，下场就是我们这样。

更具体的结论有三条：

第一条：知识库的死亡时间点，不是“没人用”的那一刻，而是搭建方案写下来的那一天。

我们事后复盘发现，绝大多数导致失败的因素，在方案阶段就已经埋好了。比如目录结构设计的过度复杂、权限边界的模糊、内容贡献机制的空转，这些病根都在上线之前就注定了，只是需要30天左右才会显形。

第二条：飞书知识库真正的坑不在功能层面，而在“人”的层面。

协作文档实时编辑强不强？强。结构化树状目录好不好用？好用。AI智能摘要香不香？香。但问题是，当没有人愿意往里写东西、没有人知道该写什么、没有人觉得写了有收益的时候，再强的编辑器也只是个空壳。功能的强大，掩盖不了机制的缺失。

第三条：中型以上团队的知识管理，需要一个独立的“内容治理层”，而这个东西飞书给不了你，任何工具都给不了你。

100人以上的组织，知识管理的问题复杂度是指数级上升的。部门墙、信息孤岛、离职人员文档归属、版本一致性问题、合规审计要求，这些挑战单靠一个协同文档工具是兜不住的。你需要的是工具+规则+角色+考核的一整套体系。飞书知识库是这套体系里的“展示层”，但你不能指望展示层去代替整个体系运转。

下面我会把我们踩过的五个坑一一拆开，把当时的决策现场还原出来，告诉你为什么我们会在每个节点上犯错，以及如果重来一次，我们会怎么做。

三、背景：一个典型的中型企业知识管理翻车现场

1. 我们的团队画像

先说清楚“我们”是谁。这是一家做企业SaaS的公司，主产品线两个，技术团队约60人，产品+运营+销售+客户成功加起来大约80人。全公司加上行政、市场、管理层，在项目启动时有137个人。

这个规模很微妙：说小吧，已经出现了明显的部门间信息不对称，新销售入职要拿着三个不同版本的报价单问“我到底该信哪个”；说大吧，还没大到需要专门的KM（知识管理）岗，也没人愿意为这个事单独招一个人。

这就造成了典型的“中间态困境”：组织已经天然产生了知识管理的需求，但还没有意识到知识管理是需要资源投入的独立职能。大部分人的想法是：“用飞书搭个知识库不就行了吗？反正大家本来就在用飞书办公。”

2. 启动决策的致命盲区

决定用飞书做知识库的决策过程高效得令人窒息：CTO在某次管理例会上提了一句“我们的信息太散了，能不能用飞书知识库整理一下”，当场获得了CEO的认可，所有部门负责人在3分钟内表态支持。

多么和谐的场面。多么危险的信号。

在场的所有人都默认了一个假设：“有了知识库，信息就会自动整理好→团队就会自动阅读和学习→工作效率就会自动提高。”这个假设链条上的每一个箭头，事后都被证明是一厢情愿。

当时还做了一件特别典型的蠢事：给项目定了一个“15天上线”的激进目标。不是因为业务多紧急，而是因为“大家都觉得这个工具很简单，15天肯定够了”。

于是，在没有专职负责人、没有内容审核标准、没有更新维护机制、没有激励机制、甚至连“哪些内容该进知识库”都没定义清楚的情况下，我们轰轰烈烈地开工了。

3. 我们把知识库当成了一次性工程项目

这是整个翻车事件中最根本性的错误。知识库本质上是一个需要持续运营的内容系统，而我们的SOP把它当成了一次性的“搭好上线”工程。

我们关注的问题全是工程交付式问题：目录建好了吗？文档批量迁移完成了吗？权限能覆盖预期场景吗？功能测试通过了吗？

但我们没问过任何运营式问题：上线第一周谁负责监控内容质量？存量文档三个月后谁来清理？新员工入职后第一个要看的知识页面是哪个？贡献知识的同事能得到什么正反馈？如果有两个部门对同一篇文档有不同版本的更新需求，怎么裁决？

这种思维方式的差异，直接导致了后面五个坑的连环暴雷。

四、第一坑：把分类当成了知识管理的全部工作

1. 那个价值万元的目录会议

我们知识库项目的第一件大事，是召开了一场长达5个小时的“目录结构设计会”。

与会者包括：CTO、技术总监、产品总监、运营总监、两位高级产品经理。按工时成本折算，这场会议的成本不会低于一万元。我们讨论的是什么呢？讨论的是“技术文档应该放在「研发中心」下面，还是放在「产品资料」下面？”“行业研究该不该建一个独立空间？”“新员工入职材料应该按职能分类还是按入职阶段分类？”

你知道吗，这些讨论最后都达成了共识。我们设计出了一套颇为精美、逻辑自洽的三级分类体系：8个一级空间，23个二级分组，超过60个三级标签。我们甚至认真地为这套分类写了使用说明文档，要求所有人按照这个体系来存放内容。

三个月后复盘，这套精心设计的分类体系是导致知识库野草化的第一元凶。

2. 为什么复杂的分类反而会杀死知识库

原因很简单：分类体系应该服务于检索者，但它最终只服务了设计者本人的强迫症。

设计者（也就是我们这群坐在会议室里的管理层）的逻辑是树状逻辑，天然喜欢穷举、互斥、层级分明。但实际使用者的行为模式是搜索逻辑+粗颗粒度浏览逻辑。大部分同事找东西的方式是：第一选择搜索框，搜索不到就直接问人。愿意一层层点开目录树去找的人，不到总用户的15%。

更致命的是，复杂的分类体系拉高了贡献门槛。当一个技术同事想写一篇排查数据库连接池的文档时，他需要先判断应该放在「研发中心-后端架构-数据库专项」还是「运维保障-线上故障-数据库问题」，这两个节点的路径看起来都合理，但放在其中一个就意味着在另一个节点里找不到。他犹豫了10秒，关闭了浏览器标签页，心里想：“算了，反正也不是非写不可。”

这个场景不是假设。我们在复盘日志里翻出了至少4个类似的例子。

3. 如果重来一次：够用原则与渐进式生长

根据我们的观察和同行交流，对于一个137人的团队，知识库的一级空间以不超过5个为佳，二级分组控制在15个以内，不要设计任何三级分组。

更关键的转变是，把分类体系的设计权从“管理层会议”下放到“实际使用者”。我们现在的做法是：只定下3个最核心的一级空间（产品知识、业务操作台、技术资产），然后允许各个业务小组在各自的一级空间下自己建立和调整分组。哪个分组内容多了、自然分裂出新分组；哪个分组长期空置，就合并掉。

知识库的分类体系不是建筑物，修好了就不能动；它更像一棵树，应该允许枝条自然生长和修剪。飞书知识库的目录拖拽排序、页面移动功能其实非常好用，问题是我们一开始非要用“一次性设计”的思路去强行框死它。

五、第二坑：把内容搬运当成了知识生产

1. 那场轰轰烈烈的“搬家公司行动”

在15天工期的压力下，我们做了一件极其愚蠢又极其常见的事：组织各部门把散落在飞书个人空间、飞书群文件、钉钉工作台、邮箱附件、老员工笔记本里的“存量文档”集中导入知识库。

行动代号叫“搬家行动”。每个部门分配了KPI：技术部200篇，产品部150篇，运营部100篇。行政甚至打算把三年前的团建通知也导进去，被我们拦下来了，这大概是我们那15天里做出的唯一正确的拦截。

7天之后，347个文档页面就位了。CTO在群里发了一长串👍，说“终于有了知识的归属感”。

三个月后，这347篇文档里被同事评价为“真正有用”的，不到40篇。原因在这里：

搬进去的全是原始物料，不是知识。什么叫原始物料？会议纪要原文，带着“那个事小王你跟一下”的口语碎片。三年前的竞品分析，数据已经失效但没有任何标注。某次钉钉群里的故障排查记录，截图全部失效，关键指令淹没在大量的“收到”、“明白”里。

这些东西能叫知识吗？它们只是信息垃圾的另一种存在形式。我们不生产任何新价值，只是把这些垃圾从A仓库搬到了B仓库，然后给B仓库贴了一个“知识库”的标签。

2. 什么是“可复用的知识”：三个硬指标

后来我们总结出了一条铁律，现在贴在我们的文档标准第一条：“凡进入知识库的内容，必须是经过再加工、可独立理解和可被验证的。”三个条件缺一不可。

可独立理解：意味着任何新加入团队的成员，不需要额外问谁，就能读懂这篇文档在说什么、上下文是什么、结论是什么。

可被验证：意味着文档中的流程、数据、链接、联系方式必须真实有效。我们后来要求所有涉及操作步骤的文档必须包含“最后验证日期”。

经过再加工：意味着原始素材不等于成品。一次会议纪要需要提炼出关键决策和行动项；一次复盘需要结构化呈现“背景-问题-归因-改进措施”；一次故障排查记录需要写成“现象-排查路径-根因-解决方案-预防措施”的标准格式。

这个标准一落下来，知识库的内容贡献量从平均每月60篇直接掉到了15篇。但用户满意度从2.3分回到了4.1分（5分制）。我们宁愿一个月只进10篇高质量文档，也不要再塞100篇谁都不会看的搬运件。

六、第三坑：没有解决“为什么我要写”的问题

1. CEO站台解决不了贡献意愿

项目上线时，CEO在大群里发了一段几百字的小作文，深情讲述了“知识沉淀对企业长远发展的重要性”，结尾是“希望大家多多贡献”。

上线第一周，各团队负责人带头贡献了二十几篇高质量的文档，一片欣欣向荣。第二周，贡献量腰斩。第三周，知识库编辑日志里只剩我自己。

我们犯了一个所有知识管理新手都会犯的错误：把“号召”当成了“机制”。

CEO的站台能解决什么？能解决项目的合法性，能解决初期的注意力，它能告诉所有人这个事很重要。但它解决不了每个人心里的那本账：“我花两个小时写一篇文档，对组织有好处，对我有什么好处？”

这才是最核心的问题。知识共享是天然反人性的事。一个人花时间积累了经验、形成了认知壁垒，这是他区别于别人的核心资产。你让他毫无代价地交出来，他凭什么？

2. 什么情况下人才愿意分享知识

后来我和超过三十位同行聊过这个话题，发现愿意长期、主动贡献知识的人，动机不外乎这几种：

互惠预期：“我写了这篇，以后我也能从别人写的文档里获益。”

社会认同：“我写的文档被很多人看了、收藏了、点赞了，被当成团队里的‘内行’，这种感觉挺好的。”

强制性要求：“写文档和我的绩效/晋升挂钩，不得不写。”

降低的写成本：“不需要从头写，有现成的模板，填一下就行。”

你在设计激励机制的时候，至少需要覆盖这四类动机中的两类以上，只靠“领导说了很重要”是绝对不够的。

我们在初期仅覆盖了互惠预期（口号式的）和社会认同（点赞和评论功能），没有涉及任何强制性要求和降成本的措施。结果就是：那些本来就不爱写文档的人，还是不会写；而那些本来愿意写的人，也因为缺乏正反馈而慢慢流失了。

3. 我们后来怎么把贡献意愿拉起来的

分了三步走，没有一步是复杂的。

第一步：把知识贡献写成团队OKR。不是个人OKR，而是每个季度的团队级OKR里必须有一条知识沉淀相关的内容。比如“Q3完成客户常见问题FAQ 30条，准确率95%以上”。这条OKR对团队负责人有约束力，负责人自然会拆解到个人。

第二步：月度知识之星。不是由某个评委选出来的，而是纯粹看飞书后台的数据：当月新增页面数最多的个人、当月被阅读次数最多的文档作者，两个指标各选一个人。奖励是全员群公告表扬+300元奖金。重点不是钱，重点是“被看见”。

第三步：模板化。我们最成功的举措之一，就是做了10个核心模板放到知识库首页。故障复盘模板、竞品分析模板、项目复盘模板、新功能上手指南模板……每个人点“新建页面”的时候直接选一个模板，标题都帮你生成好了，正文里帮你搭好了骨架，你只需要往里填东西。

这个举措把写文档的启动成本从“我不知道怎么写”降到“我填完即可”，对于写作意愿不强的同事尤其有效。

七、第四坑：内容治理缺位导致知识库快速腐化

1. 那个被AI坑了的新同学

这件事发生在知识库上线两个月后，它直接催生了我们的“文档黄牌机制”。

当时我们启用了飞书知识库的AI摘要功能，确实好用。新来的一个运营同学，在接手某个客户对接任务时，先用AI搜索了知识库里关于这个客户的过往信息。AI帮她生成了一份简洁摘要，里面写道该客户“售后服务采用30分钟响应制”，并在摘要末尾附上了原始文档链接。

她信了。按30分钟响应制的标准去对接，第一周就和客户产生了预期差，客户后来告诉我们，那个30分钟响应制是2022年试行的老政策，2023年中期已经改为“首次响应4小时内、紧急提单15分钟内”。

AI没问题，它准确概括了那篇过期文档的内容。问题在于没有人告诉AI那篇文档已经过期了，也没有人告诉这位新同学要看文档的最后更新日期。

这个事故让我们意识到一个残酷的事实：知识库的内容是有保质期的，而飞书本身不会自动帮你管理这个保质期。

2. 三种腐化类型和应对策略

我们后来把知识库内容腐化归为三类，每一类的应对策略都不一样。

第一类：事实性过期。产品价格调整、团队架构变化、联系方式更新、政策法规变更，这些“客观事实改变”导致的过期，最容易发现，但最容易遗漏。

我们的应对是：要求所有包含“事实性信息”的文档在页首标记最后验证日期，且责任人必须明确标注。每季度由各团队负责人对口清理一次。

第二类：流程性过期。SOP文档里的操作路径随着系统版本更新而失效，这是技术团队最容易踩的坑。比如飞书本身的某个菜单入口调整了，原来写的操作步骤就全乱了。

我们的应对是：把流程性文档和工单系统打通。一旦有同事在工单里反馈“按文档操作走不通”，会自动触发一条评论提醒给到文档负责人。

第三类：结构性腐化。这是最隐蔽的。指的是文档本身没错，但由于整个业务方向调整了，文档提供的信息在当下已经不重要了、不相关了。这种文档不会有人专门来指出它的问题，它就安静地躺在目录里，占着搜索结果的位置，干扰着所有人的判断。

我们的应对是：设置一个“90天静默规则”。任何一个页面如果在90天内编辑次数为零、且访问次数低于5次，系统不会自动处理（飞书也不支持），但我们会每个月导出一份清单，由内容管理员手动打上“待清理”标记，群发给原责任人确认。

3. 不要让“内容管理员”变成虚设岗位

踩完这个坑之后，我们设了一个兼职内容管理员的角色，每周占用他4小时工作时间。一开始我很担心这会变成又一个没人当的虚职，但实际运行下来效果远超预期，因为这位管理员是我们运营团队的一位妹子，她本身就热衷于把事情理得清清楚楚，给她这个职责反而让她找到了存在感。

这引出了我一个非常重要的判断：知识管理的人选，意愿比能力重要得多。找一个有整理癖、有强迫症倾向的人来做这件事，远比找一个级别很高但没有兴趣的管理层有效。

八、第五坑：权限设计失当，制造了“孤岛互联”

1. 安全焦虑下的过度设限

在搭建知识库之初，我们被一轮又一轮的数据安全事件新闻搞得神经过敏。再加上行政和财务部门坚决要求自己的文档“不能让技术的人随便看”，我们最终在权限设置上走了“从严从细”的路线。

具体方案是这样的：8个一级空间里有一半做了部门级隔离，只有该部门的成员才能访问。企业内部通用的HR制度、行政流程放在一个“全员开放”的空间里。项目相关的技术文档，甚至细化到了按项目组设权限。

这个方案在逻辑上完美无瑕，在实战中一地鸡毛。

最典型的后果：一个跨部门项目组，产品经理的文档放在产品空间，前端技术人员需要建立一个链接过去。但前端开发的同事在技术空间里没有产品空间的阅读权限，于是每次都需要产品经理导出PDF发给技术，知识库的协同价值瞬间归零。

另一个后果：新来的同事在入职第一天试图在知识库里探索公司的业务全貌，结果她能看到的空间只有“全员公告”和“行政部门操作手册”。她对公司的第一印象是“这是一家只有行政部的公司”。

2. 权限的底层逻辑应该是“默认开放、例外封闭”

这是我和好几位做知识管理的同行反复讨论后形成的共识。

一个企业的内部知识，真正需要严格保密的比例其实很低，薪资数据、未公开的财务报表、涉及客户隐私的信息、核心算法代码，这些东西加起来可能不到整体知识的10%。为了这10%的保密需求，对整个知识库层层设限，是典型的安全过度。

我们的现行规则变成：

全员默认阅读权限：任何新建页面，默认全员可读，仅部分行政和财务敏感页面需申请权限。

编辑权限按团队授予：你只能编辑你自己团队空间里的页面，但可以评论任何页面。

敏感内容用独立空间隔离：真正敏感的文档放在一个单独空间，想管控就管控那一个，不要污染整个知识库的开放结构。

这个调整带来的变化立竿见影：跨部门文档的引用量在一个月内上升了4倍，因为大家终于能点开那些链接了。

九、更深一层的反思：工具和管理的边界在哪

写到这一章，我想讨论一个更根本的问题。前文说过，我们自己团队用的是飞书知识库，踩的坑也都是在飞书生态里踩的。但我不认为这是飞书特有的问题。如果换语雀、换Notion、换Confluence，这些坑该踩还是会踩。

因为工具解决的是文档的存储、呈现和协同，而知识管理要解决的是内容的组织、治理和流转。这是两个层面的东西。

让我打个比方。飞书知识库就像一个装修豪华的图书馆。你可以买到最舒适的书架、最精准的检索系统、最明亮的阅读灯。但如果没有人决定该买什么书、没有人给新书编目录、没有人把过时的旧书下架、没有人告诉读者哪些书是最近被引用最多的，这个图书馆很快就会变成废纸仓库。

而我们犯的错误就是：花钱买了个好图书馆，然后觉得万事大吉了。

1. 中型以上团队的额外挑战

对于100人以上的团队，知识管理还要面临几个飞书知识库本身无法覆盖的挑战：

离职人员知识归属：一个工作了3年的核心成员离职，他的飞书个人空间里可能有一大堆未被整理进知识库的文档，这些文档在他离职后权限被回收，团队永久丢失了这部分资产。飞书的解决方案是什么？管理员可以移交离职员工的文档。但问题是，谁来甄别哪些文档有价值？移交完之后谁来整理？

多工具链路割裂：需求文档在飞书里，测试用例可能在PingCode里，代码在GitLab里，设计稿在Figma里，这四个地方的知识相互关联，但任何一个工具都不可能打通全部链路。

合规审计要求：一些行业（如金融、医疗、政务）要求知识资产有完整的版本审计线、访问控制记录和内容有效性证明。飞书知识库提供了版本历史，但审计级别的追溯、定期的合规性审查，需要额外的流程和制度。

我们团队如果从50人涨到200人以上，我会开始考虑引入一套更完整的知识管理方案，而不是单纯靠飞书文档去扛。

以同类企业SaaS服务商PingCode为例，它的知识管理模块和飞书的思路有显著差异。飞书做的是“通用协同文档”，而PingCode做的是“研发场景下的知识管理”。它把需求文档、测试用例、代码提交记录和知识库页面做了双向关联，不是在飞书里引用PingCode链接那种“跳转式关联”，而是页面和具体的工作项绑定在一起，工作项状态一更新，关联的知识页面自动收到通知。我们有一个客户在用PingCode管理研发资产的时候，他们的一个测试文档关联了217条测试用例，每一条用例的通过/失败状态会实时同步回知识页面上，PM在看复盘报告的时候不需要打开另一个系统去查。这种深度打通是通用型文档工具做不到的，因为它需要后端数据结构的原生支持，而不是靠API拼接。

但话说回来，对于大部分还在从0到1做知识管理的团队，PingCode这种垂直方案可能太重了。重要的是你得先知道自己现阶段要解决的核心矛盾是什么。是要解决“多人写文档不打架”的协同问题？那飞书文档就够了。是要解决“研发资产和业务文档脱节”的关联问题？那你需要考虑PingCode或者至少是Jira+Confluence的组合。是要解决“没人写文档”的问题？用什么工具都一样，先把激励机制建起来再说。

十、不同团队的搭建策略和行动建议

1. 按团队规模给出不同路径

基于我和近二十个不同规模团队的交流经验，我画了一张决策矩阵，你可以直接对号入座。

30人以下的小团队：别建知识库。真的，别建。这个阶段的知识管理最大的问题根本不是工具，而是没东西可管。你们需要的不是知识库，而是一个能快速互搜聊天记录的飞书群和一个在线的共享文档。每周花半小时把关键讨论整理成一个飞书文档发给全员，足矣。

30-80人的成长型团队：可以开始用飞书知识库，但要极度克制。建议只建1-2个一级空间，不超过10个二级分组。把80%的精力花在“写什么”和“怎么写”上，而不是搭架子。模板化先行，内容质量控制先行。

80-150人的中型团队：知识库必须配内容管理员。兼职即可，但必须有人担责。这个阶段最大的问题是信息开始分层，管理层看到的信息和基层看到的信息开始出现差距。知识库恰好是用来填这个差距的。建议引入基础的内容审计机制（如90天静默清理规则），并开始试验知识贡献与绩效轻度挂钩。

150人以上的中大型团队：单靠飞书知识库不够用了。你需要评估是否引入更垂直的知识管理方案（如PingCode，或自建Confluence+Jira的组合）。这个阶段的挑战从“怎么让人写文档”变成了“怎么让不同系统之间的知识不散落”。内容治理层面需要一个独立的KM角色（至少0.5个人力），并建立跨部门的知识资产盘点流程。

2. 我们的“最小可行知识库”启动清单

如果今天让我从零开始重搭一次，我会走一条完全不同的路。不是15天的“大爆炸”式上线，而是6周的渐进式生长。

第一周：定边界。明确三件事：知识库和飞书聊天记录的分工边界（什么进库、什么不进）；知识库和项目管理系统（如PingCode、Jira）的分工边界（需求文档以哪个系统为源）；知识库和个人飞书空间的分工边界（什么时候该从私人文档升级为团队文档）。

第二周：做模板。先不要写任何正式文档，花整整一周做5-8个核心模板。这件事一个人做就行，不要开会讨论。模板的质量直接决定了后续内容的质量上限。

第三周：试写10篇。选3-5个团队里的内容种子选手，每人给模板，让他们试着写两篇。写完以后全员（或者至少核心团队）一起评审一次，重点不是挑毛病，而是通过讨论让大家对“什么是一篇好文档”形成共识。

第四周：小范围上线。只对1-2个团队开放，观察一周。观察什么？看有没有人在模板之外自己新建空白文档（如果有，说明模板覆盖不全）。看有没有人在文档下面留言提问（如果有，说明内容不够自洽）。看有没有人搜不到想要的内容（记录下每一次搜索失败，这是最宝贵的补全信号）。

第五周：补齐最痛的缺口。根据第四周的观察，集中补齐一批文档。这次补齐的不是“我们觉得该有的”，而是“有人搜了但没搜到的”。

第六周：全量开放，启动轻量运营。全员开放，同步推出两个机制：月度知识之星（基于数据），和季度知识贡献OKR（基于组织目标）。

没有“搬家行动”。没有“目录评审会”。没有“一次性建完所有类别”。

十一、最后的话：知识库重建的不是文档，是你的耐心

我写这篇东西的时候，我们的知识库正好运行到第14个月。

那个曾经死透了的347页主空间，现在还有137页在活跃使用。63个被清理掉的页面躺在回收站里，像一个沉默的纪念碑，提醒我们曾经多么理所当然地把“搭好工具”等同于“做好管理”。

飞书知识库是个好东西。它的实时协同、AI搜索、结构化呈现，在这一年里帮我们省掉了大量“这个东西在哪”、“上次那个文档谁有”之类的碎片沟通。但我们必须诚实地说：让它真正起作用的，不是功能迭代，而是我们自己终于接受了知识管理是一个永续经营的过程。

工具会换，平台会变，但那个让人愿意写、让人找得到、让人信得过的基本逻辑，从来都是关于规则的、关于人的、关于耐心的。

如果你正在启动团队的知识库项目，或者你已经搭好了一个但发现没人用，我建议你先把飞书后台的“新建空间”按钮放下，先问自己三个问题：

第一，我们团队里，谁是最在意“信息别乱”的人？找到他，给他资源，给他时间和授权，让他当内容管理员。

第二，如果我们只允许知识库里有20篇文档，这20篇应该是什么？先写出这20篇，写到团队公认“就靠这20篇我也能干活”的程度，再谈扩展。

第三，我们有没有哪怕一条规则，能保证这20篇文档在半年后依然是有效的？如果你对这个问题没有答案，那说明你还没有真正开始做知识管理，你只是在用知识库存放你的焦虑。

祝你的知识库活着。活到那些建它的人走了以后，还在被人打开和相信。