Vibe Coding 是什么——新的开发范式还是营销噱头
Vibe Coding 是什么——新的开发范式还是营销噱头
适读人群：对AI辅助开发有好奇心的工程师、想了解Vibe Coding真实效果的人 | 阅读时长：约11分钟 | 核心价值：老张亲测Vibe Coding的真实体验，搞清楚它能用在哪、不能用在哪
三个月前，我决定做一个小实验。
我要用纯"Vibe Coding"的方式——就是完全用自然语言描述需求，不手写任何代码，让AI全程写——来完成一个真实的小项目：一个命令行工具，用于批量分析我的文章目录结构，统计字数、提取标签、生成索引文件。
这不是玩具项目。我有真实的使用需求，功能不复杂但有几十个边界case。
我想知道：这条路到底走不走得通？
什么是Vibe Coding
这个词大概是2025年初开始流行的，最早是Andrej Karpathy在社交媒体上提到的一个概念。意思是：你不写代码，你只是描述你想要什么，AI帮你写，你负责"感受"（vibe）整体方向是否对，而不是逐行理解代码细节。
听起来很美。代码是执行层，你只需要关心意图层。
但这个概念出来之后，两种声音都有：一种是"工程师要失业了"，另一种是"这不就是美化版的代码补全吗，有什么了不起"。
我不想靠猜，所以去试了。
实验记录
第一阶段：起步顺利（前2小时）
我的第一条指令是这样的：
"我需要一个Python命令行工具，扫描指定目录下的所有markdown文件，统计每个文件的字数（按中文+英文单词算），提取文件中出现的所有以#开头的标签，按字数倒序输出一个汇总表格，同时生成一个index.json文件记录所有文章的元数据。"
AI给了我一个可以运行的脚本，大概150行。我跑起来，基本能用。字数统计有点问题（没有正确处理中英文混合），我用自然语言说："字数统计不对，中文要按字符数算，英文要按空格分隔的单词数算。"它修了。
这个阶段的体验是好的。速度快，我不需要想"用什么库、怎么遍历目录、怎么解析markdown"，直接描述结果，能跑。
第二阶段：开始失控（第3-5小时）
问题从需求变复杂开始出现。
我想加一个功能：如果文章有frontmatter（就是markdown开头那段---包起来的yaml），也要解析出来，优先用frontmatter里的标签，没有就fallback到正文里的#标签。
我描述了这个需求，AI修改了代码。能跑，但只对部分文件有效。我再描述问题，它再改。改了五六次，每次它都说"好了"，实际上还有其他case没覆盖。
问题在哪？在于我开始花大量时间描述我发现的问题，而不是解决问题。这个过程比我自己去读代码、定位问题、修复，要慢得多。
为什么？因为我没有在看代码。我是在"感受"，但"感受"不够精确，我描述问题的方式也因此不够精确，AI能猜中我真实意图的概率就降低了。
第三阶段：我妥协了（第6小时）
到最后，我对一个字符编码的边界case放弃了纯自然语言的方式。我打开了代码，看了看，发现是一个utf-8和gb2312编码识别的问题，三行代码可以修掉。
我自己改了。
然后项目完成了，总共花了大约6个小时。
我的真实判断
这6小时里，我理解Vibe Coding是什么了，也理解了它的边界在哪。
Vibe Coding真正有用的场景：
1. 原型验证阶段。 你有个想法，不确定是否可行，想快速跑通一个demo看看效果。这个场景下，代码质量不重要，能跑就行，Vibe Coding非常适合。一两个小时能验证一个想法，比手写快得多。
2. 你不熟悉的技术领域。 比如我不太会前端，让我用React写一个管理界面，我可以用Vibe Coding的方式快速得到一个能用的东西，然后基于它调整，比从零学React再写要快。
3. 明确、有限的单一任务。 "给这个CSV文件写一个数据清洗脚本"、"把这个JSON转换成这个格式"。任务边界清晰、需求不会变化的场景，Vibe Coding效率很高。
4. 不需要长期维护的一次性脚本。 用完就扔的工具，代码质量不需要考虑，速度就是一切。
Vibe Coding根本不靠谱的场景：
1. 有复杂边界case的生产代码。 边界case需要你有领域知识去识别，你看不到代码就发现不了它，发现不了就没法精确描述，AI也就补不上这个漏洞。
2. 需要长期维护的系统。 Vibe Coding产生的代码往往缺乏一致的架构逻辑——因为每次修改都是局部修补，没有人在全局做设计决策。这样的代码维护成本会随时间快速累积。
3. 性能敏感的场景。 AI写的代码通常是"能跑的"，不是"跑得快的"。数据库查询优化、算法效率这类事情，需要你真正懂代码，才能判断哪里有问题。
4. 安全相关的代码。 认证、权限控制、数据加密。这类代码你必须看，不看就是埋雷。Vibe Coding产生的安全代码往往有你不知道的假设，而那个假设可能在你的场景下不成立。
一个更尖锐的问题：Vibe Coding会让工程师退化吗
我认识几个最近刚开始工作的工程师，他们写代码基本就是Vibe Coding的方式——描述需求，AI写，调整，再让AI改。完全不去深入理解代码。
我觉得这对他们来说是一个危险的习惯。原因不是"AI会被淘汰所以你要会手写代码"，而是另一个逻辑：
你判断AI输出好坏的能力，来自于你对领域的理解深度。 如果你本来就不懂代码，AI给你的补全再精准，你也无法辨别它是否正确、是否有潜在问题、是否适合你的具体场景。你会接受所有看起来能运行的代码，最后出了问题也不知道问题在哪。
Vibe Coding对有经验的工程师是加速器，对没有基础的人是麻醉剂。
它真的只是营销噱头吗
不完全是。
"Vibe Coding"这个词的出现，捕捉了一个真实的开发方式演变：越来越多的工程师开始用高层次的意图来驱动AI，而不是逐行写代码。这个趋势是真实的，而且会继续发展。
但"Vibe Coding等于不需要写代码、不需要理解代码"这个推论是错的。准确的说法是：代码的编写越来越多地由AI来做，但代码的设计、判断和质量控制仍然需要工程师。 这个中间地带就是2025年的工程师需要占领的位置。
所以我的判断是：Vibe Coding是一个真实存在的开发方式，在特定场景下很有价值，但它不是"不需要技术能力的开发"，它是"把技术能力重心从编写转移到判断和设计"。
对经验丰富的工程师来说，这是解放。对刚入行的人来说，如果跳过了基础能力的积累就直接Vibe Coding，未来会有麻烦。
我现在怎么用Vibe Coding
实验之后，我没有放弃Vibe Coding，但我用得更精准了。
我会用它来：
- 快速生成新功能的骨架代码，然后我来填细节
- 写单元测试（描述测试场景，AI写测试代码，我检查覆盖度）
- 处理格式转换、数据清洗这类明确的机械任务
- 快速验证一个技术方案是否可行（原型）
我不会用它来：
- 写核心业务逻辑（要看、要理解、要自己负责）
- 处理安全相关的代码
- 在没有单元测试覆盖的情况下改动关键路径
这不是什么复杂的策略，就是把Vibe Coding当作提效工具，而不是替代思考的工具。