Vibe Coding 实战：用感觉和 AI 写出第一个小工具

Vibe Coding 不是“不写代码”，而是换一种写代码的方式：你用自然语言描述意图，AI 生成实现，你运行、观察、调整，再继续对话。它更像是在和一位反应极快的结对程序员合作，而不是逐行敲出每个语法细节。

Andrej Karpathy 提出的这个概念，核心是“跟着感觉走”。但这不意味着放弃工程判断。相反，Vibe Coding 把人的精力从语法记忆转移到需求、体验和验证上。下面用一个很小的实战案例，走一遍完整流程。

一、实战目标：做一个午餐选择器

需求很简单：我每天中午不知道吃什么，想要一个命令行小工具，随机从几个选项里挑一个。这个需求足够小，适合 Vibe Coding 快速验证。

第一步，写清楚意图。不要只说“帮我写个代码”，而是给出场景、输入、输出和约束：

用 Python 写一个命令行午餐选择器。预设几个午餐选项，每次运行随机输出一个。代码不超过 15 行，输出中文，尽量简单。

第二步，让 AI 生成初稿。几秒后，得到类似下面的代码：

import random

foods = ["牛肉面", "麻辣烫", "沙拉", "寿司", "盖饭"]
print("今天吃：", random.choice(foods))

第三步，运行。结果能跑，但很快会发现几个问题：选项写死在代码里，想加新餐厅要改代码；每次完全随机，可能连续两天推荐同一家；没有“排除昨天”的感觉。

这就是 Vibe Coding 的关键：先让东西跑起来，再根据真实使用感受迭代。

二、凭感觉迭代，而不是凭想象设计

我继续对 AI 说：

改成从外部文件读取午餐列表，并记住上一次的选择，尽量不连续推荐同一家。代码仍然保持简短。

AI 可能给出一个使用 JSON 或文本文件的版本。你运行几次，发现“不连续推荐”确实更符合直觉。然后再问：

再加一个功能：如果列表为空，就提示我添加餐厅。

这时，工具开始从一个 Demo 变成真正会用的小产品。整个过程没有画 UML 图，没有写详细技术方案，而是“用一下，感觉不对，就改”。

这就是 Vibe Coding 的节奏：小步生成，快速运行，即时反馈，持续微调。

三、最小可用版本

如果只保留最核心的逻辑，代码可以非常少：

import random

foods = ["牛肉面", "麻辣烫", "沙拉", "寿司", "盖饭"]
print("今天吃：", random.choice(foods))

这段代码很短，但它已经完成了核心价值：帮你做决定。至于持久化、排除上次、添加餐厅，都是后续根据真实需求长出来的。Vibe Coding 不追求一次写全，而是让需求在使用中逐渐清晰。

四、Vibe Coding 的实用技巧

第一，提示词要带上下文。告诉 AI 你用什么语言、运行环境、输入输出、代码长度和风格偏好。上下文越具体，生成越稳定。

第二，一次只改一件事。不要一次性要求“加登录、加数据库、加界面、加部署”。小步修改，才能快速定位问题。

第三，必须运行。AI 生成的代码看起来对，不等于真的对。运行、输入边界值、看报错，是 Vibe Coding 不可省略的环节。

第四，用版本控制。每次能跑通就提交一次。这样即使后续改坏了，也能快速回滚。

第五，保持怀疑。AI 可能生成过时 API、错误逻辑或不安全代码。涉及密钥、权限、资金和用户数据时，必须人工审查。

五、什么时候不该 Vibe Coding

Vibe Coding 适合原型、个人工具、学习实验、内部脚本和创意验证。它不适合直接生成生产级核心系统、安全敏感模块、金融交易逻辑或医疗决策代码。

原因很简单：AI 擅长生成“看起来合理”的代码，但工程要求的是“经过验证的正确”。Vibe Coding 可以加速从 0 到 1，但 1 到 100 仍然需要测试、审查、监控和架构。

结语

Vibe Coding 的本质，是把编程从“逐行实现”变成“意图驱动、快速迭代”。你负责判断要什么、好不好用、能不能信；AI 负责快速给出草稿和变体。少量代码，快速运行，持续调整，这就是 Vibe Coding 的实战方式。

它不会让工程能力变得不重要，反而让判断力、品味和验证能力变得更关键。因为当生成变得便宜，真正稀缺的，是知道什么值得生成、什么必须验证、什么不能上线。