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

确切的说，不是资深工程师，而是熟练工

@CodeCodeStudy 你懂意思就行啊，代号而已。我其实没好意思说资深/初级。好多企业喜欢这么叫，但都是人分什么三六九等呢你说对吧。

可算了吧，我都懒得看同事用豆包、DeepSeek 生成的代码，他甚至自己都看不懂。很多时候我问他的问题他都听不懂，他把我问的话再拷贝到去问豆包，真他妈无语了。

@JYii #3 那我要是让豆包再生成对应注释呢😁

以为是缩小了，但其实并没有。反而在初期就扼杀了很多初级开发成长的机会。很多都是不知道 AI 写的是啥，只是知道能跑、能实现。
但是也正好，这部分人也就会被快速淘汰掉。剩下的那一撮才是会利用 AI 快速成长缩小资历差距。

大多数情况下是节省了时间,而不是提高使用者的技术能力

基于需求进行系统架构设计

@94 对，你提到的这一点我感觉也是极大可能。现在很多小老弟直接 AI 一把梭，就像刚才楼上一哥们儿提到的，自己都不知道自己提交的是什么意思。这个确实很危险，对自身成长很不利。

是的 在简单需求上可以缩短 但是...在复杂一点,逻辑再多一点... 如果他坚持自己不再 review 一边给 AI 出出主意的情况下, 这楼说倒就倒, 并且倒了之后没有重建可能.

只能堆功能,做不了架构设计

并不是缩小了，而是加大了差距...看过很多人写的提示词，一言难尽。

工业级的项目，提示词并不能只考虑解决需求，还需要考虑架构、技术选型、难点测试、分工协作问题、代码规范与风格、已有模块与组件的对接、可调试性、注释与可阅读性、生成测试方案甚至接入自动化测试、生成文档等等。

你完全可以找个小需求，自己写段提示词，然后和高手的比一比，就知道差距了。

同意 5 楼说的，看了我司的实习生提交的代码以及 bug 反馈，感觉已经废了

@justfindu 最怕那些仅要交付不管一切的人不断用 AI 加代码，最恶毒的是并不对整个文件进行修改，而是以方法为单位不断增加冗余代码。一旧出现 bug ，这种强嵌套的结构的代码 又会造成 AI 过载产生幻觉....

不会的用这个越用越废

用 ai 做重复工作很好，生成一段 mock 数据，通过提供的数据生成表单，编写一些变量名称

并不，反之这东西会极大程度压缩初中级，以及部分看似资深的水货的生存空间，以后这个行业都不是 28 效应了，可能会达到 1-99 效应了。

其实并不是，初级才是被秒死的那个
企业更喜欢让高级替代初级 压榨高级的效率
资深属于大头兵岗位 还是要用来抗事抗压提高团队上限的

初级用了以后感觉自己能达到高级的水平水因为在初级的视角中很多不爱学习的躺平高级不学 ai 罢了，等再经过市场的清洗之后基本不会有初级中级的岗位了，要么初级快速成长为高级但是拿中级的薪资，要么高级变的更强薪资不变，原地踏步的高级和初级中级直接淘汰，估计明年会开始清洗了。

资深的不行。
或者彼此对资深开发的定义有区别。

不管黑猫白猫，抓到耗子就是好猫

作为老码农，我是觉得非常扼杀新人的机会。很多体力活，之前需要招新人干，然后顺便慢慢培养上手到可以处理相对复杂的工作。现在直接扔给 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 ，可以提高学习效率。

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

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