问题一：提问密度
先统计一周内重复出现的咨询量，按岗位与渠道分开看。同一类问题每天出现多次且答案基本一致，才值得把回答沉淀下来；偶发问题即使答错代价高，也应走专家通道，而不是为此建一套很少有人查的索引。
问题二：底稿可解析
要确认答案现在以什么形式存在：电子文档、工单记录、聊天记录，还是只在老员工脑子里。扫描件与手写批注要先识别校对，这部分工作量常被低估；底稿互相矛盾时，上系统只会把矛盾放大，识别错误还会被当成事实。
问题三：答错代价
对外承诺、报价口径、安全操作类问题答错会引发返工或纠纷，必须设人工复核与引用出处；内部流程类容错较高，可以先放开试用。两类内容不宜共用一套复核规则，否则要么拖慢高频场景，要么放过高风险场景。
问题四：权限清晰度
如果业务部门自己都说不清哪些内容能给哪些岗位看，先做一次内容分级再谈系统。片段级权限依赖清晰的标签体系，标签设计不清只会出现两种结果：过度放开，或大量内容被锁住无法检索，后者常被误判成检索效果差。
问题五：维护责任人
立项文件要写清知识负责人、复核人与更新节奏，并落到岗位职责。没有维护人的知识库半年内必然过期，而过期内容比没有内容更危险，因为它会被当成权威答案引用，纠正时还要解释当初为何这么回答。
适用与不适用
适合谁
- 正在评估是否单独立项知识库的企业
- 客服、售后、交付等有稳定重复提问的团队
- 需要向管理层说明投入理由的业务负责人
不适合谁
- 只是想做一次演示、没有后续维护安排
- 知识底稿尚未电子化、也没有校对资源
典型场景
一家工业设备代理商准备立项知识库。评估时先调出三个月客服工单，按问题类型聚类，发现安装调试类问题占多数且答案稳定；底稿是厂商手册与内部邮件，其中不少是早期扫描件。团队据此把范围缩到安装调试问答，先做扫描件校对再谈系统。
可执行步骤
- 导出近三个月工单与咨询记录，按问题类型聚类，标出高频且答案稳定的问题
- 抽样访谈一线人员，确认答案的现有形式、查找耗时以及常用的获取渠道
- 标注高风险问题，单独设定复核要求、引用规则与响应时限，避免所有问题一刀切
- 与业务部门逐条梳理内容分级与可见范围，形成标签草案并逐项确认边界
常见坑
- 用访问量或文档数量论证价值，说不清究竟省下了什么；应回到重复提问量、平均查找时长与转人工比例，再谈立项。
- 把扫描件直接计入可用底稿，识别错误进入回答；应先校对再入库并保留原图，别把识别问题算成模型问题。
- 五个问题只答技术可行性，漏掉维护人；上线后无人更新，回答失效却仍被引用，最终被业务整体弃用。
自检与验收清单
- 是否统计过重复提问的实际频次、渠道分布与责任人
- 底稿格式、可解析比例与校对工作量是否已估算清楚
- 高风险问题是否单列，并配置复核人与响应时限
- 内容分级与可见范围是否与业务部门达成一致
常见问题
没有量化收益数据，能不能立项？
可以，但要把论证换成可核查的过程指标：重复提问次数、平均查找时长、转人工比例、过期文档数量。这些数据来自工单与访谈，不必编造效果数字，也便于上线后对照复核，判断投入是否真的见效。
五个问题里哪一项最容易出问题？
通常是底稿质量与维护人两项被低估。技术选型可以更换，底稿校对与责任分工换不掉；这两项不解决，上线后问题会以答非所问和版本冲突的形式反复出现，最后仍靠人工兜底。
可以先上系统再补条件吗？
风险很高。系统会把内容问题放大成回答错误，而且错误带有权威口吻，一线很难分辨。更稳的顺序是先做内容盘点与分级，用人工流程跑通一轮问答，再决定哪些环节交给系统处理。