用 Claude Code 跑通跨境电商的 5 个核心场景
大部分团队用 AI 还停在翻译、写文案和生成图，AI 只参与了工作中间一小段。Claude Code 的区别在于它能读本地文件、通过 MCP 接外部数据、把流程写成 Skill 反复执行，也就是能自己动手而不只是给建议。但对外发送、改价、改库存这类动作必须留人工确认；能批量生成不等于该批量生成。建议先挑一个每周都要重复、规则写得出来、结果能验证的动作跑通，再往外扩。
大部分团队用 AI 还停在翻译、写文案和生成图，AI 只参与了工作中间一小段。Claude Code 的区别在于它能读本地文件、通过 MCP 接外部数据、把流程写成 Skill 反复执行，也就是能自己动手而不只是给建议。但对外发送、改价、改库存这类动作必须留人工确认；能批量生成不等于该批量生成。建议先挑一个每周都要重复、规则写得出来、结果能验证的动作跑通，再往外扩。
现在大部分跨境团队都在用 AI，但用法高度集中在三件事：翻译、写文案、生成图。
这些用法有价值，但有个共同特征——AI 只参与了工作中间一小段，前面的取数据和后面的落地执行，仍然全部由人做。
Claude Code 值得单独讲，不是因为它模型更强，而是因为它的形态不一样：它跑在你自己的电脑或服务器上，能读本地文件、能调外部接口、能写脚本还能自己把脚本跑起来。
同一个问题，聊天工具给你的是「你应该怎么做」，它给你的是一份已经做完的东西。
需要同时说清楚另一面：能自己动手，也意味着它能把事情做坏。所以这套东西真正的门槛不在能不能跑起来，而在你有没有把「哪些动作必须人点头」这件事先定下来。
举一个每周都会遇到的场景：广告数据要复盘。
用聊天工具，你会得到一套很像样的分析框架：看 ROAS、看 ACOS、看搜索词报告、看转化率，还会告诉你异常怎么判断。方法没错，但你还得自己导数据、自己算、自己填表、自己写结论。
换成 Claude Code：
一个给方法，一个交成果。这就是全部区别。
很多人一看到 Code 就默认这是开发工具，直接跳过了。
它确实从写代码起家，但从能力结构上看，它本质是一个能读文件、能跑命令、能连外部系统的执行环境。写代码只是这个环境最早、最成熟的一种用法。
对运营和老板来说，真正相关的是这几点：
最后一点在小团队里特别实际：把规则配好的人和每天真正用的人，往往不是同一个。
要把一件事真的交出去，需要四层都到位。缺哪一层，就在哪一层出问题。
引擎决定它能不能看懂资料、能不能自己拆步骤、能不能把活干完。
这一层现在是最不缺的。真正卡住团队的，都在后面三层。
AI 之所以经常「说得对但没用」，多数时候不是笨，是没看到你的数据。
这一层解决的是：它从哪里拿到订单、广告报表、库存、客服邮件、供应商合同和店铺后台数据。
Claude Code 这里有两条路：本地目录直接读，或者通过 MCP 连外部系统。官方文档里举的例子是 Google Drive、Jira、Slack 和自建工具；电商侧则有 Shopify 官方提供的几个 MCP，后面单独讲。
有一个很现实的判断：能不能把数据接进来，比模型选哪个更影响最终效果。
这一层是大多数团队真正的资产，也最容易被忽略。
一个做了三年的老运营，看到一封询盘就知道归哪一类、用哪套话术、什么情况必须升级；看到广告报表就知道哪个数字要先看。这些判断通常只在他脑子里，最多散落在几个文档里。
在 Claude Code 里这些东西有固定位置：公司口径和长期规则写进 CLAUDE.md，每次开工自动生效；一条完整流程打包成 Skill，团队共享，谁执行都是同一套动作，而不是各写各的提示词。
这件事的副作用往往比 AI 本身更值钱：你会第一次被迫把流程写清楚。
前三层决定它能干多少活，这一层决定你敢不敢让它干。
跨境业务里有几类动作，默认就不该全自动：
正确做法是让它把草稿和依据准备好，把最后一步留给人。Claude Code 本身有权限设置控制哪些动作可以自动、哪些必须确认，也可以用 Hooks 在动作前后自动跑校验，比如执行写操作前先过一遍检查。
同时要留记录：这次读了什么、做了什么、谁批准的。出问题时你需要能回溯，而不是只能猜。
输入是一个类目或一批关键词，输出是一份能直接拿去开会的调研。
它能做的事：拉竞品矩阵，算价格带分布，把评论里的高频抱怨聚成痛点清单，再反过来找产品机会——差评和论坛吐槽里藏着的信息，通常比销量榜更有用。
这里有两个必须说清楚的边界。
一是数据来源决定结论质量。接第三方数据服务也好，自己抓也好，数据口径、覆盖范围和更新频率都要先搞清楚，不要把抓来的数据当成平台官方口径用。
二是抓取本身要守平台规则。技术上能抓，不等于抓了没风险。
Listing 这一侧，现在要同时应付两种入口：一种是传统关键词检索，一种是 AI 问答式的商品推荐。亚马逊公开的 AI 购物助手是 Rufus；卖家圈里流传的 A10、COSMO 这类叫法，并不是平台统一对外的官方命名，写 Listing 时不必围着名字打转，重点是同一条 Listing 要能同时被关键词匹配和 AI 读懂——参数写全、卖点写具体、使用场景写清楚。
广告这一侧更适合自动化：每天或每周读一次广告报表，按你定的阈值标出问题——CPA 超标的广告组、持续烧钱没转化的搜索词、值得加进否定词的候选、可以提竞价的高转化词。
真正的价值在频率。人工复盘一周一次，一年 52 次；接上之后一天一次，一年 365 次。同样的判断规则，迭代次数差一个量级。
审批点建议这样切：阈值内的调整可以自动执行并记录，超过阈值的必须人确认。不要一上来就把改预算和改竞价全放开。
Shopify 侧官方已经有现成的接入方式：Shopify AI Toolkit 给 AI 编码工具一个 Shopify 感知的起点，Shopify Dev MCP 让它能查官方文档和 API schema，Storefront MCP 面向购物者场景，提供商品发现、购物车和政策问答，Customer Accounts MCP 处理订单查询这类需要登录身份的请求。
日常运营里更常用的是另一类活：批量改商品信息、同步库存、批量生成或修订 SEO 元数据、清理历史数据。这些走 Admin API，Claude Code 可以直接写脚本执行。
也正因为能直接写能直接跑，这个场景是审批要求最高的一个。建议默认规则：写操作先跑一遍不落地的预演，把将要改动的清单打出来给人看；改价、改库存、上下架必须人确认；任何批量操作都要能回滚。
这块现在有两件事在同时发生：一是搜索入口从搜索框往 AI 问答迁移，二是页面能被批量生产出来。
Claude Code 在这里能做的事很具体：按模板批量生成页面、批量补齐结构化数据、检查标题和描述的重复与缺失、发现内链断层。
但有一句必须写在前面：能批量生成，不等于该批量生成。
那种只把地名或行业名替换一下、正文几乎相同的页面，短期可能有量，长期是负债。真正值得批量做的是有独立信息量的页面——不同规格、不同用途、不同问题的实际答案。判断标准很简单：把这一页给一个真实客户看，他能不能拿到别处拿不到的信息。
面向 AI 搜索的写法也有共性：结论前置、结构清楚、事实可核、来源写明。这些做法对普通搜索同样有效，不需要为 AI 单独做一套。
这类活单看每件都不大，加起来占掉运营大量时间：
用 Routines 可以让这些按固定节奏自己跑，例如每周一早上先把周报放在那儿等人看。
这一类的默认设定应该是「只通知，不动作」。发现竞品降价，它给通知；跟不跟、跟多少，人来定。
不是所有活都适合。挑第一件事时按这三条筛：
三条都满足的先做，只满足一两条的往后排。一条都不满足的，说明这件事本来就没标准化，别指望 AI 替你解决管理问题。
反过来，看起来很难但规则清晰的活，往往比看起来简单却全靠经验的活更适合先交出去。
这是最容易算错的一笔账。很多人只算订阅费，然后得出「很便宜」或者「不值」的结论，两个方向都容易错。
订阅和模型费通常是整件事里最小的一部分。要一起算进去的还有：
所以判断值不值得，不能只看每月花多少，要看这件事一年重复多少次、每次省多少时间、错误率降了多少。这三个数跑不出来，就说明还没到扩大投入的时候。
顺带说一句对比逻辑：定制方案和现成 SaaS 不是同一个东西。SaaS 的优势是开箱即用和有人维护，定制的优势是完全贴合你自己的口径和流程。团队小、流程标准、没人维护的，先用 SaaS 更合理；流程特殊、口径自己定、且有人能持续维护的，定制才划算。
不用先规划系统，先做这三步：
第三步之前，记四个数：原来多久、现在多久、错了几次、哪一步仍然必须人来判断。
最后一个数最重要。它会告诉你下一个该自动化的是哪一段，以及哪一段永远不该自动化。
这篇是总论，后面按场景逐个拆，每篇给出可复用的规则、模板和审批设计：
如果你手上正好有一件每周都要重复的工作，可以直接把它现在的输入和做法发过来，我们先判断它适不适合交给 Claude Code。联系方式在关于页面。
下一篇
没有了
作者
大阪烧鸟
大阪烧鸟，关注跨境电商、Shopify 独立站与日本商业观察，偏爱把复杂问题拆成可执行的方法。
如果这篇内容对你有帮助，可以继续浏览 zens.osaka 的文章列表，按主题顺着看相关问题。
转载或引用请保留 zens.osaka 的原文链接与标题。
