知识管理要成功，先解决谁写谁用的问题

一、一个被刻意回避的真问题

我先给一个数据。过去三年，我以外部顾问身份参与过 17 家企业的知识管理项目。其中 14 家在第一年结束后，知识库的月度活跃用户比例低于 12%。也就是说，100 个有权限的人里，真正在用的人不到 12 个。

更扎心的是，这 14 家企业里，有 11 家在第一年投入了大量资源做“内容生产”，让各部门写文档、写 SOP、写经验沉淀。HR 催，部门主管盯，写的人痛苦不堪，写出来的东西却几乎没人看。

问题出在哪儿？答案其实非常简单，但大多数企业在规划阶段就把它刻意绕过去了：写的人不用，用的人不写。

这不是一个技术问题。你用 Confluence、Notion、飞书、PingCode，或者花几百万定制一个知识管理系统，都绕不开这个最底层的问题。它本质上是一个“供需错配”的结构性矛盾，而不是“员工不配合”的态度问题。

所以这篇文章，我只讲一件事：知识管理要成功，先解决谁写谁用的问题。我会用我亲自踩过的坑、观察过的数据、总结出的判断逻辑，把这件事拆开来讲清楚。

二、核心结论：不是“谁写谁用”，而是“谁用谁写”

先把这个结论摆出来：成功的知识管理，逻辑链条不是“写的人决定写什么，然后指望用的人来用”，而是反过来，用的人需要什么，由最接近那个场景的人来写。

这句话说起来拗口，但我在至少 5 个项目中验证过。其中 3 个项目在第二年把内容生产机制翻过来之后，月度活跃用户直接从 10% 左右拉到 35% 以上。

为什么这句话这么重要？因为它直接推翻了大多数企业在采购知识管理工具时默认的假设。那个错误的假设是：“我们先搭好框架，让大家往里填内容，填满了自然有人用。”

这个假设错在三个地方：

1. 它假设“填内容”是一个零成本的行为。实际上，一个工程师写一篇像样的技术方案，可能需要 3-6 个小时。如果他写完了根本没人看，这个行为马上就停止了。
2. 它假设“用的人”和“写的人”是同一批人。但在 100 人以上的组织里，这两个角色高度分离。写 SOP 的是资深员工，需要用 SOP 的是新员工；写技术设计的是架构师，需要看设计的是执行工程师。
3. 它假设“有人管”就等于“有人用”。HR 或者知识管理专员盯着大家写，只能解决“有没有”的问题，解决不了“好不好用”的问题。

所以，我给出的核心判断是：知识管理的本质，不是一个“创作系统”，而是一个“服务系统”。它的服务对象是“用的人”，而不是“管的人”。

这个判断来自于我在一家金融科技公司（约 400 人规模）的真实经历。他们在 2022 年花了大量精力做知识沉淀，要求每个项目结束后必须输出结项文档。一年下来，文档数量很漂亮，超过 300 篇。但后来我们做了一次回溯分析，发现其中 70% 以上的文档，在入库后从未被打开过。更讽刺的是，新入职员工在遇到问题时，仍然是通过私下打听来获取信息，而不是在知识库里搜索。

为什么？因为那些结项文档，写的时候根本不是从“新员工会遇到什么问题”出发的，而是从“这个项目做了什么”出发的。写的人满足了“完成任务”的需要，用的人却找不到“解决我的问题”的答案。

三、角色分离：知识管理里最被低估的结构性矛盾

我把知识管理里的角色拆成三类：生产者（写的人）、消费者（用的人）、连接者（管的人）。在 100 人以上的组织里，这三类角色高度分离，而大多数知识管理系统只为“连接者”设计了功能，却忽略了“生产者”和“消费者”之间根本性的利益不一致。

1. 生产者：沉默的代价承担者

生产者是谁？在一家软件公司，可能是写技术文档的架构师、写操作手册的资深运维、写培训材料的业务专家。他们有一个共同点：写文档这件事，在当下的激励体系里，几乎是纯粹的负收益。

我算过一笔账。一个资深工程师的时薪成本大约在 200-400 元（含企业用工总成本）。一篇 3000 字的技术文档，从梳理思路到成文到配图到复核，平均需要 4-6 小时。也就是说，一篇像样的文档，企业在人力成本上投入了 800-2400 元。但如果这篇文档写完之后，半年内只有 3 个人打开过，而且这 3 个人没有给出任何反馈，你知道那个工程师下次还会认真写吗？绝对不会。

更糟糕的是，在很多企业里，文档写得越好，别人越依赖你，越把你钉在“写文档”这个位置上。没有晋升加分，没有绩效奖励，写得好是应该的，写得不好反而被挑毛病。这种扭曲的激励结构，直接导致了“应付了事”成为最优策略。

2. 消费者：沉默的流失者

消费者的痛，是另一种痛。他们不是不想用知识库，而是用不起来。

我在 PingCode 服务的企业客户里观察到一个典型场景：一家 300 人的 SaaS 公司，用 PingCode 知识管理搭了一个很完整的技术知识库，按产品模块、版本、角色层层分级。但一线技术支持人员在实际处理客户问题时，很少去搜索这个库。原因不是库里的内容不对，而是搜索到的内容与当前遇到的问题之间存在一个“翻译成本”。

举个例子。客户报了一个错误提示，一线支持人员想找对应的解决方案。但知识库里的文档标题是“2.3.1 版本数据库连接池配置优化记录”，而不是“客户报错 ERR_TIMEOUT 怎么处理”。这个“翻译成本”每高一点，消费者就流失一批。到最后，知识库就变成了一个“看起来很好，但没人用”的陈列馆。

3. 连接者：最辛苦但也最容易跑偏的角色

连接者通常是谁？知识管理专员、HRBP、技术运营、质量部门。他们的 KPI 往往落在“内容数量”“更新频率”“覆盖率”这类指标上。这就导致了一个系统性问题：连接者天然倾向于“堆量”，而不是“提效”。

我见过最极端的一个案例：一家 500 人规模的企业，知识管理专员每个月给各部门下达文档产出指标，不完成的通报批评。结果呢？每个月底的最后三天，系统里涌进来大量拼凑出来的“合格”文档。标题规范、格式统一、内容空洞。这种内容越多，知识库的信噪比越低，消费者越不愿意用，形成恶性循环。

所以你看，三个角色的利益根本没对齐。生产者的投入没有回报，消费者的需求没有被精准满足，连接者被困在错误的指标里。这个结构性矛盾如果不解决，你换什么工具都白搭。

四、我见过的最常见的四种失败模式

做了这么多项目之后，我把最常见的失败模式提炼成四类。如果你所在的企业正在做知识管理，大概率能在下面找到影子。

1. “霸王硬上弓”模式

特征是：自上而下强推，全员必须写。常见于传统企业数字化转型或新系统上线阶段。老板觉得知识管理很重要，一声令下，全员写周报、写总结、写案例。写得不好扣绩效。

这种模式的崩溃路径非常清晰：第一个月大家认真写，第二个月开始应付，第三个月出现大面积复制粘贴，第四个月系统变成废墟。我在一家制造业企业见过这个完整周期，从启动到彻底烂掉，正好四个月。

为什么？因为当你把“写”变成一个行政命令时，写的人唯一的动机就是“不被罚”。他绝对不会去想“怎么写才能帮到别人”。

2. “专家闭门造车”模式

特征是：请几个资深员工或外部顾问，关起门来写一堆“完美”文档。常见于追求“体系化”的团队。先把知识体系框架搭得非常漂亮，目录层级四五层，然后安排人一层一层往里填。

这个模式的问题在于：写的人离实际使用场景太远。专家写的文档，准确度没问题，但“可用度”很低。专家习惯于从头开始讲起，把来龙去脉都讲清楚；但使用者只想解决眼前那个具体的、微小的、紧急的问题。

我在 PingCode 知识管理的一个客户案例里看到过对比数据。同样一个“接口调用说明”，由该接口的开发工程师自己写（用的人就是集成方工程师），文档的月度打开次数是专家代写文档的 3 倍以上。不是因为开发工程师写得好，而是因为他知道集成方会踩哪些坑，所以文档里重点标出了那 5 个最容易出错的地方。专家不知道这些坑。

3. “工具决定论”模式

特征是：觉得换个工具就能解决问题。“我们现在用的 Confluence 不好用，换飞书知识库就好了。”“飞书也不行，试试 Notion。”然后就陷入工具选型的无限循环。

我旗帜鲜明地说一句话：工具解决的是“能做什么”的问题，解决不了“谁愿意做什么”的问题。PingCode 知识管理的实时协同编辑、页面关联项目任务、AI 自动摘要这些功能好不好？非常好。但如果你们企业的激励结构让写文档的人得不到任何正反馈，这些好功能只会让他在更高的效率下生产出更多没人看的文档。

工具是放大器。好的机制加上好的工具，事半功倍。坏的机制加上好的工具，事倍功半。

4. “没有运营”模式

特征是：系统搭好了，内容灌进去了，然后就没有然后了。没有人去分析“哪些文档被搜索了但没找到”“哪些文档打开了但很快就关掉了”“哪些文档被频繁引用”。

知识管理在运行起来之后，需要的不是管理员，而是运营者。管理员负责“有没有”，运营者负责“好不好用”。这两个岗位的能力模型完全不同，但大多数企业只配置了前者。

五、我的判断逻辑：用“双边市场”思维重新理解知识管理

前面说了这么多失败模式，现在来讲我的判断框架。这个框架来自于我自己踩坑之后的提炼，以及观察到的一些成功案例的共性。

我把知识管理看作一个双边市场。一边是生产者（写的人），一边是消费者（用的人）。中间是连接者（平台运营方）。这个市场要繁荣，需要同时解决三个问题：

1. 生产者的激励问题：他为什么要写？写了能得到什么？
2. 消费者的匹配问题：他需要的东西，能不能最省力地找到？
3. 连接者的运营问题：怎么让供需两端持续良性循环？

任何一个问题没解决，这个市场就会走向衰败。我在下面对每个问题给出具体的判断和方案。

1. 生产者的激励：从“行政命令”转向“专业声望”

我的核心观点是：行政命令驱动不了高质量的知识生产，只有“专业声望”可以。

为什么？因为知识生产的本质是一种创造性劳动。创造性劳动需要内在动机。内在动机的三个核心要素是：自主感、胜任感、归属感。行政命令直接摧毁了自主感，所以你得到的永远是“及格线产品”。

那么“专业声望”怎么建立？我在几个成功案例里提炼出三条可行路径：

（1）让被帮到的人直接反馈给帮助者

PingCode 知识管理有一个功能叫“页面评论与点赞”。这个功能本身不稀奇，几乎所有协同工具都有。但关键在于怎么把这套反馈机制用起来。

我在一家 200 人的软件公司里观察到一个很好的做法：他们每周的技术分享会，最后会留 5 分钟，让上一周被文档帮到的人，当面说出来，是哪篇文档、帮到了什么。这个动作成本极低，但对写文档的人的激励效应远超任何绩效评分。因为他感受到了“我的输出对别人真的有价值”。

（2）把质量信号显性化

“被打开次数”不是一个好指标，因为它只反映了标题的吸引力。“被收藏次数”稍好一点。“被引用次数”更好。最好的指标是“被实际帮助到的人的证词”。

但考虑到可操作性，我建议至少做两步：

• 在文档末尾设置一个“这篇文档帮到你了吗”的快速反馈按钮（PingCode 可以通过页面组件实现类似功能，也可以用评论区的引导语代替）。
• 每个月生成一个“本月最有价值文档”榜单，基于反馈数据而不是阅读量，在全公司公示。

这样做的好处是，写得好的人获得了专业声望，写得一般的人看到了对标的标准，整个生产端的质量基准线就被拉上去了。

（3）把知识输出纳入专家晋升的“加分项”而非“必选项”

这是一个很精细的操作。如果把知识输出变成硬性指标“不写就不能晋升”，就会回到“应付了事”的困境。但如果是“加分项”，写了且质量高可以加速晋升评审，效果就完全不同。因为这是正向激励，而不是负向惩罚。他可以选择不写，但愿意写的人，会真正为了建立自己的专业声望而写。

2. 消费者的匹配：把“知识库”变成“答案引擎”

消费者端的核心问题是：他怎么在最短时间、最少点击次数内，找到能解决他当前问题的那个内容。

这个问题说起来简单，做起来非常难。难点在于：搜索者的用词习惯和写作者的用词习惯天然不一致。

我在 PingCode 的一个金融客户那里做过一个实验。我们把 50 个最常见的一线问题列出来，然后让对应的技术人员去知识库里搜索答案。结果发现，能直接搜到正确答案的比例只有 38%。62% 的搜索行为要么没结果，要么结果不相关。

后来我们做了一件事：在每个文档的标题下面，加一行“易搜关键词”，由实际的消费者（而不是写作者）来填写。比如原文档标题是“批量代扣接口 V3.2 参数说明”，消费者添加的关键词是“代扣失败怎么查、对公账户扣款报错、批量扣款限额设置”。改动之后，同一个测试集的搜索命中率从 38% 提升到了 71%。

这件事给我的启发是：知识的“可发现性”不是一个技术问题，而是一个翻译问题。写作者习惯用技术语言命名，消费者习惯用场景语言搜索。连接者的工作，就是弥合这两套语言体系之间的鸿沟。

3. 连接者的运营：从“图书管理员”转向“内容产品经理”

我把大多数企业设置的那个“知识管理专员”角色叫做“图书管理员”，负责编目、上架、借阅登记，但不负责“这本书好不好看、有没有人看”。

而真正需要的角色，我称之为“内容产品经理”。他的职责包括：

• 洞察消费者需求：定期分析高频搜索词、零结果搜索词、高跳出率页面，判断“消费者想要什么但找不到”。
• 撮合供需：把需求精准地推给最合适的生产者，而不是全员群发“大家多写文档”。
• 设计内容格式：不同类型的内容，用不同的模板和结构，适配不同的阅读场景。
• 推动内容迭代：对高频使用文档定期回顾和更新，保证信息的时效性。

我见过做得最好的一个案例，是 PingCode 服务的一家 600 人规模的互联网企业。他们设置了一个“技术内容运营”岗位，只有一个人，但他每周做三件事：

第一，每周一拉出上一周知识库里“被搜索但未命中”的关键词 Top 20，发到对应的技术群里，@ 最懂的那个人，请他用 20 分钟写一个简短答案。

第二，每周三检查过去一个月内创建的新文档，对打开率低于 5% 的文档联系作者，一起修改标题和导语。

第三，每周五发一封“本周知识库精选”邮件，推荐三篇被高频打开或收到好评的文档，附上一句话推荐理由。

这个人的存在，让那个 600 人组织的知识库月度活跃用户比例从 18% 提升到了 42%，只用了不到半年的时间。而且他没有增加任何一个文档的考核指标。他只是让“供需匹配”这件事，有了一个专职的人在持续做。

六、以 PingCode 为例：工具如何支撑“谁用谁写”的机制

前面讲了很多机制层面的判断，这一节我专门讲一讲工具层面。为什么选 PingCode 举例？因为在知识管理这个领域，我观察到他们在“谁用谁写”这个方向的很多功能设计，确实比其他通用文档工具更贴近实际业务场景。

我不是在说“只有 PingCode 才能做好知识管理”。工具只是加速器，机制才是发动机。但我确实看到，PingCode 的某些设计，恰好解决了我在前面几节反复提到的那几个关键问题。

1. 知识页面与工作项的双向关联：让“写的”和“用的”自然汇合

这是 PingCode 知识管理区别于纯文档工具最核心的一个点。在 PingCode 里，一个知识页面可以直接关联到一个需求、一个缺陷、一个测试用例，反过来也一样。

这个设计为什么重要？因为它解决了“生产者和消费者在什么场景下交汇”的问题。

在传统的知识管理里，写文档是一个独立的任务，和实际工作流程是割裂的。文档写完放在知识库里，等别人来搜。但在 PingCode 的体系里，一条用文字写出来的方案，可以直接挂在一个具体的项目任务下面。接手那个任务的工程师，在打开工作项的同一条视线上，就能看到相关的知识沉淀。

这就是“谁用谁写”在工具层面的体现：知识内容紧贴着使用场景放置，不需要消费者额外去“找”。

2. 多人实时协同编辑：让“场景亲历者”成为共同作者

我前面反复强调一个观点：最好让“场景亲历者”来写。PingCode 的实时协同编辑，让这件事变得特别顺滑。

举一个真实场景。一个线上故障处理完毕，通常需要写复盘文档。以前的模式是，负责复盘的人（往往是模块负责人）花几个小时回忆、梳理、成文。但最了解故障细节的人，其实是当时值班的一线运维，或者那个半夜被叫起来修 Bug 的开发。

在 PingCode 里，我可以建一个复盘页面，直接把链接发给所有参与处理的人。每个人花 5-10 分钟，在自己负责的那一小块区域写上最第一手的信息。等所有人填完，我再花半小时统稿、补充结论。这样产出的复盘文档，信息的丰富度和准确度远高于一个人闭门造车，而每个人平均投入的时间反而更少。

让最懂行的人用最低成本贡献他擅长的部分，而不是让一个“代理写手”去还原整个场景。这就是“谁用谁写”在协同编辑里的落地。

3. 结构化空间与权限管控：让不同角色的边界清晰

PingCode 的知识管理支持“组织级 / 团队级 / 个人级”多级空间，每个空间可以独立设置读写权限。这个设计解决了一个非常容易被忽略的问题：不同层级的信息，对“写”和“用”的要求完全不同。

我把它分成三层来看：

这个分层的意义在于：不要把三种完全不同性质的知识生产方式混在一起管。组织级的内容，必须“谁用谁校验”，格式和权威性是第一位的。团队级的内容，要的是“场景亲历者的第一手沉淀”，速度和准确度优先于格式。个人级的内容，则是前两层的“苗圃”，好的个人笔记应当能方便地升级为团队文档。

4. 历史文档迁移与 AI 能力：降低“冷启动”和“维护”成本

现在很多企业问我：“我们已经有几千篇文档在 Confluence 或者别的系统里了，迁移过来会不会工作量巨大？”PingCode 支持 Confluence、Html、Markdown 等多格式的一键迁移。这一点在“谁写谁用”的框架下，意义在于不打断已有的知识积累，让生产者和消费者在新旧系统的切换中几乎感知不到断层。

另外，PingCode AI 的文档摘要、语法检查、翻译功能，我看到一个特别有用的场景是：大幅降低了“消费者预览成本”。一篇 5000 字的技术文档，AI 自动生成一个 200 字的摘要挂在页面前面，消费者一眼就能判断这篇文档是不是他要找的，避免“点进去，扫一遍，发现不对，关掉”这个高摩擦路径。

七、不同阶段、不同规模下的行动建议与取舍

写到这里，有些读者可能会觉得：“这些机制听起来不错，但我们团队现在只有 30 个人，或者我们才刚开始做知识管理，用得着这么复杂吗？”

答案是：你不用一步到位，但你需要在对的时机做对的动作。下面我按团队规模和知识管理成熟度，给出我认为最合理的行动清单和取舍原则。

1. 初创期团队（50 人以下）

这个阶段，知识管理的核心需求是“不要让关键信息依赖单一大脑”。

行动建议：

• 不做任何考核。任何形式的“要求写文档”都是错误的。
• 只做一件事：把口头决策变成文字记录。每次开会、每次方案讨论、每次 Bug 复盘，指定一个人花 10 分钟把结论和关键依据写成 3-5 条要点，扔到一个共享空间里。
• 用 PingCode 的个人空间或团队空间起手，不需要任何复杂架构。
• 写的人就是当时参与讨论的人，“谁参与谁写”就是这个阶段最自然的“谁用谁写”。

要避免的错误：不要在这个阶段花大量时间搭建“完美的知识体系框架”。10 个人的团队，最大的知识库是每个人的大脑，你需要的只是把这些大脑里的关键信息外化出来一点点，方便新加入的第 11 个人快速跟上。

2. 快速扩张期团队（50-200 人）

这个阶段是知识管理最危险也是最关键的时期。团队人数快速翻倍，新老员工比例骤变，信息传递开始出现严重衰减。

行动建议：

• 识别出 3-5 个“新员工入职后必须搞明白的核心知识点”，不是面面俱到，就只聚焦这几个。把最懂这几个点的人找出来，请他写一份不超过三页的文档。
• 设置一个兼职的“内容运营”角色。不需要全职，这个人可能是 TL 或者资深员工，每周花 2-3 小时关注知识库的搜索数据和问答情况。
• 建立最基础的反馈闭环：在每篇对新人重要的文档末尾，放一个简单的“帮到你了吗”。
• PingCode 知识管理里的“页面关联工作项”功能，从这个阶段开始发挥真正价值。把业务过程中产生的文档，和对应的项目、任务挂在一起，而不是让它们单独存在于一个“知识库孤岛”里。

要避免的错误：不要试图搞全员写文档运动。这个阶段需求的不是数量，是精准覆盖关键入职节点的 5 篇高质量文档。5 篇真正有用的，胜过 50 篇凑数的。

3. 成熟期组织（200 人以上）

到了这个规模，“谁写谁用”的机制必须建制化，否则知识管理一定会滑入我第四节里讲的某一种失败模式。

行动建议：

• 正式设置“内容产品经理”岗位（可以兼岗，但职能必须明确）。这个人直接对知识库的活跃度和内容质量负责，不对文档数量负责。
• 建立分层分级的空间体系（可以借助 PingCode 的多级空间与权限管控），将组织级、团队级、个人级内容分开治理。
• 在晋升和绩效体系中，为高质量知识输出设计一个“正向加分”通道，而不是“不完成就扣分”的负向惩罚。
• 把“搜索命中率”作为一个核心运营指标，周期性复盘零结果搜索词和低质量文档，驱动内容迭代。

要避免的错误：

• 不要迷信工具功能。PingCode 也好，别的工具也好，强大功能只有在对的机制下才有用。
• 不要同时对所有类型的内容设定同一套标准。组织级内容要“权威格式”，团队级内容要“场景鲜度”，允许它们长得不一样。
• 不要用“文档产出数量”考核任何人。如果你一定需要一个 KPI，用“高活跃用户数”或者“关键文档的月均打开次数”来替代。

4. 三种典型取舍决策

在实际操作中，你一定会遇到需要做取舍的时刻。我列出三个最常见的决策困境，给出我的判断：

（1）“所有人都写”还是“少数人写”？

答案：少数人写。不是不让其他人写，而是不强制。知识管理的舞台上，真正有效的内容由 20% 的人贡献。你只需要让这 20% 的人写得开心，让另外 80% 的人用得方便，系统就能持续运转。那些偶尔冒出来的高质量贡献者，应该被欢迎而不是被忽略，但他们不是主体。

（2）“质量优先”还是“数量优先”？

答案：永远质量优先。100 篇没人看的文档，不如 3 篇被反复查阅和引用的文档。但在初期，你可能会面临库很空的焦虑。我的做法是：先允许一部分“感知到需求后由连接者撮合生产”的定向文档进来，而不是用“每人每月必须写一篇”的方式堆量。

（3）“先搭架子再填内容”还是“先有内容再理架子”？

答案：先有内容再理架子，但需要有一个最轻量的起点框架。完全没架子，内容会散成一团乱麻。但架子搭得太精细，你会发现很多空格根本没人填。我建议的做法是：分层空间+不超过两级目录，内容自然沉淀 3-6 个月后，再根据实际使用情况重新调整分类结构。PingCode 知识库支持把页面在空间之间移动，这个灵活性在初期非常有帮助。

八、为什么大多数企业做不好这件事

写到这里，我想回到文章一开头的问题。为什么 14 家里面有 11 家做不好？

根本原因不是工具选错了，不是预算不够，也不是员工不配合。而是从一开始，决策者把知识管理定位成了一个“存储系统”，而不是一个“服务系统”。

存储系统的逻辑是：建一个仓库，让大家往里放东西。放得越多越成功。但服务系统的逻辑是：理解用户的需求，把对的答案在对的时间送到对的人面前。

这两种逻辑之间的差距，决定了知识管理的成败。

而“谁写谁用”这个问题的解决，恰恰就是从一个存储系统转向一个服务系统的分水岭。当你开始问“谁在用”“他用什么场景”“他在什么时候需要什么信息”时，你就已经走在正确的路上了。

另外还有一个更隐性的原因，说出来可能有些得罪人，但我认为必须讲：很多企业里，负责决策知识管理采购和顶层设计的人，自己并不是这个系统的高频使用者。他们决策的时候，想的是“我怎么管好这件事”，而不是“我怎么用好这件事”。这个视角偏差，贯穿了从选型到落地到复盘的全过程，导致所有的设计都偏向“管控便利”而非“使用便利”。

怎么纠正？很简单：在做任何知识管理的决策之前，先问 5 个真实的一线员工，问他们“你最近一次遇到问题是怎么解决的？如果当时有一个理想的工具帮你，你希望它怎么帮你？” 把他们的原话记录下来，贴在决策会桌面上。做每一个设计决定的时候，都回头看一眼那 5 句原话。

九、读完这篇文章，你下一步可以做什么

我不喜欢一篇文章读完让人觉得“有道理，但不知道该干嘛”。所以我给出三个具体的下一步动作，你可以根据你当前的实际情况选一个来做：

动作一：花 30 分钟做一次“知识库现状快检”。

打开你们现有的知识库（如果有的话），拉出最近 30 天的数据，回答三个问题：

1. 有多少文档在这 30 天内被打开过？（计算活跃文档比例）
2. 被打开次数最多的前 5 篇文档，它们的共同特征是什么？（从标题、长度、结构、作者四个维度分析）
3. 最近 30 天被搜索但结果为 0 的关键词有哪些？（如果有搜索功能的话）

就这三个问题的答案，往往已经能告诉你很多信息。

动作二：找一个“高频使用场景”，做一次“端到端体验测试”。

选一个新人入职场景，或者一个常见故障处理场景。让一个真实的执行者从头到尾走一遍：他遇到问题了，他去知识库搜索，他找到一篇文章，他看完，他解决了问题。你坐在旁边全程观察但不帮忙。记录下他在哪一步皱眉、哪一步停顿、哪一步说“算了不找了直接问人”。

这些“皱眉时刻”，就是你们知识库最需要被修复的地方。

动作三：如果你正在选型或者打算重新规划知识管理工具，把 PingCode 知识管理列入你的考察范围。

不是盲目推荐，而是基于前文的分析：PingCode 在“页面与工作项双向关联”“结构化多级空间”“多人实时协同”“AI 摘要与搜索辅助”这些点上，确实匹配了我所讲的“谁用谁写”的机制落地需求。你可以预约一个演示，带上你前面两步收集到的真实场景和真实痛点，去看它的功能能不能解决那些特定的问题，而不是看它“功能多不多”。

最后，我想用一句话收尾这篇文章。

知识管理从来不是关于“知识”，它本质上是关于“人”。人愿意写，是因为有人看、有人认可、有人受益。人愿意用，是因为好找、好懂、好用。这两件事，没有一件是靠行政命令能解决的。它们靠的是正确的结构设计、精准的激励设计、持续的内容运营。而这一切的起点，就是这句话：

先搞清楚谁写谁用，再决定怎么写怎么管。

顺序对了，知识管理就跑通了。顺序错了，花再多钱、上再多系统，都只是在装修一座没有人住的房子。