VibeCoding 很爽，但我又开始认真看代码了

前段时间换工作之后，Coding 的习惯开始慢慢调整回正常的 AI 辅助的方式，编程的习惯感觉有点像是恢复到了古法编程阶段了。

去年最开始 VibeCoding 的时候也没有那么放心，自己开发应用的时候，AI 只是辅助生成代码，我去 Review 一下 AI 生成的代码逻辑，过了半年之后，因为模型能力的进化以及老板对项目开发速度的变态要求，就开始进入纯纯 VibeCoding 阶段。

随着工作流的变化，是我对 IDE 的使用习惯也发生了变化，去年最开始用 VibeCoding 的时候，我还在用 Cursor 辅助编程，同时也预览项目文件结构和代码内容，过了半年我已经切换为 Codex，也就是我甚至不需要去看代码实现了，我只需要和 Codex 聊天就可以完成实现，我会根据 Codex 回复的内容和项目运行的效果来判断改动是否生效。

使用对话进行编程的时候，如果出了问题要调试，最直观的方式就是加日志，然后把报错的日志再扔给 Codex 来进行修复，整个流程基本就闭环了。这种编程方式不需要太懂技术也能实现，所以那段时间我有点困惑，不知道自己在公司待着还有啥意义 ...

这种纯 Vibe 的编程方式对小公司的意义在于，快速开发、快速上线、快速验证结果，真正在生产级环境稳定运行起来还是会有很多问题，需要再去研究 AI 是如何实现这些功能的。

换工作之后，新的项目要求是稳定，虽然公司鼓励使用 AI 工具，但从项目层面是不可能用纯 VibeCoding 的方式进行开发，也就是公司的项目不存在 VibeCoding 的可能性。

VibeCoding 顾名思义就是氛围编程，你不需要搞明白里面的内容，只管一个劲堆功能，只要结果大致没问题就可以，但是公司的项目要求是能稳定运行，对 BUG 率等应用指标有严格要求，这种对结果要求反推到开发这边的话，就要求每个开发人员要搞明白自己负责业务的具体实现逻辑，当出现问题的时候，能快速排错。毕竟人是对最终结果负责，而不是 AI。

公司项目不用 VibeCoding 也不意味着连 AI 都不能用，这完全是两回事。现在还是需要 AI 来辅助进行架构设计、代码编写等等，但是最终上线保证代码质量的是人。

现在在工作的时候，拿到需求首先梳理清楚需求是怎么回事，然后让 AI 出实现计划，Review 一眼开发计划是否能满足需求和整体项目的架构要求，如果没问题的话进行 AI 开发阶段，开发完之后再次 Review AI 的代码看看有没有 BUG 和实现是否符合要求，其实这个步骤很多时候是没什么问题的，人眼过一遍的目的就是为了保证实现是忠于计划的，以及我们要搞清楚具体的逻辑，我自己理解现在 AICoding 还没有进入全自动驾驶阶段的，所以开发人员是有必有有义务了解和熟悉自己业务模块的代码的。

所以文章的开头我说的是，自己有点像是回到古法编程阶段了，就是从纯 VibeCoding 切换到 AI 辅助编程阶段。

对于我自己开发小的工具项目我还是使用纯 VibeCoding，但是涉及到用户存储的工具我也会再次审查 AI 的代码，保证用户数据是安全的。VibeCoding 实在是太快了，让开发也能体验当产品的爽感。

PS: 我从我自己的角度来看，我不会使用 VibeCoding 做出来带数据存储的应用，因为担心数据丢失。VibeCoding 不那么可靠的本质让我没办法对这些应用放心。