Vibe Coding 盛行下，App 质量参差不齐，我们该拥抱还是 say no

最近这段时间，我明显感觉到一件事：做 App 的门槛被拉低了。

以前想做一个能跑起来的产品，至少要懂一点前端、后端、数据库、部署，踩过几次坑，才知道哪些地方不能乱来。现在不一样了，很多人一句话、几轮对话，就能把一个页面、一个接口，甚至一个完整的小产品搭出来。

这当然是好事。

我自己也用 vibe coding。写 Go 的时候，让它帮我起草结构、补样板代码、生成测试用例，确实能省不少时间。有些重复劳动，没必要再硬扛。工具变强了，程序员应该把时间更多花在判断、设计和取舍上。

但问题也在这里。

现在很多 App 看起来能用，点几下也没问题，可一旦用户多一点、数据复杂一点、异常情况多一点，就开始露馅。错误处理很随意，权限边界没想清楚，数据结构凑合着来，日志没有，测试没有，出了问题也没人说得清到底为什么。

这种东西不是“开发快”，而是把成本往后推。

所以我不太认同简单地说“拥抱”或者“say no”。我的态度是：拥抱工具，但不要把判断权交出去。

AI 可以帮我写代码，但不能替我负责。尤其是写 Go 这种偏工程化的语言，我更在意代码是不是清楚、错误是不是可控、接口是不是稳定、并发和资源释放有没有想明白。能跑只是第一步，能维护、能排查、能长期演进，才算真的写完。

如果 vibe coding 只是帮我更快进入状态，我会用。

如果它让我开始不读代码、不理解实现、不写测试，只靠“看起来差不多”就上线，那我会 say no。

工具越强，人越不能偷懒。因为最后用户遇到 bug，不会去问这段代码是不是 AI 写的。他只会觉得：这个 App 不靠谱。

本作品采用《CC 协议》，转载必须注明作者和本文链接