Taro + Cursor：小程序AI开发实战，从需求到上线全记录
去年年底我接了一个海外商超小程序的需求，要求4周内上线，需要做商品浏览、购物车、订单、多语言切换这几个核心模块。
按照以前的节奏，一个人做这个项目，4周很紧张。
但最后实际用了18天。
这篇文章把整个过程拆开来说，不讲理论，只说我实际怎么做的。
项目基本信息
先说清楚项目情况：
- 框架：Taro 3.x + React
- UI组件：TDesign Mobile
- 状态管理：Zustand
- 后端：Node.js，接口已经由后端同事写好
- 目标平台：微信小程序 + H5
我一个人做前端，后端有一个同事配合。
第一步：搭项目脚手架（Cursor帮我省了半天）
以前搭一个新项目，从初始化到能正常跑起来，怎么也要大半天：安装依赖、配置路由、配置请求封装、配置状态管理、对接UI库……每一步都要查文档、踩坑。
这次我直接在Cursor里说：
"我要搭一个Taro 3 + React的小程序项目，UI用TDesign Mobile，状态管理用Zustand，需要配置请求封装（统一处理token和错误码），配置多语言（i18n），配置路径别名。帮我把这些全部配好，给我具体的配置代码。"
Cursor给了我一套完整的配置，包括：
app.config.ts路由配置src/utils/request.ts请求封装src/utils/i18n.ts多语言初始化tsconfig.json路径别名package.json所需依赖清单
不是100%能直接用，有几处需要根据自己项目调整，但框架是完整的，我只花了1.5小时就把脚手架跑起来了。
以前这个过程要大半天。
第二步：搭建项目上下文文档
脚手架搭好之后，我做了一件很重要的事：写cursor-context.md。
这个文件放在项目根目录，内容是给Cursor看的，不是给人看的。
# 项目：海外商超小程序
## 技术栈
- Taro 3.x + React
- TDesign Mobile（组件库）
- Zustand（状态管理）
- TypeScript
## 目录规范
- src/pages/ 页面
- src/components/ 公共组件（业务无关）
- src/features/ 功能模块（业务相关，按业务划分子目录）
- src/store/ Zustand store
- src/api/ 接口定义
- src/utils/ 工具函数
- src/locales/ 多语言文件（zh.json / en.json）
- src/assets/ 静态资源
## 命名规范
- 页面组件：PascalCase，文件名与组件名一致
- 普通函数：camelCase
- API函数：以"api"开头，如 apiGetProductList
- Store：以"use"开头，如 useCartStore
## 接口规范
统一响应格式：{ code: number, data: any, message: string }
- 200：成功
- 401：未登录，跳转到登录页
- 403：无权限
- 500：服务端错误，Toast提示
## 已有公共组件
- components/NavBar 自定义导航栏（带返回按钮、标题、右侧操作区）
- components/Empty 空状态（支持图标、文字、操作按钮）
- components/Loading 全屏loading
- components/Toast 轻提示（封装了TDesign的Toast）
## 多语言
用 i18next，调用方式：import { t } from '@/utils/i18n'
用法：t('key.name')
中英文key保持一致，文件在 src/locales/
## 代码风格
- 函数式组件，不用class
- 异步操作用 async/await，不用 .then 链
- 样式用TDesign组件自带的props，特殊情况才写CSS
- 条件渲染用三元，列表用.map()
- 重要逻辑必须加注释，说明"为什么这样做"而不是"这段代码做了什么"
这个文件大约花了我20分钟写好。
从第二天开始，每次我打开新的Cursor Chat，第一件事就是把这个文件的内容复制进去。它知道了我的项目全貌，给出的代码从一开始就符合我的规范，不需要反复纠正。
第三步：模块化推进，每个模块的Cursor用法
项目拆成了5个模块：登录、商品列表、商品详情、购物车、订单。
每个模块我都是这样推进的：
1. 先给Cursor看接口文档
把后端给的接口文档粘进去，让Cursor整理成TypeScript的类型定义和API函数：
这是接口文档中商品相关的接口，帮我：
1. 定义TypeScript类型（放在 src/types/product.ts）
2. 写API函数（放在 src/api/product.ts），用我项目的request封装
[粘贴接口文档]
这步Cursor做得很准，类型定义和API函数基本能直接用。
2. 说清楚页面需求，让Cursor先给设计思路
我不会直接说"帮我写登录页面"，而是这样：
我要做登录页面，需求如下：
- 手机号 + 验证码登录
- 验证码60秒倒计时
- 登录成功后保存token到Zustand store，并跳转首页
- 国际化支持（中英文切换）
先不写代码，告诉我你的设计思路，等我确认后再写。
Cursor给出设计思路之后，我看一眼有没有方向问题，确认后再让它写代码。
这样做多了一个确认环节，但后面改的时间少了很多。
3. 拆分写，不要一次性让它把整个页面写完
我会把一个页面拆成几个部分：
先写登录表单部分（手机号输入框 + 验证码输入框 + 发送验证码按钮）
表单验证的逻辑先不写，我确认样式没问题后再加
这样每次Cursor输出的代码量小，我review起来快，出问题也容易定位。
第四步：遇到复杂场景怎么处理
有几个场景确实超出了Cursor的舒适区，我踩了一些坑。
场景1：Taro特有的API
Cursor有时候会写出来一些看起来像React Native或者Web的写法，在Taro里跑不起来。
比如用window.location.href跳转，或者直接操作DOM。
遇到这种情况，我会说：
这段代码里用了[具体的Web API]，在Taro里需要换成[对应的Taro API]。
帮我改一下，同时确保iOS和Android都能正常跑。
有时候Cursor自己也不确定，我就去查Taro官方文档，确认正确的API之后直接告诉它，让它改。
场景2：TDesign组件的特殊用法
TDesign Mobile的某些组件用法有点特殊，Cursor偶尔会写错props。
这种情况我直接把TDesign的组件文档链接丢给它，或者把关键的props描述粘进去，让它参照文档重写。
场景3：Zustand store的复杂逻辑
购物车的状态逻辑比较复杂：加购、修改数量、删除、全选、计算总价……这些逻辑相互关联。
我的做法是先自己理清楚逻辑，画了个简单的流程图，然后用文字描述给Cursor：
购物车store需要处理以下逻辑：
- addItem(product, quantity)：如果商品已在购物车，增加数量；如果没有，新增一条
- updateQuantity(productId, quantity)：更新数量，quantity为0时自动删除
- toggleSelect(productId)：切换单个商品的选中状态
- toggleSelectAll()：全选/全不选
- selectedItems：计算属性，返回所有选中的商品
- totalPrice：计算属性，返回选中商品的总价
帮我写这个store。
这样Cursor写出来的逻辑基本正确，我只需要补充一些边界处理。
第五步：调试和上线
调试阶段Cursor帮我解决了几个比较棘手的bug。
有一个bug是：商品图片在某些情况下不显示，换成占位图。
我把Image组件的代码和问题描述丢给Cursor，它给出了三个可能原因：
- 图片URL有特殊字符需要encode
- Taro的Image组件默认mode不适合某些图片比例
- 跨域问题（H5模式）
第2个是真正的原因。我在真机上测试的时候发现有些长图被裁掉了，换了mode="widthFix"就好了。
Cursor没有直接告诉我答案，但列出的排查方向帮我省了不少时间。
最终结果
18天上线，具体时间分布大概是这样：
| 模块 | 预估时间 | 实际时间 |
|---|---|---|
| 脚手架+基础配置 | 1.5天 | 0.5天 |
| 登录模块 | 2天 | 1天 |
| 商品列表+详情 | 5天 | 3天 |
| 购物车 | 3天 | 2天 |
| 订单模块 | 4天 | 3.5天 |
| 多语言适配 | 2天 | 1.5天 |
| 调试+上线 | 3天 | 2.5天 |
| 合计 | 20.5天 | 14天 |
有4天时间用来修改需求（客户中途改了两次）。
几点感受
Cursor最好使的地方是模板化的代码：表单、列表、详情页、接口对接、类型定义……这些重复性的代码让Cursor来写，速度快、质量稳。
业务逻辑复杂的地方，还是得自己把逻辑想清楚，再让Cursor写。把一个说不清楚的需求丢给Cursor，得到的代码也会很乱。
用了这个项目之后，我的结论是：Cursor帮你省的是"体力活"，不是"脑力活"。
脑力还是你的，体力交给它。
有问题评论区聊，也欢迎分享你用Taro + AI开发的经验。
