AI 以后能否替代码农不好说，但现阶段真的缩小资深/入门开发之间的差距

很容易理解的事情：

1 如果这位初级他敏而好学，那么没有 AI 他也能快速成长为中高级，AI 只是加速
2 如果他只 vibe coding 而不看不学，那么不远的将来你们项目将迎来爆炸💥，他得换个地方冒充中高级，但是没有 AI 的时候这种水货已有很多。

AI 的品味是需要，而且也在不断提高的。今天我刚好有一个例子。

我有一个 VectorBuilder<T>的组件，这个组件是纯函数的，它接受 N 个 T 类型的输入，给出一个 vector<T>类型的输出。

问题来了，在代码中，可以用 VectorBuilder<number>这样方式简单定义，但实际业务中，需要由用户在 UI 界面上选择这个 T 类型。在 UI 界面中，怎么决定某个组件是不是有可以配置的选项呢？这些选项又怎么呈现在 UI 界面上，供用户选择呢？

AI 给出了它的通用解决方案（这个通用的方案，还是在我一再要求下给的，之前它给的就是针对这个组件写死的方案），它的方案就是在 VectorBuilder<T>这个类型的定义里面，添加一个配置项 genericConfig ，再添加一个 applyGenericConfig()函数。
```
getGenericConfig?(): Record<string, {
label: string; // 菜单显示名
type: 'select' | 'number'; // 控件类型
value: any; // 当前值
options?: any[]; // select 的可选值
min?: number; // number 的最小值
max?: number; // number 的最大值
}> | null;

applyGenericConfig?(config: Record<string, any>): BaseComponent;
```

然后被我一通批判：
```
我觉得，最好不要将这些接口，比如 applyGenericConfig ，放到组件的定义里面！我来说明一下理由，这些接口，本质上仅仅是替换一下类型，与组件本身的功能几乎没有关系，比如 VectorBuilder 这个组件，将 number 替换为 string 类型，不应该由 VectorBuilder 来考虑实现类型替换这件事。可选的类型或者可以选择的配置，也不应该是 VectorBuilder 这个组件本身需要关心的事，因为 VectorBuilder 就是一个包含泛型的类！

所以，我完全不能接受将这些东西放到组件定义里面！！

当然，你的这个通过配置来实现通用化的方法，还是比较好的，但是能不能拿到组件定义的外面呢？而且，最好也不要写一个统一管理的函数，在里面用 if else 来分别判断！
```

@vcyuyu 确实 半年前我已经把离职的同事代码用 ai 重构过 重构过才能看得下去...

维护也让 ai 维护吗。有个说法是你以大模型速度产生技术债，最终会变得难以维护。

无非是面向百度变成改为面向 AI 编程，效率提高了。
不愿意学习的人，有没有 AI ，都是复制黏贴。
愿意学习的人，通过 AI ，可以提高学习效率。

大项目会遗留非常多的技术债务，而且堆积的太快了

现在还看汇编吗?看得懂吗?历史的车轮不会为谁而停下.

能正确理解需求，用 AI 写出稳健代码提交，这个同事算是资深了。

真正的初级，你把需求告诉他，他都不知道怎么让 AI 出活。

@1zh3n 不用担心，这是必然事件。
让 ai 维护的前提是你要让 ai 完全了解所有代码的结构，但实际的上下文，ai 不可能了解这么多，所以 ai 实际只能一块一块的去处理。不可能考虑到所有地方。到这个时候，麻烦的事就来了

现实是入门程序员的需求变小，资深程序员的需求变大。以后想进入程序员行业的门槛越来越高，不像移动互联网刚开始那会只要想就能进，很多人还是跨行学会一个编程语言就能入行。

debug ai 写的代码时也能体现出差距

现在是 1 个资深加 3 个初级，以后是 1 个资深加一个 AI
现在是 3 个初级，以后是 1 个初级+AI
现在是 3 个资深，1 个初级，以后是 3 个资深+1 个初级+AI
AI 可以很好的代替初级，代替资深还是有点困难