资料散在多人和多个系统里
新人、销售或交付人员反复问同样的问题，答案取决于刚好问到谁，已有资料也很难找到。
服务 / Enterprise Knowledge Base
资料很多，
团队还是找不到答案？
企业知识库的难点从来不只是“把文档导进去”。真正决定它能否支持业务和 AI 的，是资料是否可用、权限是否清楚、谁负责更新，以及能否经得住真实问题的检验。
先治理，再接入 AI不把没有出处、权限不清或已经过期的资料默认交给模型。先让团队用得上，再讨论 RAG、Agent 或工作流。
这些问题通常意味着该先做知识库建设
知识库建过，但没人相信
内容过期、结论冲突、没有来源或责任人，检索得到的信息无法直接用于业务判断。
想做 RAG 或 Agent，却担心答错
团队希望接入 AI，但还没界定哪些资料可用、哪些必须隔离，以及谁对输出承担最终责任。
从一条流程，而不是全公司文件开始
- 明确实际问题：选择销售回复准备、项目交付问答、内容审校或新人上手等一条需要稳定知识支持的流程。
- 盘点可用资料：列清来源、版本、适用范围、更新频率和不能进入通用知识库的材料。
- 划分权限与责任：定义谁能看、谁能维护、谁能确认冲突内容，以及哪些内容只能生成候选而不能直接对外使用。
- 用真实问题验证：让实际使用者提问并回查来源，记录找不到、答错或缺少边界的地方，再回到资料和规则修正。
建设过程中要留住的四个结果
- 一类业务知识的范围、来源、可见权限和不适用边界。
- 明确的业务 Owner、维护节奏与过期、冲突处理方式。
- 一组来自真实业务的问题，用来持续验证“找得到、用得上、能回溯”。
- 可用于后续 AI 试点的安全输入范围，以及必须保留人工确认的动作。
目标不是堆积文件数量，而是让团队在允许的范围内更稳定地找到可靠依据。
什么时候才适合接入 RAG、Agent 或 Workflow？
当知识来源明确、权限已经区分、维护有人负责，并且已经通过真实任务验证后，才适合接入 AI。接入之后也要保留最小权限、人工审核和记录：AI 可以检索、归纳和准备候选，不能越过业务负责人做最终承诺。
沟通前带来什么？
选一条团队每天会遇到的提问或协作流程即可：现在谁在回答、资料通常在哪里、哪些答案最容易过期或冲突、是否涉及客户或内部权限。我们从这条流程判断问题是资料整理、知识治理，还是已经适合进入 AI 试点。
先让一类知识
在真实流程里可用。
带来一条反复被问的问题或一组散落资料，我们先判断最小的建设范围。
发起场景沟通 →