site-architecture

site-architecture 技能概览

site-architecture 技能能做什么

site-architecture 技能用于规划或重组网站的页面层级、导航、URL 结构和内部链接。它面向的是信息架构（IA）工作，而不是技术层面的 XML sitemap 生成。如果你真正想解决的问题是“这个网站应该有哪些页面、它们该如何关联、用户应该怎样在其中移动”，那这个技能就是对口的。

谁适合使用 site-architecture

site-architecture 技能尤其适合：

• 正在规划新站或大规模改版的营销团队
• 需要定义 SaaS 营销站结构的创始人
• 负责导航与信息架构的 UI/UX 团队
• 需要决定内容枢纽、栏目划分和页面关系的 SEO 导向内容团队
• 需要快速产出第一版 sitemap、URL map 和导航规范的代理商

当一个网站是“自然生长”起来的，后来变得难逛、结构不一致、层级过深时，这个技能尤其有价值。

最适合用 site-architecture 解决的任务

当你需要做这些事时，就该用 site-architecture：

• 把一份粗略的页面清单整理成逻辑清晰的网站地图
• 决定采用扁平结构还是更深的层级结构
• 定义 header、footer 和各分区导航
• 为 /features、/compare、/integrations 这类栏目制定 URL 规则
• 优化 hub 页面与详情页之间的内部链接
• 输出可供评审的 ASCII 或 Mermaid 可视化 sitemap

site-architecture 与普通提示词的区别

普通提示词也许只能列出一些页面。site-architecture 更强的地方在于，它会把结果推向一套更完整、可落地的交付物：

• 先明确业务和受众背景
• 明确设计页面层级
• 给出导航建议
• 规划 URL 结构模式
• 提供内部链接建议
• 输出可视化 sitemap
• 提供适用于常见站点类型的复用模板

仓库里还包含 Mermaid 图表、导航模式和站点类型模板等实用参考，所以相比从零开始，输出会更稳定，也更一致。

site-architecture 的重要边界

这个技能并不主要覆盖：

• XML sitemap 文件
• 完整的 SEO 审计
• schema markup
• 最终 wireframe 或精修 UI mockup

如果你是在做 site-architecture for UI/UX Design，它最有用的阶段是“结构层”：页面分组、路径引导、导航区划和内容可发现性，而不是详细界面设计。

如何使用 site-architecture 技能

安装方式与调用模式

使用下面的命令从仓库安装该技能：

npx skills add https://github.com/coreyhaines31/marketingskills --skill site-architecture

在实际使用中，用户通常会通过提出 sitemap、导航、页面层级或 URL 规划相关问题来触发 site-architecture。它最适合运行在支持 Skills 的 agent 环境中，这样模型可以读取技能文件并按既定工作流执行。

使用 site-architecture 前，优先看这些文件

如果你想快速判断这个技能值不值得用，建议先看：

1. skills/site-architecture/SKILL.md
2. skills/site-architecture/references/site-type-templates.md
3. skills/site-architecture/references/navigation-patterns.md
4. skills/site-architecture/references/mermaid-templates.md
5. skills/site-architecture/evals/evals.json

这个阅读顺序能帮助你快速理解它的工作流、常见输出、具体导航选项、图表格式，以及评测里“好结果”长什么样。

site-architecture 最需要哪些输入信息

当你提供以下信息时，site-architecture 的输出质量会明显提升：

• 公司是做什么的
• 主要受众是谁
• 网站最重要的目标是什么，通常控制在 2–3 个
• 这是新站建设还是改版重构
• 是否有现有页面清单
• 当前痛点，例如内容重复、层级过深、难以找到信息
• 网站类型，例如 SaaS、电商、服务型、平台型或内容型网站

如果这些信息缺失，模型仍然可以先起草一个结构，但结果通常会更泛，也更容易选错导航模式。

先检查 product-marketing 上下文

这个仓库里有一个很实用的行为设计：技能会明确要求 agent 先检查 .agents/product-marketing-context.md，或者旧版路径 .claude/product-marketing-context.md，然后再决定要问什么问题。这个细节很关键，因为很多架构决策都依赖定位、受众和产品/服务结构。

如果你已经把 product marketing context 写好了，直接把文件指给模型看。这样能减少来回补充背景信息的成本，也能让页面分组更准确。

把模糊目标改写成高质量的 site-architecture 提示词

弱提示词：

Help me make a sitemap.

更强的提示词：

Use the site-architecture skill to plan a SaaS marketing site for an analytics product aimed at ecommerce teams. Our goals are demo requests, SEO traffic, and partner integrations. We need a homepage, pricing, feature pages, docs, blog, integrations, and competitor comparison pages. Keep top nav to 5-6 primary items. Propose page hierarchy, URL structure, header/footer nav, and internal linking model.

为什么这个写法更有效：

• 明确了受众和业务类型
• 指出了转化目标与内容目标
• 列出了必须包含的内容类型
• 加入了导航层面的约束
• 直接要求产出这个技能最擅长的具体交付物

什么样的 site-architecture 用法算是高质量

建议你按这个顺序要求输出：

1. 假设条件与缺失输入
2. 建议的页面层级
3. URL map
4. navigation spec
5. 内部链接建议
6. ASCII 树或 Mermaid 图
7. 取舍点或待确认问题

这正好对应了这个技能最实用的强项，也能让你先评审结构，再去争论命名或设计细节。

不要从空白开始，优先用参考模板

这个技能最容易上手的捷径，就是它自带的参考集：

• site-type-templates.md 提供现成的层级模式
• navigation-patterns.md 帮你判断该用简单 header、mega menu，还是其他导航模型
• mermaid-templates.md 可以加速生成可视化 sitemap

对很多团队来说，最优工作流通常是：先选最接近的站点模板，再调整栏目，最后细化导航与 URL。这个流程通常比完全自由发挥更快，也更稳。

新站项目中推荐的 site-architecture 工作流

如果是从零搭建新站，推荐这样做：

1. 明确业务目标和受众
2. 选择最接近的站点类型模板
3. 调整一级栏目
4. 设定 URL 约定
5. 把 header 导航限制在高优先级项目内
6. 将辅助页面分配到 footer 或分区导航
7. 在合适的地方加入 hub-and-spoke 内部链接结构
8. 导出 ASCII 树或 Mermaid 图供利益相关方评审

这套流程对 SaaS 尤其有效，因为像 /features、/customers、/resources、/integrations、/compare 这类栏目通常需要清晰分开。

站点重构时推荐的 site-architecture 工作流

如果你面对的是一个混乱的现有网站，建议给模型这些输入：

• 当前导航结构
• 页面数量或页面清单
• 重复的栏目
• 流量差或归属不清的页面
• 用户抱怨，例如“文档找不到”或“下拉菜单太多”

然后要求它：

• 合并重复栏目
• 删除重复入口
• 压平不必要的层级深度
• 把主导航与 utility/footer 项分开
• 在可能的情况下保留高价值旧 URL

这正是 site-architecture 比普通 brainstorming 提示词更有用的地方：它会把问题定义为“重组网站”，而不只是“列几个页面”。

面向 UI/UX Design 团队的 site-architecture 用法

对于 UI/UX Design 团队，site-architecture 最适合放在 wireframe 之前使用，用来厘清这些问题：

• 哪些内容应该进入全局导航
• 哪些栏目需要 section landing page
• breadcrumb 应该如何映射页面层级
• 哪些页面应当直接可达，哪些适合间接进入
• 什么情况下才有必要上 mega menu

它不能替代 interaction design，但能在设计组件之前，为 UI/UX 团队提供一个更有依据的信息架构基线。

建议要求的实用输出格式

当你明确要求以下一种或多种格式时，这个技能的表现通常最好：

• 便于快速评审的 ASCII tree
• 便于文档沉淀的 Mermaid sitemap
• 带优先级的 URL map 表格
• header/footer navigation spec
• 按栏目划分的 internal linking model

这些格式都有仓库内容作为支撑，因此你的请求会更贴合该技能已经验证过的强项。

site-architecture 技能 FAQ

site-architecture 适合新手吗？

适合，前提是你已经知道网站目标和主要内容类型。相比从零发明 IA，这个技能能更快给你搭出结构。新手通常卡住，不是因为技能太高级，而是因为给的上下文太少。

什么时候该用 site-architecture，而不是普通提示词？

当你需要的是可执行、可评审的结果时，就该用 site-architecture：页面层级、导航规则、URL 规则和链接策略。普通提示词可以帮你发散页面想法，但如果你需要一个可审核的架构产物，这个技能更合适。

site-architecture 会生成 XML sitemap 吗？

不会。这个技能用于信息架构和导航规划，不适合拿来做 XML sitemap 生成或技术爬取诊断。

site-architecture 只适合新站吗？现有网站有用吗？

也很适合现有网站。尤其当网站页面过多、分组不一致、导航混乱时，它对重构非常有帮助。输入时请提供当前状态和实际痛点，而不只是理想中的未来状态。

它和人工做 IA 相比怎么样？

人工 IA 依然很有价值，但这个技能能明显加速第一版结构产出，并提供可复用模板。它最适合用来快速起草方案、暴露取舍点，以及生成供团队评审的结构材料。至于政治因素、归属关系、实施约束，仍然需要人来判断。

它适合用于 site-architecture for UI/UX Design 吗？

适合，前提是把它当作前置规划工具。它能帮助 UI/UX Design 团队在做详细布局之前，先定义页面关系、导航深度和路径引导逻辑。但它不太适合组件级设计决策。

什么情况下不该用 site-architecture？

如果你的真实需求是以下这些，就不该用它：

• 技术 SEO 审计
• schema 规划
• 内容写作
• 高保真页面 wireframe
• 明显超出营销网站模式的 app 信息架构

另外，如果你连基本业务背景都提供不了，它的效果也会比较弱。

如何改进 site-architecture 技能的使用效果

给出更明确的业务约束

想让 site-architecture 输出更好，最快的方法就是把约束说清楚：

• 主要转化动作是什么
• 核心受众分层有哪些
• header 导航最多几个项目
• 哪些栏目必须保留
• 哪些栏目不应进入主导航
• SEO landing page 是否是优先事项

如果没有这些约束，模型往往会把页面加得过多，却没有把导航优先级排清楚。

重构项目务必提供页面清单

对于现有网站，直接贴一份粗略的页面 inventory 或当前导航结构即可，哪怕很乱也没关系。这能帮助 site-architecture 识别可合并区域、重复结构和孤立栏目，否则这些问题很容易被漏掉。

不要只要一个答案，要让它给出取舍方案

一个很好用的改进方式是：

Give me a recommended architecture plus one simpler option and one SEO-expansion option.

这样能把真正的决策点暴露出来，比如：

• 简单导航 vs 可扩展导航
• 更少的一级栏目 vs 专门的 landing page hub
• 更扁平的层级 vs 更清晰的分类

这会让技能在利益相关方对齐时更有用。

用明确交付物强制输出更具体

如果第一版结果看起来太空泛，可以直接要求：

• 完整的 ASCII tree
• 精确的 URL patterns
• 带项目数量的 nav labels
• breadcrumbs 示例
• section-level internal links

具体格式越清晰，泛泛而谈的建议就越少，site-architecture 产出也越接近可实施状态。

首稿里最常见的失败模式

评审第一版时，重点留意这些问题：

• 一级导航项目过多
• 分类名称互相重叠
• 内容 hub 和转化页面混在一起，但没有清晰优先级
• 层级嵌套过深，却没有明显用户价值
• blog/resources/docs 分组方式不一致
• 增加了 SEO landing page，却没有配套的链接方案

当你的提示词过于宽泛或含糊时，这些都是 site-architecture 容易引入的典型 IA 问题。

提高内部链接建议的可执行性

不要接受“add internal links”这种过于宽泛的建议。应该要求模型明确说明：

• 哪些 hub 页面链接到哪些详情页
• 哪些详情页需要回链到 hub
• 哪些 cross-link 合理，例如 features 指向 integrations，或 comparisons 指向 pricing
• 哪些页面不应该做过重的交叉链接

这样 site-architecture 才会从概念层建议，变成真正可执行的方案。

用仓库参考文件收紧泛化草稿

如果输出看起来太泛，可以明确要求模型应用：

• references/navigation-patterns.md 来辅助导航决策
• references/site-type-templates.md 来补足栏目覆盖
• references/mermaid-templates.md 来生成更清晰的图表

这是在不改技能本身的前提下，提升 site-architecture 结果质量最简单的方法之一。

第一轮 site-architecture 之后务必迭代

比较推荐的第二轮提示词会像这样：

Revise this site architecture to reduce header nav to 5 items, move low-priority pages to footer, preserve our existing /blog structure, and create a clearer hub model for integrations and comparison pages.

这种有明确修改目标的二轮迭代，通常才是这个技能真正变得“可用于生产”的关键阶段。

用真实用户路径验证 site-architecture 结构

在正式采用结果之前，先验证这些关键路径是否顺畅：

• 首次访问者是否能顺利理解产品
• 比较型用户是否能快速到达决策页面
• 从文章进入的 SEO 用户是否能自然走向产品意图页面
• 现有客户是否能方便找到 docs 或 support
• 潜在合作伙伴是否能快速看到 integrations 细节

如果这些路径走起来仍然别扭，即使 sitemap 看起来很整齐，site-architecture 也还需要再迭代。

通过收窄受众范围来改进 site-architecture

受众定义太宽，最终往往会得到一套发灰、发散的架构。如果第一版输出看起来像是“谁都想服务”，就要拆开优先级：

• buyer vs user
• SMB vs enterprise
• prospect vs customer
• educational content vs conversion content

当受众优先级足够清晰时，site-architecture 的效果会明显提升，因为导航和页面分组都会更容易自圆其说。