知识搜不到时，排查清单的价值在于把模糊的“搜不到”拆成可逐项确认的检查点，并为每一步写明判断依据和责任人。本文按“现象确认—内容与发布状态—权限与可见范围—索引与同步—入口与环境”五个阶段组织，每项给出通过标准、证据形式和负责角色，同时标出阻断项与关闭条件，供一线支持人员直接填写使用。
要点总览（TL;DR）
- 清单按“现象确认—内容与发布状态—权限与可见范围—索引与同步—入口与环境”五阶段组织，一线支持人员先记录检索词、入口、账号和复现结果，再逐层排查。
- 每个检查项都要写清可核验的判断依据：页面状态截图、权限配置截图、索引时间戳、换关键词或换入口的复测结果，并注明采集人和采集时间。
- 责任角色按一线支持、知识库管理员、内容负责人、平台运维划分，交接以“上一阶段给出结论和证据”为条件，跨角色无法定位时升级处理。
- 阻断项包括内容缺失、权限错配、索引未更新、入口配置错误，未解决前清单不能关闭；关闭需同时满足现象定位、责任角色给出处理结果、用户复测通过三个条件。
- 排查记录可放在 ONES Wiki 页面中按阶段维护，待处理事项转为 ONES Project 工作项跟踪状态，具体检索配置与权限规则以实际产品文档和现场环境为准。
谁在什么时点使用这份清单
这份清单主要给一线支持人员使用：他们最先接到“搜不到”的反馈，也最接近用户的实际检索场景。知识库管理员、内容负责人和平台运维是协作角色，分别承接权限、内容和索引环节的确认工作。清单在三种时点启用：用户直接反馈搜不到某篇内容；支持人员自己检索时未命中预期结果；同一时间段内出现多条类似反馈。第三种情况往往指向索引或入口的共性问题，需要优先判断影响范围。
每张清单在开头固定记录表头字段，保证后续接手的人能还原现场。建议表头包含以下内容：
| 字段 | 填写要求 | 填写人 |
|---|---|---|
| 反馈时间 | 精确到分钟，注明时区 | 一线支持 |
| 检索词 | 保留用户原始输入，包括空格和标点 | 一线支持 |
| 检索入口 | 记录入口名称或页面地址 | 一线支持 |
| 账号与所属空间 | 记录反馈账号及其所在空间或部门 | 一线支持 |
| 复现结果 | 命中、未命中或部分命中，附截图 | 一线支持 |
| 当前阶段 | 五阶段中的当前所处位置 | 当前责任人 |
| 当前责任人 | 具体到人，不写岗位代称 | 交接双方 |
| 下一步动作 | 一句话说明接下来做什么、由谁做 | 当前责任人 |
表头字段填不全时，清单不进入下一阶段。这一步看似繁琐，实际能避免大量“查了半天发现检索词记错了”的返工。
第一阶段：现象确认与信息记录
这一阶段的目标是把“搜不到”变成可复现的具体现象。判断标准是：换一个人按记录的信息操作，能得到相同结果。
| 检查项 | 通过标准 | 判断依据 | 负责人 |
|---|---|---|---|
| 检索词是否准确记录 | 原始检索词完整保留，未做改写 | 用户输入截图或聊天记录 | 一线支持 |
| 是否换用同义词复测 | 至少用两个近义表达复测并记录结果 | 各次复测的检索词与结果截图 | 一线支持 |
| 是否区分标题检索与全文检索 | 两种方式分别测试并记录差异 | 检索方式选择状态截图 | 一线支持 |
| 复现次数 | 连续复测不少于三次，结果一致 | 复测记录表 | 一线支持 |
| 用户确认现象 | 用户认可记录的现象描述 | 用户回复记录 | 一线支持 |
阻断项：现象无法复现时，先补充记录再进入下一阶段。常见原因是检索词记录有偏差、入口记错或用户账号与反馈账号不一致。此时应回到用户侧重新采集信息，不带着不确定的现象往下排查。
第二阶段：内容与发布状态检查
现象确认后，先排除最基础的可能：内容本身不存在，或者存在但没有发布到用户能访问的范围。
| 检查项 | 通过标准 | 判断依据 | 负责人 |
|---|---|---|---|
| 目标文档是否存在 | 能定位到具体文档页面 | 文档详情页截图，含标题与地址 | 内容负责人 |
| 文档是否处于已发布状态 | 状态显示为已发布或等效状态 | 文档状态标识截图 | 内容负责人 |
| 文档所在空间或目录是否正确 | 位于用户应访问的空间路径下 | 空间路径截图 | 知识库管理员 |
| 最近修改记录 | 记录最近一次修改时间与修改人 | 版本或修改历史页面 | 内容负责人 |
阻断项：内容缺失或未发布，直接判定为内容侧问题，转内容负责人处理，不再进入权限和索引排查。这一步能把相当一部分问题挡在早期，避免后续角色做无效工作。
第三阶段：权限与可见范围检查
内容存在且已发布，接下来确认用户账号是否具备查看权限。这一阶段要区分“搜不到”和“无权查看”，两者的处理路径完全不同。
| 检查项 | 通过标准 | 判断依据 | 负责人 |
|---|---|---|---|
| 用户账号所属角色与空间权限 | 账号在目标空间具备查看权限 | 权限配置页面截图，含账号与角色 | 知识库管理员 |
| 文档可见范围设置 | 可见范围覆盖用户所在空间或成员组 | 文档权限设置截图 | 知识库管理员 |
| 是否存在密级或成员限制 | 记录限制条件及其适用范围 | 密级或成员名单配置截图 | 知识库管理员 |
| 同权限测试账号复测 | 用同等权限账号检索，结果与用户一致 | 测试账号复测截图 | 知识库管理员 |
| 账号状态确认 | 账号正常、未被停用或调整 | 账号状态记录 | 平台运维 |
阻断项：权限错配未修正前，不判定为检索问题。修正后需由用户或同权限账号复测，复测通过才可进入下一阶段。
第四阶段：索引、同步与检索匹配检查
内容存在、权限正常，仍然检索不到，问题通常落在索引或匹配环节。这一阶段需要平台运维提供系统侧的可观察信息。
| 检查项 | 通过标准 | 判断依据 | 负责人 |
|---|---|---|---|
| 内容是否已进入索引 | 索引记录中存在该文档标识 | 索引状态查询结果 | 平台运维 |
| 最近一次索引更新时间 | 更新时间晚于文档最近修改时间 | 索引时间戳记录 | 平台运维 |
| 是否存在同步延迟 | 延迟在约定范围内，或已确认延迟原因 | 同步任务日志片段 | 平台运维 |
| 检索词与分词或匹配规则是否冲突 | 换关键词或精确短语能命中，或已定位冲突点 | 多组关键词复测结果对比 | 知识库管理员 |
阻断项：索引未更新或同步失败未恢复前，清单不得关闭。这一阶段还适合判断影响范围：如果多条反馈集中在同一时间段，优先检查同步任务是否中断，而不是逐条排查内容。
第五阶段：入口与客户端环境检查
最后一层排查用户从哪个入口检索、用什么设备检索。入口配置错误或客户端缓存问题，会表现为“别人能搜到、这个人搜不到”。
| 检查项 | 通过标准 | 判断依据 | 负责人 |
|---|---|---|---|
| 检索入口是否正确 | 用户使用的入口与预期入口一致 | 入口地址截图 | 一线支持 |
| 客户端或浏览器版本 | 版本在支持范围内 | 版本信息截图 | 一线支持 |
| 缓存与登录状态 | 清理缓存或重新登录后复测结果一致 | 清理前后复测截图 | 一线支持 |
| 换入口或换设备复测 | 记录不同入口、不同设备的结果差异 | 复测结果对比表 | 一线支持 |
| 入口可用性 | 入口服务正常，无报错 | 入口健康检查记录 | 平台运维 |
阻断项：入口配置错误未修复前，不归因为内容问题。入口问题修复后，由一线支持指导用户复测并记录结果。
判断依据怎么写才可核验
判断依据的写法决定清单能否被他人复核。合格的标准是：换一个人拿着这条依据，能独立判断该检查项是否通过。写法上把握三点。
第一，写可观察的事实，不写主观判断。页面状态、截图、日志片段、时间戳、复测结果都属于可观察事实。例如“文档详情页状态标识显示为已发布，截图见附件，采集时间 10:32”可以复核；“状态看起来正常”无法复核。
第二，注明采集人和采集时间。同一份清单可能经过多个角色，缺少采集信息时，后续接手的人无法判断依据是否仍然有效，尤其在索引和同步这类随时间变化的环节。
第三，复测类依据要写清对比条件。例如“同一检索词在全局入口未命中，在空间内入口命中，两次复测间隔 2 分钟，截图各一张”，比“换了入口就好了”提供的信息多得多。
| 不推荐写法 | 推荐写法 |
|---|---|
| 权限应该没问题 | 账号 A 在空间 S 的角色为查看者，权限配置截图 1 张，采集人张某，10:45 |
| 索引好像没更新 | 索引记录中该文档更新时间 09:10，文档最近修改时间 10:20，索引时间戳截图 1 张 |
| 用户说搜不到 | 用户原始检索词“报销标准”，全局入口连续三次未命中，用户确认截图 1 张 |
责任角色分工与交接规则
四个角色按阶段承接，职责边界清晰，交接以证据为条件。
| 角色 | 负责阶段 | 核心职责 | 交接产出 |
|---|---|---|---|
| 一线支持 | 现象确认、入口与环境 | 记录检索词、入口、账号与复现结果，指导用户复测 | 现象确认表、复测截图 |
| 知识库管理员 | 权限与可见范围、空间归属 | 核查权限配置、可见范围与空间路径，配合关键词复测 | 权限配置截图、复测对比 |
| 内容负责人 | 内容与发布状态 | 确认文档存在性、发布状态与修改记录 | 文档状态截图、修改历史 |
| 平台运维 | 索引与同步、入口可用性 | 查询索引状态、同步日志与入口健康情况 | 索引时间戳、日志片段 |
交接规则：上一阶段给出结论和对应证据后，才移交给下一角色。交接时在清单中填写交接时间、交接人和已完成的检查项，接收方确认证据可复核后再开始本阶段工作。跨角色无法定位时，升级至平台运维或知识库负责人，由其在清单中记录升级原因和新的排查方向。
排查记录需要长期留存和多人协作时，可以把清单放在 ONES Wiki 页面中维护，按阶段分节填写；需要跟踪处理状态时，将每个待处理事项转为 ONES Project 中的工作项，指定负责人和截止时间，状态变化直接反映在清单对应行。ONES 方案中的全局知识检索能力也覆盖 Wiki 页面、附件等内容的检索，权限边界在方案层面有相应保障，具体检索配置与权限规则以实际产品文档和现场环境为准。
阻断项与清单关闭条件
阻断项是必须先解决的问题，未解决前清单不能关闭，也不能把问题标记为已处理。汇总如下：
| 阻断项 | 判定条件 | 解除标准 | 责任角色 |
|---|---|---|---|
| 内容缺失 | 目标文档不存在或未发布 | 内容补齐并发布，用户复测命中 | 内容负责人 |
| 权限错配 | 账号权限或可见范围不覆盖用户 | 权限修正，同权限账号复测通过 | 知识库管理员 |
| 索引未更新 | 索引时间戳早于文档修改时间或同步失败 | 索引恢复更新，检索命中 | 平台运维 |
| 入口配置错误 | 用户入口与预期入口不一致或入口异常 | 入口修复，用户换入口复测通过 | 平台运维 |
清单关闭需同时满足三个条件：现象已复现并定位到具体阶段；对应责任角色给出处理结果并附证据；用户复测通过并确认。三个条件缺一不可，仅“已转交”或“已排查”不构成关闭理由。
未关闭时，清单保留当前阶段、当前责任人和下一步动作三项信息，确保任何人接手都能继续推进。若问题在约定时限内无进展，按升级条件提交平台运维或知识库负责人，并在清单中记录升级时间与原因。
常见问题
用户反馈搜不到，但支持人员自己用同样关键词能搜到，清单应该从哪个阶段开始查？
这种情况说明现象与账号或入口相关，建议从第一阶段“现象确认与信息记录”开始，重点核对用户原始检索词、检索入口、账号与所属空间是否与支持人员一致。如果这些信息都一致但仍无法复现，再进入第三阶段检查用户账号的权限与可见范围，以及第六阶段检查用户使用的入口和客户端环境。不要因为支持人员自己能搜到就跳过现象记录，否则后续排查缺少可对比的基准。
判断依据里写“已截图”但没写采集人和时间，这样的记录能用吗？
不建议直接使用。截图本身是可观察事实，但缺少采集人和采集时间时，后续接手的人无法判断这份依据是否仍然有效，尤其在索引和同步这类随时间变化的环节。合格的做法是在截图旁注明采集人、采集时间和截图对应的页面或状态，例如“账号 A 在空间 S 的权限配置截图，采集人张某，10:45”。这样换一个人也能独立复核该检查项是否通过。
多条“搜不到”反馈在同一时间段集中出现，清单的排查顺序要不要调整？
可以调整。集中反馈往往指向索引同步或入口配置的共性问题，建议先由平台运维检查索引更新时间和同步任务日志，同时确认入口服务是否正常，再逐条核对单篇内容的状态和权限。这样能避免对每条反馈重复走完整流程。调整顺序时在清单中记录判断理由和影响范围，便于后续复盘。
清单关闭后用户又反馈同样的问题，之前的记录还有用吗？
有用。关闭时保留的阶段定位、判断依据和处理结果可以作为再次排查的起点，优先核对之前修正过的权限、索引或入口配置是否发生变化。如果问题重复出现，建议在清单中标注复发次数和间隔时间，并检查是否存在同步任务不稳定或权限继承规则被调整的情况。复发记录也是判断是否需要升级处理的依据。
一线支持人员没有权限查看索引状态和权限配置，交接时应该提供什么？
一线支持人员完成现象确认和入口环境检查后，把检索词、入口、账号、复现结果和截图整理好，在清单中填写交接时间和已完成的检查项，再移交给知识库管理员或平台运维。接收方确认证据可复核后开始本阶段工作。一线支持不需要自行查询索引或权限配置，但需要保证交接信息完整，避免接收方重复采集现场信息。
