Fall '26 引入了一套新的主题架构，把页面结构从 JSON 模板搬回 Liquid。表面上看，这像是对 Online Store 2.0 的倒退。
它确实是一次倒退——倒的是优化目标，不是进展。OS 2.0 为可视化编辑器优化，所以结构必须是机器可编辑的 JSON。新架构为「自上而下读完一页」的读者优化，而这个读者越来越不是人。
核心要点
- 页面结构回到
templates/*.liquid。新增的{% block %}标签可与原生 HTML 混写。 - 块的输入有 typed contracts；新增
{% partial %}标签让 JavaScript 刷新片段。 - 内置 Tailwind，且只下发页面实际用到的 CSS——这是实打实的 Core Web Vitals 收益。
- 主题附带 markdown 伴随文件，向 Sidekick 说明主题是怎么搭的。
- 2026 年 7 月起开发者预览，与现有主题并行运行。不强制迁移，GA 日期未公布。
新旧对照
维度 | Online Store 2.0 | Fall '26 架构 |
|---|---|---|
页面结构 |
|
|
组件 | section 加嵌套 block schema |
|
类型安全 | 松散的 schema 约定 | 块输入有 typed contracts |
局部更新 | Section Rendering API |
|
样式 | 自带或自引入，全站下发 | 内置 Tailwind，只下发该页用到的 CSS |
机器可读性 | 需要用 JSON 加 section 树重建页面 | 一个文件自上而下读完，另附 markdown 说明 |
JSON 为什么成了问题
要理解 OS 2.0 下的一个商品页，你得解析一个按顺序列出 section 引用的 JSON 模板，把每个引用解析到对应的 Liquid 文件，走一遍嵌套 block schema，然后在脑子里把结果拼回去。对可视化编辑器来说这很理想——每个节点都可寻址。
对语言模型来说，这既贵又有损。上下文被花在重组而不是理解上，而重组出来的图景经常是错的。任何让 AI 助手改过主题的人都见过这种失败：它把看起来对的东西改到了错的地方。
线性的 Liquid 模板去掉了重组这一步。人和代理读同一个文件、按同一个顺序，得到同一个理解。
AI 之外的三个收益
性能。 只下发页面用到的 CSS，直指 Shopify 主题里最顽固的问题之一：一个全局样式表携带着本页根本不渲染的 section 的规则。这直接落在 LCP 与 CLS 上。对那些主题体积问题屡治不愈的店铺，这是多年来第一个结构性解法。
不走 API 往返的片段更新。 {% partial %} 让 JavaScript 刷新一个具名片段——购物车数量、价格块、库存徽章——不必走 Section Rendering API 那套编排。活动部件更少，缓存 bug 更少。
Typed contracts。 块的输入有了类型。配置写错会在边界处失败，而不是在三屏之外渲染出某个微妙错误的东西。
markdown 伴随文件才是真正的信号
新架构下的主题会附带 markdown 文件，描述主题是怎么搭的，写给 Sidekick 读。
这是一个真正的新品类：它不是写给新加入团队的开发者的文档，而是写给即将修改这段代码的代理的。这与店铺层面的 /agents.md 是同一种直觉，只是应用到了主题上——也正因如此，单视图店铺编辑器 Canvas 才能让商家用描述的方式改版主题。
这也意味着一项新义务。如果你给客户做主题，这个文件现在是交付物的一部分，而它的质量决定了客户的 AI 助手能多好地处理你做的东西。
现在该怎么办
如果你在运营店铺。 不急。该架构处于开发者预览，与现有主题并行，没有 GA 日期。问一下你的主题伙伴是否在跟进，把这个问题留到下一次大改版。
如果你做主题。 现在就开始。预览从 2026 年 7 月就开放了，而第一波迁移需求会集中在 GA 时到来。光是 CSS 子集化这一点，在任何 AI 论据之前就已经是一个可售的性能故事。
如果你在权衡 Headless。 这缩小了差距。相当一部分 Headless 迁移的动机是逃离主题层的性能与结构限制。Tailwind 加按页 CSS、typed block、片段更新直接回应了其中几项。再加上 Hydrogen 从框架变成库，Liquid 与 Headless 之间的二选一已经变成了一条连续光谱。
常见问题
我现在的主题会停止工作吗？ 不会。新架构与现有主题并行运行，不强制迁移，也没有公布弃用计划。
它本身会提升 AI 可见度吗？ 间接会。它让代理更容易读懂一页，这对引用层有帮助，也让 AI 辅助编辑更可靠。但它不改变商业工具路径返回什么——那来自目录数据，不是标记。
Tailwind 是强制的吗？ 它是内置的。把它当默认项而不是硬性要求，在决定重做之前先评估它与现有设计体系的契合度。