让 Claude Code 管 Shopify 的商品、库存和 SEO 信息
同样是批量改商品，CSV 导出改完再导回、写 Admin API 脚本直接改、用官方 MCP 查数据，三条路的风险完全不同。原则是读操作可以放开，写操作一律先出预演清单再人工确认，并且任何批量改动都要能回滚。低库存盘点、找出售价低于成本的商品、补齐缺失的 Meta Description，这三件事收益最直接，适合先做。
同样是批量改商品，CSV 导出改完再导回、写 Admin API 脚本直接改、用官方 MCP 查数据，三条路的风险完全不同。原则是读操作可以放开，写操作一律先出预演清单再人工确认，并且任何批量改动都要能回滚。低库存盘点、找出售价低于成本的商品、补齐缺失的 Meta Description，这三件事收益最直接，适合先做。
独立站的日常维护里，有一大堆又碎又必须做的活：改几十个商品的描述、查哪些 SKU 快断货、找出哪些商品因为改过运费实际上在亏钱、补齐没写 Meta Description 的页面。
这些事情人做没有难度，只有量。正好是 Claude Code 的位置。
但 Shopify 和前面几篇的场景有一个本质区别：**它是线上店，改错了直接影响成交。**广告诊断最坏是给了个错建议，改商品数据最坏是几百个商品的价格错了。
所以这一篇的核心不是「怎么让它改」，而是「怎么让它改得可控」。原则只有一句：读操作可以放开，写操作一律先出预演清单再人工确认。
让 Claude Code 碰 Shopify 数据有三种方式，选哪条决定了你的风险敞口。
Shopify 后台支持商品数据的 CSV 导出和导入。流程是：后台导出 CSV → 放进本地目录 → Claude Code 读取、按规则修改、生成新的 CSV → 你自己在后台导入。
这条路最安全，因为最后那一步是人做的，导入前后台还会让你确认一次。改错了也有原始 CSV 可以对照回滚。
缺点是慢，而且不适合需要频繁执行的任务。
建议：所有批量写操作，第一次都走这条路。
给它一个自定义应用的访问令牌，让它写脚本直接调 Admin API 改数据。
这条路快，能自动化，但风险也最高——脚本跑起来就是几百个商品同时变。
用这条路的前提是三件事都做到：先跑不落地的预演、把要改的清单打出来给人看、保留原值以便回滚。少一件都不要开。
Shopify 提供了几个官方 MCP：Shopify Dev MCP 让 AI 工具能查官方文档和 API schema，本地运行、不需要认证；Storefront MCP 面向购物者场景，提供商品发现、购物车和店铺政策问答；Customer Accounts MCP 处理订单查询这类需要登录身份的请求。此外还有 Shopify AI Toolkit，作用是给 AI 编码工具一个 Shopify 感知的起点。
这些主要解决「让它懂 Shopify 怎么用」和「查询」，配合前两条路用，本身不是批量改数据的通道。
纯读操作，零风险，可以直接自动跑。
输入是商品和库存导出，加上一段时间的销量。产出是两张表：按当前销速算，多少天后断货；哪些 SKU 超过多少天没动销、占了多少库存金额。
这件事很多人靠感觉，实际上一算经常会发现压货比想象中严重。
这一件最容易被忽略，也最容易出真金白银的问题。
促销改过价、运费规则调整过、汇率变了、成本涨了——任何一个都可能让某几个 SKU 变成卖一件亏一件，而后台不会提醒你。
做法是把商品导出（含售价）和你自己的成本表放一起，算出每个 SKU 的毛利，把毛利为负和毛利低于阈值的挑出来。
跑第一遍的时候留点心理准备，多数店都能找出几个。
也是读操作为主，产出是草稿。
先扫出哪些商品页和集合页没写 Meta Description，或者写得过长被截断、或者几十个页面共用同一段。然后按商品资料批量生成草稿，输出成 CSV，你审一遍再导入。
注意是生成草稿，不是直接写回去。这一点下面还会展开。
---
name: shopify-audit
description: 盘点 Shopify 商品数据，输出低库存、滞销、负毛利和 SEO 信息缺失清单，并生成批量修改的 CSV 草稿。当用户要做库存盘点、检查商品毛利、补 Meta Description、批量改商品信息时使用。
argument-hint: [任务类型]
allowed-tools: Read Write Bash(python3 *)
---
## 数据
读取 `data/shopify/` 目录：
- `products.csv`：后台导出的商品数据
- `inventory.csv`：库存数据
- `cost.csv`：我们自己维护的成本表，按 SKU
- `sales-90d.csv`：最近 90 天销量
任何一份缺失，就跳过依赖它的检查，并在报告里写明缺哪份，不要用估算值代替。
## 检查项
### 库存
- 按最近 30 天日均销速，算出每个 SKU 的预计断货天数
- 断货天数小于备货周期的，标为「需补货」
- 超过 60 天零动销的，标为「滞销」，并算出占压的库存金额
### 毛利
- 毛利 =（售价 - 成本 - 预估运费）÷ 售价
- 毛利为负的，标为「亏损」，排在最前
- 毛利低于 15% 的，标为「偏低」
- 成本表里没有的 SKU，单独列出，不参与计算
### SEO 信息
- 找出 Meta Description 缺失、超过 160 字符、或与其他页面重复的商品
- 找出标题超长被截断的商品
## 输出
在 `reports/` 生成一份 Markdown 报告，同时在 `output/` 生成修改用的 CSV 草稿。
CSV 草稿必须满足：
- 只包含需要修改的行，不要全量导出
- 保留原值列和新值列，两列并排，便于人工核对
- 文件名带日期
## 禁止动作
- 不调用任何 Shopify 接口，不直接修改线上数据
- 不修改原始导出文件
- 生成的 CSV 一律是草稿，由人在后台导入
- 成本、运费这类数据缺失时，直接写「数据缺失」，不要估算后当成结论
跑顺了之后，你大概率会想把「导出、导入」这两步也省掉。可以，但要先把下面这套流程建起来。
任何写操作，先跑一遍不落地的版本，把「将要改哪些商品、从什么改成什么」完整打印出来。
这一步是硬要求，不是可选项。预演清单没看过就执行的批量操作，出事只是时间问题。
给单次操作设上限，比如一次最多改 50 个商品。超过就拆成多批，每批之间人确认一次。
这条能把「脚本写错」的损失从全店缩小到 50 个。
执行前把所有将被修改字段的原值存成一份文件。这就是你的回滚数据。
没有这份文件，回滚意味着从备份恢复整个店，代价完全不同。
不是所有字段都一样危险：
| 修改内容 | 处理方式 |
|---|---|
| Meta Description、商品描述 | 预演后可批量执行 |
| 商品标签、集合归属 | 预演后可批量执行 |
| 库存数量 | 人工确认每一批 |
| 价格 | 一律人工确认，不做批量自动 |
| 上下架状态 | 一律人工确认 |
| 变体和 SKU | 一律人工确认 |
价格和上下架不做自动，理由很简单：这两项错了，客户当场就能下单，撤不回来。
上面把 Meta Description 归到了「预演后可批量执行」，但还是要人抽查。
原因不是怕它写错语法，是怕它写得太像。批量生成最典型的问题是几十个商品的描述结构完全一致，只有商品名不同。这种东西对搜索没有帮助，还会让页面看起来像批量灌水。
抽查的办法很简单：随机挑十条连着读。如果读起来像同一个模板填了不同的空，就回去改 Skill——让它必须用到每个商品自己的参数和使用场景，而不是套一个句式。
这个问题在批量生成页面时会更严重，那一篇专门讲。
商品数据是可以回滚的，主题代码不是——改坏了整个店的前台就是坏的。所以主题修改要另建一套流程，下一篇专门讲那四步。
结论前置、事实可核、结构清楚、来源写明，这几条对普通搜索和 AI 问答同时有效，所以不用为 AI 单独做一套内容。Claude Code 在这里的价值不是替你写，而是替你查：哪些页面没有直接回答标题提出的问题、哪些缺结构化数据、哪些事实没有具体数字。为 AI 单独准备一份和用户看到的不一样的内容，是风险动作，不要做。
商品数据改错了可以再导一次，主题代码改错了是整个前台挂掉，两者的容错空间完全不同。安全流程就四步：复制主题、拉到本地在副本上改、预览加自动检查、人工确认后发布。核心约束是永远不要让 AI 直接推到线上主题，以及每次只改一件事——一次改五处，出问题时你无法定位是哪一处导致的。
大部分团队用 AI 还停在翻译、写文案和生成图，AI 只参与了工作中间一小段。Claude Code 的区别在于它能读本地文件、通过 MCP 接外部数据、把流程写成 Skill 反复执行，也就是能自己动手而不只是给建议。但对外发送、改价、改库存这类动作必须留人工确认；能批量生成不等于该批量生成。建议先挑一个每周都要重复、规则写得出来、结果能验证的动作跑通，再往外扩。
作者
大阪烧鸟
大阪烧鸟，关注 AI 在跨境电商运营中的实际应用、Shopify 独立站与日本商业观察，偏爱把复杂问题拆成可执行的方法。
如果这篇内容对你有帮助，可以继续浏览 zens.osaka 的文章列表，按主题顺着看相关问题。
转载或引用请保留 zens.osaka 的原文链接与标题。
