内部知识库助手
把制度与项目文档做成可问答的内部助手，并用“答不上来”的问题反哺文档更新。
背景
制度、项目规范散落在网盘、群文件与个人笔记，新人上手大量打断老人。
已有过一次“聊天机器人演示”，因乱答与无权访问问题被叫停。
信息安全要求：合同、薪资、未公开商业数据不得进入可检索范围。
约束
- 试点范围限定行政制度 + 工程规范，不含客户合同原文
- 入口走企业微信，不另装 App
- 必须能审计：谁问了什么、引用了哪篇文档、是否被点赞/点踩
真正的难点
失败点通常不在模型，而在知识边界与运营闭环：没有人维护文档时，助手会越用越错；边界不清时，一次越权回答就会失去信任。
关键取舍
先做检索增强问答，不做自动改制度
助手只回答与引用，不直接改 Wiki。高风险操作一律人工。先建立“敢用”的信任，再谈更深自动化。
权限跟着文档库走，不另造一套角色
沿用现有知识库 ACL。检索阶段即过滤不可见文档，避免“先召回再屏蔽”造成泄露风险。
把未回答问题做成产品 backlog
无法回答或差评问题每周汇总给知识管理员。助手价值=答对率×文档更新速度，缺一不可。
怎么做的
梳理可公开知识范围与文档模板；构建切片、向量检索与引用展示。
企业微信入口集成；回答附带文档链接与权限说明；记录问答与反馈。
试点部门跑通后，再扩到更多事业部，并增加敏感词与主题黑名单。
可核对的结果
常见问题自助率提升试点部门新人周询老人次数下降（内部问卷）
文档更新形成闭环四周内根据未回答问题补了 20+ 篇规范空洞
敏感内容按权限隔离安全抽检未发现越权引用
从演示走向日常入口企业微信工作台固定入口，周活跃稳定
复盘
- AI 项目要先写清“不能答什么”，再写“能答什么”。
- 没有知识管理员编制，就不要承诺“上线即减负”；减负来自文档运营，不是模型本身。
- 效果指标用“可核对的引用 + 人工反馈”，比只看点赞数更靠谱。
技术栈
向量检索大模型 API企业微信对象存储