“Vibe Coding（凭感觉编程）”无法取代技术活，反而要求更高

作者：Pawel Brodzinski

“凭感觉编程”或许能帮你搞出一个能用的原型，但想用它来打造一个可持续的产品，门都没有。在数字化产品开发领域，技术能力依然是成功的关键。

关于“凭感觉编程” (Vibe Coding) 的可行性以及它到底能走多远，我和别人有过不少争论。简单说，我的看法是：

• • 想用“凭感觉编程”来打造一款真正的产品，是行不通的。

• • 但用它来做原型，那简直太棒了。

第一点显然惹恼了许多 AI 爱好者。不出所料，这些被激怒的人里，绝大多数都没有技术背景。

我懂。这些爱好者可能会觉得，我（以及其他人）不愿承认“凭感觉编程”的威力，是在维护现状。毕竟，几十年来，软件工程师一直处于金字塔尖的优越位置。而特权是不会轻易消失的。

“凭感觉编程”的美梦

雪上加霜的是，我们总能听到一些有影响力的人物说，“凭感觉编程”（以及 AI 生成代码）是解决产品开发难题的答案。

插句题外话。你可能会问，如果人们都相信自己能靠“凭感觉编程”搞出一家十亿美元的公司，那些顶尖 AI 创业公司的创始人能得到什么好处呢？比如说，他们的客户会不会变得更多？

像 Lovable、Bolt 和 Replit 这样的公司，它们的战略核心就是让用户能够生成完整的应用程序。把 AI 生成应用宣传成一种可行、可取且令人向往的模式，是他们的常规操作。他们没法回头了，尤其是在增长速度创下记录的今天，甚至有人预测他们最快明年就能实现十亿美元的年收入。

在这股热潮下，肯定会有大批人尝试用“凭感觉编程”来开发自己的产品。事实上，我们已经听到了不少成功案例。然而，如果你仔细研究，会发现这些故事更像是自我营销，而非可持续的商业实践。

技术知识，依然是王道

“凭感觉编程”工具的基本前提是，一个没有技术背景的人也能生成可以工作的软件。然而，“可以工作的软件”这个词本身就很模糊。

我曾和我儿子一起，为了他的小学计算机课，用 Lovable 开心地做了一个类似 Wordle 的小游戏。在我的公司 Lunar，我们也用 v0 和 Bolt 为客户快速制作创意原型。然而，很多人想象中的“可以工作的软件”，是可以用来创业、达到生产级别的数字应用。

这两者之间最根本的区别在于，前者的代码完全是一次性的，而后者不是。做原型时，我们不打算长期保留成果。但如果你想围绕一个软件来创业，那就意味着它需要长久存在。

对于这样的代码库，技术能力不是可有可无的。我甚至认为，我们可能需要比以往更多的技术能力。

“凭感觉编程” vs. AI 生成代码

在继续之前，先声明一下。我把“凭感觉编程”和由 AI 工具（无论是代码自动补全还是 AI 智能体 (AI Agent)）生成的代码区分开来。

“凭感觉编程”指的是，我向 AI 工具发出指令，描述我想要的产品——它的功能、外观等等。在这种情况下，我甚至不需要看代码（虽然工具有时也允许你看）。

相反，使用 AI 生成代码时，我向工具描述的是代码层面的结果——比如类 (classes)、函数 (functions)、接口 (endpoints)、数据结构 (data structures) 等。最终的产出物，必然是代码本身。

我接下来的论点，并非反对广义上的 AI 生成代码。在 Lunar Logic，在某些项目中，我们（初始）生成的代码中，由 AI 完成的比例轻松超过 90%。但关键是，时至今日，我们仍然坚持，在没有经过人类仔细审查之前，一行代码都不会被推送到任何地方。

“凭感觉编程”则颠覆了这一规则。它向我们承诺，我们甚至不需要看一眼代码，更不用说审查了。

技术债

任何在软件开发领域待过一段时间的人，都熟悉“技术债” (technical debt) 这个词。它指的是所有那些为了图一时之快而使用的取巧、过度简化和肮脏的解决方案。这些做法虽然能完成任务，但同时也会让整个代码库变得不必要地复杂、可读性差，并且更容易出现连锁问题。简而言之，代码变得越来越难以维护。

随着时间的推移，修改产品会变得越来越困难、耗时。直到有一天，你几乎无法在不破坏其他功能的情况下做任何改动。是的，我亲眼见过因为技术债堆积如山而导致项目进展完全停滞的情况。

这就是为什么任何明智的开发者，都会把持续偿还部分技术债作为工作的一部分。这是我们长期维持代码可维护性的方式。

但是，如果那个开发者是一个只会“凭感觉编程”的 AI，而我们又没有技术能力去审查它的工作，或者详细告诉它什么样的代码才算可维护的代码，那情况就完全不同了。

在这种情况下，我们可以预见技术债会以惊人的速度累积。毕竟，所有这些 AI 工具的训练数据，并不仅仅是那些最闪亮、最优秀的代码库。

很快，对应用做的任何改动都会破坏其他功能。而修复这些问题又会引发新的问题，或者把之前的修改覆盖掉。这会变成一个令人绝望的死循环，任何进一步的开发都将变得不可能。

代码质量

但是等等，我们为什么不直接告诉 AI 工具要保持高代码质量呢？哦当然，我们可以这么说。但问题是，它根本不理解“高代码质量”意味着什么。

当我们的开发人员使用 AI 编码智能体时，第一步就是准备编码规范。这是一份相当详尽的上下文文档，用代码示例来解释我们所期望的代码质量是什么样的。

虽然我不再是开发者已经二十多年了，但我还能就软件工艺和架构进行一般性的交谈。即便如此，如果认为我能准备出那种水平的规范，那就太自不量力了。

更重要的是，AI 智能体虽然不常见，但总会偶尔“幻觉”出一些完全违背规范的东西。在现阶段，即使有最好的上下文，没有人为监督也意味着代码质量会随着时间推移而下降。

安全性

在听 CreatorHunter 的“凭感觉编程”故事时，我一直对一个方面很好奇，那就是安全性。我承认，我本以为“安全”这个词在整个对话中都不会出现。

结果我赌输了。CreatorHunter 的创始人 Paulius Masalskas 确实提到了安全。

“只要给一点提示，再做些评分，它就能把应用变得很安全。”
Paulius Masalskas

是的，就这么简单。给点提示，做点评分，就搞定了。真是好样的！唯一的问题是，这无异于告诉“凭感觉编程”工具：“把你的应用变安全点。”

AI 没有一个世界模型，让它能理解我们说“一个安全的 Web 应用”时到底是什么意思。通过鹦鹉学舌般地模仿最流行的答案，它肯定能做对一些事。但是，既然不存在一个关于“什么构成了一个安全的 Web 应用”的最终答案，我们就不能指望 AI 能给我们这个答案。

即使存在这样的答案，一旦复杂性超过某个水平，AI 编码智能体仍然会“幻觉”出一些不安全的东西。

在没有能够合理评估所提方案安全性的专业人士监督下，这将是一条危险的下坡路。迟早，潜在的漏洞几乎是必然会出现的。

安全性，再加码

然而，这还只是个开始。随着开发者越来越依赖 AI 编码工具，我们又给自己挖了一个全新的大坑。

历史上，漏洞进入软件产品通常是由于疏忽。开发者可能懂得不多，或者无意中犯了个错，导致代码不够安全。因此，代码是有漏洞的 (vulnerable)。

现在，游戏规则变了。我们既要防范因疏忽导致的不安全，也要防范因 AI 生成代码的存在而引发的恶意行为。当然，AI（目前的形式）本身不是邪恶的。邪恶是个抽象概念。但是，那些了解 AI 模型工作原理的黑客，正在伺机利用那些想走捷径的人。

• • 自动代码更新可能意味着恶意代码会被添加到代码库中，黑客可以借此窃取数据、获取代码访问权限，甚至对产品为所欲为。

• • 攻击者会利用AI “幻觉”出不存在的库（这本来只是个小麻烦），然后真的去创建这些库，只不过里面塞满了恶意代码。这必然会导致重大的安全事故。

• • 黑客会创建一些公开的代码库，其中包含一些对人类肉眼不可见的、专门给 AI 智能体看的指令。人类阅读这些文件时不会注意到任何异常，但“凭感觉编程”工具会把它当作合法的指令来执行。

• • 更糟糕的是，编码智能体的设计初衷就是为了生成看起来不错的输出。它们可能引入的任何恶意更改，都会被一层“看起来没问题” (LGTM, Looks Good To Me) 的代码所掩盖。

如果你对我之前说的“我们现在需要比 AI 出现前更多的技术技能”感到疑惑，这就是一个重要原因。当然，也绝非唯一的原因。

合规性

如果你暂时听够了安全问题，我们来谈谈合规性 (compliance)。任何处理信用卡的业务都必须遵守支付卡行业数据安全标准 (PCI compliance)。当然，你可能会说，这不是有 Stripe 吗？他们处理信用卡支付，所以他们才需要关心 PCI 合规，对吧？

嗯，不完全是。根据我们集成支付处理的方式不同，我们需要遵守不同级别的 PCI 合规要求。但问题是，在“凭感觉编程”时，我们根本不知道具体的实现方式是怎样的。

天啊，除非我们过去亲手做过这件事，否则我们既没有洞察力去考虑这可能是一个问题，也不知道该如何提出正确的问题。

但是，嘿，最坏的情况能有多糟呢？对于一个依赖信用卡处理的业务来说，在一个仅仅是异地支付就可能触发“了解你的客户”(KYC) 程序的世界里，最坏的情况可能就是灭顶之灾。

而且，除非真的出了事，我们甚至都不会意识到有麻烦正在酝酿。

可扩展性、性能、可访问性

对于任何一个数字产品长期可行性至关重要的方面，我几乎都能提出类似的宏观论点。像扩展性 (scaling)、性能 (performance) 或可访问性 (accessibility) 这些词，对开发者来说是有具体含义的。但对一个 AI 模型来说，它们完全是抽象的。除非你告诉它这些词对你意味着什么。

更重要的是，对于什么是可扩展性或性能，不可能有普遍的共识。它在很大程度上取决于特定产品的具体情境。

所以，你能用“凭感觉编程”搞出一个可扩展的 Web 应用吗？嗯，可以，前提是你根本不需要任何扩展。

而且，很可能，除非你有相当广泛的技术经验，你甚至都无法提出正确的问题写出正确的提示。

比如说，万一你的 AI 智能体失控删除了你的数据库，你是否应该关心备份和恢复策略？一个独立创业者想用“凭感觉编程”替代的技术角色越多，他们就越需要明白，软件开发已经发展成为一门相当复杂的学科。

他们要么自己具备这些技能——在这种情况下，与使用 AI 编码智能体相比，“凭感觉编程”可能是一个失败的选择；要么通过某种方式从外部聘请这些技能。

无论哪种方式，“凭感觉编程”可能都不会存在太久。

雷区

当然，如果你只是发布一个最小可行产品 (MVP) 来测试市场对你最新想法的兴趣，那么很多这些考虑都是无关紧要的。但仅此而已——发布一个一次性的 MVP。

一旦出现任何积极的势头，这个想法开始变成有价值的东西时，我们就立刻进入了工程的雷区。

此时，一个热情的“凭感觉编程”者很可能会毫无察觉、因此也毫不在意地继续前进。这将导致某些东西比预想的更快在他们面前爆炸。然而，即使是那些意识到其中部分（或大部分）风险的人，也难免会踩中这样或那样的陷阱。

这就是为什么我并不指望能看到完全没有技术专长的、价值数百万美元的创业公司出现。

同样基于这些原因，我也不认为 Lovable（及其竞争对手）的增长势头是可持续的。专家会选择能给他们更多控制权的工具，无论是出于自愿还是被迫。而外行则会发现，当他们的产品创意初见成效时，“凭感觉编程”工具要么能力不足，要么令人沮丧。

如果你喜欢这篇文章，它的灵感来源于 CreatorHunter 的“凭感觉编程”成功故事，而这个故事似乎并不完全像其创始人声称的那样。

这里有一篇后续文章，从产品开发的角度探讨了这个问题。

原文链接: https://pawelbrodzinski.substack.com/p/vibe-coding-doesnt-replace-tech-skills