信息架构 是做什么的？
信息架构是指系统内容和功能的分组、标记和连接方式，以便人们找到所需内容并理解自己能做什么。每一个决策都服务于一个测试：这种结构是否能帮助面前的人快速做出正确的选择，而无需被明确告知？
它位于所有其他工作的上游。错误的结构会给内容带来负担（内容无处安放）、设计带来麻烦（需要发明额外的导航）、搜索带来混乱（URL不断变化），以及CMS系统（充满各种变通方案）。
本技能界定工作范围并设定贯穿整个工作的规则。具体工作内容见下文所列的技能。
1. 选择工作
大多数请求只需要部分工具，而非全部。明确你将交付什么，以便相关人员知道他们能得到什么。
| 任务 | 按顺序执行以下步骤 |
|---|---|
| 重新组织现有内容 | 内容清单、卡片分类或分类法、站点地图、URL结构（如果地址发生变化）、树形测试、重定向映射 |
| 新建站点、应用区域或章节 | 站点地图、导航、URL结构、内容模型 |
| 重新思考菜单、导航或应用切换器 | 导航、标签、树形测试 |
| 标签和分类 | 分类法 |
| 失效的名称 | 标签 |
| “人们找不到X” | 可发现性，然后根据诊断指向的具体技能 |
| 移动或重建站点 | 站点地图、导航、URL结构、内容模型、重定向映射 |
| 在构建前检查结构 | 树形测试 |
| AI功能或产品 | 此处的第5节，然后是可发现性 |
单独的站点地图只是装饰。对于站点构建，完整集合包括站点地图、URL规则、导航规范、内容模型，以及对于任何重建项目，还包括重定向映射。缺少其他四个，任何人都无法据此进行构建。
如果某个相关技能不可用，则在此处使用以下规则完成该部分工作，并加以说明。
2. 框架化，然后映射现状
在任何路径选择之前，确定谁在使用此系统以及他们试图做什么，当前以及两年内有多少内容，业务从中期望什么，以及如何衡量成功。在做出任何改变之前记录这些指标的当前数值，否则事后就没有可比较的对象。
然后构建当前画面。切勿仅从首页开始重新设计。
- 在代码库中： 读取路由、导航组件、
sitemap.xml、CMS架构以及任何类别或标签表。统计每个部分的项目数量。空部分和超负荷部分本身就是发现的问题。 - 在内容文件夹中： 调查整个语料库，而非逐个查看内容。说明内容是什么以及它似乎服务于谁，并在对方纠正之前不要基于错误的理解进行构建。
- 在数据库或CMS中的内容： 首先导出标题、类型、标签和日期。
- 非常大的数据集： 按类型调查，并在每种类型中抽样，同时说明抽样情况，以免有人将抽样误认为是全面普查。
还要询问只有人们才知道的信息：受众及其首要任务、组织的发展方向、分析数据、站点搜索日志，以及支持团队反复回答的问题。
3. 贯穿工作的规则
- 根据用户试图完成的目标来构建结构，切勿根据组织架构图。 “面向开发者的API”优于“关于我们、工程部、API”。
- 为每个项目分配一个规范主页。 它可以从其他地方链接，但只存在于一个位置。
- 保持线索而非点击数。 当每一步都明确指向用户目标时，人们会继续点击。“三点击规则”是误区。死胡同和模糊的标签才是真正的成本。
- 设计支持十倍的内容。 如果某个类别会增长，现在就要为这种增长设计。
- 提供多种入口。 浏览、搜索、过滤、相关链接、面包屑导航。
- 在决策点提供线索。 一个好线索能回答用户已有的问题，在他们做出选择的时刻、正在查看的位置，安静且低成本地提供。
- 为更大的上下文设计。 一个页面属于一个部分，一个部分属于一个站点，一个站点属于一个业务。
4. 作为AI从事信息架构工作
你的优势： 在几分钟内阅读整个语料库、提出替代方案、一致地将分类法应用于数千个项目、发现近似重复的术语，以及识别无处安放的项目。
你无法做到的事情： 与真实用户进行卡片分类或树形测试，或了解组织的战略和政治（除非被告知）。因此：
- 提议，而不是决定。 提供两到三种方案及其权衡，推荐一种并说明原因。单一的答案掩盖了决策过程。
- 首先获取受众和方向。 如果尚未告知产品或受众方向，请询问，或在文档顶部说明你的假设。
- 放置所有要求你放置的项目。 对于不合适的项目，给予其最不糟糕的家并标记，然后将移动、合并或废弃的论证作为单独的建议提出。
- 交付所有要求的工件。 即使你认为某个工件不应该存在，也要交付它，并单独进行论证。
- 切勿编造研究数据。 没有编造的参与者数量、成功率、工单量、引述或频率。像“每小时使用一次”这样作为事实陈述的说法也算。应该说“大概如此”，并将其列为假设。
- 不要猜测平台行为。 主机或CMS的能力因平台而异。说明你的预期，并要求对方进行确认。
- 保护内容。 在编辑内容、元数据、路由或重定向之前，确保工作已置于版本控制中或已备份。
5. AI产品的信息架构，以及智能体的上下文
在为产品添加AI之前，先观察实际阻碍用户的是什么。如果人们无法判断系统如何工作、无法区分其分类、或不断重复提问，那么更清晰的结构、更好的标签或放置得当的线索通常比聊天框更经济有效。按钮和菜单承担两个职责：让用户行动，并展示系统能做什么。开放式聊天在第一个职责上缓慢，在第二个职责上则完全无法胜任。在任务确实开放的情况下使用聊天，在其他情况下，将AI置于结构化界面之后。
智能体的上下文本身也是一个信息架构问题。在正确的时间给模型正确的信息：一个指向深层文件的简短入口文件、每个事实的一个规范主页、一致的名称，以及不加载任务不需要的任何内容。
6. 当任务涉及多个技能时
除非另有要求，否则返回一份包含以下内容的文档：
- 摘要： 两到三句话的推荐建议及主要原因。
- 现状： 当前的树形结构及其存在的问题，附有数量统计。
- 备选方案： 两到三种方案，每种方案说明其服务对象、成本和潜在压力点。
- 提案： 推荐的树形结构，每个节点的模板类型，然后是标签和导航规范，以及相关的URL规则和内容模型。
- 迁移： 新旧映射和重新标记说明（如果有任何内容移动）。
- 假设和未解决问题： 所有你猜测的内容。
- 验证方法： 树形测试任务及其正确答案和目标，或需要首先运行的卡片分类。
根据任务规模调整。 以推荐建议开头，每个部分在保持可用性的前提下尽量简短，将长表格放在文档末尾。较长的文档不一定更详细。
在交付前确保文档内容一致。 对照放置表重新计算总数，对照你编写的表格检查你陈述的每条规则，通过树形结构追溯任何关于路径长度的声明，并确保任何可交付的文件实现了其源自计划中的每一行。
要审查信息架构（无论是你自己的还是他人的），请使用 references/rubric.md 进行评分。
7. 需要识别的模式
- 组织架构图导航： 以部门命名的部分。
- 两个竞争的分类法： 侧边栏、面包屑导航和URL各自表述不同。
- 一切归于一统：
/services/<thing>用于每个部分，一个带有URL的杂物抽屉。 - 占位符部分： “即将推出”页面却已发布。要么构建它，要么删掉它。
- 用聊天框替代结构： 一个开放式的AI界面，而清晰的选项本可以更快地回答问题并教会用户如何使用系统。