站点地图（Sitemaps）
站点地图决定了哪些内容存在、每个内容位于何处，以及用户与内容之间有多少决策步骤。菜单、URL、模板和重定向都源于这一决策，因此错误的树结构会拖累所有下游环节。
首先需要什么
| 输入 | 来源 | 若缺失如何处理 |
|---|---|---|
| 当前结构 | 在代码库中，首先阅读路由、导航组件、sitemap.xml、CMS模式和分类表。永远不要仅从首页开始重新设计。 | 请求提供URL列表或导出。若无可读内容，将树标记为“空白草案”。 |
| 内容规模（当前及两年后） | 统计每个章节的项目数量。空的或超载的章节视为发现项。 | 请求提供粗略数字。若无法获取，则展示每种可能规模对应的形状。 |
| 受众与核心任务 | 用户、分析工具、搜索日志、支持团队频繁回答的问题 | 询问，或在其交付物顶部写明假设。 |
| 组织发展方向 | 用户 | 询问。模糊的简报会产生模糊的树结构。 |
若具有内容文件夹：先全面调查整个集合，再进行分组，然后反馈内容是什么、似乎为谁服务，以便用户纠正。若为数据库或动态CMS：先导出标题、类型、标签和日期。若为PDF等二进制文件：转换为文本并说明转换质量。若为非常大的集合：按类型调查，每种类型内抽样，并说明抽样内容。
若以上信息均无法获取，说明需要什么，并在references/tree-format.md中提供树格式，同时为该类站点建议节点类型。
方法
-
绘制现有结构。 当前树、每个章节的项目数及其问题：重叠、空章节、孤立项、按部门归档的内容。
-
评估规模。 使用两年后的总量，而非当前量。
项目数 结构 50以下 扁平，1至2级 50至500 2至3级 500至5000 3至4级，加上分面 5000以上 浏览、搜索和分面结合 -
根据内容选择形状，绝不要根据组织架构图。
内容 形状 代价 少数几个不同的产品/服务，约50页以下 中心辐射型： 几个宽而浅的章节，每个从首页点击一次即可到达。营销站点默认选择。 首页负责所有路由。增长空间小，后续需重新裁剪。 真正分类性的，如大型目录或按行业划分 深层层级 每级增加一次点击并降低一点线索。一个错误的早期猜测会让人迷失方向。 大多扁平，但有1-2个密集区域（如文档或资料库） 混合型： 上层为中心辐射型，这些章节内采用较窄的层级。大型站点的常见答案。 需要构建并解释两种导航模型。 用户可多角度切分的项，或即将超出单一列表的类别 分面型： 独立的维度组合为过滤器 每个项目需要干净的元数据，且有人维护。 -
起草两到三个备选方案，沿不同轴线切分（按任务、按受众、按内容类型），而非同一想法的三个版本。对每个方案说明为谁服务、代价是什么以及何处会吃力。推荐一个并说明理由。单一答案会掩盖决策过程。
-
给每个项目一个规范归宿。 它可以从别处链接，但只能位于一个地方，即人们预期的位置。两个归宿会分散搜索结果、链接和维护。
项目似乎属于两个位置 决策 少量真正跨切分的项 一个归宿，从其他位置交叉链接 许多项目属于多个位置 树切分错了轴。使用分面。 无法判断用户会去哪里找 选择最可能的归宿，并标记为待树测试 -
注释每个节点。 每个节点都有一个模板类型；没有模板的节点通常意味着想法未完成。标记新建、移动和废弃节点。对重复页面使用模式节点如
/guides/<slug>，并在有分面和项目的节点上放置facets:和items:。 -
施加压力测试。 内容增加十倍后，某个章节是否会变成无人能扫描的列表？现在立即设计子章节或分面。树是否服务于更大的上下文（产品或业务）？是否任何章节映射到部门而非任务？每层级超过9项或深度超过4层需要理由，而“三击规则如此说”不是理由，因为该规则是神话：只要每一步都清晰指向用户目标，用户会继续点击。当深度和广度存在争议，或审查他人树时，阅读
references/depth-and-shape.md。
交付物
编写sitemap-tree.txt，仅包含提议的树结构，因为检查脚本会读取它：
/ home
├── /guides section-hub items: 40
│ └── /guides/<slug> guide
├── /products listing items: 120 facets: use, price
│ └── /products/<slug> product
├── /pricing marketing (new)
└── /about marketing (moved from /company)
然后编写sitemap.md，按以下顺序：
- 推荐： 两到三句话及主要原因。
- 现有结构： 当前树及其问题，附带统计。
- 选项： 每个结构一行，列包括：组织依据、服务对象、代价、何时吃力。
- 提议树： 在代码块中提供
sitemap-tree.txt的精确文本。 - 放置： 项目、归宿、备注。仅在询问具体放置时提供。
- 假设与待定问题： 所有猜测的内容，尤其是受众和方向。
- 验证方法： 风险最高的放置项，交给树测试。
适度缩放。对于一个12页的网站，只需推荐、树和三行选项表。更长的文档并不代表更详尽。如果要求放置每个项目，则每个项目都要有归宿：为不合适的项提供最不坏的归宿，标记它，并单独论证应移动、合并或废弃。
检查
node "${CLAUDE_SKILL_DIR}/scripts/tree-check.mjs" sitemap-tree.txt
它将报告每个分支的深度和广度、出现两次的标签、没有模板的节点、Other或Misc节点以及每个章节的项目数。使用其结果，而非个人对树的判断。退出码1表示警告：修复每个警告，或在sitemap.md中写一行说明为何该例外成立。当树没有计数时，传入--items N。
然后手动：重新核对放置项与总数是否一致，追踪任何关于路径长度的声明在树中的实际路径，确认sitemap.md中的代码块与文件匹配。
Claude在此处不能做的事情
- 除非被告知，否则无法知道组织的战略或政治。树是一个供反馈的草案，决策权属于人类。
- 不能编造流量、使用量或研究。包括以事实陈述的频率词，如“每天使用”。应写上“可能”并列为假设。
- 不能对真实用户进行树测试或卡片分类。可以设计它们，并分析用户带回的结果。
- 不能承诺CMS能做到什么。只能说明预期功能，如嵌套路由或分面过滤，并请用户确认，因为平台支持情况各异。
交接点
仅站点地图本身只是装饰：没有URL规则、导航规范、内容模型以及重建时的重定向计划，任何人都无法据此进行构建。
information-architecture：当任务涉及多个此类功能时的总入口。content-inventory：当没人知道现有内容时。card-sort：当分组应来自用户时。taxonomies：当树需要设计分面或标签时。labeling：用于命名节点。navigation、url-structure和content-models：将节点转化为菜单、地址和模板。redirect-maps：当任何内容移动时。tree-tests：在构建前验证树。findability：构建后测量可发现性。design-os:create-sitemap：将确定的树编写为后续设计阶段读取的链接文件。