Vibe Coding：聪明的工程师，一定会用聪明的工具

聪明的工程师一直都会使用聪明的工具，这并不是什么新鲜事。AI 编程工具的出现，只是把这件事推向了一个新的高度。

首先，AI 可以帮助开发者把大量枯燥、重复、低价值的工作交出去，比如：

• 项目脚手架搭建
• Mock 数据与接口
• 重复性样板代码
• 简单但耗时的重构

而像 Cursor 这样的工具，则让事情变得更有意思。开发者可以通过对话的方式，与 AI 结对编程，不断试探和拓展“可能性的边界”。一个高质量的 Prompt，往往能带来非常远的结果。

很多时候，AI 生成的代码不仅“能跑”，而且看起来非常合理。但也正因为如此，事情开始变得有趣：

👉 你必须真正理解代码，才能判断 AI 什么时候已经到了极限。

开发者到底该不该用 AI？

答案很简单：当然应该。

如果一个工程师刻意拒绝使用 AI，那在我们看来反而是一个负面信号。只要使用得当，AI 能让一个好工程师的生产力产生质的飞跃。

但另一个问题同样关键：

AI 能把一个差工程师，变成一个好工程师吗？

答案同样简单：不能。

事实上，AI 的存在反而会放大一个工程师是否真正理解自己代码的能力。我们见过很多工程师：

• 代码写得很漂亮
• 语法几乎从不出错
• 但对代码真正“在干什么”理解并不深入

例如，他们可能能写出完美的模块，却在系统集成、边界处理、异常场景上频频踩雷。

但当 AI 让“写代码”这件事变得极其容易时，真正的分水岭就出现了。

我们是如何评估工程师能力的？

工程师能力评估本身就是一个极具争议的话题。这里并不宣称这是“最好的方法”，但可以确定的是：它在我们这里行之有效，而且 AI 让这件事变得更容易，而不是更难。

我们并不追求“完美解法”，而是关注：

• 你为什么这样设计？
• 你权衡过哪些方案？
• 遇到了哪些困难？
• 如果重来一次，会怎么改？

👉 如果只是把 PR 和需求整体丢给 AI 来写代码，这一关通常会直接暴露。

AI 如何放大工程师的“基本功”

在今天，几乎每个人都“能写点代码”。因此，真正重要的工程师能力，早已不再是某个语言的语法熟练度。

真正关键的是：

• 对编程模型的理解
• 对编译、运行、内存、性能的基本认知
• 对架构、抽象与模式的把握

AI 在编码时可能会：

• 陷入复杂的嵌套结构
• 产生低效的内存使用
• 覆盖不存在的场景，却遗漏明显的错误来源
• 测试不足，却看起来“很完整”

工程师必须能判断：

• 什么时候这是可接受的（例如快速实验）
• 什么时候是不可接受的（生产级代码）

因此，在代码评审讨论中，我们往往并不执着于代码细节本身，而是聚焦于：

你是怎么想的？你为什么这么做？背后的逻辑和概念是什么？

真正优秀的工程师，会让我们看到一些 令人惊喜的 AI 使用方式 —— 前提是：他们能清晰解释背后的设计逻辑。

• AI 应该成为每个工程师工具箱的一部分
• AI 并不会掩盖能力，反而会放大差距
• 它帮助区分：谁真正懂工程，谁只是在“演示代码”

真正的工程能力，从来不是写代码本身，而是理解代码背后的世界。