同一个问题，销售问同事、项目经理翻群聊、工程师查文档，各自能找到一部分答案，却难以解释它们之间的关系。建设企业知识中枢，第一项交付应该是一份能支持工作的公司全貌：公司做什么、谁负责什么、哪些项目正在推进、规则在哪里、当前数据去哪个系统查。
这份全貌不要求把所有信息塞进一篇长文。它由概览、对象档案、职能知识和关联入口组成，让人和 AI 都能逐步找到所需背景。企业已有文档搜索时，仍值得检查是否具备这层组织能力。
公司全貌应回答的六类问题
| 内容 | 应能回答的问题 | 合适的表达 |
|---|---|---|
| 业务与产品 | 提供什么，适用于哪些需求 | 产品说明与业务边界 |
| 组织与职责 | 谁主责，谁协作，谁确认 | 岗位职责与负责人链接 |
| 合作对象 | 与谁发生业务，使用哪些系统编号 | 对象档案与系统入口 |
| 进行中的工作 | 在推进什么，下一步由谁处理 | 项目概况与任务入口 |
| 现行规则 | 哪个版本有效，适用范围是什么 | 规则正文与批准来源 |
| 信息地图 | 去哪里查、用什么身份查 | 来源清单与读取说明 |
例如，新同事收到一份技术要求，首先要识别对应产品与项目，再找技术评审规则和负责人，最后查询系统里的当前版本。只找到那份附件，仍然需要同事补上整条工作链。
先整理连接关系，再追求字段齐全
可以从真实工作出发逐项整理：一个项目关联哪些合作方、合同、交付物和规则；一个产品由谁维护、有哪些现行说明；一个岗位的职责在哪里确认。每条关系都应能解释用途，不能为了画一张漂亮的关系图而制造大量无业务意义的连接。
对象名称可能变化，简称也会重复。档案应保留正式名称、常见别名和原系统编号，引用时指向同一对象。假设“远航项目”同时是群名和项目简称，就要通过项目编号与参与关系确认，不能仅因文字相同合并资料。
不必一开始规定所有行业通用的几十种属性。先保证当前档案能读懂、能回源，再根据使用中反复出现的问题补充结构。把不确定的关联记为待确认，远比写入一个看似完整的错误关系更有用。
先让当前状态清楚，再保留历史入口
一页档案的开头应该告诉读者现在是什么情况。过去的计划、后来取消的安排和旧负责人，可以放在历史记录或证据链接中，避免读者每次从头推理哪个说法还有效。
“资料最后整理于某日”也不等于“所有业务字段在该日都已核实”。项目简介可以周期更新，交付状态、库存与应收余额则应回到原系统读取。知识中枢应写清自己的信息时点和回源位置，让 AI 知道哪些内容可以直接使用，哪些需要现场查询。
用接手任务验收完整度
选一项真实工作，交给没有参加过前期沟通的同事：整理项目背景、找到现行要求、列出需要确认的问题，并说明下一步交给谁。记录他在哪一步停下来、又去问了谁、缺少的是资料还是关系。
如果他能找到十份文档，却仍不知道哪个项目在用哪份，缺的是关联与现行状态；如果知道应该查什么，却没有权限或入口，缺的是系统接入；如果资料本身互相矛盾，缺的是业务裁定。三类问题要分别修，不能统一归为“模型不够聪明”。
第一轮交付的检查方式
建议保留一份问题清单，逐题记录答案、来源、缺口和维护负责人。先覆盖高频工作涉及的公司信息，并明确尚未覆盖的范围；不要用已导入文件数量代表完整度。后续新资料进入时，检查它改变了哪份档案、哪条规则或哪段现行说明。
公司全貌整理好之后，员工提问不用每次从公司背景讲起，AI 也有了查找信息的起点。继续建设时，可结合三层知识目录和知识时效与实时查数确定组织与更新方式，整体服务范围见企业知识中枢。
更多同主题内容见企业 AI Agent 落地专题。
