vertical-site-conventions

垂直领域网站规范

按照所属垂直领域的布局、信息密度和商品展示规范来构建页面和整个网站，让成品看起来像是该领域中可信的一员。与技术栈无关。适用于任何能够实现服务端渲染页面和组件组合的框架。

此技能负责垂直领域层面的页面组合：各模块的布局、页面的信息密度、展示多少商品目录或服务内容，以及导航支持哪些访问路径。日常视觉决策交由 design-standards 处理，美学风格交由 creative-direction 处理，网站结构建模交由 information-architecture 处理，组件实现交由 frontend-component-build 处理。此技能不会重复这些工作，而是将它们的产出组合成符合垂直领域规范的网站。

这是 competitor-experience-audit 在构建侧的对应技能。审计从七个维度衡量行业现状；此技能则逐个维度按相同的七项标准进行构建。两者有意设计为同一标准的两个侧面，因此审计得出的体验标准可以一一对应到此技能构建的内容。

---

适用场景

• 在此前未构建过的网站垂直领域中创建新网站
• 修复看起来过于通用或不符合所属领域的网站，尽管其技术实现干净规范（SEO、无障碍和组件实现都没有问题，但页面看起来不像该类别的网站）
• 按照 competitor-experience-audit 得出的体验标准构建（预期用途是基于审计结果开展工作）
• 为网站补充该类别预期具备的商品展示、信息密度和导航规范
• 构建展示站或演示站，要求成品呈现所属垂直领域的特征，而不是通用的 SaaS 落地页

不适用场景

• 已知项目的日常视觉决策（使用 design-standards）
• 从头定义品牌风格或美学方向（使用 creative-direction、brand-archetype-system、brand-discovery）
• 优化单个组件（使用 frontend-component-build）
• 从头建模网站结构和导航层级（使用 information-architecture）
• 构建正式的设计系统或令牌系统（使用 design-system）
• 审计竞争环境中现有的规范（使用 competitor-experience-audit；此技能使用该审计的产出，而不是生成审计结果）

---

必需输入

• 项目所属的网站形态，须从以下受控列表中选择：ecommerce-catalog、inventory-listing、directory-marketplace、local-service-booking、subscription-app、hospitality-food、institution-mission、b2b-manufacturer、ecommerce-standout、hospitality-experience。
• 来自 competitor-experience-audit 的体验标准（该垂直领域跨网站的模式和差距）。如果没有，则技能会采用参考资料中针对各网站形态的默认规范；基于审计结果开展工作的效果更好，也是预期用途。
• 品牌风格和美学决策（来自 creative-direction 或已确定的方案）。此技能不会重新定义这些内容。
• 项目所用的框架或技术背景（此技能与技术栈无关，但使用者需要了解这些信息）。

如果网站形态不明确，请先询问。按错误形态的规范构建会导致成品不符合所属领域的特征，而这正是此技能要避免的问题。

---

框架：按照七个维度构建

此框架与 competitor-experience-audit 衡量的七个维度相对应。每个维度在此都以构建指南的形式呈现（该怎么做），而不是审计问题（观察什么）。请按顺序执行；第 7 个维度中的综合检查清单用于发现前六个维度遗漏的问题。

1. 将主要任务作为最突出、最先呈现的元素

访客到来时通常有一项主要任务。该垂直领域的优秀实践会首先呈现这项任务；偏离垂直领域惯例的构建则会用营销文案或互相竞争的 CTA 将其埋没。

• 从体验栏或各形状参考中确定该垂直领域的主要任务。（电商目录：适配、搜索或类别入口交互。酒店餐饮：菜单或预订入口。库存列表：搜索和筛选。本地服务预订：“立即预订”或服务选择器。）
• 在首屏主视觉区域中，以最大、最醒目的交互方式呈现该任务。
• 降低其他 CTA 的优先级。主视觉区域只保留一个主要操作；次要操作放在首屏以下或界面框架中。
• 确保访客使用该垂直领域常用的设备类型时，无需滚动即可访问核心任务。
• 对于商业页面，将主要任务的精简版本固定在界面框架中，确保访客滚动时仍可访问。

如果主要任务因利益相关方要求或受监管垂直领域的限制而无法放在主视觉区域，请呈现最接近的替代方案，并记录这一取舍。不要悄无声息地将主要任务推到首屏以下。

2. 按照该垂直领域的布局风格和信息密度进行构建

大多数偏离垂直领域惯例的构建，默认采用通用、疏朗的 SaaS 落地页风格。零售和目录类垂直领域的信息密度更高；编辑类垂直领域更为沉静；酒店餐饮则以图片为主导。应按照所在领域的信息密度进行构建，而非采用默认风格。

• 从体验栏或各形状参考中确定布局风格（店面密集、编辑沉静、营销疏朗、图片主导）。
• 匹配该领域每个视口中的内容量：目录类垂直领域在首屏呈现的模块应多于 SaaS 落地页。
• 有意识地确定首屏上方的模块数量，并在构建说明中注明数量。
• 将实际的色彩、字体和美学选择交由 creative-direction 和 design-standards 处理。此技能负责信息密度和模块数量决策，而非视觉风格本身。

构图决策由此处负责，视觉风格由彼处负责。不要重新定义其中任何一项；应交由合适的技能处理。

3. 构建该垂直领域使用的商品陈列和类别展示界面

一次呈现多少目录或商品，以及以何种形式呈现，是构建时必须根据具体垂直领域决定的事项。

• 按照该垂直领域的方式呈现目录：确定滚动前出现多少类别、系列或入口模块。
• 按照该垂直领域的方式展现层级：使用悬停式大型菜单、类别卡片网格、分面搜索侧栏或面包屑导航层级。选择一种并贯彻到底；不要将三种方式叠加。
• 根据该垂直领域的惯例，选择扁平结构（显示一层）或分层结构（同时显示父类别和子类别）。
• 根据该垂直领域，选择图标、图片、文字或混合式类别展示方式。

请参阅 information-architecture，了解导航树的结构建模。此技能负责组合式界面；彼技能负责结构模型。

4. 构建该垂直领域所需的「明确知道需求」和「浏览探索」路径

不同垂直领域的主要路径各不相同。目录类垂直领域需要同时支持搜索和按类别浏览，且搜索通常是主要路径。餐饮接待类网站很少需要搜索，但总是需要菜单和预订入口。应根据实际体验所提供的路径，以及这些路径在体验中的突出程度来构建。

• 列出体验规范中提到的路径（按类别、品牌、属性、车型、位置、场合、受众）。
• 针对每个垂直领域，将每条路径评为主要、次要或不存在。
• 将主要路径放入主视觉区域或主导航中。将次要路径放入界面框架或首屏以下区域。移除该领域不使用的路径。
• 搜索输入框的突出程度应按垂直领域决定：置于页眉主位、在侧边栏中作为次要元素，或完全不显示。与实际体验保持一致。

将结构化导航建模交由 information-architecture；将搜索 UX 模式交由该技能或项目现有的搜索组件。本技能负责确定有哪些路径，以及它们的突出程度。

5. 在整个页面中保持品牌姿态一致

品牌基调由 creative-direction 和 brand-archetype-system 确定。本技能不会重新定义品牌基调。但页面构图决定了这种姿态是贯穿整个页面，还是只体现在主视觉区域中。

• 将品牌基调从主视觉区域延续到导航、卡片、空状态、信任信号和页脚。如果实用高端的基调在主视觉区域以下消失，这是构图上的失败，而不是品牌上的失败。
• 在标题、微文案、CTA 和空状态中始终保持一致的品牌语调。不要让空状态默认使用泛泛的文案。
• 在整个页面中保持一致的图像风格：如果某个垂直领域在主视觉区域使用影棚产品摄影，就不要在信任信息区改用抽象插画。

将品牌基调的具体选择和语调特征交由 creative-direction 和 brand-voice。本节负责确保一致性。

6. 构建该垂直领域所需的信任与转化信号

不同垂直领域需要呈现的信任信号各不相同。缺少这些信号的构建版本会显得不够可信。应将它们纳入构建。

• 根据体验规范或各类页面形态的参考资料，确定所需信号。（电商目录：评价、保证、价格透明度、库存信息、适配性确认、配送承诺。餐饮接待：营业时间、地点、预订情况、菜单价格范围。B2b-manufacturer：认证、客户标识、规格表。Local-service-booking：执照、保险、服务区域、响应时间。）
• 在实际体验呈现这些信息的位置展示它们。评价应靠近购买操作；服务区域应置于主视觉区域；认证应放在界面框架中。
• 对于展示型构建，应遵守真实功能与演示内容之间的界限：可交互处应使用真实内容（如果有真实评价，就使用真实评价；购物车状态也应真实），需要后端支持的部分则应如实演示（明确标注为演示版的结账弹窗，不使用虚假的付款流程）。

7. 将综合检查作为构成清单来执行

第七个维度是综合检查：明确列出这个领域中值得信赖的构建必须遵循的具体惯例。在宣布构成完成之前，将此清单作为发布前检查。

• 从体验标准的维度 7，或各形态参考中的「反复出现的惯例」部分提取这些惯例。
• 对每项惯例，确认构建是否遵循。标记为已具备、缺失，或已转交其他技能处理（附上转交决策的链接）。
• 如果缺失的惯例达到三项或更多，则构建偏离了该领域。返回检查前面的维度；这不是通过润色就能解决的问题。
• 如果缺失一到两项，请说明原因：有意的定位（构建利用了审计「差距」部分中的切入点）、约束（利益相关方或技术限制），或疏漏（发布前修复）。

综合检查能发现这样的构建：它们单独通过了维度 1 到 6，但组合起来仍然偏离该领域。请执行综合检查。

---

此技能如何使用体验标准

当 competitor-experience-audit 已针对该领域运行后，其输出便是此技能的输入。审计的七个维度会按顺序直接映射到此技能的七个维度。具体来说：

• 审计中的 Primary-task prominence 模式指出此技能维度 1 应构建什么。
• 审计中的 Layout register and density 模式指出维度 2 的密度目标。
• 审计中的 Merchandising and category surface 模式指出维度 3 的展示面形态。
• 审计中的 Primary navigation and search paths 模式指出维度 4 的路径清单。
• 审计中的 Brand register and conviction 模式指出 creative-direction 应采用的风格基调；此技能会在维度 5 中将其贯穿整个页面。
• 审计中的 Trust and conversion signals 模式指出维度 6 所需的信号。
• 审计中的 Recurring vertical conventions 是维度 7 的清单。
• 审计中的 Gaps 部分指出构建可以利用的定位机会，即切入点。

如果尚未运行审计，请改用 references/ 中各形态对应的参考文件。那里的默认惯例源自可观察到的跨站点模式，具有可信度；不过，针对具体领域进行审计的效果更好，也是预期采用的路径。

---

各司其职（关键原则）

此技能只负责一件事：领域层面的页面和站点构成。其他所有事项都会转交处理；正是这种转交规范让此技能保持实用，也让目录保持整洁。

• 视觉令牌、颜色、字体、对比度、间距比例：转交给 design-standards。
• 美学基调、原型、声音属性：转交给 creative-direction 和 brand-archetype-system。
• 站点结构、导航层级、URL 设计：转交给 information-architecture。
• 组件 API、状态、无障碍实现：转交给 frontend-component-build。
• 正式设计系统、令牌库、组件文档：转交给 design-system。
• 生成体验标准的审计：转交给 competitor-experience-audit。
• 页面 SEO 和无障碍审计：转交给 seo-onpage 和 accessibility-audit。

如果某项构建决策属于上述某个技能的职责范围，请勿在此重复其标准。链接到对应技能，并由该技能负责其领域。

工作流

1. 确认网站形态和体验基准。 网站形态从受控列表中选择。如果运行了 competitor-experience-audit，则以其结果作为体验基准；否则使用对应形态的参考。
2. 按顺序执行维度 1 到 6。 对每个维度，说明构建决策，以及该维度会转交给哪些其他技能处理（适用于需要转交的部分）。
3. 将维度 7 作为检查清单执行。 确认该垂直领域的每项惯例均已体现、因明确理由而未体现，或已转交处理。
4. 撰写构成说明。 使用 references/shape-conventions-checklist.md 中的模板。这些说明是 frontend-component-build 和 design-standards 用来实现的规范。
5. 交接给实现技能。 此技能的输出是构成决策，而非完成的组件。当这些决策已通过 frontend-component-build、design-standards 和项目的组件库实现后，构建才算完成。

---

失败模式

发现以下任一情况时，请在交付前提出异议。

• “让它看起来现代。” 这太含糊了。请询问具体属于哪个垂直领域、采用什么体验基准、遵循哪些惯例。没有垂直领域的“现代”会导致通用、疏朗的 SaaS 式构建，而本技能正是为了避免这种情况。
• 垂直领域需要更高密度的店铺页面，却按通用、疏朗的默认方式构建。 零售和目录类垂直领域每个视口展示的内容比营销页面更多。如果构建结果显得平静宽敞，请对照业内情况检查内容密度。
• 把主要任务埋没了。 塞满营销文案、包含 3 个相互竞争的 CTA 的主视觉区，是最常见的偏离垂直领域惯例的失败。维度 1 不可跳过。
• 重新定义美学词汇，而不是转交给 creative-direction。 本技能不会创造新的风格名称，也不会虚构新的品牌语气属性。品牌要采取何种姿态，应由 creative-direction 决定。
• 体验基准可用时却将其视为可选项。 如果已对该垂直领域运行 competitor-experience-audit，那么体验基准就是规范。忽略审计基准、只按各形态默认值构建，等于只完成了一半。
• 产出模板，而不是依照该领域的实际惯例构建。 各形态参考只是起点，不是完整模板。它们指出该领域共有的模式；构建时仍须将这些模式落实到当前品牌和需求中。
• 跳过维度 7。 即使构建在维度 1 到 6 上分别都达标，整体组合仍可能偏离垂直领域惯例。综合检查正是用于发现这一问题。
• 把实现细节称为“构成”。 按钮圆角、字号和颜色对比度属于 design-standards 的决策。模块数量、主要任务的突出程度、类别界面的深度属于本技能的决策。不要越界。

---

输出格式

默认输出为一份 Markdown 构成说明，保存于项目根目录，文件名为 composition-[site-shape]-[brand-slug].md。结构如下：

1. 网站形态和参考的体验基准（或写明“没有可用的审计；使用了对应形态的参考”）
2. 按维度说明构建决策（1 到 6）
3. 综合检查清单（维度 7），将每项惯例标记为已体现／未体现／已转交
4. 差异切入点（本次构建利用了审计“差距”部分中的哪项差距，如有）
5. 交接清单：frontend-component-build、design-standards 和 creative-direction 实施时需要从这些说明中获取哪些信息

说明控制在 1500 词以内。这些说明是供实现技能使用的规范；如果它们还需要更多细节，说明更深入的规范应由其中某项技能负责。

参考文件

• references/shape-conventions-checklist.md - 发布前审核时应用的各维度构建检查清单，是审计中各维度检查清单在构建侧的镜像。
• references/shape-ecommerce-catalog.md - ecommerce-catalog shape 的默认约定（首个测试案例；适用于汽车零部件及类似的商品繁多的网店）。
• references/shape-inventory-listing.md - 占位文件；构建首个 inventory-listing 演示时填写。
• references/shape-directory-marketplace.md - 占位文件。
• references/shape-local-service-booking.md - 占位文件。
• references/shape-subscription-app.md - 占位文件。
• references/shape-hospitality-food.md - 占位文件。
• references/shape-institution-mission.md - 占位文件。
• references/shape-b2b-manufacturer.md - 占位文件。
• references/shape-ecommerce-standout.md - 占位文件。
• references/shape-hospitality-experience.md - 占位文件。