员工反馈在 Amazon Quick 里搜不到某份文档，管理员通常要在三种可能之间做判断：数据源本身没把这份内容接进来、目录里没把检索范围给到提问者、或者同步任务还没跑完。可行的顺序是先固定“接了哪些数据源、同步到哪一层”，再用测试账号复现检索结果，最后回到企业目录核对提问者所在的组。三步分开做，讨论时才不会在“到底是权限问题还是数据问题”上反复漂移。

处理顺序建议：先在管理后台记录每个连接器的类型与同步范围，作为判断基线；再用一份已知文档加一个测试账号做可复现检索，得到返回与不返回的对照；最后在目录服务里核对提问者的组成员关系。这三步互相不能替代，跳过任一步都可能把数据侧问题误判成权限问题。具体字段名与组模型需结合自身环境确认。

在管理后台确认已连接的数据源及其同步范围

先回答“接了什么、同步到哪一层”。在管理后台找到连接器列表，逐个记录连接器类型（例如对象存储、协同文档、工单或知识库系统）、该连接器当前是否启用、以及同步范围的设置位置。同步范围有时挂在连接器配置里，有时在独立的抓取任务或数据空间设置里，位置以实际管理界面为准。不要凭记忆填，截屏或抄录当时的取值，后续排查都以这份记录为基线。

字段名同样以实际界面为准，下面的骨架只用于整理信息，不代表任何产品的真实字段：

connector_type:       <对象存储 / 协同文档 / 工单系统 / 知识库>
endpoint:             <服务地址，如 https://...>
auth_method:          <OAuth 客户端凭证 / 服务账号密钥 / API Token>
sync_scope:           <指定空间或顶层目录 / 全量 / 按标签筛选>
sync_filter:          <按父目录、按文档可见性字段、按更新时间>
identity_mapping:     <身份映射依据，如邮箱或员工号>
visible_to_groups:    <允许检索的目录组或用户组>
last_sync_status:     <最近一次同步结果与时间>

把每个连接器按这张表填一遍，就得到一份从数据源到用户组的可见范围对照清单：左边是数据源与它的同步范围，中间是身份映射方式，右边是这份内容最终对哪些组可见。清单的价值在于，当有人说“搜不到”时，可以直接定位是左边（内容没进来）还是右边（组没给到）。

需要留意的边界：同步范围写“全量”不等于所有内容都会进入检索，部分系统仍会按文档自身的权限标记做二次过滤；配置保存成功也不代表同步已完成，建议同时记录最近一次同步的状态与时间。

用测试账号检索一份已知文档，记录返回结果

可见范围设置是否真的生效，只能靠可复现的检索动作判断。准备两个账号：一个属于应能看到该文档的用户组，一个不属于；用一个刻意挑选的关键词去搜，关键词尽量取自文档标题或正文里的专有名词，避免用“报告”“方案”这类会命中大量无关内容的宽泛词。

操作步骤：1）用 A 账号（应在可见组内）登录，用关键词检索，记录是否命中目标文档；2）退出，用 B 账号（应在可见组外）重复同一关键词，记录结果；3）两次检索之间不要改配置，改过配置后要重新记录一次。

对照记录建议用下面这种格式，一条文档一行：

检索关键词:
文档标识:            <标题或唯一编号>
账号A 所属组:        <组名>   预期: 命中   实际: <命中/未命中>
账号B 所属组:        <组名>   预期: 不命中 实际: <命中/未命中>
记录时间:
同步状态:            <最近一次同步结果>

几种结果对应不同方向：A 不命中、B 也不命中，倾向于内容没进同步范围；A 命中、B 也命中，说明权限过滤没生效，需要回头检查同步范围里是否带了按组可见的规则；A 命中、B 不命中，是预期状态；A 不命中、B 命中，通常是组映射或身份映射出错。记录时间点很重要，同步是异步任务，前后两次结果不一致时，先确认同步是否已经跑完。

在目录服务里核对提问者的组成员关系

测试账号能搜到、提问者搜不到，差异往往在目录侧。到目录服务里查提问者账号当前所在的组，再和连接器配置里允许检索的组做比对。常见的不一致有三类：

• 组嵌套：配置里给的是父组，提问者实际在子组里。需要确认连接器或 Quick 是否会展开嵌套组，核对位置在组属性里查看成员来源，以及配置侧写的是父组还是子组。
• 外部协作者：账号类型与会话账号不同，可能不在同一目录域内。核对位置是该账号的账号类型与所属域，以及它是否被纳入了同步的身份映射范围。
• 离职或残留账号：账号已停用但组关系仍保留，或账号迁移导致组名变化。核对位置是账号状态、最近登录记录和组成员变更记录。

排查时按“配置里的组名”到“目录里的组名”逐层对齐，不要只看用户显示名。组名在两侧不一致（一个是显示名、一个是唯一标识）时，靠人工比对容易出错，建议用邮箱或员工号做锚点。

把搜不到的原因分成数据侧和权限侧两类

给业务方的回复最好只分两类，先定性再修：

数据侧：内容没有进入同步范围，或者进了但还在等同步。可验证动作：用测试账号 A 也搜不到同一关键词，同时管理后台里该连接器的最近同步状态为空或报错。对业务方可以说：“这份内容目前不在已同步的范围内，我们先确认它所在的位置是否需要加入同步范围，加入后要等一次同步跑完才能检索到。”

权限侧：内容已经同步，但提问者所在的组没有检索范围。可验证动作：测试账号 A 能命中，提问者账号经目录查询确认不在配置允许的组内。对业务方可以说：“内容已经可以检索，但这位同事的账号还没有对应的访问范围，我们来核对一下他应该在哪个组里。”

两类都排除后，再考虑同步任务未完成、索引延迟这类中间状态，此时保留记录时间点，等下一次同步结果出来再判断。不要在没有对照记录的情况下，直接告诉业务方“权限已经配好了”。