企业官网建设流程全解析

手写 vs Cursor vs Copilot，我拿同一个需求跑了三遍

手写4小时3个Bug，Cursor 1.5小时写完但要修2小时，Copilot中规中矩

一、三组数据

同一个需求：优惠券发放与核销模块。包含创建优惠券、用户领取、使用核销、过期失效四个功能，涉及并发控制、状态流转、时间处理、条件校验。

我分别用三种方式实现了一遍，记录数据如下：

手写最慢但最稳。Cursor写得最快但收尾最累。Copilot介于两者之间，没啥惊喜也没什么大坑。

二、需求长什么样

// 核心接口interfaceCoupon{id:stringname:stringtype:'discount'|'cash'value:number// 折扣百分比或现金金额minAmount:number// 使用门槛totalLimit:number// 发放总量perUserLimit:number// 每人限领startTime:Date endTime:Date status:'draft'|'active'|'expired'|'depleted'}// 用户领取functionclaimCoupon(userId:string,couponId:string):Promise<CouponRecord>// 使用核销functionuseCoupon(userId:string,couponRecordId:string,orderAmount:number):Promise<OrderDiscount>

需求就这些，不算复杂但也不白给——有并发风险、有状态流转、有时间边界，正好能试出AI的水平。

三、手写版本：慢，但有数

4个小时写完，出了3个Bug，都是自己的问题：

// Bug 1：状态流转漏了中间状态// 优惠券核销直接从 'active' 跳到了 'used'awaitcouponRecord.update({status:'used'})// 漏了 'pending' 状态，如果核销过程中支付失败，记录就永远卡在 'used' 了// Bug 2：边界条件漏了if(orderAmount>=coupon.minAmount){// 算折扣}// 只判断了大于等于，没判断 coupon.minAmount 为 0 的情况（平台券）// Bug 3：并发计数// 用数据库字段累加，没加乐观锁awaitcoupon.increment('claimedCount')// 两个请求同时进来，claimedCount 从 10 变成 12 而不是 11

修Bug花了半小时。代码虽然慢，但每一行都是自己推过的，修起来快，方向明确。

四、Cursor版本：写得快，修得慢

Cursor Composer模式，喂了需求文档和接口定义，15分钟生成全部代码。1.5小时内完成了初版交付，速度是手写的近3倍。

但打开代码一看，表面光鲜，底下全是坑。

坑一：并发处理写了等于没写

// Cursor写的领取逻辑asyncfunctionclaimCoupon(userId:string,couponId:string){constcoupon=awaitCoupon.findByPk(couponId)// 检查总量if(coupon.claimedCount>=coupon.totalLimit){thrownewError('已领完')}// 检查个人限领constuserClaims=awaitCouponRecord.count({where:{userId,couponId}})if(userClaims>=coupon.perUserLimit){thrownewError('已达个人领取上限')}// 创建领取记录awaitCouponRecord.create({userId,couponId})awaitcoupon.increment('claimedCount')}

逻辑没毛病，单线程跑全对。但两个用户同时领最后一张券时：

用户A：查询claimedCount → 10，总量10 → 未超，进入下一步 用户B：查询claimedCount → 10，总量10 → 未超，进入下一步 用户A：创建记录 → 成功，claimedCount → 11 用户B：创建记录 → 成功，claimedCount → 12 总量10，发出去12张，超发。

我让Cursor修这个并发问题，它给出的方案是加Redis分布式锁，然后又把Redis配置写成了硬编码。修了三次才修对，每次修完都引入一个新问题。

坑二：any类型遍地走

// Cursor生成的类型asyncfunctioncalculateDiscount(params:any):Promise<any>{// ...}

问它为什么不写类型，回答说"根据上下文自动推断"。实际跑起来之后，params.orderAmount是字符串还是数字全靠运气。为了修类型问题又补了40行interface定义。

坑三：乐观锁加了但是没锁住

Cursor自己发现并发问题后，加了个乐观锁：

awaitCoupon.update({claimedCount:sequelize.literal('claimedCount + 1')},{where:{id:couponId,claimedCount:coupon.claimedCount// 乐观锁条件}})

这个where: { claimedCount: coupon.claimedCount }在并发下确实能防止超发。问题在于，它只给更新加了锁，没给查询加锁——两个线程依然可以同时读到claimedCount = 10，然后同时进入更新流程。

第一个线程更新成功（10→11），第二个线程更新时发现claimedCount已经不是10了，更新失败抛出异常。用户B拿到一个"领取失败请重试"的错误，实际上优惠券已经发完了。

用户体验很差，但起码没超发。修了一个bug，又暴露了另一个问题——异常处理吞掉了具体信息。

坑四：异常捕获吞信息

try{awaitclaimCoupon(userId,couponId)}catch(error){// 直接返回 '领取失败，请稍后重试'thrownewError('领取失败，请稍后重试')}

真正的错误原因是"优惠券已领完"，被吞成了"请稍后重试"。用户反复重试反复失败，客服电话被打爆。

坑五：日期比较写反了方向

// 检查优惠券是否过期if(coupon.endTime<newDate()){thrownewError('优惠券已过期')}

endTime < new Date()意味着"结束时间比当前时间早"才过期，逻辑没问题。但同一段代码里另一处：

if(newDate()>coupon.startTime){// 优惠券还未开始thrownewError('优惠券活动未开始')}

这里应该用<，写成了>。优惠券明明是明天开始，今天用户就能领。测试环境没测这个边界因为测试数据的时间都是当天的，上线第二天才开始陆续有人反馈。

修复这5个AI引入的Bug用了2小时。加上编码的1.5小时，总共3.5小时——跟Copilot和手写的总耗时一样了。写得快但修得慢，总时间没省。

五、Copilot版本：中规中矩

Copilot不能一次性生成整个模块，我是这样用的：

1. 先写接口定义和类型声明（Copilot补全结构体）
2. 再写业务逻辑函数（Copilot补全函数体）
3. 遇到不会的语法问Copilot Chat

3个小时写完，出的4个Bug里2个是AI引入的。

Bug一：类型定义不完整

// Copilot补全的类型interfaceCoupon{id:stringname:stringvalue:number// 漏了 type 字段minAmount:number}

type字段漏了，导致后面判断优惠券类型的代码全用any顶着。

Bug二：日期格式化时区偏差

// Copilot写的过期检查constnow=newDate()constend=newDate(coupon.endTime)if(end.getTime()<now.getTime()){// 过期}

看起来没问题，实际跑的时侯个别用户反馈"优惠券提前过期了"。排查发现，某些场景下coupon.endTime存的是UTC时间，new Date()取的是本地时区，东八区用户看到优惠券提前8小时过期。

Copilot不知道项目里时间统一用UTC还是北京时间，也不问，直接写了最通用的写法。

剩下的2个Bug是手写逻辑遗漏，和手写版本犯的错误类似，修起来也快。整体体验就是：它不会给你整出大乱子，但也别指望它替你考虑周全。

六、为什么Cursor的Bug更多？

Cursor的Composer模式是"一次性生成整个模块"，Copilot是"逐行补全 + 单函数生成"。这个差异决定了AI犯错的方式完全不同。

Cursor生成量大，在代码块之间做"自以为聪明"的关联时，翻车概率成倍上升。

Copilot生成的量小，出问题也就是单个函数层面的问题，不会把两个不相关的模块改坏。

七、写完之后的三条判断

判断一：AI只适合"生成"，不适合"设计"

Crusor生成的并发处理逻辑，看起来像模像样，实际上根本防不住并发。原因很简单：AI知道"分布式锁"这个词，知道sequelize.literal的语法，但它不知道你的业务允许多少并发、你的数据库隔离级别是什么、你的Redis稳不稳定。

这些设计层面的判断，AI做不了。

判断二：修AI代码的时间，跟手写差不多

这是个反直觉的结果。Cursor编码1.5小时，修Bug 2小时，总耗时3.5小时。手写编码4小时，修Bug 0.5小时，总耗时4.5小时。

AI省了编码时间，但把时间挪到了修Bug阶段。而且修AI的Bug比修自己的Bug更费脑子——你得先理解它为什么要这么写，再判断它错在哪，最后再改。

判断三：Copilot是目前性价比最高的选项

数据摆在这：Copilot总耗时3.5小时，Bug数4个，AI引入的只有2个。虽然写的时候要自己多动脑子，但至少收尾不累。

Cursor适合的场景是"模板代码 + 已知模式"，比如写CRUD层、写单元测试骨架。涉及业务逻辑的核心模块，让它自己跑一个礼拜回来验收，大概率要砸电脑。

手写适合的场景是"业务复杂 + 出错成本高"，比如支付、库存、权限这些模块。慢是慢了点，但每一行代码都是自己推过的，出问题知道从哪查。

八、我的选择

做了这次对比之后，我现在的习惯是：

• 手写：核心业务逻辑、金额计算、状态流转
• Copilot：日常CRUD、类型定义、工具函数
• Cursor Composer：只用来生成测试数据和Mock接口

不用谁替代谁，用对地方就行。