一行代码没写，用 Cursor 实现了一个抽奖项目，相比之前的一行代码没写用 ai 开发了一个链接转二维码的网站、Cursor 写一个网页标题重命名的浏览器插件 复杂度提升了很多，涉及到实时通信、状态维护、数据库读写等，AI 编程的利弊也迅速凸显出来。
项目演示
分为观众、玩家、主持人的身份。主持人负责整个抽奖的流转，用户加入 -> 成为玩家，加入抽奖箱 -> 第一轮抽奖 -> 依次选择奖励 -> 第二轮抽奖 -> 抽奖结果公布 -> 游戏结束。
整个抽奖流程实时保存，刷新页面回到之前状态。
项目开发过程
全程采用的 Claude Sonnet 4 ，累计 100+ 轮的对话。
prd 准备
朋友直接给了我一个飞书的 prd 链接，小程序需求 ：
Cursor 最好是去读 markdown 文件，但是飞书只能导出 word，所以就导出了个 word，又找了一个在线工具，把 word 转成了 .md。
这是一个婚礼抽奖项目，请使用 Next.js，SUPABASE，完成这个移动端项目，支持部署到 Vercel，请拆解任务一步步完成，每一步之后我进行测试，没问题再进行下一步。
ui 美观一些。
**抽奖需求**
1. 抽取确定顺序流程阶段
1. 分玩家身份和主持人身份、观众身份，不同身份有不同的头像框
2. 观众身份
1. 所有人进入时均为观众身份，大家登录进来能看到自己的头像，所有人的头像在大厅里下半部分，按进房间顺序排序，退出房间不删除，重连回到当前位置
2. 所有观众界面上有成为主持人按钮，点击成为主持人，出输入密码弹窗，点击确认，密码正确弹窗关闭成为主持人身份，移动自身位置，密码错误弹窗关闭，弹出提示“密码错误”给输入密码的人
3. 主持人点击观众头像，出弹窗，可设置观众为玩家身份
4. 主持人点击玩家身份头像，出弹窗，可设置玩家为观众身份
5. 所有人头像排列在下方区域，人越多，头像越小，自适应大小，规则可再详聊
6. 点击抽奖箱打开一个小弹窗能看到当前抽奖箱里有哪些人，打开后侧边出现关闭按钮，再次点击则关闭抽奖箱弹窗
3. 玩家身份
1. 可以点击参与抽奖按钮，能把自己的头像复制一份扔到抽奖箱里，已经点过并在抽奖箱中的玩家按钮置灰
2. 点击抽奖箱打开一个小弹窗能看到当前抽奖箱里有哪些人，打开后侧边出现关闭按钮，再次点击则关闭抽奖箱弹窗
4. 主持人身份
1. 主持人最多两位，进入后头像在抽奖箱左边/右边
2. 点击抽奖按钮（屏幕左下角），即开始抽奖，有二次确认提示弹窗防止误触，弹窗有确认和取消两个键，点击确认则开始一次抽奖，点击取消则不进行操作。
3. 首次抽奖开始后，任何玩家不再能点击参与抽奖进入抽奖箱中
4. 每次抽奖开始后，3秒内不能再次抽奖，期间任何主持人均不显示抽奖按钮，服务器也不再接收抽奖请求。
5. 点击抽奖箱打开一个小弹窗能看到当前抽奖箱里有哪些人，打开后侧边出现关闭按钮，再次点击则关闭抽奖箱弹窗
5. 抽奖箱位于屏幕中上部
1. 每次开始抽奖后，主持人头像靠近抽奖箱，箱子摇一摇约两秒，之后箱子中目前在的一个随机头像从箱子里飞出，头像展示2秒播个光效，主持人头像回归原位
2. 抽出来的玩家头像复制飞回到玩家座位头像本体身上，并在座位的头像上标上数字，数字为自己被抽出后，仍在箱子里的人数+1的数，作为第二个阶段玩家的顺序
3. 给对应被抽出来的玩家在屏幕正中华弹文字提示，“您获得了第x名”，其他玩家弹提示“y获得了第x名”，x为对应的第二阶段的顺序，提示2秒后消失
4. 抽出第一名后（箱子里没玩家了），主持人再次点击开始抽奖按钮，进入下一个阶段
2. 轮流选择奖励阶段
1. 在箱子里所有人被抽取出来后，进入轮流选择奖励阶段，两个主持人头像被移动至屏幕左上角，纵向排列
2. 抽奖箱消失
3. 屏幕中间出现奖励选择列表，每个奖励纵向排列，每个奖励均由奖励图片、奖励文字描述、单选框组成
1. 主持人不显示单选框
2. 观众不显示单选框
4. 主持人屏幕左下角，有开始选择按钮，点击按钮有二次确认弹窗，点击取消则关闭弹窗，点击确认则开始选择流程，任一主持人点击开始选择，所有主持人按钮消失，服务器也不再接收开始请求
5. 开始选择后，从第一轮确定顺序的玩家的第一名开始，依次选择奖励，会在左侧展示对应头像
6. 玩家点击奖励后，列表中对应奖励的单选框变为选中状态，其余奖励的单选框变为未选中状态，点击确定选择按钮，弹出二次确认弹窗“是否确认选择该奖励”，并展示奖励对应的图片和文字描述，点击取消则关闭弹窗不操作，点击确认则确认选择该奖励
7. 确认选择后头像挂到对应奖励上，放在单选框位置，该奖励无法再次被选择
8. 直至第一阶段所有参与的玩家均选择完毕进入下一个阶段
9. 每个玩家选择时，有30秒倒计时，倒计时结束前未选择则系统随机选择一个
10. 记录下所有人的选择，保存并导出记录
3. 绝地翻盘阶段
1. 回到第一阶段的界面布局
2. 进入阶段是全部人拍脸公告“绝地翻盘阶段”，展示奖品及参与者、参与者排名情况，10秒后自动关闭界面
3. 所有首轮排序最后5名的玩家，将参与最后一个阶段的抽奖，主持人点击第三阶段开始后，他们的头像复制飞入抽奖箱，先最后一名飞入5个头像，再倒数第二名飞入4个，以此类推，最后倒数第五名飞入1个
4. 此时所有玩家、主持人、观众均可点击抽奖箱，弹出抽奖箱弹窗，看里面有几个头像复制，排序按飞入顺序排
5. 主持人点击抽奖按钮，二次确认弹窗确认后，从抽奖箱中随机一个出来，并在屏幕中出现获得者、绝地翻盘奖励图片及文字描述
6. 播放5秒后之后进入下一阶段
4. 完结阶段
1. 布局稍微调整，清除所有人的排名情况，屏幕中间位置一直在放烟花动画，大家仍可继续发送表情，随时可以退出
5. 断线重连
1. 如果中途断网or闪退，再次打开小程序则自动连入，还是刚才的角色身份、选择情况等，不额外作为新玩家加入
6. 游戏重置
1. 留控制方式，需要手动重置时，可操作进行游戏重置
7. 发送表情
1. 每个人可以点击下方区域表情图标，发送表情，每次表情展示2秒，期间不可再次点击所有表情按钮，点击无效，发送的表情在头像上展示，大家可以看到彼此发送的表情
标题层级有点怪，但没管了，直接让 AI 进入开发了：
整体开发完后接着就是每个功能的测试修改。
AI 编程确实大大提升了效率，这么大的一个 PRD，总共就开发了不到 20 小时，期间大部分时间还是等待 AI 写代码的过程。甚至已经达到了一个可用的状态，把网站部署上线后让朋友去体验了。
二次改造
让朋友看完之后进行了新的一轮改造，而且比想象的顺利，用户登录系统改造直接下边一段话就搞定。
整体改造
用的 supabase 但感觉卡卡的，想着是不是服务器的问题，准备换成国内的服务器试试。
但 AI 目前还没有强大到这种程度，一句话是改不出来了，改完各个功能都坏掉了，先放弃迁移了。
bug 修复
前期开发确实非常快，但是后期修复 bug 就会令人感到痛苦。由于 AI 写的代码完全没有去看过，所以只能告诉他表象然后让他修复。
如果是必现的问题修起来还好。但如果是偶现的问题，让他修复之后完全无法验证，只能相信他。
事实证明，有时候修了之后确实复现不了了，有时候修了之后多试试还是偶尔能复现，这也回到了大模型的本质——概率，哈哈。
AI 的局限
这里举两个典型的例子，AI 目前需要专业知识的人来引导。
样式遮挡
这也是平常开发经常遇到的问题，就是元素的层级不对，尝试让 AI 修复：
第一次修复失败，继续让他修复：
二次尝试之后还是失败，因为它只是在无脑提升 z-index，但我们知道 z-index 只影响同一层叠上下文的层级关系，如果是跨层叠上下文，层级关系要看父元素的 z-index，详见 css层叠上下文和z-index的使用和思考。
此时提示它看一下层叠上下文的关系：
问题直接就被解决了。
二次抽奖功能
抽奖有两轮，第二轮抽奖是选取第一轮抽奖的最后 5 名进行重新抽奖，但第二轮抽奖总是不成功。
让我检查第一轮抽奖的数据库，但数据库中是有数据的。
失败。
失败。
失败。
失败。
此时已经失败好多轮了，我猜测原来的表是不是设计上有问题，导致一直拿不到第二轮抽奖的人。所以让他把第二轮抽奖的人放到一张新的表中。
但还是失败。此时我突然意识到它实现上是不是有问题。
第二轮抽奖给每个人赋予了不同的抽奖概率，所以我怀疑他为了增加中奖概率是不是在重复将同一个人插入到数据库才导致问题。所以给他提供一个思路，只增加概率就行，用户不需要存多次。
终于成功了。
代码分析
AI 确实帮我快速实现了项目，但也带来了一些无论怎么说都无法修复的问题。除了一些非必现的 bug，还有一些严重影响用户体验的问题，比如引起电脑发烫、交互卡顿等，这里尝试读一下代码看不能分析出来。
打开控制台疯狂输出日志，卡的根本调试不了，先改一下不让他输出日志。
发送表情
发送表情主要是一个写库操作
打印了前后的时间：
有时候会慢一些，问问 AI 有没有优化空间：
一个是缺少索引
一个是不必要的 select 的。
代码中查了 roomId 是为了以防万一，但我们已经明确只有一个房间，可以把 roomId 删掉。
疯狂网络请求
打开控制台，这应该也是造成电脑发热的原因：
只是降低请求频率，治标不治本。
给他提供新思路：
说的很好，但是打开之后还是疯狂的请求。
打开控制台请求依旧在发，AI 修好无望。
我们自己找一下调用位置：
控制台输出，说明就是这里：
明确了问题点之后再让 AI 修复：
这次真修好了，原因就是 useRealtime 依赖的这几个函数在不停变化：
比如 handleRoomChange 依赖了 room ，但内部又更新了 room 导致 handleRoomChange 不停的重新创建，引发了 useRealtime 的重复执行。
但这也只修好了重新发送请求的问题，再回过头看表情系统，会发现被改坏掉了。
所以如果这个项目想完全修好，靠 AI 是不太行了，只能通读代码理解全部细节去优化了。
从代码来看，AI 仅仅是完成了功能，对于合理性完全没有考虑到，甚至太保守了反而造成一些问题。
代码在 github.com/wind-liang/… ，感兴趣的同学也可以去看一看。
总
从实际体验来看，AI 可以大大大大大大大大提升开发效率，但仍离不开专业开发者的引导和把控。
对于非技术人员来说，虽然可以通过自然语言完成部分开发任务，但很容易在某个阶段陷入死胡同。尤其是当项目面向更多用户时，依赖自然语言的开发方式很难应对复杂需求和多变场景。一些交互体验、非必现的 bug，都严重影响用户的体验。
因此，对于生产级别的项目，当下（2025.8.2）最靠谱的方式是：由开发者提出需求，AI 协助实现，之后再由开发者严格 review 所有改动，开发过程中需要引导 AI 进行优化或者解决 BUG。
正如年初 AI 杂想 中讲的：
未来一定是 ai 的，这已经毋庸置疑了，而我们需要做的就是拥抱 ai，学习 ai，使用 ai。
从 php 开发、.NET 开发、java 开发、python 开发、塞班开发、安卓开发、iOS 开发、web 开发、小程序开发，到现在的 ai 开发，短短几十年，程序员的职业在不停变化。
但变了吗？其实没有。程序员核心掌握的应该是「解决问题的能力」，而变的只是我们使用的工具罢了。
革命尚未成功，AI 仍需努力。
