Vibe Coding 久了之后的一点想法

以前写一个模块出来有啥问题手拿把掐，出个小问题直接就知道是哪里导致的

现在写一个模块出来，出个小问题还得继续 vibe 。。。。

我一个十年开发老菜鸟，感觉 AI 能提高我的方方面面，包括架构能力。
为数不多的脑细胞能学习 AI 给出的大神解决方式，更多思考架构。

唯一需要注意的是：AI 给出的用次等劣等实现方式时，纠正它，这时就用到 过去 10 年的经验储备。

今天把需求从 500 行扩充到 1000 多行，并完成了需求的 80%

@auhah 哈哈哈真实了。。

我 vibe 了一天，发现是有两个重名文件，难怪半天改不对

自己写 AI 题词可以，vibe 这种一次性生产一大片的，不敢用。

我个人是把 AI 当搜索引擎用，以前有东西不知道怎么实现好的时候就去网上搜别人的代码然后 copy ，现在问 AI 也是差不多的

我认同你的部分说法，但并不完全认同，因为并非所有问题都是一致的，你说的我觉得更多对于解决特定问题是正确的思路，但对于业务开发来说，这并不一定适用：

> 对程序员而言，长期过度依赖自然语言来表达和解决问题，可能会削弱原有的编程思维。

我不认同。我认为大部分程序员最欠缺的就是表达能力（我不特指自然语言表达能力，因为我也不认可 prompt 要用自然语言表达）。对于解决特定的问题，我认可 “Talk is cheap, show me your code”，但对于需求（特别是产品层面的需求），我从来都不认可 Framework First 或者 Coding First （除非要解决的是工程化问题）。一个业务功能，我从来都是要求设计优先，甚至是配置优先（先写你要怎么配置 —— 我会说 `Design is cheap, show me your config`）。

我认为 AI 的出现就是一个契机，那些连需求都表达不清楚的人，他们连 AI 都用不好。最终一定会被淘汰。

> 面对问题时的第一反应不再是 “先敲一段代码试试深浅”，而是 “先写一段 prompt 问问 AI”。

我认为，对于 **业务开发** 的程序员：

首先不应该有 “先敲一段代码试试深浅” 的这个想法
也不应该有 “先写一段 prompt 问问 AI” 这种想法
你的第一件事情应该是 “先理解自己的需求”

AI 的出现正在迫使部分人员准确的描述（理解）需求，我认为这是好事。

> 指望 AI 直接生成解决方案，或者更多时候是在这个基础上 review 。

归根结底极力推崇 AI ，但我一点也不喜欢 Vibe Coding 这个概念（或者是狭义的 Vibe Coding ）。
这个狭义的理解正在 **纵容** 人们把 AI 当成神话一样的存在，纵容人们对 AI 的不切实际幻想。

一个标准的生产流程（无论是在哪个行业哪个岗位）都应该是类似：调研、（分析）、设计、验证、实施、迭代。（ Vibe Coding ）
而狭义的 Vibe Coding 理解正在引导人们将这些步骤简化为：提出问题，生成答案。

而我认为，正在践行这种理念的人，即使没有 Vibe Coding ，他原本的习惯也一定不是很好。

我的观点就是：我们可以批评 Vibe Coding ，但不要把所有的错都怪在 Vibe Coding ，如果你认为他不正确，那不用就好了。

以及，AI Coding != Vibe Coding

vibe coding 带来的思考能力下降可能有其它方面的原因吧，例如，正好在 vibe coding 的成瘾阶段导致坐在屏幕前的时间变长，运动时间变少，各项导致的身体健康情况下降

em 我现在不敢给他写很大的功能 一般是我拆 先分析思考实现给他指令编写

antigravity 的做法其实就比较好的，给一个指令给他，会做需求理解和代码分析，出方案设计，讨论完了出执行计划，然后不断的沟通，最后出一个总结，重要的东西看着几个基本都了解了，代码方面，要求符合 solid 之类的，基本都能贯彻得不错，当然，输出的代码，其实还是要过的，人会偷懒，ai 一样的，有时候也会有很多问题，但总的来说，还是省了很多事情

缺乏对细节的了解就不容易在出问题的时候快速接手，如果项目不严格可以考虑，如果是严格的生产项目还是得古法。