很多企业想把经验沉淀成知识库，建完却没人用。问题通常不在工具，而在输入端：知识没有被拆成可检索、可复用的条目。本文给出一套从盘点、改写、维护到验收的做法。
知识库建不起来，多数是输入问题
不少企业上过知识库系统，结果往往是：系统在，没人写；写了没人看；看了找不到。把原因归给工具，通常不准确。同一套工具，有的组织用得起来，有的用不起来，差别在输入端的知识形态。
一条知识要能被反复使用，需要满足三个条件：能被找到（标题和关键词对得上提问方式）、能被看懂（不依赖上下文和口口相传的背景）、能被执行（看完知道下一步做什么）。散落在聊天记录、会议纪要和个人笔记里的经验，三个条件一条都不满足。
所以动手建库之前，先要接受一个前提：从日常沟通里直接搬运的内容，几乎都不能直接入库。库不是仓库，是编辑部——原始素材进来，得经过一轮改写和结构化，才能变成资产。
先盘三类知识资产，再谈工具
盘点建议按三类走。一类是显性文档：制度、流程、模板、案例复盘，这类内容已经成文，工作是把它们归到正确的目录、补上摘要和关键词。一类是隐性经验：资深员工知道但没写下来的判断依据，比如「这个供应商报价偏低时要追查哪几个地方」，这类要靠访谈和追问，从具体事件里把判断逻辑抠出来。
第三类常被忽略：外部输入。专家讲座、行业交流、培训记录里的内容，如果不整理，听的时候热闹，散场就忘。把外部输入里的可用部分改写成内部条目，是知识库性价比很高的一块来源——花过成本获得的东西，值得沉淀下来。
盘点时给每类内容记两笔账：现在谁掌握、丢了这个岗位还能不能接得住。凡是「接不住」的条目，优先写。清单不必追求一步到位，先覆盖高频场景，跑起来再扩。
隐性经验要改写成问答体，而不是文档体
隐性经验入库的常见失败写法，是把口述整理成长篇文档。篇幅越长，越没人查。更有效的写法是问答体：把经验拆成一条条「遇到什么情况、怎么办」的条目，标题就写成提问的方式。
每条建议控制在三五百字内，结构固定：什么场景、判断依据、具体动作、常见误区。场景写得越具体，检索命中率越高。「投标报价怎么审」就不如「收到低于成本线的报价，审核从哪里下手」。
改写过程建议由使用者和掌握者配合完成：掌握者口述，使用者提问。使用者问出来的问题，往往就是未来检索时的真实问法。这样写出来的条目，天然对齐查询习惯。
条目命名也要统一：同一类问题用同一套句式。审核类条目都写成「收到什么情况、审核从哪里下手」，排查类都写成「出现什么征兆、排查顺序是什么」。句式统一后，写的人有模板可套，查的人有规律可循。库的规模上去之后，这种一致性就是检索体验的底座。
维护机制比内容量重要
知识库的衰落多半源于过期。判断依据变了、流程改了、联系人换了，条目没跟着更新，使用者被坑一两次，就再也不来了。所以库要建主人制：每个分类有明确的主人，负责新增、修订和废弃。
两个低成本机制值得固定下来。其一，时效标记：每条注明上一次核对的时点，超过约定周期没复核的条目自动进入待核清单。其二，使用反馈：每条留一个「有用、没用、内容有误」的轻量入口，被标记有误的条目由主人在约定期限内处理。
废弃也要有仪式。被新条目替代的旧条目不要直接删，标注「已由某条目替代」再归档——一方面保留演进脉络，另一方面避免别人收藏的旧链接直接变成死链。
能被准确查到的知识，才算资产
建到一定量之后，验收方式很简单：挑十个新人真实工作中的问题，让他们只靠知识库找答案，记录几个问题找到了可用答案。这个比例，就是知识库的真实可用度，比条目数量诚实得多。
接入智能工具的组织，还可以多一道测试：把同样的十个问题交给内部智能助手，看它引用的条目对不对。答不对，通常不是模型的问题，而是条目的写法不适合被检索——回头按问答体重写，比换工具有效。
知识库不是一次性项目，是一套持续运转的机制：有人盘、有人写、有人核、有人用。想把这套做法落到自己的组织里，或者需要请到有知识管理实操经验的专家来带一轮，可以在观潮智库官网按行业和主题检索合适的专家人选（www.guanchaothinktank.org.cn），具体邀约以实际沟通及最终确认为准。
核心要点
- 知识库建不起来多半是输入问题：能被找到、能被看懂、能被执行，是入库内容的三个门槛
- 盘点按显性文档、隐性经验、外部输入三类走，凡是「岗位接不住」的条目优先写
- 隐性经验改写成问答体条目，由使用者提问、掌握者口述，天然对齐真实检索问法
- 建主人制与时效标记，被标记有误的条目限期处理，旧条目标注替代关系后归档
- 用「十个真实问题」测可用度：能被准确查到的知识才算资产
