把技术栈整个甩给Claude——结果跑起来的全是我没听过的服务

这个品牌的内核是「AI驱动的品牌冷启动」

先把前提说清楚：MODAY一半是T恤品牌，一半是实验。

我本职做电商咨询，品牌从0到1的运营现场看过不少，但都是从副驾驶视角。MODAY是故意换了一种打法：一个人，全球市场，三天时间，判断和执行只要AI愿意接手，就尽量交给AI。

技术栈选型也是同一套逻辑。不是「我不懂所以问AI」，而是：从一开始就预设由AI来选，我唯一的工作是把判断标准写下来。

最后跑出来的，是这套：

层	服务
店铺	Shopify (Dawn 主题)
按需印刷	Gelato
翻译	Translate & Adapt
自动化	Make.com
Webhook 服务器	FastAPI on Render.com
图像生成	fal.ai (FLUX Pro)
文本 / AI 处理	Anthropic API

这七个里，开始之前我认得名字的，只有 Shopify 和 Anthropic API。 其他全是和 Claude 聊出来时第一次见到的名字。

这套栈从开始搭到现在，刚满三天。

选 Shopify 是因为一条新闻，不是因为技术

最诚实的解释，多少有点不好意思说。

前阵子我看到 Shopify MCP 的发布消息扫过屏幕。第一反应：「行，这下 Claude Code 能直接从内部操控 Shopify 店铺了。」决策的 90 % 就到这儿。

作为咨询顾问，我看 Shopify 看了好多年，但从没真正在它上面自己搭过店。无所谓——只要 Claude Code 能通过 MCP 进得去，我就不必先把自己变成 Shopify 老手再去交付。

日本本地平台（BASE、STORES）从一开始就没进短名单。原因只有一个：第一天就要面向全球卖。 九种语言、多币种、真正的跨境结账。这件事在第一天就做得轻松的，只有 Shopify。

所以我真正的选型标准其实不是「技术上最好的平台」，而是「和 Claude Code 配合最顺」加上「明天就能向全世界卖东西」。

POD 这块，从一开始就打算外包给 Claude

T恤怎么印、怎么寄？

立项之前，按需印刷服务我一个都不认识。Printful、Printify、Gelato——全没听说过。

但这不是问题。这一块从一开始就是要让 AI 来选的。 我个人对全球 POD 市场的认知很薄。与其我自己花一周做调研，不如把生意层的限制条件写清楚，让 Claude 按这些条件给我排序。出来的结果会比我自己琢磨的强。

我发出去的 prompt：

我想用 Shopify 卖定制 T 恤，按需印刷，自动履约。目标市场是美国、欧洲、亚洲，日本是次要市场。该用哪家 POD 服务？比较几家给我看看。

就这些。全是生意层的条件。 没有 SDK 语言、没有速率限制、没有 webhook 格式、没有鉴权机制。这些东西就算想写我也写不出来。

回来的答案：

我比较了三家主流 POD 服务。结论：Gelato 最贴你的场景。

🥇 Gelato（首推）
- 32 个国家、140 多个本地印刷据点
- 在日本、韩国、新加坡、马来西亚、澳大利亚、印度、中国都能本地生产
- 欧盟 / 美国 / 亚洲客户平均 72 小时内送达
- 关税风险低（生产留在目的国，不跨境运输）
- 发货覆盖 200 多个国家
- 短板：商品库比 Printify 略小，单价稍高

🥈 Printful（适合做品牌）
- 北美、欧洲、亚洲共 17 个据点
- 三家里品控最严
- 短板：单价最高

🥉 Printify（适合控成本）
- 90 多家印刷供应商，950+ 商品
- 大多数品类比 Gelato 便宜 10–20 %
- 短板：亚洲本地生产网络较薄，没有日语支持

建议： 「全球为主、日本为辅」的定位下，把 Gelato 当主力。三大区域都能本地生产，运费、关税、时效三件事一起占便宜。

定。履约链条的核心，现在跑在一个我从没见过、也没碰过的服务上。

如果按咨询顾问的老办法做同样的对比——三套文档全读、人脉里挨个问——一周就没了。这次几乎是即时给出答案。

至于 FastAPI，我连「你在用？」这个层面都还没到

栈表里写着：「Webhook: FastAPI on Render.com」。

我自己写到这一行的时候忍不住笑。我其实还没真搞清楚 FastAPI 是什么。

搭店初期，需要一个东西接住 Shopify 过来的订单 webhook，再转发给 Gelato。Claude Code 说：「我用 FastAPI 写好，部署到 Render.com。」我对它的认知止步于「Python 的某个框架」，于是说「拜托了」。

代码写完了。部署完了。能跑。我的参与就是在 Render 后台盯几眼日志而已。

（顺便说一句，这一块已经被换掉了。 搭着搭着觉得不对劲，就切到另一种方案。这段故事下回或下下回再写。）

只要决定「AI 优先」，就得接受一件事：自己的栈，自己解释不全。 这种取舍本身就是这次实验要观察的对象，不是 bug。

这是聪明，还是莽撞？

我自己都还没想明白。

好处很清楚：

• 我从没考虑过的选项，第一天就出现在短名单上
• 「我个人会的东西」不再是项目的天花板
• 选型和实施合并成同一个动作——本来要花一周的环节，瞬间就过了
• 一个非工程师想做全球 D2C 品牌，从假设变成了一个真实可行的项目

风险一样清楚：

• 有问题的时候，我可能根本读不出来到底坏在哪
• 「为什么用这套栈」我现在还没法用自己的话讲明白（所以才在写这篇——边写边把自己理一遍）
• 哪家供应商挂了，我重新选型的反应会很慢

这个取舍半年后会怎么演变，现在还不知道。能跑的时候极其爽，倒下的那天可能会很惨。

我之所以还是这样做下去，是因为我想要一个诚实的答案：「AI 到底能走多远？」——而且要在真生意上量出来。 玩票项目给不出这个答案。只有真金白银在流，真客户在买，真包裹在发的场景里反复试，最后才会蹦出一个能信的数字。

三天搭起来的栈，准备卖给全世界

从定栈到开始搭，整整三天。
真正动手写代码的时间比这还短。

就在这三天里：店铺上线了，九种语言跑起来了，订单 webhook 已经会响，Gelato 商品同步开始动。这是「AI 优先品牌冷启动」实验的 V1 栈。

到年底，这套栈大概率有一半会被替换。FastAPI/Render 已经下岗。其他几处也在悄悄发出怪声。

但今天这个时刻，它差不多已经能向全世界卖货了——今天只有这一件事重要。

下一篇写「我交给 Claude Code 的活，和我自己亲手做的活，是怎么分的」。

— Yoskee
moday.me