可发现性（Findability）
“用户找不到内容”是一个症状，通常有四种原因，每种需要不同的修复方法。本技能服务于决定首先更改什么：它将原因与抱怨分开，选择解决该问题的最便宜修复方案，并设定一个能显示其效果的衡量标准。
开始之前
| 你需要 | 如果缺失则… |
|---|---|
| 用户找不到什么、他们是谁、以及他们在哪里找 | 询问。如果仍然模糊，列出候选内容并视为假设。 |
| 网站、应用或至少其导航系统 | 询问。如果没有，你只能编写诊断计划。 |
作为CSV的搜索日志：query,count,results，以及clicks（如果可用） | 说明要导出什么以及导出时间段。交付诊断计划、衡量标准和空表格。永远不要估计日志中可能包含的内容。 |
| 分析数据、支持工单、内容清单 | 说明它们会改变哪些结论，并将那些结论标记为“未确认”。 |
方法
-
将失败描述转化为任务。 “一个[用户类型]试图[目标]，在[位置]查找[事物]，结果[发生了什么]。”每个投诉一行，使用他们自己的话。
-
读取日志并使用其数据。
node "${CLAUDE_SKILL_DIR}/scripts/search-log.mjs" searches.csv如果脚本提示日志太小无法排名，则将其作为用户输入的词汇列表，并声明无法计算比率。说明导出覆盖的时间段；脚本无法获知。
-
在开出处方前进行诊断。 按此顺序检查原因，因为每个原因都基于前一个。可能同时存在多个原因。将每个结论标记为“已确认”或“推断”。
原因 如何确认 常见修复 关联技能 内容缺失： 根本不存在 查找用户使用的所有名称。零结果查询且任何地方均无匹配内容 创建它，或者明确声明不提供此项 content-inventory 标签错误： 以其他名称存在 用户词汇得到零结果或无点击，而内容实际存在于你使用的名称下；用户反复跳出 重命名，添加同义词 labeling 埋藏过深： 命名正确，但没有路径到达 从首页和枢纽页计算步骤数；查找孤立页面、死胡同、深度分页作为唯一路径、用户已在应该提供内容的章节页面上开始搜索 在用户已经寻找的地方链接它，或者移动它 navigation, sitemaps 搜索功能失效： 内容存在，查询匹配，但结果错误 亲自运行最热门的查询并阅读结果；结果无点击、用户重新措辞、退出结果页面 最佳匹配、同义词、索引范围、排序 第5步 许多可发现性问题在标签和分组方面修复比在搜索引擎中修复更便宜，所以不要从搜索引擎开始。深度本身不是缺陷：三点击规则是一个迷思，当每一步都清晰看起来像他们的目标时，用户会点击更多次。
-
决定哪条路径应该生效。 同时支持浏览和搜索，因为用户会在两者之间切换。热门查询应该能在首页开始的一到两步内到达。
用户类型 需要加强的路径 知道确切名称 搜索，或A到Z列表 知道需求但不知道名称 带有清晰标签的浏览，然后使用分面导航 正在探索或比较 浏览、筛选器、相关链接 返回查看某物 最近项目、保存的视图、快捷方式 正在任务中途 在工作位置提供的上下文链接或提示 -
在搜索是原因时修复搜索。 为热门查询在结果顶部放置精心策划的最佳匹配。从脚本的变体分组中构建同义词集，从标记为
SYNONYM WOULD ANSWER的组开始，然后添加只有人才能发现的同义词，如首字母缩写和行话。绝不让无结果页面成为死胡同。references/search-tuning.md 涵盖了所有这三项以及要导出的内容。 -
在决策发生的地方放置提示。 一个好的提示回答了用户已有问题，在他们做出选择的那一刻，在他们已经在看的地方，安静且廉价。汽车燃油表旁边的箭头指示油箱盖在哪一侧，就是典范。在添加提示或个性化入口点之前，请阅读 references/routes-and-cues.md。
-
如果有人提议使用AI对话作为修复方案，请先测试。 按钮和菜单让用户能够行动并展示系统的功能。开放的对话框执行前者缓慢，执行后者根本不行。
情况 更好的答案 有限且可知的选项集 按钮、菜单或筛选器 用户不知道系统能做什么 可见的结构；空的输入框什么也教不会 步骤已知的重复任务 直接路径 内容缺失或标签错误 先修复这些问题；对话无法检索不存在的内容 真正开放式的、每次措辞都不同的问题 对话可以发挥其作用，但需围绕它建立结构 -
设定你实际能收集的衡量标准。 在更改任何内容之前采集基线，每个问题一个衡量标准。如果没有基线，请说明。
衡量标准 数据来源 目标 找到简单项目所需时间 与真实用户进行的定时任务测试 30秒以内 任务成功率 任务测试或树测试 至少70%，热门任务达到80% 零结果搜索占比 搜索日志 低于其自身基线 搜索退出、重新措辞 分析数据（如果结果页面被追踪） 低于其自身基线 针对此主题的支持工单量 帮助台（如果已标记） 低于其自身基线 references/measures.md 说明了每个衡量标准能显示什么以及不能显示什么。
交付物
除非用户指定其他文件名，否则编写 findability-diagnosis.md，按以下顺序：推荐（两到三句话）；失败任务（作为任务描述）；证据（来源、时间段、脚本数据）；诊断（内容、原因、证据、已确认或推断）；选项（两到三个，每个选项的成本及其未修复的问题）；按顺序排列的修复列表及其关联技能；最佳匹配和同义词（query, action, target）；无结果页面（如果相关）；衡量标准（名称、基线、目标、来源、复查日期）；假设以及未可用的信息。
| 工作内容 | 返回内容 |
|---|---|
| 一件没人能找到的事情 | 失败、原因、证据、修复方案和一个衡量标准，直接回复 |
| 一个需要读取的搜索日志 | 证据、最佳匹配和同义词，以及零结果查询的差距 |
| “整个网站的可发现性都很差” | 完整的文档 |
将长表格放在最后。更长的文档并不代表更详尽。
检查清单
- 每个数字都源自脚本运行或用户提供给你的来源。如果日志发生变化，请重新运行脚本。
- 每个修复方案都指明了它所解决的原因，并且每个原因都有证据或标记为推断。
- 如果你有访问权限，请亲自运行最热门的查询，因为日志无法判断结果是否优质。
- 你已检查每个提议的同义词是否含义相同。脚本根据拼写进行分组，因此它可能将含义不同的词汇配对在一起。
- 搜索日志可能包含输入到搜索框中的姓名和电子邮件。脚本会隐藏电子邮件地址；请勿将其他个人详细信息复制到报告中。
Claude 在此无法做的事情
除非被告知，否则你不能观察真实用户搜索、为他们计时或了解组织的策略。永远不要编造使用量、搜索量、成功率或引用；没有数据的衡量标准应显示为“尚未收集”。提出包含权衡的替代方案，推荐一个并说明原因；决策权归于人类。搜索产品的能力（同义词、置顶结果、查询日志记录）各不相同，因此说明你的预期并请用户确认。
本技能的交接点
| 下一个需求 | 关联技能 |
|---|---|
| 查明存在什么内容 | content-inventory |
| 名称错误 | labeling |
| 术语和筛选器需要优化 | taxonomies |
| 分组与用户的思维方式不符 | card-sort |
| 缺少到达路径 | navigation, sitemaps |
| 测试更改后的层级结构 | tree-tests |
| 分面或预览所需的字段 | content-models |
| 页面移动 | url-structure, redirect-maps |
| 整个网站的重构，或不确定从何开始 | information-architecture |