用 AI 撸代码太快，快到很多人把「跑通了」误以为是「懂了」

如果你习惯用 Cursor 或 Copilot 这种工具，你一定会发现一个很诡异的现象：现在很多人只要输入一个 Prompt，拿到一个能跑的 Landing Page，顺手丢到免费托管平台上，反手就能在社交媒体上宣布自己是「创始人」了。

这种快感很欺骗人。最核心的问题在于，现在「做出一个能运行的东西」在很多人潜意识里竟然等同于「理解这个东西为什么能运行」。这就像是在自动贩卖机买了一瓶可乐，就敢说自己是个调酒师。AI 确实能让你在几分钟内生成一个 App，这很棒，但如果你把「生成」和「理解」混为一谈，那你离翻车也不远了。

我之前在折腾一个叫 ShelfTalk 的项目时，被狠狠上了一课。

这个项目起初只是个大学作业，一个用 MERN 栈写的读书会 App。当时勉强写完拿了及格分，就扔在 GitHub 上吃灰了。后来我参加了 GitHub 的 Finish-Up-A-Thon（这个挑战赛的核心就是让你用 AI 辅助把那些半成品真正地完成），我才意识到之前的代码有多烂，于是决定把它重构成生产级别。

这次重构我做了很多实操层面的变动，这些细节是单纯靠 Prompt 刷不出结果的：

• 把之前的 REST 轮询全部换成了真正的 Socket.io 实时聊天；
• 实现了实时的同步阅读室功能；
• 数据库迁移到了 MongoDB Atlas 并使用了 GridFS；
• 最关键的一点，我把 Create React App 换成了 Vite，结果 HMR（热更新）速度提升了大约 80%，开发体验直接起飞。

我在做推送通知时，自以为聪明地写了一个「优化」：如果用户当前正看着这个页面，我就抑制掉桌面通知，因为没人喜欢在盯着屏幕时还听到一声叮叮响。从 UX 角度看这很优雅，但上线后用户开始疯狂投诉说收不到私信。

最诡异的是，我在本地测试怎么都复现不了，因为代码逻辑完全按照我的设计在跑。直到我意识到，这个 Bug 根本不在代码行里，而是在我的「假设」里。

我错误地把「操作系统能渲染这个像素」等同于「用户正在关注这个页面」。结果那些用双显示器的人全中招了——只要 ShelfTalk 窗口在副屏上可见，哪怕用户已经盯着主屏看了 20 分钟没理会副屏，系统依然判定为「可见」，导致所有通知被静默拦截。

最后的解决办法是：把那个我引以为傲的「优化」给删了。因为一个冗余的通知声顶多算烦人，但一个被静默丢弃的消息才是真正的产品缺陷。

这种 Bug 在 Demo 演示时绝对不会出现，你也没法通过简单的 Prompt 提示词来发现它。它需要你面对用户投诉，面对「代码运行正常」却「功能失效」的矛盾，然后通过反思设计假设来解决。

Copilot 在我重构 ShelfTalk 的过程中确实帮了我很多，它能帮我快速搭建 Socket 骨架，但它没法替我承担「设计错误」带来的后果。真正的工程工作并没有消失，它只是从「怎么写出这行代码」转移到了「这行代码在真实场景下是否合理」的判断上。