Cursor实战：用Cursor实现积分商城系统

写在前面

这篇文章聊聊我是怎么用 Cursor 从 0 到 1 落地"积分商城"的。核心就三件事：怎么和 Cursor 配合、怎么把业务模型迭代到靠谱、以及怎么用自查和单测兜底，别让代码"跑得动但扛不住"。

不聊具体框架，示例都是伪代码/DSL，换技术栈也能看明白。

1) 需求预备 & 表设计起步

用 Cursor 写业务，输入质量基本决定输出质量。开工前先把这些准备好：

C端和后台原型图（关键页面/流程截图）
表设计规范（命名、主键、时间字段、唯一键等）
示例表结构（哪怕不完整也行），并说明"请在此基础上完善/修正"。

Prompt 我一般这么写：

diff 复制代码

目标：实现积分商城（用户兑换虚拟/券/实物）
请基于下述规范输出DDL：
- 命名：snake_case；主键bigint自增；必有created_at/updated_at
- 唯一键：幂等关键的字段组合必须有唯一约束
- 示例：user(id, name,...), goods(id,...), ...
- 输出：DDL + 字段解释 + 关键约束说明

2) 表结构迭代：从"余额字段"到"批次FIFO"的纠偏

最容易翻车的其实是"积分"。我踩过这俩坑：

用一个 balance 保存余额，再靠定时任务扣过期 → 过期那一瞬的并发很难精确处理；
用"总发放 - 总消耗"算余额 → 过期后总消耗不变，总发放减少，可用余额可能出现"负数"。

最后是和 Cursor 拉扯了好几轮，边踩坑边纠偏，才落到这套相对靠谱的方案：

采用"批次模型 CoinLot"：每次发放产生一个批次（grant_coins, consumed_coins, expire_time）
余额查询：仅聚合未过期批次；
扣减：严格FIFO（First In First Out，先进先出），优先扣快过期批次；
乐观锁更新，避免并发下超扣。

伪代码：

csharp 复制代码

// 场景：采用"批次模型"管理积分，并按FIFO（先入先出）进行消费分摊
// 目标：保证过期优先消耗、并发安全、不出现超扣

// 数据结构（示意）：每条记录代表一次"发放批次"
struct CoinLot {
  id: number                 // 批次ID（自增，作为排序的第二关键字）
  user_id: number            // 用户ID
  grant_coins: number        // 本批次发放的积分数
  consumed_coins: number     // 本批次已消费的积分数
  expire_time: datetime      // 过期时间（<= now 则视为不可用）
  source_type: string        // 来源类型（月发放、活动等）
  source_biz_id: string      // 来源业务ID（用于发放幂等）
}

// 余额查询（实时计算）：仅聚合未过期且仍有余额的批次
function getAvailableBalance(userId, now) {
  sql = "SELECT SUM(grant_coins - consumed_coins) AS available\n" +
        "FROM coin_lots\n" +
        "WHERE user_id = ? AND expire_time > ?\n" +
        "AND grant_coins > consumed_coins"
  result = database.query(sql, [userId, now])
  return result.available || 0
}

// 消费（FIFO分摊）：严格按 expire_time ASC, id ASC 顺序扣减
function consumeCoinsFIFO(userId, amount, now, bizId) {
  // 0) 快速校验：余额不足直接返回（最终以事务内结果为准）
  if getAvailableBalance(userId, now) < amount { return error("insufficient") }

  // 1) 查询未过期批次并排序（过期时间优先、ID次之，保证稳定顺序）
  lots = database.query(
    "SELECT * FROM coin_lots\n" +
    "WHERE user_id = ? AND expire_time > ?\n" +
    "AND grant_coins > consumed_coins\n" +
    "ORDER BY expire_time ASC, id ASC",
    [userId, now]
  )

  remaining = amount
  begin tx
    // 2) 幂等消费单：建议 (biz_id, user_id) 唯一，重复请求不重复扣
    consume_id = create_or_get_consume_record(userId, amount, bizId)

    // 3) 逐批次分摊（乐观锁避免超扣；失败跳到下一批次）
    for lot in lots {
      if remaining <= 0 { break }
      can_use = min(lot.grant_coins - lot.consumed_coins, remaining)
      if can_use <= 0 { continue }

      // 乐观更新：仅当剩余额度足够时才累加；RowsAffected=0 表示并发被抢走
      rows = database.exec(
        "UPDATE coin_lots SET consumed_coins = consumed_coins + ?\n" +
        "WHERE id = ? AND (grant_coins - consumed_coins) >= ?",
        [can_use, lot.id, can_use]
      )
      if rows > 0 {
        // 分摊明细：用于退款/审计
        insert_consume_alloc(consume_id, lot.id, can_use)
        remaining -= can_use
      }
    }

    // 4) 分摊后仍不足：并发下额度被占用；整体回滚，提示重试
    if remaining > 0 {
      rollback()
      return error("race: insufficient")
    }
  commit

  return success()
}

3) 基于原型驱动的接口设计（DAO/Service/HTTP）

拿着原型喂给 Cursor，更不容易跑偏：

先定好接口风格（命名、分页、错误码、鉴权）
DAO→Service→HTTP 三层接口一次性说清；
分页统一"游标"，别用 offset（漏/重问题多）；
字段能少就少，保留前端真用到的。

伪接口示例（DSL）：

scss 复制代码

service Mall {
  POST /h5/mall/goods/list -> ListGoods(tgid, cursor, limit)
  POST /h5/mall/goods/detail -> GetGoodsDetail(goods_id)
  POST /h5/mall/order/precheck -> PrecheckOrder(goods_id, qty)
  POST /h5/mall/order/create -> CreateOrder(goods_id, qty, role_favorite_id?, address_id?)
  POST /h5/mall/order/list -> ListOrders(cursor, limit)
}

dao MallOrder { create, mark_charged, mark_delivered, mark_failed, list_by_cursor }

dao Coin { ensure_lot, create_consume_fifo, cancel_consume, get_available }

dao LimitCounter { get, incr_if_within_limit, decr }

4) 逐层逐接口落地实现：自查 + 单测消灭隐性 Bug

实战里真会踩的坑（都遇到过）：

限购计数：无记录时"先插入初始计数又加一"，导致重复计数；
发货失败没回滚限购/没退款；
商品详情/预校验/下单自校验重复三份，稍一改动就分叉。

我一般这么干：

每实现一个接口，就让 Cursor 自查：并发/幂等/事务/回滚/边界；
让它补单测：
- 限购：首次无记录 => Incr成功；同事务二次Incr不越界；并发下不超限
- 订单：扣积分成功但发货失败 => 必须回滚限购+退款+标记失败
- Coin：并发消费边界不出现负分摊；取消消费能完整回滚分摊
最后自己再过一遍，重点盯"回滚路径"是否全。

5) 减重复：把三处校验逻辑抽成一个

最初代码里，"详情/预校验/下单"三处校验重复。做法很简单：抽成一个函数，三处共用。

javascript 复制代码

function precheckOrder(user, goodsId, qty, now) -> {...}
// 详情：precheck(qty=1) 返回摘要
// 预校验：precheck(qty=req.qty) 返回完整
// 下单：事务前再 precheck 一次，防绕过

好处很直接：口径统一、只改一处、省心回归。

6) 外部依赖别急着硬接：先留空再逐步绑定

遇到发奖/券/VIP 这类外部系统，别一上来就硬接：

先留 TODO 的"空实现"，保证主流程能跑通；
单测 OK 后，再引 SDK/HTTP 接口逐步接入；
发货用"策略模式"，失败要有补偿（限购回退+退款）。

伪代码：

go 复制代码

// 发货策略路由：按商品类型选择不同策略；外部依赖初期留空实现，避免AI"自作主张"
function deliverGoods(order, goods, user) {
  switch goods.type:
    case "virtual_prize":
      // TODO: 与游戏发奖系统对接；要求幂等（同一orderId重复调用不重复发）
      // 入参建议包含：userId/serverId/itemId/quantity/orderNo/source
      return deliverVirtualPrize(order, goods, user)

    case "coupon":
      // TODO: 与券系统对接；失败要返回明确错误，并保持可重试
      // 入参建议包含：couponType/userId/quantity/orderNo/source
      return deliverCoupon(order, goods, user)

    case "physical":
      // 线下发货：写入发货队列，记录地址与联系人信息
      return enqueuePhysicalDelivery(order)

    default:
      // 默认无操作，或返回可识别的业务错误码
      return error("unsupported_goods_type")
}

Prompt 写法和检查清单示例

表设计阶段
- 规范+示例DDL先给清楚；
- 重点说明"批次+FIFO，余额实时聚合"；
- 唯一键/幂等键必须点名。
- 自己再按清单过一遍：

css 复制代码

[ ] Coin FIFO扣减是否严格有序且具备乐观锁
[ ] 订单失败是否回滚：限购、退款、状态
[ ] 限购Incr是否不存在时不会重复+1
[ ] 游标分页是否稳定且可回溯
[ ] 公共校验是否被三个入口一致复用

接口设计阶段
- 分页统一游标；状态码与错误结构统一；
- DAO/Service/HTTP 三层一次性对齐。
实现阶段
- 每个接口写完都自查：幂等/并发/事务/回滚/边界；
- 覆盖边界条件的单测必须补上；
- 最后再用上面那份清单过一遍。

重点共识（一句话版）

别幻想一步到位：清晰输入 + 多轮拉扯 + 人工把关 + 该手改就手改，才是正道。

实操建议（可落地）

先把输入讲清楚再让它动手：原型图/字段规范/幂等与约束先说清，Cursor 才不乱跑。
一轮只啃一个点：并发/幂等/回滚/边界/性能，逐个攻破；每轮都让它"自查+补测"。
该手改就手改：改字段名、删冗余、修一两行 SQL/条件、提取重复校验，自己动手最快最稳。
真要大改：先给目标结构/接口，再让 Cursor 重构，少走弯路。
人工把关别省：幂等键闭环？排序稳不稳（FIFO/时间窗口）？事务边界合不合理？补偿到不到位？分页稳不稳？
自测红线：
- 并发下扣积分/限购不超限；
- 发货失败回滚限购+退款；
- 重复请求不重复扣；
- 游标翻页不漏不重；
- 跨月/过期边界不卡壳。

和 Cursor 合作的正确姿势

小步快跑，边跑边验：一次只改一个风险点，改完立刻看效果。
固定话术别省：按"问题→方案→变更点→单测→影响面"输出，少走来回沟通的弯路。
外部依赖先画框：发奖/券/VIP 先 TODO，等接 SDK 再填坑，别让它自由发挥。

怎么更高效

大改就说清楚、给骨架；小改就直接上手。生成样板/重构结构用 Prompt，命名/去重复/小修小补直接动刀。
但凡动到一致性（事务/幂等/并发/回滚），都走"多轮对话+单测验证"，再合入，别心急。

结语

用 Cursor 落地业务，不是"把代码全交给 AI"，而是用高质量输入去"驱动它迭代"。总结三点：

前置准备清楚（原型+规范+示例）；
业务模型扎实（积分批次+FIFO+幂等）；
自查+单测+人工Review 把关，问题前移，安心上线。

做到这些，Cursor 才能从"写点代码的助手"升级成"能托付的交付伙伴"。