一行代码没写，用 Cursor 实现了一个抽奖项目，相比之前的一行代码没写用 ai 开发了一个链接转二维码的网站、Cursor 写一个网页标题重命名的浏览器插件 复杂度提升了很多，涉及到实时通信、状态维护、数据库读写等，AI 编程的利弊也迅速凸显出来。
项目演示
分为观众、玩家、主持人的身份。主持人负责整个抽奖的流转，用户加入 -> 成为玩家，加入抽奖箱 -> 第一轮抽奖 -> 依次选择奖励 -> 第二轮抽奖 -> 抽奖结果公布 -> 游戏结束。
整个抽奖流程实时保存，刷新页面回到之前状态。
项目开发过程
全程采用的 Claude Sonnet 4 ，累计 100+ 轮的对话。
prd 准备
朋友直接给了我一个飞书的 prd 链接，小程序需求 ：
Cursor 最好是去读 markdown 文件，但是飞书只能导出 word，所以就导出了个 word，又找了一个在线工具，把 word 转成了 .md。
1 |
|
标题层级有点怪，但没管了，直接让 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 仅仅是完成了功能，对于合理性完全没有考虑到，甚至太保守了反而造成一些问题。
代码在 https://github.com/wind-liang/lottery ，感兴趣的同学也可以去看一看。
总
从实际体验来看，AI 可以大大大大大大大大提升开发效率，但仍离不开专业开发者的引导和把控。
对于非技术人员来说，虽然可以通过自然语言完成部分开发任务，但很容易在某个阶段陷入死胡同。尤其是当项目面向更多用户时，依赖自然语言的开发方式很难应对复杂需求和多变场景。一些交互体验、非必现的 bug，都严重影响用户的体验。
因此，对于生产级别的项目，当下（2025.8.2）最靠谱的方式是：由开发者提出需求，AI 协助实现，之后再由开发者严格 review 所有改动，开发过程中需要引导 AI 进行优化或者解决 BUG。
正如年初 AI 杂想 中讲的：
未来一定是 ai 的，这已经毋庸置疑了，而我们需要做的就是拥抱 ai，学习 ai，使用 ai。
从 php 开发、.NET 开发、java 开发、python 开发、塞班开发、安卓开发、iOS 开发、web 开发、小程序开发，到现在的 ai 开发，短短几十年，程序员的职业在不停变化。
但变了吗？其实没有。程序员核心掌握的应该是「解决问题的能力」，而变的只是我们使用的工具罢了。
革命尚未成功，AI 仍需努力。
