大家如何看待 vibe coding

> you've reviewed, tested, and understood

这是关键。生命安全、财产安全、信息安全相关的代码，每一个字检查过来都不够。以后你住的高楼，是用 vibe coding 生成的代码计算的结构力学，想想就刺激。

与其写一大堆文字让 LLM 去做一个功能，不如直接手写代码。

最好还是自己能知道自己在干吗
一个最好的例子： https://www.reddit.com/r/ProgrammerHumor/comments/1jdfhlo/securityjustinterfereswithvibes/

看你写什么了，如果只是玩玩 vibe coding 很快的

改天谁直接在互联网上投毒，发布些有后门的代码，等 vibe coding 用起来，然后一把梭全给你服务器加密勒索

现在二极管太多了，要不就是一个字一个字敲，要不就是无脑劝人 vibe 。我觉得一个开发者应该自己去探索 AI 能帮助自己到哪，而不是天天在评论区尝试说服别人。

帖子开头引用的 Wikipedia 的段落就是很棒的看法。

全靠 LLM 生成出来的项目，你可以拿来用，可以说是你的作品，但是当你对基本概念跟项目结构都不能把握好的时候，它跟你上网随手摸了一个压缩包下载下来编译运行的场面差不多，除了多了一个能帮你试错、配环境和改错的大模型。
需要改动和修问题时不知道怎么指挥和定位问题，那就是靠大模型来帮你乱撞了。有的用户连如何描述一个问题都做不好，全靠大模型靠常识的猜测来兜。

自己对项目到底了不了解，越是遇到复杂或者技术栈不热门的项目越容易原形毕露。


假如是初学者，我们来整一个 ToDo List App ，好，这种场景你用 LLM 哗啦一下给你工作流排好然后开始生成全栈代码，最后也跑起来了，ok 。问题来了，你学到了什么？学到了怎么一句话提出模棱两可的问题？还是学到了大模型多牛逼 xx 又要失业了？它是怎么知道昨晚这一步然后下一步是什么的，到头来还得自己查。查吧又因为一开始基础知识也没有，搜索关键字都不一定能踩对。

如果是初学者，手搓一个 ToDo List App ，从技术栈选型开始，你就被要求要有自己的思考跟选择。你选了 React ，下面你通过实践知道了它内部的机制是什么样子的，知道了为什么网上搜到的旧教程是 Class Component 而新的都全部转为了 Function Component ，知道了它的 Hook 机制提供了怎样的状态与 UI 绑定的设计思路，知道了有异步请求时组件设计要把载入中、完成、出错等待重试的状态都设计进去，知道了工程目录的组织结构可以怎样设计和拆分，顺便还学到了 CSS 真的是个大坑。假如你让 LLM 帮你做完这一堆，到头来随便开一个文件都是看天书，从哪开始看都摸不着头脑。


如果已经是从业者或者有基础的，用这套工具做单元测试、做脚本工具、把重复的工具类工具函数之类的代码快速整完来协助提效，你会说这叫 Vibe Coding 吗？这就是个正常用 AI 辅助自己工作流的行为。全靠提示词来整项目就跟低代码平台一样，用在复杂一点的场景那都是挖坑高手，越往后坑越大。

造玩具造工具随便造，但是也请不要把那些样板页一样的产出叫做作品然后在网上到处发，至少带上点自己的理解和设计吧。

Vibe Coding 这个概念太宽泛了。
严格的 Vibe Coding 是指在完全不懂软件开发的前提下利用 AI 做开发。
比如你是个厨师，突然想做一个做饭的 App ，然后让 AI 帮你搞，这就是典型的 Vibe Coding 。
但如果你本来就是个程序员，写过几年代码，也知道前端后端数据库都是怎么回事，知道自己要写的软件需要用到哪些软件栈，功能需要怎么分类到不同的功能区，前端需要加哪些元素，后端需要预留哪些接口方便以后扩展。这其实和 Vibe Coding 并不是一回事。

当你对着 LLM 说的第一句话是，利用 XX YY ZZ 技术构建一个 AAApp ，实现 A B C D 功能，的时候，就已经不算是严格的 Vibe Coding 了。

那些地址 vibe coding 的，怕是以后连 coding 的机会都快没了

@ixcode 抵制

vibe coding 就以我的使用经历来说，会钝化我写代码的直觉。在 ai editor 里，更多时间是等着自动生成代码，然后 review 没有问题直接 tab ，或者 tab 以后修改逻辑。时间长了以后脱离 ai 封装一些 class 和 function 都变得有些吃力。目前已经移除了编辑器中集成的 ai 了，只用 chat 来学习一些 demo 。现在大部分时间是在阅读文档和查阅项目依赖包的 issue 来解决工程问题。

怎么感觉这又是某群体发明一个“高大上”的词来粉饰其不成熟的行为呢？:-D

各有利弊，如何将其驾驭好是关键。bug 制造者 -> 屠龙宝刀

又是血统论。
是不是还得转进到用 IDE 不如用编辑器，用编辑器不如用记事本，用记事本不如打孔。

程序员产出代码，不管是通过什么手段，直观、可读、逻辑清晰、符合原则、健壮。那就是好代码。如果语法和格式契合企业标准，那就更好了。

你用你的打孔带，我用我的 AI ，最终产出一样，那就是一样的。谁也不比谁高贵。


还是不要把用 AI=埋雷，手撸=稳定、健壮这种刻板印象二极管思维带入到软件工程这种领域吧。

想当初，用记事本手撸 vbs 代码还是一种“高贵”。这才 15 年，“高贵”就已经贬值成不用 AI 了么。

btw：我个人理解，现在用类似 vibe coding 来地图炮别人的人，其实和当初万事不决 SSH ，微服务，vue ，php ，VSCode 的是一拨人。只认为自己会的、用的工具才是最先进，最好的。

殊不知所有的工具没有好坏之分，只有是否适宜之别。你的斧头即便是金的，他也一样不擅长吃饭夹菜。

@sentinelK 我觉得没有必要这么着急开始滑坡。并不是说用 AI 来编程就是 vibe coding ，vibe 强调的是一种不加思考的面向结果编程（但其定义依然很模糊），并不是像 IDE 和记事本这样的党内斗争。

@sentinelK #16
> 其实和当初万事不决 SSH ，微服务，vue ，php ，VSCode 的是一拨人
我再加一个，docker 。

> 殊不知所有的工具没有好坏之分，只有是否适宜之别。你的斧头即便是金的，他也一样不擅长吃饭夹菜。
我不是很懂你对 vibe coding 是怎样的理解，但还是觉得你这句话有点文不对题。vibe coding 带来的争论并不是“AI 这样的工具是否适合拿来 coding”，相反，我认为 AI 现在能胜任一部分范围内编程工作已经成为既定的事实。

vibe coding 给我带来的疑问在于，一个程序员对自己开发流程的理解，他的责任心以及他长期以来所积累的技术经验是如何轻易地允许他接受以一种 vibe 的方式去构造产品（如果是单纯的 throwaway weekend project 就没什么好说的了）。如果他的确是一个有经验者，我好奇这样做的理由是什么。如果他并不具备这些经验，是一个晚入局者，又为何以外行的视角来企图撼动现有的工程大厦。

@sentinelK 仔细看了你列的这几个
> 万事不决 SSH ，微服务，vue ，php ，VSCode

遇事不决微服务，遇事不决 vue ，遇事不决 VSCode 这我都可以理解，因为很显然不止这些选择，怎么就非要用那一个呢对不对？ PHP 我觉得是在玩梗。SSH 出现在这种语境下面我有点不太能理解了。

今天尝试了一下 vibe coding ，确实有帮助。

不过模型的差异对效率有较大的影响，低质量的模型需要多次修正才能达到可用的效果。
不过比自己写要省精力。

如 DS 我需要修正 3-4 次，claude3.7 需要 1-2 次就能明白。