AI 没有拿走工程的工作，它只是让你更容易假装自己做过
作者说，问题不在于人们用了 AI，而在于「手里有个能跑的东西」已经悄悄被当成「明白它为什么能跑」。他讲了自己重做一个读书会应用的经历，以及一个只在第二块显示器上出现的通知 bug，把界线画在审阅、调试和真正知道自己建了什么那一段上。
中文
复制
9 月 15 日是印度的工程师节，斯里兰卡和坦桑尼亚也一起过，纪念的是 M. Visvesvaraya 爵士的诞辰。他负责过多个大型灌溉与水资源管理项目，包括 Krishna Raja Sagara 大坝，还首创了自动泄洪闸系统，最早装在 Khadakvasla 水库。他从不自称创始人。他忙着造那些真的得能蓄住水的东西。
我提他，是因为在 AI 编程工具和「公开构建」时代之间的某个地方，很多人悄悄把「什么算工程」的门槛降低了，而这件事开始显形了。
新的错觉
这个套路你见过。有人往 AI 工具里丢一句提示，拿到一个能跑的落地页，部署在免费档的主机上，到晚上就自称「创始人」了。没有做过任何架构决策。不知道免费档的速率限制被撞上时会发生什么。没有看过模型到底写了什么。只有一个 URL，和一篇讲「公开构建」的帖子。
问题不在于他们用了 AI。
问题在于，手里有个能跑的东西，已经悄悄变成了明白它为什么能跑的同义词。
这等于朝自动售货机要了一罐汽水，然后自称调酒师。
可怕的地方不是 AI 能在几分钟里生成一个能跑的应用，那部分确实很棒。可怕的是，在很多人的脑子里，「生成一个东西」和「理解一个东西」已经悄悄变得可以互换。快速上线，当然可以。只是别把它和那个让你成为工程师的部分搞混。
差别实际上长什么样
今年早些时候，我一个人在这件事上得了一个具体的教训。
重建
ShelfTalk 最初是一份大学作业：一个完整的 MERN 读书会应用，我一个学期独自做完，交付到刚好能过，然后就在 GitHub 上放了几个月没动。GitHub 的 Finish-Up-A-Thon（一场专门围绕「把 AI 辅助的活认真做完、而不是半途丢下」的挑战）给了我一个截止日期，让我回去把它重做成生产级：用真正的 Socket.io 聊天替掉 REST 轮询，做一个实时同步的阅读室，迁移到 MongoDB Atlas 并用 GridFS，以及从 Create React App 搬到 Vite，把 HMR 时间砍掉大约 80%。
我在 500 多份参赛作品里进了前十。
ShelfTalk：书不会说话，我们会（一个被复活的大学项目）
那个替我说明一切的 bug
这些东西教给我的，都不如几周后在生产环境里冒出来的一个 bug。
我曾加过一个自认为很聪明的通知优化：如果标签页可见，就不要弹桌面提示，因为没人喜欢已经正在看的那条消息还来通知你。我当时觉得 UX 很干净。然后用户开始漏掉私信，而我自己的测试复现不出来：代码完全按我设计的方式在跑。
这个 bug 原来住在一个假设里，而不是某一行代码里。
我的代码悄悄把「操作系统能渲染这个像素」和「有个人正在看」混为一谈了。任何把 ShelfTalk 开在第二块显示器上的人，都在无声地丢掉每一条通知，因为一个全屏可见的标签页在技术上确实是「可见」的，哪怕二十分钟没人看过它一眼。修法是删掉那个我引以为傲的优化。稍微多余的一次提示只是有点烦，而一条被无声丢掉的消息是坏掉的产品。
那个好得过了头的优化：为什么我们的推送通知只在你不看的时候才有效
这个 bug 在演示里根本不会出现，你也不可能靠一路提示着把项目做完就发现它。要发现它，需要一个用户来抱怨，然后我得跟「它完全按设计在工作」这句话待足够久，久到意识到这个设计的核心假设本身就是错的。
ShelfTalk 的重建里有很大一部分是 Copilot 和我一起写的：它搭了 socket 事件处理器的骨架，在迁到 Vite 的过程中抓出 import 错误，自动补全了我本来也要去查的 UI 写法。但我不会把其中任何一部分称为「vibe coding」，因为我批评的那种 vibe coding，跳过的是发现自己的项目坏了、然后在压力下把它修好的那一段。
那一段，也就是审阅、调试、真正知道自己建了什么，就是这份工作的全部。而且是独自一人，没有别人帮你兜住你漏掉的东西。对拿着混凝土和钢铁的 Visvesvaraya 来说是这样。现在由 Copilot 打一部分字的时候仍然是这样，而对第二块显示器上的一个傻乎乎的布尔值来说，也完全一样。
那么，界线在哪里？
我不认为 AI 是问题。我认为问题在于，跳过那个让你成为工程师的部分、却保留那个让你听起来像工程师的部分，已经变得太容易了。
AI 并没有拿走工程的工作。它只是让你更容易假装自己做过。
所以我直接问：用 AI 造东西，和只是看着 AI 替你造，你的界线画在哪里？
你有没有抓到过自己站错了那一边？ 👇