说服自己去“Vibe Code”

Source: Dev.to

振动敲门

“Vibe Coding” 描述通过纯自然语言意图而非手动语法来构建应用程序。它在 2024 年底进入我的视野，老实说，我觉得它只是懒人的流行词。直到我在自家客厅看到它时，这种看法才改变。我的妻子使用 v0 在免费层下，用不到三十分钟就搭建了一个功能性网页应用。

它远非完美——界面丑陋，逻辑脆弱——但 它运行了。我过去常自豪地宣称自己能在一天内搭建出一个基本的功能应用。而她就在我面前，直接跳过了我平时引以为豪的数小时模板和底层工作。

它的优势与局限

在此之前，我发现 AI 很少具备足够的智能来帮助我修复细微的 bug 或升级特定的包。于是自然会产生这样的想法：

“如果连 bug 都修不好，怎么可能为我构建应用？”

这种心态让我停滞了很久。经过客厅里那次惊人的体验——以及稍作探索——我终于能够对 AI 真正擅长的领域进行分类。

• 快速启动 – 生成模板代码、搭建初始存根以及解决极其明确的问题，这正是它的强项。
• 企业环境 – 一旦引入复杂的业务逻辑、庞大的已有代码库以及已经维护了十年的遗留系统，AI 就会开始“幻觉”。在设计不佳的系统或拥有 10 万行以上代码的仓库中，AI 的建议往往毫无意义。它无法“感受到”十年技术债务的沉重。

为什么我们说不

如果你问我最初为什么对 vibe coding 说不，诚实的答案不仅仅关乎 AI 的技术能力。更在于我们的身份认同。

质量陷阱

我们看到这些工具生成的“垃圾”代码——缺乏模式、重复、凌乱的文件结构——就会本能地退缩。作为工程师，我们被训练去控制细节。放弃这种控制感就像是对我们手艺的背叛。

对未知的恐惧

AI 具有快速推进的动能。它会引入我从未使用过的解决方案或库。如果我不理解底层的每一个机制，就会觉得自己在失去锋芒。这是一道哲学上的障碍：

是否必须理解每一行代码？

对我而言，答案始终是 是。项目中出现的未知代码片段，就像随时可能引爆的地雷。

自尊检查

这是一种真实且令人不适的职业嫉妒感。看到一个非技术人员只需支付 20 美元的订阅费，就能绕过我多年为学习框架所付出的努力，感觉“很不公平”。把 vibe coding 止步为“不是正经工作”，可以让自己对已有的投入感到更安慰。

代码质量真的成问题吗？

Vibe‑coded 项目往往寿命短暂，注定要消亡。它们是为了验证一个想法或工具本身而构建的。如果想法失败，代码就会在“404 河”里悄然消失。如果想法成功，则会被工程师重新编写。

**从工程师的角度看：**我们真的在乎一段短命代码的质量吗？我经常编写快速的 Bash 脚本或一次性 Python 脚本，根本不在乎它们的质量。如果我能接受一段用于 10 分钟任务的凌乱脚本，为什么不能接受一个用于 1 天验证的 vibe‑coded 原型呢？

**从非技术用户的角度看：**大量的 vibe coder 并没有技术背景，且很可能永远不会拥有。他们大概永远也不会去查看代码库。重要的是他们能够在不雇佣工程师的情况下测试想法。

这类人群中有很大比例是产品经理和设计师。他们可以在更短的时间内获取验证想法的工具，而这与工程师无关。在某种程度上，这减少了我们必须进行的“废弃”工程工作量。

定义软件工程

软件工程不仅仅是启动应用程序；绝大部分工作是维护它们。 这并不是一个新发现，但重新审视它帮助我重新找回了信心。如果 AI 处理“启动”，工程师的价值就转向 可持续性。工程是把“氛围”重构为可维护的形式。它在于设计能够在第二年仍然存活的系统，而不仅仅是第一周末。

划定界线

AI 可以是魔术表演，也可以是生产力工具。两者的界限模糊，但明确划分能够帮助我提升生产力，同时不失工程师的身份。

氛围侧

• 使用 AI 进行探索、快速原型制作和验证。
• 如果产品经理想要“感受”以验证想法，就让他们这么做。该代码仅用于短期使用。

工程师侧

• 使用 AI 实现 存根，修复 范围限定的错误，并生成后续会重构并拥有的 样板代码。

---

—

Author: Zane Chen (original article on dev.to)

• 学习 新的模式，搭建 样板代码，以及任何对工程师明确且有益的内容。