ARTICLE · 1347490
企业知识库第一批该入库哪些文档?一份按＂被问频率＂排序的清单
一句话结论
第一批入库的不是"重要文档"，是被反复问的那 30 件事。判断标准只有一个——它有没有对应的真实提问记录。
这篇讲方法，也讲落点：在 2Ryun 里，它是「文档树入库 → 保存即提取 → 一键建站 / 一行脚本挂客服」这一条链。文末按你实际会点的顺序走了一遍。
一个反常识的开场
问"企业知识库该放什么"，十个人有八个回答"公司制度、产品资料、培训材料、会议纪要"。
这是按文件类型回答。但知识库是按问题被使用的。
这两种视角的差别，直接决定第一批入库的成败：
沙利文报告把企业知识库的服务对象写成三类：员工、Agent 和业务系统［R01］。注意，这三类都不是"按文件类型"来取知识的——它们都是带着一个具体问题来的。你按类型存，它按问题取，中间的翻译成本就落在检索质量上。
而报告同时提醒：入库和查询是两条流水线，解析、分块、召回、重排任一环节失真，都会沿链路放大［R05］。第一批就放一堆低价值文档，等于在源头给整条链路加噪音。
所以这篇不给"分类清单"，给一套生成清单的方法，和一张可以直接照着走的样表。
✦ ✦ ✦
一、先建"问题账本"，再建"文档清单"
在选文档之前，先花两小时做一件事：把已经发生过的提问收集起来。
四个来源，按可信度排序：
- 客服/售后聊天记录
——最真实，因为提问的人不用考虑"该怎么问才专业"。 - 销售与客户的微信/邮件往来
——高频且带商业意图。 - 新员工入职后的提问
——暴露的是"文档写了但找不到"。 - 内部群里的重复提问
——同一个问题被问三次以上，就是入库信号。
收集时只记三列：原话 / 提问者身份 / 是否被回答过。
不要在这一步就归类。人一旦开始归类，就会不自觉地合并相似问题，丢掉措辞差异——而措辞差异恰恰是后面测试检索的素材。
产出：50–200 条原始提问。
判据：里面至少有 20 条是你从没想过会被问的。
隐藏收益：你会发现问题集中在极少数主题上。多数公司的分布是——前 30 个问题覆盖 70% 以上的提问量。这就是第一批的边界。
二、给每个问题打三个分
有了问题账本，再回过头去找"哪个文档能回答它"。这时给每个候选文档打三个分（1–5）：
然后按 频率 × 风险 ÷ 变化频率 排序。这个公式想表达的是：优先入"常被问、答错代价高、内容又相对稳定"的东西。
三个维度各自的作用：
只看频率，会把"今天天气怎么样"这种高频闲聊放进来； 只看风险，会优先放一堆合规文件——正确，但没人问，上线即荒废； 不看稳定度，会把价格表、库存、排期这类天天变的内容放进第一批，然后你每天都在修过期条目。
稳定度这一项最容易被忽略，也最伤。一个每周变一次的数字，入结构化知识库的成本远高于它的收益——这类内容更适合做成"查询接口"，而不是"知识条目"。
✦ ✦ ✦
三、第一批 30 条的样表（制造业版）
下面这张表是模板，不是标准答案。它的价值在于结构：每一条都对应一个真实提问，而不是一个文件。
到第 30 行你会发现一件事：这 30 条里，真正需要"写新文档"的可能只有 5–8 条，其余都是"已有文档里其实写了，只是散落、过期或表述不一致"。
这就是第一批真正的工作量所在——不是写作，是对齐。
✦ ✦ ✦
四、按"能不能答"分四类，处理方式完全不同
同样是"高频问题"，处理动作不一样。用一个 2×2 分一下：
四类的处理顺序建议是：先做左上（快赢），再做右上（补写），然后左下（裁决），最后右下（暂缓）。
右下这一类要特别小心。它是"业务本身还没想清楚"的问题，比如"定制单能不能退"。这种问题入库的后果是：AI 会把某个人的临时说法当成公司规则，反复对外输出。它不该由知识库解决，该由管理层解决。
2Ryun 的知识条目带三档置信度（extracted / inferred / ambiguous），第二档和第三档在对外场景里是要被限制使用的——这套机制存在的意义，就是让"没定论的东西"不要冒充"定论"。
五、明确不该进第一批的五类
比"该放什么"更重要的是"先别放什么"。以下五类，第一批一律排除：
- 时效性内容
价格、库存、排期、活动。它们不是知识，是状态。放进知识库的当天就开始过期。 - 未裁决的争议内容
两个部门说法不一致的制度、正在改版的流程。入库等于把矛盾固化。 - 一次性项目资料
某次投标的标书、某个客户的定制方案。它们有价值，但不构成"被反复问的事实"。 - 只有作者本人看得懂的笔记
缩写、代号、没头没尾的表格。这类内容提取出来的条目，错误率最高。 - 大段的法务文本
合同全文、法规原文。不是不能入，是第一批不入——它们的正确用法是"引用条款 + 解释"，需要先做摘要与适用条件，工作量大且容易出错。
✦ ✦ ✦
六、怎么让这份清单自己长大
第一批 30 条只是起点。真正的运营是让清单持续被真实提问刷新。
2Ryun 的"问题洞察"就是干这个的：客服会话结束（静默 30 分钟）后，系统归纳访客问题、打标签、判断知识库有没有答上；没答上的排前面，并且可以一键"生成草稿"。
这里有个值得说的设计细节：生成的草稿里，查不到的事实会留（请填写：…） 占位符。
这个设计看起来"不智能"，但它是对的。宁可留一个空让你填，也不要编一句话让你信。知识库最大的风险从来不是"答不上来"，是"答得很顺但错了"。
于是一个闭环形成了：
真实提问 → 问题洞察 → 未答上的排前 → 生成草稿（留占位）→ 人工补全 → 入库 → 下一次答得上这个闭环跑起来之后，你不再需要"猜该放什么"——系统每周告诉你缺什么。
七、一周能做完吗
能，但要接受"第一批很小"。
如果第 4 天卡住了（分歧裁决不动），不要跳过去做技术。带着分歧上线，等于把内部矛盾外包给 AI 对外广播。
✦ ✦ ✦
常见坑
坑一：按"部门交作业"收集文档。每个部门都会交自己最得意的材料，而不是最常被问的答案。要用问题账本倒推，不用部门申报。
坑二：把"完整"当目标。第一批追求的是覆盖率，不是完整度。30 条覆盖 70% 提问，比 500 条覆盖 75% 划算得多。
坑三：忽略"提问的措辞"。客户说"漏油"，文档写"密封失效"。这两种说法都得能被检索到，否则用户永远搜不到。入库时把常见同义词写进条目描述。
坑四：不记录"没答上"。没答上的问题才是最值钱的资产。它们是下一批入库清单的唯一可靠来源。
用 2Ryun 把这 30 篇跑成条目
清单是纸上的，条目是库里的。中间这几步，决定你这份清单能不能变成可用的东西：
- 把"问题账本"也写成一篇文档。
它本身是最该入库的知识——谁在问、问什么、现在怎么答。后面每周更新它，比更新任何一篇手册都有用。 - 只导入这 30 篇，建一个新库。
不要和存量文档混在一起。混进去，你就无法判断"这 30 篇到底覆盖了多少问题"。 - 看提取结果，不看导入成功数。
保存即触发提取（首次立即，后续去抖 5 分钟），产物是 17 类知识条目，每条带置信度。导入 30 篇成功不等于提取出 30 篇的事实。 - 建"必备条目"清单。
那 20 个高频事实，逐条在库里搜一遍，看是"有条目"还是"只有原文段落"。只有段落的，说明这篇文档结构有问题（没标题层级、表格没表头）。 - 缺的补文档，不是补条目。
正文少于 50 字不触发提取；条目正文也不能直接编辑。想让 AI 说对，只能回到来源文档把话说完整。 - 验收用语义搜索。
搜客户的原话（"这个多久换一次"），看返回的是条目还是整篇文档。返回条目，说明这 30 篇真的被拆开了。
一个反直觉的边界：不是所有文档都值得进第一批。内部通知、会议纪要、过期报价单，进去只会稀释检索结果——它们不是知识，是记录。
FAQ
Q1：我们提问记录很少，怎么办？
用"角色代入法"补：找 3 个一线的人（销售/售后/客服），各花 40 分钟，让他把"这周被问到的 10 个问题"写下来。三个人就是 30 条，够第一批用。
Q2：制度文件要不要入？
入，但不是全文入。把"制度"拆成"可回答的问题"——"请假要提前几天"比"考勤管理制度第三章"更有用。
Q3：同一个问题，销售和客服的答法不一样，怎么处理？
这属于"答案有分歧"，必须先裁决。裁决结果写成一个"标准答案 + 适用场景"，两个版本都保留会直接导致 AI 输出不稳定。
Q4：30 条够不够撑起一个客服？
够起步。多数客服机器人的真实问题分布是长尾的，30 条能覆盖主干；剩下的靠"答不上来→补"的闭环慢慢长。
Q5：怎么判断某条内容"该不该入库"？
问三句：有人问过吗？答错会出事吗？一个月内会变吗？前两个"是"、第三个"否"，就入。
✦ ✦ ✦
从今天开始：今天就把 30 篇导进去
清单可以在导入之后再改，库空着永远不会自己长东西。
这篇用到的是 2Ryun 的文档树、保存即提取、语义搜索、条目置信度——在同一个账号里就能跑通。
中文站 2ryun.wiki｜英文站 2ryun.com，注册即可免费使用； - 第一步
新建一个库，只放这 30 篇； - 第二步
5 分钟后搜 3 个客户原话，看返回条目还是整篇； - 第三步（可选）
把没搜到的补成"问答型文档"，一篇一个现象词。
第一批选错的代价，是后面每一篇都要重新判断一次。所以宁可少，不要凑数。
想先看看自己的问题账本能覆盖多少？
联系我们，一起过一遍清单
引用来源
[R01][R05] 弗若斯特沙利文（Frost & Sullivan）联合头豹研究院，《中国企业级 AI 知识库市场研究报告，2026 年 H1》，2026-10-23。英文发布页：frostchina.com [R09] Andrej Karpathy 对"上下文工程"的表述（原话出自 2025 年 6 月公开发言），术语汇编页：ai-magazine.com [R11] Nelson F. Liu et al., "Lost in the Middle: How Language Models Use Long Contexts", TACL 2024：arxiv.org/abs/2307.03172
