AI 的品味是需要，而且也在不断提高的。今天我刚好有一个例子。我有一个 VectorBuilder<T>的组件，这个组件是纯函数的，它接受 N 个 T 类型的输入，给出一个 vector<T>类型的输出。问题来了，在代码中，可以用 VectorBuilder<number>这样方式简单定义，但实际业务中，需要由用户在 UI 界面上选择这个 T 类型。在 UI 界面中，怎么决定某个组件是不是有可以配置的选项呢？这些选项又怎么呈现在 UI 界面上，供用户选择呢？
AI 给出了它的通用解决方案（这个通用的方案，还是在我一再要求下给的，之前它给的就是针对这个组件写死的方案），它的方案就是在 VectorBuilder<T>这个类型的定义里面，添加一个配置项 genericConfig ，再添加一个 applyGenericConfig()函数。
闽公网安备 35020302035485号
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 来分别判断！
```
企业更喜欢让高级替代初级 压榨高级的效率
资深属于大头兵岗位 还是要用来抗事抗压提高团队上限的
初级用了以后感觉自己能达到高级的水平水因为在初级的视角中很多不爱学习的躺平高级不学 ai 罢了，等再经过市场的清洗之后基本不会有初级中级的岗位了，要么初级快速成长为高级但是拿中级的薪资，要么高级变的更强薪资不变，原地踏步的高级和初级中级直接淘汰，估计明年会开始清洗了。
企业更喜欢让高级替代初级 压榨高级的效率
资深属于大头兵岗位 还是要用来抗事抗压提高团队上限的
初级用了以后感觉自己能达到高级的水平水因为在初级的视角中很多不爱学习的躺平高级不学 ai 罢了，等再经过市场的清洗之后基本不会有初级中级的岗位了，要么初级快速成长为高级但是拿中级的薪资，要么高级变的更强薪资不变，原地踏步的高级和初级中级直接淘汰，估计明年会开始清洗了。
但是也正好，这部分人也就会被快速淘汰掉。剩下的那一撮才是会利用 AI 快速成长缩小资历差距。