2.1 知识来源盘点：文档、FAQ 与工单记录

智能体平台选定之后，我没有马上登录控制台拖节点，而是先花两天做了一件特别不性感的事——盘点知识。原因很简单：知识库这东西，喂进去什么，它就吐出什么。我们是一家五人 SaaS 小公司，客服组每天被重复问题包围，但真正能回答这些问题的素材，散落在至少五个不同的地方。很多人以为搭 AI 助手最难的是编排和提示词，真做过一遍就明白，八成的功夫花在数据上。程序员对知识管理的那点执念，可以看我写的另一本笔记知识库，这一篇只说业务落地。

盘点之前先做一件事：统一语言

拉人开会之前还有件小事容易被忽略：统一术语。我们内部习惯把套餐叫版本，客服和用户交流时也混着叫；运营文案里写的是方案，财务合同里写的是产品包。同一个东西四个名字，用户问起来 AI 会被搞晕，检索也会因为措辞不一致而漏掉答案。我花了一下午整理了一份术语对照表，规定知识库里一律用版本这个说法，其他叫法在清洗时统一改写或标注同义词。这份对照表后来在提示词调试阶段也直接用上了，模型回答的措辞因此始终和官网保持一致。刚做的 AI 客服如果答非所问，先别怀疑模型，十有八九是术语没对齐。

先列一张来源清单

我拉着客服主管和运营妹子，在会议室白板上把所有可能的知识来源全列了出来，然后逐项标注格式、更新频率和可用性。这张表后来贴在我工位边上，是整个知识库建设的起点。盘点这件事别一个人闷头做，客服每天和用户打交道，她们比我清楚答案真正藏在哪里。

会议组织上有个建议：控制在两小时以内，目标就是产出这一张表加一份待清洗清单。第一次我们没设时限，从聊产品 roadmap 聊到客户八卦，一下午什么都没沉淀。第二次我学乖了，提前打印一张空表格贴白板上，逐行填，填完散会。

盘点完我有点意外：本以为最权威的产品手册，在客服日常回答里占比其实很低——用户问得最多的反而是价格、发票、续费这类琐碎问题，答案全在 FAQ 和工单里。这直接定下了工作顺序：先 FAQ，再工单，再产品手册，最后官网帮助页和 wiki 查漏补缺。顺带一提，如果公司官网本身还在搭建阶段，可以参考我的轻量建站实战，帮助页的内容结构和官网是一起设计的，盘点时能省一轮梳理功夫。

两类最难处理的素材

清单列出来容易，真上手清洗时会发现两类素材特别磨人，工单和 PDF 手册，一个脏在内容，一个乱在结构。

第一类是工单记录。我从客服系统导出了最近三个月的 Excel，三千多行，里面什么都有：用户姓名、手机号、公司名、订单号，甚至还有用户在工单里吐槽的家长里短。这些内容若直接喂进知识库就是灾难。我的做法是先跑一遍脱敏脚本：姓名和手机号用正则替换成占位符，公司名统一替换成某企业，订单号截断只留后四位。脱敏完再人工抽检两百行，确认没有漏网之鱼。另外工单里大量是无效内容——催进度的、道谢的、同一个问题反复提问的、客服之间互相指派商量的——这类对话对检索毫无价值，我只保留带明确解决方案的闭环工单，最后筛出四百多条有效记录。筛选标准也很朴素：这条工单的问答，能不能直接回答某个未来的用户提问？能就留，不能就丢。还有一个容易被忽略的细节：工单里客服的内部备注要整体剔除，那里全是同事之间的内部缩写和情绪发泄，混进知识库会污染检索结果。

第二类是 PDF 产品手册。50 页的手册，章节结构看起来很清晰，但拆开后才发现坑：每页都带页眉页脚和重复出现的目录，图表说明跟正文混排，还有几个跨页表格从中间断开，单独读任何一页都读不通。我的处理是按章节拆成独立小文件，目录页和版权页直接扔掉，跨页表格手动合并修复，图文混排的页面单独整理成纯文字描述。PDF 解析还有个常见问题是扫描件，图片化的页面提取出来全是乱码，这种只能重新找到原始可编辑文档，或者人工补录文字。最麻烦的是表格类参数说明，横竖表头一拆就散架，这类内容我干脆重写成结构化的文字清单再入库。这种内容如果不处理就往里塞，后面切片环节会出一堆语义断裂的碎片，到时候排查起来比现在费劲十倍，这点在 2.3 篇切片实战里会细说。

手册还有个隐藏雷区：版本混乱。我们文件服务器里同时存着 v2.1、v2.3、v2.4 三版手册，客服电脑里还躺着一个不知道哪年的修订版。有阵子用户问某个功能，不同客服给出不同答案，根源就是大家看的不是一版文档。我对齐的笨办法是：把所有版本摊开，逐节对比差异，以产品后台实际功能为准做一份权威版，其余版本整体打上版本号标签归档，不进知识库只有留档备查的用途。同时在团队里立了个规矩，凡是说产品功能的内容，以知识库为准，其他渠道的旧文件一律以新换旧。这事之后我们再没出现过客服和帮助中心页各说各话的情况。

清洗的通用套路

两类硬骨头啃完，我总结了一个可复用的五步清洗流程，后来每周迭代知识库都照这个走：第一步导出原始文件，第二步脱敏（工单类必须有这一步），第三步剔除无效内容，第四步统一术语和格式，第五步人工抽检百分之五左右。抽检比例不用太高，但必须做，脚本永远替不了人眼对语境的判断。整个流程最好沉淀成一串脚本加一份检查清单，这样客服主管自己也能每周跑一遍，不用每次都来找我。

一个被忽视的来源：客服的私人收藏

清单列完之后还有个小插曲。材料都入库了，我发现有两类问题始终答不好：一类是新功能上线后的高频提问，一类是那种官网帮助页没写、但客服天天在解释的灰色地带。我问客服主管这些答案平时存在哪，她有点不好意思地掏出一个记事本——她私人攒了一年半的应答小抄，全是真实用户提的问题和她验证过的话术。

这份小抄后来成了我们知识库里质量最高的一批素材。它比 FAQ 更新更快、比工单更聚焦答案本身，而且天然带着用户问法。我把它逐条整理成标准问答格式纳入 FAQ 体系，同时和客服主管约定：每两周把小抄里新增的内容同步进知识库。这也提醒我，盘点知识来源时别只盯着系统和文档，问一句你们平时靠什么答题，可能掘出最大的宝藏。

最后给这节做个小结。盘点阶段真正花的精力不在盘点本身，而在三件事上：拉通客服拿到准确清单，统一术语避免鸡同鸭讲，以及把脱敏和筛选做到位。做完这三件事，知识库的地基就稳了。下一节我们解决这些原文存在哪、怎么管的问题。

怎么判断一份知识值不值得收

不是所有文档都配进知识库。我定了一个粗标准，和客服主管一起逐份过：

光有标准还不够落地，我又把它做成了一张打分表，每份文档五个维度各打零到二分，满分十分，七分以下直接进缓冲目录：

打分表的好处在于是它把拍脑袋变成了记录在案的决定：某份文档为什么没进知识库，日后新人翻表格就清楚，不用靠口口相传。

筛选过程中我们扔掉的东西远比留下的多：三十七篇阅读量个位数的 wiki 杂记、两份作废的活动说明、一整套去年的旧版帮助文档。有人觉得可惜，但知识库不是档案柜，它的唯一使命是支撑回答用户问题。把没用的东西留给搜索引擎，把有用的留给 AI，定位清楚了取舍就简单。

这里还有个平衡的艺术：保留标准太严会漏掉长尾知识，太松又会被噪声拖垮。我们的折中做法是设置一个缓冲目录，拿不准的文档先扔进去，等摸底测试跑完看哪些题型答不上来，再回头从缓冲目录里找对应内容补进去。既保证了起步克制，也给后续留了弹药。按这个标准筛完，最终进入知识库的有效素材是：FAQ 三十条、工单四百条、手册拆分后的二十个章节文件、帮助页十六篇。规模不大，但每一份都是确认过的干净数据。我宁可起步少一点，也不盲目把全公司文档倒进去——知识库质量和数量没什么关系，脏数据进得多，反而把干净的检索结果带偏。在盘点这一步多花的每一天，后面编排和调试都能省回来。至于知识原文最终存在哪里、怎么集中管理，是下一篇 COS 存储规划的内容；我们业务后端所依赖的服务器与数据库底座，可以看我另一本腾讯云五件套实战。

踩坑记录

• 差点把含手机号的工单原文上传：清洗前我随手把一份导出文件拖进了共享目录，好在后来检查权限时发现。从此定下规矩，任何文件先脱敏再落盘。
• FAQ 版本冲突：在线表格有多人同时编辑留下的历史版本，我导出时没注意，收进了几条已经作废的答案。后来固定每周一上午由客服主管确认后我再导出。
• 帮助页直接抓取会带上导航栏文字：抓下来的网页混着一堆菜单链接和页脚信息，需要单独提取正文区域，否则检索时会当成正文返回给用户。
• 术语不统一导致漏召回：最初用户问专业版多少钱时没命中答案，因为知识库里写的是团队版价格。术语对照表做完之后这类问题基本消失。
• 工单筛选标准太宽松：最初我只剔除了明显无效的工单，结果留下一批只有客服内部讨论、没有最终结论的记录，这些回答不了任何用户问题，第二轮被清掉了。

延伸阅读

• 知识管理的系统性方法，见笔记知识库。
• 本地存储与云端方案的对比取舍，见NAS 家庭服务器。
• 知识原文如何集中管起来，见下一节 COS 存储规划。