当 Claude 和 Codex 都来解释 Vibe Coding，差异让我看清了这件事的本质

林发和大约 6 分钟

当 Claude 和 Codex 都来解释 Vibe Coding，差异让我看清了这件事的本质

我做了一个实验：让 Claude 和 Codex 分别写一篇关于 Vibe Coding 的公众号文章，题目一样，要求一样，然后把两篇放在一起看。

结果很有意思。不只是文章风格不同，连对这件事的理解重心都不同。这个差异本身，反而帮我想清楚了 Vibe Coding 到底是什么。

但在说这两篇文章之前，先从头说起。

Vibe Coding 是什么

这个词由 AI 研究员 Andrej Karpathy 于 2025 年提出。他原话是：

"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists."

直译是"沉浸在氛围里，拥抱 AI 的指数级能力，甚至忘记代码的存在"。

用更朴素的话说：Vibe Coding 是用自然语言驱动 AI 生成和修改代码，通过不断运行、观察、反馈来推进软件开发的一种方式。

它的典型过程不复杂：说出目标 → AI 给出初版 → 你运行并观察 → 继续反馈问题 → AI 修改 → 直到结果可用。

这个过程更像和一个会写代码的助手持续对话，而不是传统意义上从需求、设计、编码、测试一步步线性推进。

你不再是逐行写代码的人，而是一个描述目标、判断结果、设计边界的人。

为什么它突然流行了

有几个原因叠在一起：

AI 写代码的能力跨过了可用门槛。过去让 AI 写一个完整项目，经常卡在依赖、文件结构和上下文缺失上。现在的工具已经能读项目、改多文件、跑命令、看报错，并进行多轮修复。Cursor、Claude Code、Codex、Replit Agent、Bolt、Lovable，这些工具让很多人第一次感受到：把想法说清楚，AI 就能快速做出一个原型。

自然语言成了新的开发入口。不会 React、Python 或 SQL 的人，也可以先用中文表达需求，再让 AI 把需求翻译成代码。

更重要的是：很多软件需求本来就不需要复杂工程。个人脚本、内部工具、一次性数据处理、活动页、演示原型——这些任务以前因为"启动成本太高"被搁置，现在可以很快做出来。

它适合做什么，不适合做什么

Vibe Coding 最适合低风险、高反馈、边界清晰的任务：快速验证产品想法、内部小工具、数据清洗脚本、网页原型、个人自动化工作流。这些场景的共同点是：就算初版不完美，也能通过运行结果快速发现问题；即使失败，代价也可控。

但如果涉及钱、权限、隐私、安全、合规、核心业务，不能只靠"感觉能跑"。支付结算、用户登录、医疗金融、大规模生产数据库——这些场景需要明确的架构设计、代码审查、测试覆盖和安全检查。AI 可以参与，但不能替代工程责任。

用好它的正确方式

很多人以为 Vibe Coding 的核心是写好提示词。其实不止。

更关键的能力是：把模糊想法拆成清楚需求、判断 AI 生成的方案是否合理、知道什么时候该停下来重构、能识别安全和权限风险。

Vibe Coding 降低了"写出第一版"的门槛，但没有取消"判断好坏"的门槛。

有一个更稳的工作方式：先写清楚目标，不要一上来就说"帮我做个网站"；让 AI 先说方案再写代码，避免方向跑偏；一次只改一个明确的点，小步推进；每次修改后都运行验证，不要积累未测试的改动；功能成形后，让 AI 补测试、列出边界情况和潜在风险。

还有一个最容易被忽视的坑：看不懂的成功。AI 给了一个"看起来能用"的结果，可能只是因为你还没测到异常情况；看起来修好了，可能只是隐藏了错误。如果一个项目会长期维护，"继续让 AI 改到能跑"不是唯一策略——到了某个阶段，需要停下来梳理目录、固定依赖、补测试、检查安全，把原型真正推进到工程状态。