No Coding Today 和 Vibe Coding

前些天在V站回复远程工作中，如何避免 Burnout(过劳) 的时候提到了 Anthony Fu。突然发现了 AntFu 居然主持了一档播客节目 —— 尖不想寫扣 No Coding Today。
就开始慢慢听这档播客，现在听到了他们在聊 Vibe Coding，突然就解开了我关于 Vibe Coding 的一些疑虑。

在此之前，我对于 Vibe Coding 的看法是：

Vibe Coding 只需要关注需求实现，而不是具体代码实现。所以大部分的使用者会是非开发专业的用户。
就好像我们使用AI去文生图一样，通过调整 Prompt 使得 AI 的产出实现 or 靠近自己期望目标，并不关注 AI 是怎么生成和具体的内部实现。

所以我一直觉得 Vibe Coding 的模式并不适合专业开发者，但非常适合快速 MVP 或者一次性工具类项目的场景。基本上只需要几句话就能在本地快速实现一个 Demo 去和客户 or 业务方确认需求，然后再在这个基础上去扩写功能。或者说像 JSON 数据处理和分析、图片 & PDF 的合并压缩这样的一次性工具类小项目，而且可以随意调整各种配置，来获得一个符合预期的内容产出。这些原本需要交给一个实习生花费很多时间去处理的。

从社区的很多 AI 工具推荐和使用反馈来看。大部分人并不会那么“尽心尽责”去 Review 产出的代码，AI 用得越多越深入 Review 的次数就会越少。都是在往无脑 Accept All 上面越走越远。

要不然也不会出现我在 V2ex 的这个帖子中吐槽的 #VibeCodingCleanupSpecialists# 这样的 “给 AI 擦屁股专家” 岗位了，会出现这样的岗位就说明这种现象并不是个例，而是已经造成项目管理上的困扰了。

所以看得出来我是比较反感开发人员追求在生产环境中 纯VibeCoding 这种不太负责的做法的。

Web Worker 最近一期关于 Vibe Coding 的节目中，我也提出关于这部分的困扰。很幸运抽中了 Caption 的新书 🛒 Vibe编程：探索AI时代编程新范式，可是还我没来得及拆开来看。不知道这本书会不会解答我的疑虑。

但听完听尖不想寫扣的两期节目之后_{(见文末链接中的 S1E5 & S1E6)}，我发现其实 Vibe Coding 并不一定需要说要完整的 Vibe 出来整个项目。可以把一些细小的功能拆分开来去让AI来实现，缩小它的影响范围。在自己有清晰概念、边界和规则时，在给AI安排任务它就可以十分完美的胜任了。

和 Mike Cheng 在节目中提到的一样，我最开始用 Vibe 的脚本也是在项目国际化改造时做的。把项目中的国际化JSON文件输出成Excel文件，然后给到专门的翻译人员去翻译。
在明确知道自己想要什么，以及需要怎么做得时候，按照 1-2-3-4 得步骤去让AI来实现功能。自己做甩手掌柜，只需要检查它得产出是否符合自己的需求就可以了。不需要自己再去读 NodeJS 和 ExcelJS 的文档开发起来明显就轻松了许多。

如果它生成的结果和你预期的有问题，那么我就需要继续拆分任务明确细节，让它去接近我期望的样子。就和我们去安排工作给实习生的时候是一样的。

所以我之前就是这样使用 Vibe Coding 的，不过自己没有意识到。因为当时 Vibe Coding 这个名词还没有出现，我也还在使用 Github Copilot。

只是最近社区中各种各样的使用反馈所带来的噪声，反而影响到了我的感知和判断。觉得一定要和 Vibe Coding 的定义一样来使用它，不然就不是 Vibe Coding 了。让我产生了 “不写代码的甩手掌柜式” 的这种刻板印象。开始抗拒，甚至讨厌起来。

相关资源