Vibe Coding的看法与思考

什么是Vibe Coding？

Vibe Coding（氛围编程 / “AI 手搓”）是 2025 年 2 月由 OpenAI 联合创始人、前特斯拉 AI 负责人 Andrej Karpathy 在 X 上提出的概念，原话是：

“有一种新编程方式我叫 vibe coding——完全交给感觉，拥抱指数级，连代码存在都忘了。”

他当时描述的是自己用 Cursor Composer + Claude Sonnet，配合语音转文字 SuperWhisper 口述需求，AI 生成的改动他一眼不看 diff，全部 accept，跑起来就继续；崩了就把报错贴回去让 AI 修。这种”跟着感觉走、代码爱谁谁”的写法就是原教旨 vibe coding。

它和普通”AI 辅助编程”不是一回事

这点很多人会混，Simon Willison 给过一个清晰的划线：如果 AI 写了代码，但你 review 了、测试了、能讲清它是怎么工作的——那叫”AI 辅助的软件开发”，不叫 vibe coding。

所以 vibe coding 的核心特征是 “不读代码”——人只管描述意图 + 验收结果，实现细节全交给 LLM。

典型工作流

• 用自然语言丢需求：”给我搭个js 的小应用，记录我读了哪些书”
• AI 生成文件、依赖、样式、逻辑
• 你不看 diff，直接 run
• 跑通了就继续堆功能；崩了就贴报错回去让 AI 修
• 循环直到”能用了”或”放弃了”

适合用在哪

• 周末 throwaway 原型——想验证个点子，几分钟内出 demo，不行就扔
• 个人小工具——批量重命名脚本、Chrome 插件、自用小页面，无用户无安全压力
• 学新东西时摸感觉——想看看某个 API 或框架长啥样

坑在哪

Karpathy 自己也说”周末玩具项目还行，挺逗的”。真往生产放的话问题很明显：

• 你看不懂的代码 = 你修不了，项目一大 debug 会疯
• 技术债滚得快，AI 为了跑通可能绕出奇怪实现
• 安全隐患，黑客视角看 vibe coding 生成的代码是块肥肉
• 维护者离职 = 项目报废，因为没人真正理解代码

Vibe Coding的一次尝试

背景：AI工具生成的文档或者报告大部分是markdown格式或html格式。基于此场景，期望对这些此部分文档进行很好的管理。

期望：这开发一款桌面工具，左侧是文件树，可以管理相关的文件，右侧调用浏览器内核，渲染HTML文件和Markdown文件。

最终效果：

使用Vibe Coding遇到的问题与卡点？

1、技术栈的选择？

对于一些没有技术经验的同学，可能不清楚应该用什么技术栈？或者使用AI工具，让其推荐合适的技术栈。

所以在开发之前，建议让AI先推荐适合的技术栈。然后的再制定开发需求

这里我选择的是Tauri 2。其实在该场景下使用Electron更加合适，Rust在性能层面的优势在该场景下根本表现不出来，还新引入了的一种语言，导致复杂度其实是偏高的，Electron唯一的缺点是它会把Chromium打包进安装包。对于有系统洁癖的人来说，每安装一个Electron都在在系统重安装一个Chromium，个人比较受不了。

2、AI能实现相关的功能，但中间的会出现无法预知的问题

• 问题1：文件树打开以后会在虚拟环境创建，虽然创建打开的D;\文档 但是在实际磁盘中无法找到。
• 问题2：HTML中的链接无法正确打开，点击无反应，让其修复后，产生新的问题：点击链接打开一个新的文件树
• 问题3：历史打开的文件目录，再次打开后需要重新设置，没有将已打开目录记录

当前存在的问题。

• 针对遗漏的功能，如记录上次打开的目录、添加对文档的排序功能（并记录），增加大纲显示都可以通过后期提示完成
• 针对一些无法预知的问题，调试起来非常的困难，花费时间非常的长，即时反馈了现象与问题，也需要一次次的重复修改后再验证，目前代码在为未知异常场景下的修复能力很弱。

我对Vibe Coding的看法

目前来说基本满足小工具的开发，但是详细的开发需求文档也是必须的。另外对于测试，这块会比较耗时。比较适合拿来重复发明轮子。做一些小而美的工具。

判断一个场景该不该 vibe，就看一件事——”出错的成本谁承担，出错的后果多严重”。