背景

有一段时间没写文章了，想想最近在干什么，跟着AI的浪潮一直在疯狂冲浪，这几天突然感慨良多，写篇文章聊聊 AI时代，程序员经验会不会被时代淘汰

前段时间整理旧博文，翻出来我早年写的《Java 工程师入职 —— 配置环境及安装开发工具》，Java工程师入职——配置环境及安装开发工具_java开发第一天上班安装-CSDN博客 感慨一下子涌上心头，一晃几年光景，新人入职做后端开发的方式，已经彻底变了模样。

深耕十余年后端，博主从传统Java后端到前后端都做-->大数据 --> python开发 --> AI应用开发（全栈），这一路踩过的坑的确很多。

当年写那篇文章初衷很简单，新人刚入行 Java 后端，十有八九卡在环境搭建上：下载 JDK、自定义安装路径、配 JAVA_HOME、改系统 Path，接着装 Eclipse 或者 IDEA，挨个配置 Maven、Tomcat、SVN，pom 依赖冲突、JRE 版本不匹配、Tomcat 端口占用，光是踩环境坑就能耗大半天，我那篇文章当初就是为了帮新人少走弯路，一步步把从 JDK 到项目跑通的流程写得明明白白。那时候咱们口中的入行，就是亲手把整套环境从 0 搭起来，每一个配置项代表对底层的一点点理解。

一、当下真实现状：只会套AI的新人开发常态

但最近带团队招新人，亲眼目睹现在的开发模式，落差实在太大。想要新建一个 SpringBoot 后端项目？不用下载 JDK、不用折腾 Maven 仓库、不用手动引依赖，打开 AI 对话框，一句话描述需求，几分钟整套项目目录、yml 配置、分层代码全部生成完毕，直接导入 IDE 就能启动。全程没有手动碰过一次环境配置。碰到 pom 依赖版本报错、项目启动异常，第一反应不是打开依赖树排查冲突、看启动日志定位异常点，直接把报错全量粘贴给 AI，等着 AI 修改代码和配置。

闲聊的时候我试探着提问：这个项目的 Maven 依赖为什么这么配置？JDK 版本选 1.8 而不是 17 的底层原因在哪？接口报空指针从哪块代码开始排查？yml 里线程池参数配置依据是什么？数据库查询出现慢 SQL 该从哪几步排查？得到的答案大多一致：不清楚，代码是 AI 写的，出问题继续问 AI 就行。还有就是线上偶发疑难 bug，日志丢过去 AI 改完能临时跑通，但深层根因、内存溢出、并发锁失效这类疑难问题，新人两眼茫然，既看不懂 AI 生成代码的逻辑，也没有独立 Debug 思路，完全把 AI 当成了万能拐杖。

二、我的核心观点：AI提效，但替代不了经验

由此最近一直在琢磨着个问题：AI 编程大行其道的当下，传统一步步搭环境、手写代码的 “古法编程” 是不是彻底落伍？真的没用了？我们这帮摸爬滚打十来年、靠踩无数坑攒下经验的老程序员，未来真的要被 AI 淘汰？

先说我的切身观点：AI 是绝佳的效率工具，但永远替代不了沉淀多年的开发经验，古法编程打磨出来的底层基本功，恰恰是现在很多纯 AI 派新人缺失的核心能力。

AI 的优势固定在标准化、模板化、重复性编码工作。初始化项目脚手架、批量生成重复工具类、常规 CRUD 接口、简单工具方法，这块 AI 效率碾压手动编码，以往我大半天搞定的基础工程，AI 几分钟就能落地，这点我日常开发也一直在用，从来不排斥 AI，必须承认 AI 给开发减负太多。但 AI 本质是基于海量训练数据做概率输出，它只会输出 “看起来合理” 的代码，看不懂复杂业务上下文，没办法吃透项目长年累积的业务历史、隐藏的业务规则，更不清楚生产环境服务器配置、数据库索引设计、高并发场景下的隐性风险。

之前项目压测就碰到典型案例：新人用 AI 生成的接口，压测并发上来之后频繁 OOM 宕机。新人反反复复把报错丢给 AI，AI 不停修改代码，改完之后临时能跑，一上高并发照旧崩溃。最后我靠着多年 JVM 调优、线上故障排查的经验，翻阅 GC 日志、梳理代码链路才找到问题：AI 在循环体内不停创建大对象，没有做资源回收，同时数据库连接池参数照搬通用模板，没有结合项目服务器内存、并发量级做定制化调整。这种需要结合落地经验、底层原理、业务场景综合判断的问题，AI 没有真实上线踩坑经历，天然无法精准解决。而早年我们一点点手配 JDK、调试 Maven、排查 Tomcat 异常、一点点啃底层源码的古法经历，潜移默化把底层原理刻进了开发思维里，这就是古法编程留给程序员的隐性财富。

现在不少年轻开发者陷入误区：觉得只要会写提示词，就能做后端开发，环境、底层原理、代码逻辑全都不用深究。小 demo、内部简易管理系统依靠 AI 确实能快速落地，可一旦对接复杂政企业务、海量数据存储、高并发交易场景、线上突发生产事故，纯 AI 编程的短板会瞬间暴露。AI 给出的修复方案大多治标不治本，修补一个 bug，悄悄埋下内存泄漏、并发安全、数据一致性的隐藏隐患，等到线上批量出问题，团队没人能拆解问题根源，才是项目最大隐患。

三、程序员正确的打开方式：古法打底，AI增效

当然我不是抵触 AI 编程，相反现在我日常开发也天天用 AI：生成单元测试、写重复性工具类、查冷门 API 用法，写前端代码，前端样式，数据库脚本等等，把自己从机械重复的编码里解放出来，把精力放在架构设计、业务拆解、方案评审、疑难问题攻关上面。正确的思路从来不是排斥 AI，而是古法功底打底，AI 辅助提效：自己先理清业务逻辑、梳理技术方案，再让 AI 落地基础代码，AI 输出的每一段代码我都会逐行审阅，校验逻辑合理性、排查潜在漏洞，不合适的地方手动优化修改，把控代码质量与生产可行性。

回望早年蹲在电脑前，一点点配置环境变量、因为 javac 命令报错反复核对路径、为 Maven 依赖冲突熬到深夜的日子，当时只觉得繁琐煎熬，现在才明白，那些折腾的岁月都是在夯实基本功。工具永远在迭代，从汇编到高级语言、从原生 JDBC 到 MyBatis、从手动搭建项目到 AI 一键生成，每一轮技术变革都有人喊程序员要失业，但最终被淘汰的从来不是有经验、懂底层的开发者，而是只会依附工具、没有独立思考能力的从业者。

未来程序员行业会慢慢分化成两类人：一类只会堆砌提示词，看不懂代码实现、不会 debug、不懂底层原理，纯粹做 “AI 搬运工”，随着 AI 模型持续迭代，可替代性极高；另一类手握古法编程沉淀的基本功，懂原理、懂业务、懂线上落地风险，能够驾驭 AI、把控代码质量、解决 AI 处理不了的疑难问题，AI 反而会成为他们提升效率的翅膀，个人价值只会越来越高。

编程经验不会过时，只是经验的变现形式变了，从手写全量代码，变成指挥 AI、兜底项目风险、把控项目、解决 AI 解决不了的难题，换了一种形式继续发挥价值。

我不会说哪种方式一定对，或者一定错，我觉得这只是时代的一个潮流，一层层的大浪淘沙，我们都是冲浪人，希望每人努力的人都能拥抱AI，做自己的人生主宰。

附早年入职环境搭建原文：https://blog.csdn.net/Alex_81D/article/details/91469641