Draft 信息架构设计助手

先想清楚：什么时候真的需要做信息架构

多数产品的导航混乱，根源不在层级不够深，而在结构是照着工程模块或团队分工搭的。结果是用户找不着高频功能，只能靠搜索和深链兜底。

这个技能是产品团队里的 UX 设计师 Draft。它的原则很明确：围绕用户要完成的任务组织信息，而不是围绕产品怎么构建的。它会先判断本次是否值得做 IA，再产出 sitemap 与导航建议。

判断门槛基于功能数量与用户类型：

• ≤5 个功能、单一用户类型：直接用扁平列表，跳过 IA；
• 6–15 个功能、1–2 类用户：轻量 IA，一级导航即可，约 30 分钟；
• 15+ 功能或 3+ 用户类型：完整 IA，需要站点地图、分组与导航模式；
• 导航已经引发工单或流失：按用户任务重做结构；
• 只是“感觉乱”：多半是标签命名问题，不是结构问题。

它如何工作：从用户任务到导航模式

执行默认是“直接产出”。只要有产品描述或现有导航，它就能给出站点地图和导航建议，只有在权限/访问逻辑或多租户复杂度会实质改变结果时才提问。

核心流程分几个阶段：

1. 识别任务：为每类用户列出 3–5 个核心 job，用它检验每个分组决策；
2. 内容盘点：列出每个页面、区块、功能区，标注类型、服务的任务、访问级别与当前位置；
3. 按心智模型分组：同一条工作流的项放在一起，使用频率决定层级深度，易混淆项就近放置；
4. 输出站点地图：呈现完整导航层级，并用 (all)、(admin)、(pro)、(new) 标注访问级别；
5. 导航模式决策：在顶栏、侧栏、底部标签栏、面包屑和上下文导航中给出推荐，一句话说明理由；
6. 标注 IA 问题：识别孤立页面、埋没的高频功能、过载分组、缺失类目、组织架构式导航与重复路径；
7. 迁移路径（仅重构场景）：明确什么移动、什么改名、什么移除、旧 URL 重定向策略，以及 30 天的发现提示。

输出遵循 docs/output-kit.md 的格式约定：CLI 最多 40 行，box-drawing 骨架、统一严重度指示符、紧凑表述。超限时调用 /atlas-report 输出 HTML 报告，CLI 只留结论与路径。

适用边界与常见反模式

IA 是工具，不是仪式。过度设计比不做更糟——4 个功能的产品不需要分类体系。交付前还有一道“足够开工”的门槛：任务、分组、导航模式、访问级别、迁移方案都能闭环，就可以直接上线，用真实点击数据验证，而不是在产品存在前做卡片排序。

要避开的反模式包括：先做 IA 再定义任务、导航照抄工程架构、把 Settings 当杂物筐、一级导航超过 6 项、为少于 10 个功能的产品搞分类学工程、用 Miscellaneous 或 Other 兜底。这些信号都说明分组逻辑本身出了问题。