AI 时代初级开发者的成长困境

抹掉职业阶梯

所有人都认同，AI 让高级工程师变得更有价值。但几乎没人追问：下一代高级工程师究竟要从哪里来？AI 自动化掉的工作从来都不是浪费，那些工作原本就是学徒期的训练内容。而招聘数据表明，职业阶梯最底层的那一级已经消失了。

眼下，行业里很流行这样一种说法：AI 让高级工程师变得更有价值。那些拥有判断力、站在门口就能嗅出糟糕设计的人，才是这场变革的赢家。这种说法让人安心，而且确实没错。

只不过，它中间有一个巨大的漏洞，大到足以容下一场招聘冻结。高级工程师并不是可再生资源。没有人一入行就自带十五年摸爬滚打留下的伤疤。你共事过的每一位高级工程师，最初都是一个被分配了不起眼工作、并花费多年时间亲手完成这些工作的初级工程师。而 AI 已经悄无声息地吞掉了那些年原本赖以构成的工作。

这篇文章不是要讨论 AI 能不能写出好代码。它当然能写出很多好代码。这里真正要讨论的是：能够判断代码好坏的人，今后会怎样。

高级工程师究竟从何而来

去问一位高级工程师，是什么让他成长为高级工程师，你听到的答案不会是“某张证书”。他会告诉你自己搞坏过哪些系统、熬过哪些事故，以及曾经不得不连续几周阅读哪些代码库，才终于弄明白其中的逻辑。

判断力无法直接下载。它来自与真实系统成千上万次细小碰撞后的积累，其中大多数都毫不起眼，很多在当时甚至无聊透顶。

这正是“高级工程师会成为赢家”这套说法忽略的部分。它把高级工程师的供给当成天气，仿佛这种资源天然存在，还会自行补充。但事实并非如此。高级工程师是被培养出来的。这个过程缓慢而昂贵，需要团队给某个人提供一个能够站上去的最低台阶，并容忍他在上面摇摇晃晃。

你的招聘计划可能默认，等到 2030 年需要高级工程师时，直接从市场上招聘就行。没问题，但所谓市场，不过是其他公司曾经培养过的初级工程师。总得有某个地方、某些人在维持这套学徒培养机制，否则市场上根本不会有人可招。

苦活原本就是课程

想想在 AI 工具真正成熟以前，一名初级开发者的一周通常是怎样度过的：

样板代码——搭建 CRUD endpoint 和表单验证，让你了解框架的形态、各个部分放在哪里、有哪些约定，以及这些约定为什么存在。

小型 bug 修复——那些没人想接的 ticket，会教你如何阅读 stack trace，然后是日志，更重要的是，如何阅读别人的代码。不是你自己会写出来的代码，而是系统中真实存在的代码。

胶水代码——把服务 A 接到队列 B，会让你明白系统实际上是怎样连接起来的：超时、重试，以及那个只有在生产环境中才会产生影响的配置值。

追踪别人的代码——“弄清楚为什么会发生这种情况”一类的任务，会帮助你建立对系统的心理模型，今后每一个架构决策都将依赖这套模型。

PR 中的吹毛求疵——第一次提交 pull request 时收到四十条评论，确实令人难受，但这也是这个行业有史以来传递品味最快的机制。

从来没有人替这些工作辩护。我们把它们称为 toil、苦活，是你为了证明自己而不得不熬过的东西。因此，当 AI 出现并开始在几秒钟内完成所有这些工作时，我们欢呼雀跃：初级开发者终于可以跳过无聊的部分，直接去做真正的工程了。

但问题在于，那些无聊的部分恰恰就是训练。

电工学徒需要花费数年时间拉电缆、安装接线盒。不是因为师傅不能做得更快，而是因为在任何人允许你靠近足以致命的配电盘之前，你必须通过这些工作学会建筑物实际是如何运转的。把拉电缆的工作交给机器人，建筑依然能够完成布线，但你将无法再培养出新的电工。

这正是自动化所做的事。它没有削减浪费，而是删除了课程，只留下考试。

这也让今天的初级开发者陷入一个奇怪的困境：在 AI 的帮助下，他们能交付比历史上任何一代初级开发者更多的产出，却也比历史上任何一代初级开发者获得更少的实战练习。

初级工作的重点从来都不是产出。学习才是真正的产品，ticket 只不过是交付这种产品的载体。

数据已经给出了答案

如果数据还没有反映出这种趋势，这篇文章就只是一篇泛泛而谈的思考。但数据已经出现了，而且来自多个彼此独立的方向。

SignalFire 的《State of Tech Talent》报告发现，如今应届毕业生只占 Big Tech 公司新招聘员工的 7%，与疫情前的 2019 年相比，应届毕业生的招聘数量下降了超过 50%。报告还把大家心照不宣的想法直接摆到了台面上：37% 的管理者表示，相比招聘一名 Gen Z 员工，他们更愿意使用 AI。

由 Erik Brynjolfsson 领导的 Stanford 团队分析了 ADP 覆盖数百万劳动者的工资数据，发现自 2022 年底以来，在受 AI 影响最大的职业中，22 至 25 岁的职业生涯早期劳动者，就业人数相对下降了 16%。软件工程正是其中最典型的例子之一。

与此同时，在这些相同职业中，30 岁及以上劳动者的就业人数截至 2025 年 5 月增长了 6% 至 12%。同样的工作，走势却截然相反，而且恰好以年龄为界。经济衰退不会先查看你的出生年份，但 AI 的应用显然会。

这种影响也已经传导到毕业生的就业结果中：New York Fed 的数据显示，近期计算机科学专业毕业生的失业率达到 6.1%，而所有近期毕业生的平均失业率是 4.8%。一整个世代都曾被建议选择的专业，如今表现却低于平均水平。

这些数字背后的态度也毫不含蓄。在 Stack Overflow 报道的一项调查数据中，70% 的招聘经理认为 AI 能够完成实习生的工作，57% 的招聘经理表示，相比应届毕业生完成的工作，他们更信任 AI 的产出。

职业阶梯最底层的那一级并不是正在松动，而是已经从梯子上脱落了。

对个体理性，对整体却是断粮

令人不适的地方在于：这个故事里的任何人都没有做错。

从单个团队和当前季度的角度算一笔账。一名初级员工需要一整份薪水，同时在一年甚至更长时间里，还会占用高级工程师每周相当一部分时间，之后才能为团队带来净收益。等他终于成长起来，还可能跳槽到另一家公司，获得 30% 的加薪。

而一个 AI 编程工具的成本还不及团队的咖啡预算，今天下午就能投入生产。如果你是一名工程经理，手上只有一个开放的招聘名额，还有迫在眉睫的交付期限，那么不招聘初级员工就是正确决定。任何 CFO 都会批准这个选择，而绝大多数 CFO 也确实会这么做。

问题在于，每家公司都在计算同一张表。

每家公司都单独决定从“市场上”招聘高级工程师，而不是自行培养人才。但市场不过是其他公司初级员工培养计划的产物。不招聘初级员工，实际上是在搭其他公司学徒培养体系的便车。只要这种做法尚未普及，它就运转得非常漂亮；一旦所有公司都这么做，系统就会崩溃。

这是一个公地问题，而 2031 年的高级工程师人才池就是那片公地。没有任何一家企业拥有它，也没有任何一家企业会因为本季度消耗了这项资源而受到惩罚，任何公司的 P&L 上也都没有一个对应它的项目。

真正让这件事变得危险的是滞后效应。2025 年没有获得聘用的初级工程师，就是 2028 年不会存在的中级工程师，也是 2031 年不会存在的高级工程师。

而缺失的一代人才无法在日后补招回来，因为你真正需要招聘的是多年积累下来的判断力。你可以在一个预算周期内提高薪资区间，却无法提高一个人的经验。

“或许 AI 自己会成为高级工程师”

这个坦诚的反方观点值得被公平对待，因为它并不愚蠢。它的逻辑是这样的：模型正在快速进步，所以等到高级工程师缺口真正出现时，AI 也已经能够完成高级工程师的工作了。担忧初级人才培养管道，就像在 1910 年 Ford 提升装配线产能时，还在担心马厩容量不足。

认真对待这个观点后，你仍会发现，它会撞上一条无法回避的事实：总得有人在 merge 上签下自己的名字。

当 AI 生成的 migration 在凌晨两点让生产环境瘫痪时，“这是模型做的”绝不会是一份能被接受的事故报告。你的客户不会接受，审计人员不会接受；如果你身处 fintech 或 healthcare，监管机构同样不会接受。

在软件组织中，问责能力承担着结构性的重量。你无法把责任委托给一个不能被解雇、不能接受质询、也不能得到晋升的系统。最终仍然需要某个人来审查输出、批准变更，并为结果负责。

而 review 并不是在检查清单上打个勾那么简单。要做好 review，你必须知道哪些 diff 风险很高、哪些只是常规改动；必须知道 schema 变更的爆炸半径有多大；还要分辨测试显示绿色，究竟是因为代码正确，还是因为测试根本没有覆盖失败模式。

这就是判断力。而判断力恰好是过去那套学徒培养机制所生产的东西，恰好存在于那些我们已经停止培养的人身上。

所以，“AI 会成为高级工程师”这种未来设想会吞噬自身的前提：AI 写的代码越多，人类的工作就越偏向 review；而整个行业一边押注这种能力，一边却在拆除我们所知唯一能够生产这种能力的机器。

Stanford 的数据中还有一个细节支持了这一点：在 AI 用于增强人类能力的岗位中，就业人数保持稳定或继续增长；那些使用 AI 学习和验证自己工作的人，也比将整个任务委托给 AI 的人表现更好。

市场已经开始对人进行筛选。筛选标准不是他们是否使用 AI，而是他们使用 AI 的方式究竟是在培养判断力，还是在取代判断力。

让学徒培养机制继续运转

你无法坐在办公桌前解决整个行业的招聘激励问题。但你可以决定，在你和团队现有的工作中，学习是否仍会发生。

如果你正处于职业生涯早期：

先挣扎，再写 prompt。面对每一个问题，在询问模型之前，先真正尝试自己解决。挣扎并不是一种应该被优化掉的低效，它正是把经验刻进你脑海里的机制。当 AI 为你解释一个你已经努力钻研过的问题时，它是一位非凡的导师；但如果它在你尚未形成问题之前就直接给出答案，它就是一台粉碎课程的机器。

像 reviewer 一样阅读 AI 生成的每一个 diff，因为你就是 reviewer。无论是在 git blame 还是在团队成员看来，那段代码都是你写的。如果你无法解释 diff 中的某一行，就说明工作还没有完成。把理解作为交付物，而不是把 merge 当成交付物。

有意识地用慢方法完成一些事情。亲手追踪一次 framework call；在要求 AI 生成 migration 之前，先自己写一遍。这不是在装纯粹主义者，而是在积累实战次数。就像即使已经有了叉车，运动员仍然需要举重训练一样。

尽早掌握 review。工作正在朝这个方向发展。主动参与 review，研究团队里最优秀的 reviewer 如何发表评论，并学会清晰表达某个改动为什么存在风险。这种能力的复利增长速度，会比单纯提高产出快得多。

招聘一名初级员工，并为他制定一套真正的培养计划。不要把它当作慈善，也不要把他视为提升 ticket 吞吐量的人肉工具。你需要的是一套计划：让他轮换参与不同子系统，指定一位真正预留出时间的 mentor，并让他参加事故复盘。

有意识地培养一名初级员工，原则上胜过一个也不培养；实践中，也胜过招聘三名却不给予任何支持的初级员工。

分配对理解能力的要求，而不仅仅是产出任务。让他们完整讲解支付流程如何端到端运转；让他们加入 on-call shadow 轮值；让他们撰写 postmortem 初稿。这些工作不会直接交付功能，但它们全都在生产一种东西：五年后你将迫切希望招聘到的能力。

把具有教学价值的 ticket 留给人类。不是那些消磨灵魂的任务，那些完全可以心安理得地自动化掉。但遗留模块中那个棘手的小 bug，会迫使某个人真正阅读整个系统吗？那个 ticket 是学费，不要把它花在模型身上。

一起 review AI 的使用方式。像结对编程一样，两人共同查看 prompt 和 diff。初级开发者如何使用模型，如今已经成为其工作流程的一部分。如果这个过程不可见，那么他们能力上的缺口也同样不可见。

这些事情都不会体现在本季度的 velocity 中。这正是关键所在。学徒培养从来都不会体现在 velocity 里，也正因如此，我们才能如此轻易地把它自动化掉，甚至没有人注意到它原本究竟是什么。

这个行业并没有决定停止培养高级工程师。它只是以一个又一个完全理性的季度为单位，自动化掉了生产高级工程师的机制。

五年后仍然拥有足够多高级工程师的团队，将是那些从未停止培养他们的团队。

P.S. 感谢你花时间阅读这篇文章！文中表达的观点和看法都是我个人的。英语不是我的母语，因此我会使用 AI 来帮助纠正语法，让文章表达更加清晰、更易阅读。如果有些地方读起来仍然稍显生硬，感谢你的理解！

最初发布于 nazarboyko.com。

喜欢这篇文章吗？欢迎保持联系——我在 LinkedIn 上，随时乐意聊聊天、交换想法，或者只是打个招呼。👋

部分评论可能只有登录后的访客才能看到。请登录以查看全部评论。

如果需要采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。