Shopify Section 文档模板：让主题更好维护

Shopify Section 不只是主题里的视觉模块。它也是市场、商品和内容团队上线后会长期使用的编辑界面。如果这个界面没有文档，店铺会慢慢变成一堆没人敢在活动前修改的 Section。

这份模板适合 Shopify 主题开发、网站改版、迁移清理和长期维护项目。建议在交付前、添加新 Section 时，或审计一个有太多相似模块的旧主题时使用。

先记录 Section 的业务任务，再列字段。商品证明模块、活动主视觉、集合推荐、媒体引用、对比表和 FAQ，都需要不同规则。如果任务说不清，字段通常也会变得含糊。

用一句话写明这个 Section 帮运营解决什么页面问题。然后定义它可以出现在哪里、不应该用在哪里。这样可以避免主题里积累很多功能相似、细节略有不同的重复模块。

• Section 用途：它解决哪个页面问题？
• 可用模板：首页、商品页、集合页、落地页、博客或政策页。
• 不适合场景：哪些使用方式会造成页面混乱、内容重复或弱 SEO 信号？
• 负责人：上线后谁可以批准这个 Section 的变更？

每个字段都应该让非开发人员看得懂。文档要说明字段标签、字段类型、预期内容、默认值、是否必填，以及字段为空时会发生什么。图片选择、商品引用、集合引用、富文本、链接和连接 metafield 的内容尤其需要写清楚。

不要只依赖主题编辑器里的字段名。请补充实际示例和限制。如果字段接收标题，就写明建议长度。如果图片需要裁切，就记录比例。如果商品卡片使用 metafield，就说明来源和兜底。

• 字段标签、字段类型、必填或选填状态，以及默认值。
• 标题、eyebrow 文案、正文、按钮和标签的字数限制。
• 图片比例、焦点建议、移动端裁切行为和 alt text 来源。
• 数据来源：手动输入、商品字段、集合字段、metafield、metaobject 或应用输出。

好用的 Section 一定有约束。灵活的主题不代表每个字段都可以接受任意长度、任意内容。如果没有限制，Section 在设计稿里可能很好看，但换成更长翻译、方形图片或三个 CTA 后就会变形。

请用普通语言写明这些限制。目的不是让运营不敢编辑，而是让编辑结果可预期。这样真实内容替换样例内容后，页面仍然像是有意设计过的。

• 区块、卡片、轮播、Logo、FAQ 或商品引用的最小和最大数量。
• 按钮规则：一个主 CTA、可选次 CTA、链接目标和空状态表现。
• 响应式规则：移动端排序、卡片堆叠、隐藏媒体、图片裁切和吸顶元素。
• 兜底状态：缺图、缺链接、商品缺货、集合为空和内容未发布时怎么显示。

Section 文档应该包含 SEO 和性能规则，因为很多店铺问题都是从一次看似普通的内容编辑开始的。运营改了模块标题，结果标题层级跳级。活动换了一张图，页面体积翻倍。集合推荐链接到了不该被索引的筛选 URL。

对所有可能影响搜索可见性、内链、结构化数据或 Core Web Vitals 的 Section，都加一段简短的 SEO 和性能说明。这样技术 SEO 会成为编辑模型的一部分，而不是上线周才补的清理项。

• 标题规则：这个 Section 能否包含 H1、H2、H3，还是只能使用视觉样式文字。
• 图片规则：推荐尺寸、压缩目标、懒加载行为和 alt text 负责人。
• 链接规则：允许的目标、规范商品或集合链接，以及何时避免带参数 URL。
• 性能规则：脚本使用、视频行为、轮播数量限制、应用嵌入和动画约束。

Section 不是在完美设计文案下看起来不错就算完成。它需要能承受店铺真实会遇到的复杂状态。交付前为每个 Section 跑一张小 QA 矩阵，并把结果留在文档里。

这张矩阵在后续维护时会很有用。以后有人修改主题，团队已经知道关键状态要复测什么，而不是临时猜哪些页面可能受影响。

• 桌面、平板和移动端检查，使用真实内容而不只是 placeholder。
• 长标题、长翻译、缺图、缺 CTA、空选填字段和最大区块数量。
• 商品不可售、集合为空、复杂变体商品、促销价、订阅商品和本地化市场。
• 主题编辑器预览、线上页面渲染、分析事件、内链和相关 SEO 元数据。

文档要说明谁可以修改这个 Section，以及什么时候需要开发介入。有些更新只是安全的内容编辑。有些更新会影响页面层级、数据依赖、SEO 输出、性能或转化追踪。团队不应该在活动上线前才发现差异。

加一张简单的变更规则表：运营可自行修改、需要内容负责人审核、需要 SEO 审核、需要开发审核，或已经弃用。这样店铺会有一套运营模型，而不是一堆藏在主题里的隐性知识。

• 运营可安全编辑：文案、图片、商品引用、链接、顺序或显示状态。
• 需要审核的编辑：标题结构、Schema 输出、活动追踪、应用嵌入或导航链接。
• 需要开发的编辑：新增字段、布局变化、metafield 来源变化、脚本和动画行为。
• 弃用规则：什么时候隐藏、替换、合并或移除不再使用的 Section。

最终交付物应该是一套小型 Section Library，而不是一份没人再打开的 PDF。每个 Section 一页，包含用途、字段、限制、示例、截图、QA 状态、SEO 说明和负责人规则。把它链接到项目 Wiki、主题仓库或客户交付文档里。

好的 Section Library 会降低维护成本，因为未来的工作可以从已知约束开始。下一位开发能看到字段为什么存在。运营能看到怎么使用这个 Section。SEO 团队也能看到哪些编辑会影响标题、链接、图片和结构化数据。