纯文字版教程展开阅读
第二阶段 商品与店铺结构
建立手动与自动集合，统一 category、product type、vendor 和 tags 的职责，并为导航、筛选、广告 Feed 与后续扩品留出稳定结构。
Products > Collections and Search & Discovery65分钟
第二阶段 商品与店铺结构
这一课为什么要先做
集合不是为了后台看起来整齐，而是决定客户从哪里进入商品、导航怎么组织、营销页面怎么落地。新手常把 category、product type、vendor 和 tags 全部写成同一个词，后面自动集合、筛选和 Feed 都变得难维护。先给每个字段一个固定职责，商品越多越省事。
做完以后要留下什么
一个最小可用目录，包含 All Products、Desk Organization 和 New Arrivals 等集合，明确自动规则、集合 URL、排序方式、图片和前台入口。
开始前准备
- 至少准备一款完整商品，并把 category、vendor、product type 和 tags 草稿写好。
- 列出客户实际会用的购物入口，不要按内部部门名称建集合。
- 确认后台显示的是新集合模型还是 legacy 行为，某些变体级能力可能不同。
跟着英文后台一步一步做
每做完一步就刷新页面或从前台验证一次。后台显示已保存，不代表客户看到的结果一定正确。
先画三层目录
只画主导航类别、集合页和商品页三层。North & Pine 首发只有一个核心类别，不需要建十几个空集合。每个集合都写客户意图和未来至少能放几款商品。
区分字段职责
Product category 选 Shopify 标准分类，product type 写团队自己的稳定品类，vendor 表示品牌或供应方，tags 只承担规则或运营标记。不要在 tags 里塞整段描述。
创建手动集合
对需要人工策展、数量很少或规则不稳定的集合使用 Manual。填写标题、描述、图片和搜索结果，手动添加商品后检查排序。
创建自动集合
对规则稳定的集合选择 Automated，并用 category、product type、vendor、tag、价格或库存等条件。建立规则前先在商品表测试，避免 OR 与 AND 组合把不相关商品带进来。
设置排序、SEO 与展示
新店先用手动精选或 Best selling，避免默认排序把缺货或次要商品放前面。为集合写独立介绍和 SEO，不要复制商品描述。移动端检查集合图片、筛选和首屏商品。
连接导航、筛选与 Feed
集合创建后还不会自动出现在主菜单。下一课从 Content > Menus 建链接。需要筛选时通过 Shopify Search & Discovery 等官方能力设置，字段要和 Feed、广告商品组保持一致。
North & Pine 案例怎么设置
North & Pine 先建 Desk Organization 自动集合，规则使用稳定 product type，而不是临时文案。New Arrivals 使用 tag 控制，并由运营在商品上维护。集合页写独立说明，首屏只放当前可售商品。等第二个品类真正出现后，再扩主导航。
这一课需要做出的决定
| 项目 | 推荐设置 | 为什么 |
|---|---|---|
| 首发主集合 | Desk Organization | 对应客户最清楚的购物任务 |
| 手动集合 | 活动或精选 | 内容需要人工控制 |
| 自动集合 | 稳定品类规则 | 商品增加后自动归类 |
| Tags | 少量运营标记 | 不替代 category 和 product type |
这些地方先不要乱动
- 不要建立大量只有一款商品的空泛集合。
- 不要让 category、product type、vendor 和 tags 全部重复。
- 不要认为集合创建后会自动进入导航。
完成标准
下面每一项都能拿出证据，这一课才算完成。只说我看过了，不算验收。
- 目录图能说明每个集合服务什么购物意图。
- 字段职责和命名规范已固定。
- 手动与自动集合规则都有测试证据。
- 集合 SEO、排序和移动端展示已检查。
- 导航和筛选的下一步任务已登记。
常见问题和处理方式
| 现象 | 怎么处理 |
|---|---|
| 自动集合混入不相关商品 | 逐条拆条件，确认 all conditions 与 any condition，再检查商品字段是否被误用。 |
| 集合前台是空的 | 检查商品状态、集合条件、市场与销售渠道可用性，不要只手动添加一次。 |
| 筛选项太多或没有结果 | 只保留客户会用且数据完整的字段，统一商品值并删除低覆盖筛选。 |
把英文后台截图变成验收记录
本课的截图不是装饰，也不等于设置完成。以 Products > Collections and Search & Discovery 为例，先确认左侧导航和页面标题，再看当前选中的标签、开关、状态或记录。截图需要保留完整页面外壳和必要上下文，不能只截一个按钮。这样回看时能回答两个问题：当时在哪个页面，页面当时到底显示了什么。
North & Pine 在本课要处理的是集合规则、商品分类和目录可发现性。本课案例的验收重点是让客户能从 Shop 进入正确集合，并且扩品后规则仍然可维护。按钮显示可点击，只证明下一步存在，不代表审核、同步、保存或前台结果已经通过。如果画面出现 pending、review、unavailable、错误提示或空状态，就把它记录为待确认，不要把它写成已经完成。
先看路径，再看设置
打开英文截图时，先读出左侧导航、页面标题、当前标签和可见状态，再去读字段值。截图说明同时写下页面路径、要验证的事实、负责人和下次复核时间。页面较长时可以用全页截图或两张连续截图，但每张都要保留路径和标题。
发布前仍要做隐私检查。即使使用 dev store，也要遮住邮箱、电话、地址、客户姓名、订单号、域名、App 标识、API key、二维码和浏览器 Cookie。优先使用不透明遮罩或重新裁切。英文版保留后台原文，中文版在图片下增加一行中文说明。
一项设置对应三层证据
对集合规则、商品分类和目录可发现性，把验收拆成配置、行为和记录。配置证据说明后台值已经保存，行为证据说明店面、订单或相关结果确实发生，记录证据说明谁在什么时候复核过。只拿到一层时，不能把整项写成通过。把截图文件名、检查日期、操作者、结论和待处理事项放进复盘表。
- 配置层：记录字段、开关、选项和保存后的状态，不要把默认值当成业务决定。
- 行为层：从前台、订单、通知或下一处关联设置回看结果，确认设置真的影响了流程。
- 证据层：给每个结论关联一张完整截图或连续截图，不用局部按钮图替代页面上下文。
- 边界层：写清地区、套餐、权限、审核、测试模式或第三方服务造成的例外。
出现分支时先暂停
Shopify 后台会因为经营地区、套餐、用户权限、测试数据、销售渠道和审核状态而显示不同选项。缺少按钮不一定是故障，也不一定说明功能关闭。先检查权限、适用地区、套餐和测试状态，再回到官方来源核对。若只能证明一部分，就标记部分完成并说明缺口。支付、税务、域名和客户数据不能用一张测试截图冒充真实上线结果。
本课复盘表
把下面的表复制到团队任务记录中。可证明什么只描述截图确实支持的结论，还不能证明什么用来防止过度解读。
| 检查对象 | 截图中要读什么 | 可证明什么 | 还不能证明什么 |
|---|---|---|---|
| 集合规则、商品分类和目录可发现性 | 路径、标题、当前状态和关键值 | 本次后台检查看到的配置事实 | 前台或第三方服务已经完成全部处理 |
| 关联结果 | 前台、订单、通知或相关设置的返回结果 | 设置对当前测试流程产生的影响 | 所有市场和未来订单都会得到同样结果 |
| 责任记录 | 日期、操作者、文件名和结论 | 谁完成了哪一步，以及证据在哪里 | 审核机构已经替团队做出最终决定 |
| 例外边界 | 权限、地区、套餐、审核或待处理提示 | 当前结果适用的前提 | 可以跳过条件复制到生产店铺 |
课后自测
- 能说出本课的后台路径、当前目标和一项不能由截图单独证明的事情。
- 能指出完整截图中的页面标题、关键字段、状态和对应的实际结果。
- 能把配置、行为和记录三层证据分别写进复盘表，而不是只写已完成。
- 能根据证据决定下一步主题备份与装修，或者明确写下阻塞条件和负责人。
完成本课不等于把所有按钮点成绿色。完成标准是当前判断有足够证据、边界写得清楚、下一步有人负责。如果任何一层证据缺失，就保留待确认状态，不要为了赶进度推进到主题备份与装修。
常见问题
自动集合和手动集合怎么选？
规则长期稳定、商品会持续增加时用自动集合。活动策展、规则难表达或数量很少时用手动集合。
Tags 可以直接当商品分类吗？
Tags 更适合内部规则和运营标记。长期品类应该优先用标准 category 和稳定 product type，否则后面筛选与 Feed 很难统一。
集合页需要写描述吗？
需要。它能解释这个集合适合谁、怎么选和与其他集合的区别，也能为 SEO 和内部链接提供独立内容。
官方来源
后台名称和规则会更新。本课以这些官方页面作为维护基线，截图时也要按当前英文后台重新核对。