一个人2周内上线电商MVP，要覆盖商品、购物车、订单、支付四个核心模块，这时候就要依靠Claude Code来实现了，具体Claude Code怎么制作电商系统呢？下面就分享实战指南。
Claude Code怎么制作电商系统
第 1 轮：选型（CRISPE 框架）
# Context（上下文）
要做一个电商 MVP，时间只有 2 周，1 个全栈在写。
核心功能：商品列表、购物车、订单、支付。技术栈还没定。
# Role（角色）
你是一位全栈架构师，擅长快速 MVP 开发和技术选型。
# Instructions（指令）
给一套能快速搭起来、后面也好迭代的方案，列出选型理由。
# Steps（步骤）
1. 分析 2 周时间约束下的技术选型优先级
2. 给出前端、后端、数据库、支付、部署的完整技术栈
3. 说明每个选型的理由，特别关注开发速度和后续扩展性
4. 列出潜在风险和应对方案
# Preferences（偏好）
- 优先选择成熟生态和托管服务
- 避免需要大量配置的工具
- 考虑后续迭代成本
# Example（示例）
类似的项目可以参考：Next.js + Vercel + Supabase 的快速开发模式
Claude 给的方案（节选）：前端 Next.js 14 + shadcn/ui，后端 Node + Express + MongoDB，支付走 Stripe，部署 Vercel + Railway。理由是这套栈生态成熟、部署最省事，2 周内能跑通。
第 2 轮：质疑选型，看是否撑得住后续扩展（BROKE 框架）
# Background（背景）
你之前建议用 MongoDB + Stripe。但我有几点顾虑需要重新评估。
# Role（角色）
你是一位技术架构师，需要从长期维护和扩展性角度重新审视选型。
# Objective（目标）
重新评估 MongoDB 和 Stripe 的适用性，给出更稳妥的替代方案。
# Key Information（关键信息）
- 订单和库存对一致性要求高，涉及事务和外键约束
- Stripe 在国内不能直接收人民币
- 需要预留支付渠道的替换空间
# Example（示例）
类似项目通常用 PostgreSQL 处理订单，用适配器模式抽象支付层
Claude 同意 PostgreSQL 更合适：订单/库存涉及事务和外键约束，Mongo 处理起来要绕。Stripe 国内不能直接收人民币，建议把支付层抽象成 PaymentProvider 接口，先实现 StripeProvider，上线时按需替换 WechatPayProvider、AlipayProvider。
确定调整后的栈：Next.js 14 + PostgreSQL + Prisma + Stripe（适配器模式）+ Vercel/Railway。
系统架构图：
第 3 轮：让 Claude 生成项目骨架（ROBOTIC 框架）
# Role（角色）
你是一位前端工程化专家，擅长项目架构和工具链配置。
# Objective（目标）
基于确定的技术栈生成完整的项目骨架。
# Background（背景）
技术栈：Next.js 14 + PostgreSQL + Prisma + Stripe（适配器模式）+ Vercel/Railway
时间约束：2 周内完成 MVP
# Output format（输出格式）
1. 完整的目录结构
2. pnpm-workspace.yaml 配置
3. 初始 Prisma schema（User / Product / Cart / Order 四个模型）
4. CLAUDE.md 文档
5. ESLint + Prettier + Husky 配置
# Tone（语气）
专业、简洁、可直接执行
# Instructions（指令）
- monorepo 结构（pnpm workspace）
- apps/web（Next.js）、packages/db（Prisma schema）、packages/payment（适配器）
- 预置 ESLint + Prettier + Husky
- 写一个 CLAUDE.md 把这些约定固化
# Constraints（约束）
- 所有配置文件必须可直接使用，无需额外修改
- Prisma schema 要包含必要的关系和索引
- CLAUDE.md 要包含项目约定和开发规范
Claude 输出了目录、pnpm-workspace.yaml、初始 Prisma schema（User / Product / Cart / Order 四个模型）和一份精简的 CLAUDE.md。我在它生成的 CLAUDE.md 里又补了"金额单位统一用 cents（避免浮点）"和"所有 API 路由必须经 zod 校验"两条。
第 4 轮：高风险模块单独开 session（BROKE 框架）
下单和支付链路是最容易出问题的地方，单独开 session 慢慢推：
# Background（背景）
下单和支付是电商系统的核心链路，涉及库存扣减、订单创建、支付处理等多个环节，容易出现并发、幂等、事务等问题。
# Role（角色）
你是一位后端架构师，擅长分布式事务和高并发场景的处理。
# Objective（目标）
实现一个可靠的下单接口，确保数据一致性和系统稳定性。
# Key Information（关键信息）
- 需要在事务里做库存扣减 + 订单写入 + 创建 Stripe PaymentIntent
- 任一步失败整个事务回滚
- Stripe 异步 webhook 回来后才把订单状态置为 PAID
- 幂等：同一个 cart_id 重复下单返回同一个 order_id
- PaymentIntent 创建是网络请求，不能放在数据库事务里
# Example（示例）
类似的两阶段提交模式：先在事务里建订单（状态 PENDING_PAYMENT），事务提交后再创建 PaymentIntent
Claude 给的实现里漏了一个细节——PaymentIntent 创建调用是网络请求，放在数据库事务里会拉长事务持续时间。我追问后改成两阶段：先在事务里建订单（状态 PENDING_PAYMENT），事务提交后再创建 PaymentIntent，更新订单的 payment_intent_id 字段。
第 5 轮：上线前自查（CRISPE 框架）
# Context（上下文）
项目即将上线，需要对下单和支付相关代码进行全面审查，确保没有遗漏的安全和稳定性问题。
# Role（角色）
你是一位代码审查专家，擅长发现并发、安全、性能等问题。
# Instructions（指令）
用 code-review Skill 扫一遍下单和支付相关代码，重点检查以下维度。
# Steps（步骤）
1. 检查并发竞态问题（库存扣减、订单创建）
2. 检查金额计算是否正确（避免浮点数精度问题）
3. 检查敏感信息是否泄露到日志
4. 检查 Stripe webhook 是否验签
5. 给出优先级排序的修复清单
# Preferences（偏好）
- 优先标记高风险问题
- 给出具体的修复建议
- 列出修复的优先级
# Example（示例）
常见问题：库存扣减没用 SELECT FOR UPDATE、金额计算用 float、错误日志包含信用卡信息、webhook 没校验签名
Claude 报出 4 个问题：库存扣减没用 SELECT FOR UPDATE（并发下卖超）、运费计算用了 float（要换 decimal）、错误日志里把信用卡 fingerprint 打了出来、webhook 没校验 stripe-signature header。修完后才上线。
两周排期：
- Day 1：选型确认 + 初始化 + CI 跑通
- Day 2–3：商品列表、购物车、订单核心流程
- Day 4：Stripe 支付链路（两阶段提交 + webhook）
- Day 5–6：管理后台 + 数据看板
- Day 7：全量回归 + code-review 扫一遍
- Day 8–13：UI 打磨 + 修小问题
- Day 14：上线
几个经验：
- 时间约束摆最前面，Claude 才会给你"两周能上线"而不是"理论上最好"的方案
- 第一轮方案不用照单全收，质疑两三个选型点能换来更稳的栈
- 高风险模块（支付、下单、权限）单独开 session，给出明确的并发/幂等/审计要求