这两年，AI 编程已经从“新鲜工具”变成了很多程序员日常工作的一部分。

尤其是对初级程序员来说，AI 的帮助非常直接：不会写的代码可以问，卡住的报错可以贴，接口、SQL、测试、脚手架代码都能很快生成。

这当然是好事。

但我越来越觉得，AI 编程时代，初级程序员真正的风险，不是不会用 AI，而是太早用错了 AI。

因为 AI 降低了很多开发门槛，也更容易让人产生一种错觉：

只要代码能生成出来，自己就已经掌握了这项能力。

这往往才是问题的开始。

短期看，AI 会让人写得更快；长期看，如果使用方式不对，它也可能把一个人的成长路径带偏。

我觉得初级程序员最容易走错的，通常是下面 3 条路。

1. 把提示词当成核心竞争力

很多人刚开始接触 AI 编程时，最容易关注的是提示词。

怎么提问更准确，怎么让 AI 生成得更完整，怎么写出“更像样”的 prompt，这些当然有价值，但问题在于，很多人会不知不觉把它当成最重要的
能力。

这就很容易走偏。

因为提示词只能放大你的问题表达，不能替代你的问题理解。

如果你对需求本身理解不清，对系统边界没有概念，对上下文关系也没看明白，那么提示词写得再漂亮，本质上也只是换一种方式去碰运气。

AI 很可能会给你一段看起来不错的代码，但你未必知道：

• 这段代码是不是解决了真正的问题
• 这段实现有没有遗漏边界条件
• 这段逻辑放在这个层次到底合不合理
• 这段代码会不会破坏现有设计

所以从长期看，真正更值钱的不是“会不会写提示词”，而是：

• 你能不能把问题拆清楚
• 你能不能把需求讲明白
• 你能不能判断 AI 的输出是不是靠谱

提示词是工具层能力，问题拆解和判断能力才是核心能力。

如果一个初级程序员把大量精力放在“怎么把提示词写得更花”，却没有同步补足基础和判断能力，那成长路径很容易失衡。

2. 把生成代码误当成解决问题

这是第二个特别常见的误区。

AI 最擅长的事情之一，就是把“代码写出来”。

很多时候你给它一个需求，它很快就能补一个接口、一段 service、一份 SQL，甚至还能顺手把测试和文档一起带上。

问题在于，代码写出来，不等于问题已经解决。

这两件事之间，其实隔着很长一段距离。

一个需求真正落地，往往不只是“主流程能跑”，还包括：

• 需求理解是否准确
• 边界条件是否考虑完整
• 分层是否合理
• 状态流转是否正确
• 异常路径是否可控
• 对原有系统是否有副作用

AI 在这些地方最容易给出一种“局部看起来正确”的结果。

比如：

• 接口有了，但业务规则没补全
• 页面能跑，但状态约束没处理
• SQL 能查出数据，但更新范围不够安全
• 功能看起来完成了，但放错了层，后面会越来越难维护

这就是为什么我越来越觉得，AI 时代程序员最危险的误判之一就是：

把“生成代码”误当成“解决问题”。

尤其是初级程序员，经验还不够的时候，更容易被“代码已经有了”这件事迷惑。

但真实工程里，真正稀缺的从来不是“把代码打出来”，而是“把问题真正解决对”。

3. 在基础不稳时过度依赖 AI

AI 最大的诱惑之一，是它能帮你跳过很多卡住的时刻。

你不懂一个报错，可以直接问。
你不会写某段逻辑，可以直接让它补。
你拿不准某个接口怎么设计，也可以先让它给一个版本。

这些都没问题。

问题在于，如果一个初级程序员在基础还没稳的时候，就把 AI 变成了自己的默认替身，长期会有一个非常明显的副作用：

看起来效率提高了，实际上独立判断力在变弱。

最典型的表现包括：

• 遇到问题先贴给 AI，而不是先看报错
• 没有自己推演逻辑的习惯
• 很少顺着调用链去理解问题
• 更关注“有没有答案”，而不是“为什么是这个答案”
• 用 AI 补了很多东西，但自己并没有真正消化

短期看，这种方式确实能让人更快完成任务。
但长期看，它会削弱一个程序员最该在早期建立起来的基础能力：

• 读代码的能力
• 看报错的能力
• 调试和定位问题的能力
• 判断方案是否合理的能力

而这些能力，恰恰决定了一个程序员后面能不能继续成长。

所以我并不觉得初级程序员应该拒绝 AI。
但我非常不建议在基础还不稳时，把 AI 用成“思考替代品”。

4. 这 3 条路为什么危险

把这三个问题放在一起看，它们真正危险的地方在于：

它们会让一个人很容易高估自己的成长速度。

因为 AI 会不断给你一种反馈：
你能写更多代码了，你能做更多功能了，你能更快交付了。

但这里面有一部分，未必是你的能力真的同步增长了。
它也可能只是工具在替你补齐。

如果一个人没有意识到这一点，就很容易把“工具带来的产出”误判成“自己已经掌握了能力”。

这会直接带来两个问题：

第一，成长判断失真。
你以为自己已经会了，其实只是见过了。

第二，能力结构失衡。
你补了很多“生成能力”，却没有补“理解能力、判断能力、验证能力”。

而 AI 时代真正更值钱的，恰恰是后面这些能力。

5. 初级程序员真正该补什么

如果不想走偏，我觉得初级程序员在 AI 时代最该补的，反而是这些看起来不那么“炫”的能力。

5.1 基础能力

包括但不限于：

• Java 语言和常用语法
• Spring Boot 基本开发方式
• 数据库和 SQL 基础
• HTTP 接口和常见状态处理
• 日志、异常、调试这些最基本的工程能力

这些东西不一定能立刻带来“效率暴涨”的感觉，但它们决定了你能不能真正理解 AI 给出的答案。

5.2 问题拆解能力

先定义问题，再让 AI 帮忙。

这件事非常重要。

一个需求如果你自己都讲不清楚，AI 也很难稳定给出高质量结果。
反过来，如果你能把输入输出、边界条件、约束、验证方式讲清楚，AI 才更可能真的成为你的杠杆。

5.3 评审能力

AI 时代，程序员一定要更会“审代码”。

不是只看代码能不能跑，而是要看：

• 这段代码有没有解决对问题
• 有没有遗漏边界
• 有没有破坏原有分层
• 有没有引入隐藏复杂度
• 有没有验证路径

以后“会生成代码”只会越来越普遍，真正能拉开差距的是“会不会判断这段代码该不该进系统”。

5.4 验证能力

任何 AI 生成结果，都必须经过验证。

至少要有这些意识：

• 编译是否通过
• 单元测试是否覆盖关键路径
• 边界条件有没有验证
• 关键链路有没有回归检查
• 修改会不会影响已有功能

不会验证的人，用 AI 只会更快地产生问题。

6. 怎么正确使用 AI，才不会走偏

我比较建议初级程序员按下面这种方式使用 AI：

6.1 先自己想，再问 AI

不要一上来就把问题直接丢出去。
先自己想 10 分钟，哪怕只想出一半，也会比完全不思考更有价值。

6.2 先让 AI 给思路，不急着直接要最终代码

有时候先问：

• 这个问题应该怎么拆
• 有哪些边界要考虑
• 可能有哪些风险

会比直接说“帮我写完”更有帮助。

6.3 把 AI 当协作者，不是替身

AI 可以帮你补实现、补测试、补重构思路。
但需求判断、边界控制、方案取舍这些关键点，还是要自己负责。

6.4 学会看它哪里不对

这点很关键。

不要只关心它“给了什么”，还要训练自己去发现：

• 它忽略了什么
• 它理解偏了什么
• 它放错了什么
• 它多写了什么

只有这样，AI 才是在帮你成长，而不是让你越来越依赖。

7. 最后

AI 编程不是问题，问题是怎么使用 AI。

初级程序员当然应该尽早接触 AI，也应该尽早把 AI 放进自己的工作流。
但越是在成长早期，越不能把效率放在能力前面。

因为短期看，AI 能让你做得更快；
长期看，真正决定你能走多远的，仍然是这些东西：

• 你能不能理解问题
• 你能不能拆解问题
• 你能不能判断结果
• 你能不能验证结果

所以我对这件事的结论一直很明确：

AI 编程时代，初级程序员最危险的不是不会用 AI，而是太早把 AI 当成能力替代品。

会用 AI 很重要。
但更重要的是，不要因为 AI 看起来太方便，就跳过那些本来应该属于你的成长过程。

如果你想找一个真实项目练习“AI 生成代码之后怎么判断、怎么评审、怎么理解架构”，也可以看看我的开源项目 ems4j。

• Gitee：https://gitee.com/jerryxiaosa/ems4j
• GitHub：https://github.com/jerryxiaosa/ems4j

它覆盖后台管理、计费结算、IoT 接入和远程控表，比较适合拿来练习业务理解、架构判断和工程评审能力。欢迎 Star 和交流。