Claude Code 实战：从零开发带支付的电商小程序全流程

能把一个带支付的电商小程序从零做到能上线这过程放在几年前怎么也得折腾一两个月。这次我全程用 Claude Code 当结对搭档从初始化项目到云开发、购物车、订单、支付回调、审核发布完整走了一遍全流程。这篇文章不是讲 API 的而是记录我和 Claude Code 一起“搭积木”的真实过程哪些让它直接写哪些必须自己把关哪些坑它提前帮我避开了还有哪些是它根本搞不定、只能靠我去找客服解决的。如果你也想用 AI 编程助手做小程序或者正准备搞一个电商类的小程序入门这篇应该能帮你少走不少弯路。1. 动手之前想清楚要做什么再让 AI 写代码1.1 先圈定功能边界否则 AI 也救不了你很多人一上来就跟 Claude Code 说“帮我写一个电商小程序”结果生成出来的东西看着像实际哪哪都不通。这不怪 AI怪需求本身就模糊。我这次给自己定了一个明确的 MVP 范围商品浏览、关键词搜索、购物车、下单、微信支付、订单列表、收货地址管理外加一个简单的后台数据展示。砍掉的东西包括优惠券、秒杀、会员积分、售后流程、物流跟踪这些在项目第一个版本里都属于“锦上添花”但它们会占用至少三分之一的开发量而且涉及复杂的业务规则AI 生成后你还要花大量时间验证逻辑。一个能跑通核心闭环的 MVP比一个模块齐全但到处是 bug 的半成品有价值得多。这个范围确定后我把它直接写进了项目的需求文档然后让 Claude Code 基于这份文档拆任务。它给出的拆解是数据库设计、云函数接口层、前端页面、支付联调、审核上架。和我预想的顺序基本一致但它在第二项“云函数接口层”前面偷偷加了一条“建立公共响应格式和错误码规范”这个提醒非常关键后面所有页面拿数据都依赖这一层如果每个云函数返回结构不一样前端要写一堆兼容逻辑。1.2 技术选型原生小程序加云开发为什么我不自建后端选型这件事Claude Code 帮不了你拍板但它能帮你分析不同方案的利弊。我在它面前列了三个候选原生小程序加自建 Node 后端、原生小程序加云开发、uni-app 加云开发。最终选了“原生小程序 云开发”原因有几个。第一我不需要买服务器、配域名、搞备案云开发自带数据库、存储、云函数按量付费个人开发者的成本可以压到很低。第二登录鉴权在云开发里有天然优势云函数里直接通过cloud.getWXContext()拿到用户的 openid不需要我写一套 session 管理。第三支付接入比传统模式简单云调用封装好了统一下单和支付回调对新手非常友好。自建后端当然也可以但那一套涉及 HTTPS 证书、反向代理、服务器安全组、数据库备份这些和电商业务本身没有关系却会消耗大量时间。Claude Code 再强也没法替你处理服务器宕机。1.3 Claude Code 在这个项目里到底承担什么角色Claude Code 不是替代开发者的它更像一个随时在线的结对程序员能帮你完成五类工作生成初版代码根据你描述的页面功能直接生成完整页面和云函数。解释报错把控制台的报错信息丢给它它通常能定位到具体原因并且会给出修改建议。重构优化告诉它“这个云函数超过了 100 行拆一下”它能给你一个合理的拆分方案。审查隐患让它从并发、权限、资源泄漏的角度检查代码它的经验比多数初级开发者丰富。写注释和文档生成接口说明、数据字典省掉我最讨厌的写文档环节。但有一个底线要记住它生成的每一行代码你都要能看懂看不懂的地方必须让它解释。否则上线后出问题你连排查的入口都找不到。我后面就踩过这个坑一会儿细说。2. 环境准备与项目初始化2.1 从零把环境跑通这几步最容易卡住环境准备没有太多技术含量但步骤必须踩对。我按顺序来第一步安装 Node.js版本必须 18 以上否则 Claude Code 跑不起来。第二步安装 Claude Code 命令行工具在项目目录里执行初始化然后关联我的账号。这一步很关键它会生成一个配置文件后续所有会话都在这个项目的上下文里进行。第三步去小程序平台注册账号拿到 AppID。这里有个容易踩的坑个人主体的小程序在电商类目上有诸多限制尤其是支付。如果你做的是虚拟商品、充值类个人主体基本没戏必须是企业主体。我这里做的是实体商品售卖用个人主体在开发阶段没问题但真要上线还是得落到企业主体资质上。第四步下载小程序官方开发者工具用 AppID 导入一个空白项目。目录结构和 Claude Code 的会话就绑定在这个目录里两边看到的是同一份代码。整套流程我用了大约四十分钟其中一半时间耗在账号资质确认上。如果你是企业开发者务必确认营业执照的经营范围包含“电子商务”或“零售”相关类目否则后面审核会让你补充资质。2.2 用 Claude Code 生成项目骨架别让它一上来就写页面项目骨架这件事我的经验是不要直接说“生成所有页面”而要让 Claude Code 先输出目录结构和路由配置。因为小程序页面之间互相引用如果它一次性生成十几个文件你很难检查逻辑关联。我当时的做法是先把需求文档粘贴给它要求它输出app.json的路由配置、pages目录下每个页面的职责说明、云函数目录结构并且要求它用表格形式输出页面与云函数的对应关系。它给出来的结构非常清晰首页、分类页、商品列表页、商品详情页、购物车页、结算页、订单列表页、订单详情页、地址列表页、地址编辑页、个人中心页加上六个云函数商品列表、商品详情、提交订单、获取支付参数、订单列表、地址管理。有了这个结构后面每个页面单独开发。我不会让它一次性写多个页面而是一次只写一个写完我检查完再接下一个这样出现问题能立刻定位。2.3 云开发环境初始化和数据集合设计在写任何业务代码之前先在开发者工具里开通云开发环境。这里的环境 ID 会写进很多代码里建议用env-prod或env-dev这种明确命名的 ID别用默认那串随机字符否则部署时容易搞混环境。数据库集合我提前建了四个goods商品表、cart购物车表、orders订单表、addresses收货地址表。集合的权限设置是个大坑我一开始把goods设置成“所有用户可读”订单表误设成了“所有用户可读”后来才发现用户的订单会全部暴露这个必须改成“仅创建者可读写”。Claude Code 帮我生成了一份数据字典文档里面规定了每个集合的字段。这里有个原则字段命名要全局统一比如价格字段一律叫price单位是分不叫money也不叫fee。电商项目里价格单位混乱是极大的隐患。订单金额如果前端算一份、后端算一份出来后对不上账查错能查到怀疑人生。最后我定了一个铁律所有涉及金额的计算一律在后端云函数里完成前端只负责展示和收集数据。3. 核心业务代码是怎么一步步写出来的3.1 商品模块从静态假数据到云数据库商品列表页是第一个动手的页面。我没有上来就接云数据库而是让 Claude Code 先基于本地数组生成一版静态页面把布局和交互调通后再把数据源切换到云函数。这样做的原因是静态数据下调试视觉和交互逻辑速度快而且不污染数据库。静态版本做出来后我让它编写第一个云函数getGoodsList。核心逻辑是这样的const cloud require(wx-server-sdk) cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db cloud.database() exports.main async (event, context) { const { page 1, pageSize 10, keyword , category } event const where { status: 1 } const reg db.RegExp({ regexp: keyword, options: i }) if (keyword) where.title reg if (category) where.category category const res await db.collection(goods) .where(where) .skip((page - 1) * pageSize) .limit(pageSize) .orderBy(sales, desc) .get() return { code: 0, data: { list: res.data, hasMore: res.data.length pageSize } } }注意几个细节。cloud.DYNAMIC_CURRENT_ENV会自动匹配当前云环境避免把环境 ID 写死。模糊搜索用的db.RegExp在数据量大的时候性能一般但 MVP 阶段完全够用。hasMore字段用来判断是否还有下一页前端用它来控制“加载更多”的显示避免 v-for 无限渲染。前端页面让 Claude Code 生成时我要求它必须用“卡片式布局 双列瀑布流”这是现在电商 App 的主流样式。它生成的 WXML 里用了block wx:for循环每个商品卡片包含图片、标题、价格、销量。图片用的是云存储的临时链接这里有个隐藏问题小程序里的图片域名必须在小程序后台配置 downloadFile 合法域名否则真机上图片全是白屏。我第一次就是在开发者工具里能看到图一上真机全挂了排查了半天。3.2 购物车与订单状态流转逻辑要理清楚购物车我一开始想省事直接存本地wx.setStorageSync。Claude Code 提醒了一句本地存储的方案在小程序上有风险用户清缓存、换设备都会丢数据。最后改成云数据库存储用户维度通过 openid 隔离每个用户的购物车数据在cart集合里按 openid 查询。加购逻辑的核心代码async function addToCart(openid, goodsId, count) { const cartCol db.collection(cart) const existing await cartCol.where({ openid, goodsId }).get() if (existing.data.length 0) { return cartCol.doc(existing.data[0]._id).update({ data: { count: _.inc(count) } }) } return cartCol.add({ data: { openid, goodsId, count, selected: true, createdAt: Date.now() } }) }这里用到了_.inc(count)做增量更新不需要先查出旧数量再写回。但真实场景下有一个并发问题同一时间同一个用户疯狂点加购容易造成数据不一致。云开发有事务能力但购物车的并发量不至于把数据写坏我采用了“以最后一次写入为准”的策略避免过度设计。订单模块则是整个项目里逻辑最重的部分。我一开始的设想很简单提交订单时生成一条订单记录然后跳转支付。Claude Code 在审查代码时提出一个关键问题如果用户先加入购物车再下单但提交订单时商品被其他人买完了库存怎么办这个提醒非常到位。我把库存扣减逻辑设计成了两段提交订单时先预扣库存支付失败或超时再回滚库存。这个逻辑用云开发的runTransaction事务来实现await db.runTransaction(async transaction { const goodsRes await transaction.collection(goods).doc(goodsId).get() if (goodsRes.data.stock count) { throw new Error(库存不足) } await transaction.collection(goods).doc(goodsId).update({ data: { stock: _.inc(-count), sales: _.inc(count) } }) await transaction.collection(orders).add({ data: orderData }) })这个事务保证了“库存足够才扣减扣减和创建订单同时成功或同时失败”。注意云开发事务的_.inc不能用指令要直接传值。这是我被代码注释坑过的地方Claude Code 生成的注释里写的是_.inc(-count)实际放进事务里执行会报错得直接用stock - count或者写成动态对象。这类细节靠人工 review 才能发现。3.3 用户登录、收货地址管理登录这块云开发几乎帮我把路铺好了。前端调cloud.getWXContext()只能在云函数里用拿到的是用户的 openid不需要前端传任何参数天然防伪造。我让 Claude Code 封装了一个getOpenid云函数前端在启动时调用一次缓存到全局变量里后续所有云函数请求都带上 openid 一起传。这里有个隐私问题要注意openid 属于用户敏感信息不能直接写到前端缓存里当订单字段更不能打印到日志里。我在数据库里建了一个users集合第一次登录时自动建档后续用_id关联购物车和订单而不是反复用 openid 做查询。收货地址管理相对简单就是一个标准的 CRUD 功能包含地址列表、新增、编辑、删除、设置默认地址。Claude Code 生成这个模块只花了十分钟但地址表单的小程序组件和弹窗交互是我手动调的因为 AI 生成的表单在真机上的日期选择器和省市区联动组件版本兼容性有问题这块还涉及第三方组件库的依赖引入我自己处理更可控。3.4 支付流程最折腾的一环支付是电商小程序里最绕不开的环节也是坑最多的。云开发的支付流程是后端云函数调用cloud.cloudPay.unifiedOrder生成支付参数返回给前端前端用wx.requestPayment拉起支付。实现代码本身不长const res await cloud.cloudPay.unifiedOrder({ body: 商品购买, outTradeNo: orderId, spbillCreateIp: 127.0.0.1, subMchId: 商户号, totalFee: amount, envId: 你的环境ID, functionName: payCallback })但这里卡了我整整半天。卡点不是代码而是资质。个人主体的小程序微信支付只能走“跳转外部浏览器”或“小程序内云开发支付”这类受限制的方式且需要商户号和对应的支付资质。我最终是找了一个有企业主体资质的朋友帮忙申请的商户号才把整个流程跑通。如果你是自己练手没有商户号建议直接走“开发版模拟支付”代码逻辑先写完整模拟支付通过后再替换成真实商户参数。支付回调是另一个容易忽略的点。云开发支付成功后会自动调用你指定的functionName这个云函数负责更新订单状态为“已支付”。但回调函数和前端是不同的执行路径回调和前端展示之间存在时间差。我在回调函数里加了一个字段paidAt前端订单详情页通过轮询来刷新支付状态防止用户支付成功但页面还停留在“待支付”的状态。4. 和 Claude Code 协作的高频套路4.1 怎么写 promptAI 才知道你要什么和 Claude Code 共事一段时间后我发现 prompt 的质量直接决定产出质量。写得模糊它给你的代码也是“通用风格”和你的项目气质南辕北辙写清楚它能在上下文里精准调用前面定义过的变量和接口。我总结了一套好用的模板你是资深小程序开发者。当前项目使用原生小程序 云开发。 请实现 [页面/函数] [功能描述]要求 1. 使用 [具体交互方式]例如点击加入购物车后显示 Toast 2. 数据来自云函数 [函数名]返回格式为 { code, data } 3. 金额单位是分展示时需要格式化为元 4. 只输出 [文件清单]并标注关键逻辑的注释。这套模板的核心思路是给足上下文、定义好约束、明确交付物。尤其要把项目里已经存在的函数名和字段名贴给它避免它凭空捏造接口。Claude Code 的记忆力比你想象的强但它不会读心术关键约定你不说它就不知道。4.2 让 AI 跑通报错贴全错误信息而不是只贴一句话遇到报错最忌讳只发“报错了”三个字。正确做法是把报错堆栈完整复制给它同时附上相关代码片段。有一次我在真机上遇到一个奇特的 bug商品列表在 iOS 上能显示在安卓上白屏。报错信息只有一行TypeError: Cannot read property map of undefined。我把这段报错和对应云函数的返回结构一起丢给 Claude Code它立刻发现问题是云函数返回的list字段在某种情况下是undefined前端list.map就崩了。原因是有一次请求因为搜索关键词为空走到了另一个分支没有返回list字段。它的修复建议是云函数里统一兜底list: res.data || []前端再加一个空数组默认值。这个双重保险后来成了项目的标准写法。所以我的经验是把错误丢给 AI 之前先自己看一眼错误信息里最关键的几个词比如是“undefined”“network”“permission”还是“timeout”你能说出错误的大致类型AI 定位问题的速度快很多。4.3 让 Claude Code 做代码审查专挑它的刺Claude Code 的“自审能力”是不错的。每次一个页面写完我会输入同一句话“请从并发安全、权限控制、内存泄漏、重复请求、异常捕获五个角度检查这段代码列出所有问题并按严重程度排序。”它真的能挑出代码里的隐患。有次商品详情页的加购逻辑里它发现前面提到的_.inc在事务里使用不正确。还有一次它指出购物车批量删除接口在循环里逐个doc.remove()在集合数据量大的情况下会产生大量读操作上限开销建议改用where条件批量删除明显更严谨。但它也犯错。有一次它建议我用一种“新的组件库”来实现地址联动选择结果那个组件库并不存在只是它根据记忆拼凑出来的名字。所以务必自己把关库的真实性AI 幻觉在虚构函数名和第三方库这件事上非常常见。我的处理方式是对新引入的依赖一律先查一遍官方文档再决定是否采用。5. 测试、踩坑与上线审核的突发情况5.1 本地模拟器正常真机会有一堆“隐藏问题”小程序开发里最经典的灾难就是本地模拟器跑得好好的一到真机测试就出各种问题。我在这次开发里遇到的表现有图片不显示域名白名单问题、日期选择器无法弹出组件版本问题、安卓支付后无法返回原页面支付拉起方式问题。真机调试必须在开发阶段就做不要等到最后发布前再做。我每次完成一个页面都会在真机上跑一遍确保核心交互正常。真机调试时开发者工具里打开“真机调试”模式这里有个坑云开发环境在真机和开发者工具里是同一个环境但如果你在开发者工具里登录的是 A 账号真机上是 B 账号查询到的数据就会不同。最好统一开发环境和测试账号。5.2 常见问题速查表照着处理能省一小时整个开发过程中我整理了一张问题速查表遇到同类问题直接对照处理现象根本原因处理方式图片真机不显示图片域名未配置到合法域名后台配置 downloadFile 合法域名云函数报context.getWXContext不存在忘记初始化云开发cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV })数据库查询无数据集合权限设置过严检查“所有用户可读/仅创建者可读写”配置支付成功后订单状态不更新支付回调云函数未成功执行查看云函数日志确认回调函数名与配置一致购物车数据错乱循环复用组件导致的脏数据wx:key唯一标识必须加上分页加载重复免密登录状态变化导致重复请求加loading标志位阻止并发请求安卓输入框被键盘顶起页面配置问题在 app.json 对应页面设置disableScroll或键盘模式这里面分页加载重复是最隐蔽的。用户快速滑动到底部时多个“加载更多”请求同时发出第 2 页数据被请求了三次。Claude Code 给的方案是加一个loading标志位if (this.data.loading) return this.setData({ loading: true }) // 请求回来后 this.setData({ loading: false })这个细节听起来简单但实际开发中很多人会漏掉数据就出现重复了。5.3 审核发布以及电商类小程序必须提前准备的资质材料上线前的审核是很多个人开发者的拦路虎。电商类小程序审核会卡在几个点上类目资质、支付权限、用户隐私保护协议。不同平台审核要求有差异但核心素材是共通的。我这里强调一下必须提前准备的东西企业营业执照必须包含电商或零售类经营范围微信支付商户号申请时需要提供法人身份证、银行账户、业务场景证明隐私保护指引在小程序后台填写需要明确说明收集哪些用户信息类目审核材料不同类目规划对应的资质比如食品需要食品经营许可证我第一次提交审核被拒了两次。第一次是因为地址管理页面有隐私协议弹窗但我没有在平台后台配置对应的隐私接口声明。第二次是因为商品详情页放了“联系客服”的按钮但没有实际可用的客服系统。用 Claude Code 可以帮你生成一份合规的自查清单但最终的资质材料任何 AI 都无法替你搞定只能准备好真实的证件和手续跑审核流程。最后再分享一个小经验我这次最深的体会是Claude Code 能极大提升写代码的速度但它取代不了你作为开发者的判断力。它不懂你的业务约束不懂审核合规也不懂用户的真实使用场景。所有关键决策比如金额单位、库存扣减时机、支付回调的幂等性都需要你自己懂原理之后去验证。我的做法是把它当成一个“超快的帮手”生成代码后花时间看一遍逻辑把不懂的地方当场问它让每个页面都变成自己的东西。做完这个 MVP 之后我还列了一个扩展清单打算后续逐步加进来优惠券系统、积分商城、订单售后流程、管理后台的数据看板。每一个都可以基于现有的集合结构和云函数继续扩展如果你也想拿这个项目当跳板建议从订单售后开始做因为它的逻辑扩展性最强也最能体现一个开发者对复杂状态的管理能力。