一、客户最初想要的，是一个“什么都能问”的 AI 助手
这个项目来自一家有多地销售和售后团队的企业。公司业务并不复杂，但资料分散得很典型：
- 产品资料在网盘里；
- 销售报价政策在 Excel 和群公告里；
- 售后处理标准散在培训 PPT、历史工单和个人笔记里；
- 合同条款有多个历史版本；
- 新员工遇到问题时，还是习惯在群里问老员工。
客户最初的需求是做一个内部 AI 问答入口，让销售、客服、售后和管理人员都可以直接提问。
从演示角度看，这个需求很容易做出效果。把文档导入知识库，接入大模型，再做一个网页或企业微信入口，用户就能开始问问题。
但企业内部知识库和普通 FAQ 不一样。它不是只回答“某个按钮在哪里”，而是会涉及报价、合同、客户等级、售后责任、区域政策和内部权限。只要答错一次，就可能让业务人员拿着错误口径去面对客户。
第一版试运行三天后，客户内部就出现了几个典型反馈：
- “它有时候说得挺像真的，但我不知道能不能信。”
- “同一个问题我问两遍，答案不完全一样。”
- “为什么普通客服能问到主管才该看的处理规则？”
- “如果客户追问依据，我们拿不出原文。”
这时候如果继续堆功能，比如加更多文档、换更强模型、把提示词写得更长，问题只会变得更隐蔽。
所以我先暂停了“继续扩知识库”的方向，把项目从 AI 问答开发，切回到知识治理和权限设计。
二、真正的问题不是“模型不聪明”，而是资料没有进入可被信任的状态
我们先做了一轮只读梳理，不改原资料，不急着重建系统，只看三件事：
- 哪些资料是当前有效的？
- 哪些资料适合给 AI 回答？
- 哪些资料即使被检索到，也必须先经过权限和人工确认？
梳理完后，问题比客户想象得更具体。
1. 同一类资料存在多个版本
例如报价政策，销售部手里有最新版，培训资料里有旧版，历史客户合同里还有特殊条款。对人来说，这些差异可以靠经验判断；对知识库来说，如果不标记版本和适用范围，它只会把它们都当成“可能正确的资料”。
所以第一类问题，不是问答问题，而是版本问题。
2. 文档标题清楚，但正文没有结构
很多企业资料看起来有目录，但真正落到正文，常常是大段说明、截图和口头化描述。模型检索时能命中，却很难判断哪一段才是答案依据。
这会导致一种很危险的情况：系统不是没找到资料，而是找到了太多相似片段，然后拼出一个看似完整、实际边界不清的回答。
3. 权限只存在于人脑和部门习惯里
客户内部原本就知道哪些政策销售能看、哪些售后能看、哪些只有主管能看。但这些规则没有进入文档元数据，也没有进入问答系统。
如果不处理，AI 知识库就会变成一个“绕过权限的搜索框”。
4. 没有回答依据，业务就不敢用
内部问答最重要的不是每次都说得漂亮，而是用户能判断这个回答能不能用于真实业务。
尤其是涉及报价、退款、售后责任、合同口径时，系统必须告诉用户：
- 这个回答来自哪份资料；
- 资料是什么版本；
- 适用于哪个区域、角色或客户类型；
- 如果资料冲突，应该找谁确认；
- 这类问题是否允许 AI 直接给结论。
没有这些信息，AI 回答越自然，反而越危险。
三、第一步不是调模型，而是把知识拆成四层
确定问题后，我们没有先改问答界面，而是先把知识库拆成四层。
第一层是公开型基础资料，比如产品介绍、通用操作说明、常见问题。这类资料可以直接用于 AI 回答，风险较低。
第二层是业务执行资料，比如报价规则、售后标准、服务边界和流程节点。这类资料可以参与回答，但必须带版本、适用范围和依据链接。
第三层是敏感决策资料，比如特殊客户政策、内部成本测算、合同让步空间。这类资料不能直接对所有人开放，需要按角色、部门或账号授权。
第四层是不可直接回答资料，比如争议工单、历史投诉、未定稿政策和老板临时口径。这类内容可以用于内部整理，但不能进入普通问答结果。
这一步看起来不像开发，但它决定了后面系统能不能真正上线。
如果不分层，所有资料都会混在一个知识库里；如果只靠提示词说“请谨慎回答”，系统并不知道哪些资料本来就不该被某个角色看到。
四、第二步是给每份资料补上“可检索的业务标签”
知识库不是把文件丢进去就结束。
我们给资料补了几类关键标签：
- 文档类型：产品资料、报价政策、售后标准、合同模板、培训资料、历史工单；
- 版本状态：现行有效、历史归档、待确认、禁止直接回答；
- 适用范围：区域、客户等级、产品线、服务类型；
- 权限等级：全员可见、部门可见、主管可见、仅管理员可见；
- 回答策略：可直接回答、必须引用依据、只允许给流程建议、必须转人工确认。
这样做以后，检索逻辑就不再只是“相似度最高的内容排前面”，而是先判断资料能不能用，再判断资料是否适合回答当前用户的问题。
举个例子，同样是问“客户要求延期售后还能不能免费处理”，普通客服能看到的是标准售后流程和升级处理入口；主管账号可以额外看到特殊客户处理边界；涉及合同让步和费用减免时，系统只给出“需主管确认”的提示，不直接给承诺性答案。
这才是企业内部 AI 问答和普通聊天机器人的区别。
五、第三步是把权限接进问答链路，而不是只放在页面入口
很多系统只在登录入口做权限：谁能进页面，谁不能进页面。
但知识库问答不够。用户进了同一个问答入口后，每次提问都可能命中不同权限等级的资料。如果只控制页面，不控制检索和回答，就会留下隐患。
这次改造里，我们把权限拆到了问答链路里：
- 用户提问时，先识别账号角色和部门；
- 检索时，只允许命中该角色可见的资料；
- 如果问题涉及高风险类型，先切到保守回答策略；
- 回答时必须带出依据片段和资料版本；
- 如果命中了冲突资料，优先提示“资料冲突，需要确认”，而不是强行总结；
- 对报价、退款、合同和特殊政策问题，默认保留人工确认入口。
这里有一个关键取舍：不要为了显得 AI 很强，让它回答所有问题。
企业系统里，有些问题最好的回答不是“结论是 A”，而是“当前资料不足以直接判断，请按这个流程确认”。这不是系统能力弱，而是风险边界清楚。
六、第四步是做命中回溯，让业务人员知道答案从哪里来
改造前，用户最不信任系统的一点是：AI 说得很流畅，但不知道它凭什么这么说。
所以新版本里，我们把回答拆成三块：
第一块是简短结论，用业务人员能直接理解的话回答问题。
第二块是依据来源，列出命中的文档、版本、更新时间和关键片段。
第三块是风险提示，说明这个答案是否可以直接用于客户沟通，还是需要主管确认。
同时后台保留提问日志和命中记录。运营人员可以看到：
- 哪些问题被频繁提问；
- 哪些问题经常命中不到资料；
- 哪些资料被引用最多；
- 哪些回答被用户标记为不准确；
- 哪些问题总是需要转人工。
这些数据反过来指导知识库维护，而不是让知识库上线后没人管。
七、第五步是建立维护机制：谁负责更新，谁负责下架，谁负责审核
AI 知识库最怕的不是上线那天效果不好，而是上线一个月后资料开始过期。
所以我们给客户设计了一个很轻的维护机制：
- 销售政策由销售负责人确认有效期；
- 售后标准由售后主管维护；
- 产品资料由产品或运营人员更新；
- 合同模板由管理人员审核后入库；
- 被标记为“回答不准确”的问题，每周集中回看一次；
- 过期资料不删除，但进入历史归档层，不再参与普通问答。
这个机制不复杂，但足够让系统持续可用。
很多企业做 AI 项目时，只盯着模型和界面，却没有安排“资料谁来养”。结果第一周很好看，第二个月就没人敢信。
真正能落地的 AI 知识库，必须把维护成本设计进去。
八、改造后的变化：不是 AI 变得万能，而是业务知道什么时候能信
这次改造完成后，客户内部最明显的变化不是“所有问题都能秒答”，而是回答变得可判断。
销售问报价口径时，系统会告诉他当前适用的版本和边界；如果涉及特殊客户，系统不会直接承诺，而是提示走主管确认。
客服问售后处理标准时，系统会按产品线和客户类型给出依据，不再把不同场景混成一个答案。
新员工查操作流程时，能直接看到当前有效资料，不再被旧版培训 PPT 带偏。
管理人员也能通过后台看到哪些资料缺口最明显，知道下一轮应该补什么文档，而不是继续靠群里问答沉淀经验。
这类项目最终交付的价值，不是做一个会聊天的入口，而是让企业内部知识从“散落在文件和人脑里”，变成“能被检索、能被判断、能被维护、能被追溯”的系统资产。
九、这类项目最容易踩的坑
如果你的企业也准备做 AI 知识库问答，我建议先避开几个坑。
第一个坑，是一上来就追求全量导入。
资料越多，不代表答案越准。没有版本、权限和适用范围的资料越多，反而越容易产生混乱答案。
第二个坑，是把权限只放在页面上。
内部知识问答的权限必须进入检索和回答链路。否则用户只要问法足够绕，就可能拿到不该看到的信息。
第三个坑，是不做依据回溯。
企业内部使用 AI，不只是要快，还要知道能不能对外说、能不能进入流程、出了问题能不能追责。
第四个坑，是没有维护人。
知识库不是一次性项目。政策变了、产品变了、服务边界变了，知识库也要跟着变。否则 AI 只是把过期资料用更自然的方式说出来。
