AI API 接入前，企业知识库要先整理什么？

很多团队想把制度、产品资料和客服文档交给 AI 查询，但真正决定效果的不是先写多少提示词，而是接入前有没有把资料来源、权限和验收边界整理清楚。

先确认知识库服务谁

企业知识库不是把所有文件丢给模型就结束。销售希望快速查产品参数，客服希望定位退款规则，研发希望检索接口说明，管理者希望按项目复盘历史决策。不同人关心的问题不同，允许看到的内容也不同。AI API 接入前，先写一张场景表：使用角色、常问问题、资料来源、不可回答范围、人工兜底人。没有这张表，后面即使用上 AI 模型接口，也会在权限和答案口径上反复返工。

很多新手会搜索“GPT 中转”，更规范的说法是 AI 模型接口接入与调用管理。企业知识库场景更要关注调用链路能否解释：问题来自哪里、检索了哪些资料、模型返回了什么、用户是否采纳。这个链路比单纯换一个接口地址更重要。

第一步：盘点资料来源

把资料分成四类：稳定规则、产品说明、流程记录和临时素材。稳定规则包括价格口径、售后政策、账号权限；产品说明包括功能清单、接口文档、更新说明；流程记录包括会议纪要、项目复盘、客户反馈；临时素材包括还没有确认的草稿和个人笔记。只有前三类适合进入正式知识库，临时素材应先标记为待审核。

每份资料至少记录标题、负责人、更新时间、适用对象和失效条件。过期文件比没有文件更危险，因为模型会把它当成有效依据。可以让 Codex 帮忙扫描目录、整理文件清单和提取标题，但最终是否纳入知识库要由业务负责人确认。

第二步：定义切片和引用规则

不要按固定字数粗暴切分所有文档。制度类文档适合按条款切，接口文档适合按端点和参数切，FAQ 适合一问一答切，会议纪要适合按议题切。每个片段要保留来源链接、章节名和更新时间，方便回答时带出依据。开发者 AI 调用如果需要结构化返回，可以给每个片段增加 type、owner、version、visibility 字段。

接入测试时准备 20 个真实问题，其中至少包含 5 个不该回答的问题。例如内部价格、未发布功能、跨部门敏感资料。模型调用管理不能只看回答是否流畅，还要看它是否拒答、是否引用正确来源、是否把旧版本资料误当新版本。

第三步：先做权限，再做体验

知识库最常见的风险是“问得到但不该看到”。建议按角色建立可见范围：公开资料、登录用户资料、部门资料、仅管理员资料。AI 模型接口本身只负责生成回答，权限判断应在检索和业务层完成。也就是说，先决定用户能检索哪些片段，再把允许的片段交给模型总结。

如果团队已经多人共用接口，可以参考 团队权限和日志清单，把知识库调用单独记录入口和负责人。首次上线前，也建议回到 Codex 实操与 AI 资讯 对照其他接入案例，确认接口、权限和日志三件事没有混在一起。

上线前检查点

• 每份资料都有负责人、更新时间和适用对象。
• 不确定、过期、未审核资料没有进入正式检索范围。
• 权限在检索前判断，而不是等模型回答后再过滤。
• 测试问题覆盖正确回答、拒答、旧资料冲突和敏感内容。
• 日志能追踪问题、检索片段、模型名、调用时间和人工复核结果。

常见避坑

不要把知识库上线当成一次性项目。更稳的做法是先开放给小范围用户，收集他们问不到、答不准、引用不清的样例，再逐步扩大范围。永沃云枢用户可以先在 首页 完成接入准备，再把知识库测试结果沉淀成下一轮优化清单。