规模增长会改变问题本身
小型文档集几乎可以容忍任何导航方式。只有二十页时，读者能快速扫完菜单，作者也记得内容放在哪里，重复内容仍然容易发现。到了五百页，这些优势就消失了，结构本身会成为产品能力。
第一条原则：不要把仓库目录树等同于信息架构。目录树服务于维护者，导航服务于读者，两者解决的是不同问题。
从用户意图和内容类型开始
列出用户打开文档的主要原因：理解概念、完成任务、查询字段、排查故障、了解版本变化。然后定义少量能够服务这些意图的内容类型，例如教程、操作指南、参考资料和概念说明。
内容模型为每种类型提供稳定的元数据和结构。随着内容增长，这种一致性可以支持筛选、搜索、自动检查和可复用布局。
顶层导航要保持稳定
不要因为出现了新技术、新团队或新趋势，就增加一个顶层栏目。变化快的内容应该放在更低层级，并通过标签、专题和搜索暴露。
一个简单判断：如果某个分类很可能在下一次组织调整中消失，它通常就不应该成为永久导航。
设计关联，而不仅是树
读者会从搜索、issue、代码、支持答案和旧书签进入任意页面。因此页面必须能够独立提供足够上下文，并链接到下一步最可能需要的内容。
把概念链接到任务，把任务链接到参考，把错误链接到恢复步骤。不要用巨大的“另请参阅”列表代替真正的编辑判断。
在问题变严重之前审计
持续检查孤立页面、重复标题、失效链接、过大的栏目和含义重复的标签。关注搜索中无法得到好结果的查询。
信息架构不是一次性的图。它是一项持续维护工作，目标是让新增的五百页不会让原有五百页更难找到。
实践示例
要把《面向持续增长文档的信息架构》中的方法变成真实工作，先挑选一个本周确实会发生变化的文档单元，例如操作步骤、发布说明、入门页面或故障排查文章。编辑前先写清四件事：谁使用它、什么事件触发更新、谁能验证事实，以及读者读完后应该能够完成什么。
让一次真实改动完整走过流程，不要一开始就重构全部体系。只修改一个事实、一个步骤或一项责任，然后观察信息在哪里丢失。检查：
- 读者能否在不询问作者的情况下理解预期结果；
- 下一次更新是否有明确负责人；
- 审阅者能否验证被修改的事实；
- 删除过时截图或临时方案后页面是否仍然成立。
文档实践真正可靠的标志，是它能经受真实变化，而不是只在静态示例中显得整齐。
快速编辑检查
- 规模增长会改变问题本身. 小型文档集几乎可以容忍任何导航方式。只有二十页时，读者能快速扫完菜单，作者也记得内容放在哪里，重复内容仍然容易发现。
- 从用户意图和内容类型开始. 列出用户打开文档的主要原因：理解概念、完成任务、查询字段、排查故障、了解版本变化。
- 顶层导航要保持稳定. 不要因为出现了新技术、新团队或新趋势，就增加一个顶层栏目。
- 设计关联，而不仅是树. 读者会从搜索、issue、代码、支持答案和旧书签进入任意页面。
