用 Claude Code 改 Shopify 主题，必须先建这四步流程
商品数据改错了可以再导一次，主题代码改错了是整个前台挂掉，两者的容错空间完全不同。安全流程就四步：复制主题、拉到本地在副本上改、预览加自动检查、人工确认后发布。核心约束是永远不要让 AI 直接推到线上主题，以及每次只改一件事——一次改五处，出问题时你无法定位是哪一处导致的。
商品数据改错了可以再导一次，主题代码改错了是整个前台挂掉，两者的容错空间完全不同。安全流程就四步：复制主题、拉到本地在副本上改、预览加自动检查、人工确认后发布。核心约束是永远不要让 AI 直接推到线上主题，以及每次只改一件事——一次改五处，出问题时你无法定位是哪一处导致的。
上一篇讲商品数据，那些改动都是可逆的：CSV 再导一次，或者按留存的原值改回去。
主题代码不一样。一个 Liquid 语法错误可能让整个页面白屏；一段 JavaScript 报错可能让加购按钮点不动；改动了某个 section 的 schema，可能让已经配置好的首页内容全部丢失。
这类问题的共同点是：客户比你先发现。
所以让 Claude Code 碰主题之前，先把流程建起来。就四步，不复杂，但一步都不能省。
先看店里现在有哪些主题，找到线上那个：
shopify theme list
然后复制一份出来：
shopify theme duplicate
从这一刻起，所有改动都发生在这个副本上。线上主题在整个过程中不被碰到。
这一步看起来多余，实际是整套流程的地基。有了副本，后面任何一步出问题，最坏结果都只是「副本废了，重新复制一份」，而不是「店挂了」。
把副本的文件拉到本地：
shopify theme pull
拉的时候选刚才复制出来的那个主题，别选错。
本地有了完整的主题文件，Claude Code 才能真正干活——它能读到所有 Liquid 模板、CSS 和 JS，知道这个主题的结构是怎么组织的，而不是靠猜。
这一步还有一个好处：本地目录可以用 Git 管起来。改之前先提交一次，改完看 diff，出问题直接 checkout 回去。主题目录纳入版本管理这件事，很多店根本没做，但它是这套流程里最便宜的保险。
在本地改的时候，有一条规则值得写进 CLAUDE.md：
## 主题修改规则
- 一次只改一件事，改完就提交，不要把多个改动堆在一起
- 修改 section 的 schema 之前，先说明会不会影响已有的配置数据
- 不删除看起来没用的文件和代码块，先确认没有引用
- 改完列出这次改了哪些文件、每个文件改了什么
「一次只改一件事」是这里最重要的一条。一次改五处，预览时发现页面坏了，你无法定位是哪一处导致的，只能全部回退重来。
改完先跑一遍代码检查：
shopify theme check
它会报出语法问题和不符合最佳实践的写法。这一步能拦掉一部分低级错误，但拦不住逻辑问题。
然后预览。两种方式：
shopify theme dev
起一个本地开发服务器，改动实时生效，适合边改边看。
或者把改动推到副本主题，再拿预览链接：
shopify theme push
shopify theme open
预览的时候，别只看你改的那一处。至少走一遍这几个页面：
最后一条最容易漏。很多改动在桌面端好好的，手机上布局就散了，而独立站的移动端流量通常是大头。
还要专门验一下加购流程：能不能加进购物车、数量能不能改、能不能进结账。这条链路断了，页面再好看也没意义。
前三步都过了，才发布：
shopify theme publish
这一步必须是人做的，不能写进任何自动化流程。
道理和广告改预算一样：发布是那个不可撤销、且立刻对所有访客生效的动作。前面每一步都可以让 AI 做，唯独这一步留给人。
发布之后再看一次线上页面。预览环境和线上环境偶尔会有差异，特别是涉及第三方应用注入的脚本时。
---
name: theme-edit
description: 在 Shopify 主题副本上做修改，按安全流程执行：复制主题、本地修改、预览检查，最后由人确认发布。当用户要改主题代码、调整前台样式或结构时使用。
allowed-tools: Read Write Edit Bash(shopify theme *) Bash(git *)
---
## 流程
严格按顺序执行，不得跳步：
1. 确认当前工作的是主题副本，不是线上主题。无法确认时停下来问。
2. 修改前先 `git commit` 一次，保证有干净的回退点。
3. 一次只改一件事。改完运行 `shopify theme check`。
4. 输出本次改动清单：改了哪些文件、每个文件改了什么、可能影响哪些页面。
5. 给出预览地址，并列出需要人工检查的页面清单。
## 检查清单
每次改动后，提示人工检查：首页、带变体的商品页、不带变体的商品页、集合页、购物车、结账入口、搜索页，以及以上全部的手机视图。加购到结账这条链路必须单独验一遍。
## 禁止动作
- 禁止对线上主题执行任何写操作
- 禁止执行 `shopify theme publish`，发布一律由人手动执行
- 禁止一次提交里混入多个不相关的改动
- 删除文件或代码块前，先搜索确认没有引用，并在改动清单里单独说明
allowed-tools 里放行了 shopify theme *，而禁止发布是靠指令约束的。如果你想要更硬的保障，就把权限收得更细，只放行 pull、push、check、dev 这几个子命令，让 publish 根本不在放行范围内。
不是所有主题需求都适合。按风险分：
适合先交出去的：
要谨慎的：
建议找人做的：
判断标准和前面几篇一致：改错了能不能一眼看出来。样式改坏了你打开就知道；结账逻辑改坏了，可能过三天才从订单量上看出来。
前台改动之外，独立站还有一大块是内容和流量。接下来两篇讲 SEO 和 AI 搜索：怎么让搜索引擎和 AI 都能读懂你的产品，以及批量生成页面怎么做才不变成内容滥用。
同样是批量改商品，CSV 导出改完再导回、写 Admin API 脚本直接改、用官方 MCP 查数据，三条路的风险完全不同。原则是读操作可以放开，写操作一律先出预演清单再人工确认，并且任何批量改动都要能回滚。低库存盘点、找出售价低于成本的商品、补齐缺失的 Meta Description，这三件事收益最直接，适合先做。
大部分团队用 AI 还停在翻译、写文案和生成图，AI 只参与了工作中间一小段。Claude Code 的区别在于它能读本地文件、通过 MCP 接外部数据、把流程写成 Skill 反复执行，也就是能自己动手而不只是给建议。但对外发送、改价、改库存这类动作必须留人工确认；能批量生成不等于该批量生成。建议先挑一个每周都要重复、规则写得出来、结果能验证的动作跑通，再往外扩。
选这类工具别只看模型强弱，看四件事：权限边界是系统级还是靠指令、数据怎么接进来、规则文件怎么组织、能不能不用人守着跑。Codex 的特点是沙箱做在操作系统层、网络默认关闭、内置本地模型支持，代价是接第三方服务的协议门槛更高。混用是可行的，因为真正的资产不是工具而是你写下来的口径和规则，那部分迁移成本很低。
作者
大阪烧鸟
大阪烧鸟，关注 AI 在跨境电商运营中的实际应用、Shopify 独立站与日本商业观察，偏爱把复杂问题拆成可执行的方法。
如果这篇内容对你有帮助，可以继续浏览 zens.osaka 的文章列表，按主题顺着看相关问题。
转载或引用请保留 zens.osaka 的原文链接与标题。
