AI 不会杀死初级开发者——但你的招聘策略可能会
今天没有初级开发者，就不会有明天的高级开发者：重新思考人才培养
在越来越多地使用 AI 进行编码的行业里，初级开发者依然不可或缺，只不过他们的角色正在转变，而不是消失。
简而言之（tl;dr）： 与其让初级开发者写那些现在 AI 就能搞定的样板代码，倒不如让他们把重心放在调试、系统设计以及高效协作等更高层次的技能上。那些彻底砍掉初级岗位的公司，恐怕将面临未来人才断层的风险。最能成功的初级开发者会把 AI 当作学习工具而非拐杖，他们会去验证 AI 的输出并理解解决方案背后的原理。同时，他们也会努力培养阅读和理解代码的能力。
虽然有人唱衰说 AI 会扼杀初级编程岗位，但初级工程师的需求并不会消失。行业领袖们意识到，完全跳过初级岗位实际上很短视——毕竟，所有高级工程师都曾经是初级。正如 Camille Fournier 直接指出的，很多只想“只招高级”的技术管理者是在自掘坟墓：“如果没有人从初级做起，那高级工程师又是怎么来的？” 参见 Fournier。
的确，只招经验丰富的开发者会带来人才储备的问题。今天没有初级，就没有明天的高级。除此之外，初级开发者还能带来新鲜视角和成长潜力，企业也可以有意识地培养他们。
那些只想“只要高级不招初级”的领导，最终会吞下断送未来人才的苦果。
正如 Charity Majors 所说，认为有了 AI 就能放弃培养新工程师是个严重错误——“不去招聘并培养初级工程师，其实就是在自我蚕食未来。我们必须停止这么做。” Majors 在 Stack Overflow 上强调。聪明的工程团队意识到，初级开发者仍然具有价值；只不过他们的价值定位正在改变。
与其让初级整天写样板代码，在 AI 时代，他们的贡献更体现在快速学习、适应新工具，并在有针对性的指导之下成为全面发展的工程师。正如 Fournier 所说，无视“早期职业阶段”工程师会带来严重后果：
“别小看早期职业工程师对团队的价值；除非我们这个行业要灭亡，不然他们的存在与成功才是我们未来的基石。”
简而言之，初级开发者仍然是至关重要的投资——只不过他们创造价值的方式和领域正在发生变化。
AI 编码助手正在重新塑造初级开发者的日常工作，自动化了繁琐的任务，也提高了对他们更高层次贡献的期待。
在出现 Cursor、Cline 和 Copilot 等工具后，初级工程师的日常与以往不同。过去，新手一般从一些琐碎重复的任务入手——修简单的 bug、写单元测试、做些小功能修修补补。这些看似枯燥的事，对技能积累却很关键。参见相关论述。如今，大量的“重复体力活”可以交给生成式 AI 完成。
在很多团队里，AI “对编程伙伴”可以在几秒内自动完成或生成函数的初稿。这样一来，初级可能就不再需要从头开始写样板，而是更多地在审查或微调 AI 给出的代码。听上去很棒——那些无聊的部分都搞定了，人类可以专注于更“有趣”的问题。确有开发者反映，AI 帮他们摆脱了重复劳作，使其能聚焦更高层次的设计和集成问题。但随之而来的是门槛的提高：如果 AI 都能修小 bug、搭好组件雏形，为什么还要付钱给初级来做？
Sourcegraph 的 CEO Quinn Slack 指出，许多公司都有这种疑问：
“既然 AI 可以用很少的人力来修小 bug 或加些小功能，那还要花钱请初级来做干吗？” Slack 点明
结果就是：初级工程师需要做 AI 无法替代的事，比如理解需求、验证正确性、注入创造力。不再只是出样板代码的那个人，初级更可能扮演“AI 产出代码的编辑者”或是关注需要人类洞察的任务。
前任工程负责人 Anna Demeo 描述了这种新动态：现在的程序员更像编辑，需要_“理解内容和受众（客户），从而引导 AI 生成的结果”_ 参见 Demeo 的说法。在实际场景里，初级也许用 Copilot 生成代码，但他们负责审查、测试各种边界情况，并将其调优到项目环境中。AI 在缩小初级和高级之间的部分差距，因为能更快地产出代码，但也带来新的期望：初级得为 AI 的工作把关，而不是盲目接受。这对以往的“师徒制”模式是个重大改变——从第一天起就需要更多自主性和更高层次的思考，而由 AI 来处理简单的部分。
当代初级工程师的学习方式与过去大不相同，他们更依赖 AI 工具和自我探索，而不仅仅靠吃苦耐劳和线下带教。
几十年前，初级开发者的学习道路大多是这样：加入团队，找个资深带着 pair programming，用几个月到一年的时间扎进简单活儿里打基础，通过代码评审和师傅指导慢慢提升。再看 2025 年，节奏完全加快，也更具自助性。现代初级开发者手边有各种 AI 工具来帮忙。想要了解新的代码库？AI 可以用大白话给你解析。遇到 bug？AI 能在几秒钟内给出可能的修复建议。事实上，近期的一份调查发现，75% 的开发者都在用某种 AI 工具来编程或者学习，所以对新手来说，几乎是默认就要用这些帮手。好处是他们能更快上手新技术，把 AI 当老师与向导。
坏处就是，如果他们不小心，学习就会变得浮于表面。某位技术博主就哀叹：
“每个我碰到的初级都有 Copilot 或 GPT 开着，码写得比谁都快。但当我深挖一下……那就挺堪忧了。” 某报告中提到
新手可能借助 AI 神速地解决问题，但却跳过了“为什么这么做”的关键学习。Namanyay Goel 在与一些初级聊过后发现，他们往往无法解释 AI 生成的代码原理，或者应对边界问题时没思路——“由于不从零学起，导致缺乏基础” 他提醒。在早些时候，学习虽然慢（比如翻 Stack Overflow 一行行看），但能让你彻底搞懂；而现在，“AI 给的答案虽对，但你学到的往往很浅”。Goel 还指出，阅读专家们的讨论能学到的不仅仅是做法，更重要是原理。来源同上。
另一个学习方式的改变是，和导师面对面共事的机会减少。远程工作和 AI 的普及，使得不少新手的日常求助都转向 AI。Jeff Watkins 指出，一些最近入行的新人“因为疫情而被迫学会了没有面对面导师就能工作的方式”，现在也依赖 AI 助手。这种独立性固然有好处，但也可能让初级更加孤立，错失了以往人带人的指导时机。有些公司也开始淡化“初级”和“高级”的表述，转而说“早期职业工程师”，并希望入门级别的新人也能拥有更强的独立和技能。
正如 Camille Fournier 所说：“大学生们，赶紧去折腾那些课外项目、实习！” 她写道。换句话说，现如今应届生被期望入职前就有较扎实的基础，因为他们已经用 AI、用在线资源学过东西了。对初级开发者而言，目前的学习路径不再是一步步由易到难、伴随老带新的慢慢提升，而是更多依靠自驱的持续学习，往往通过和 AI 协同完成。那些成功的初级，会把 AI 当学习工具——拿来做原型后再去研究生成的代码，以巩固理解，而不是当“万灵药”一键搞定。
选择有耐心、肯研究 AI 代码工作原理的初级，可能会迅速打牢根基；反之则知识漏洞会越来越大。总之，今天的初级开发者拥有前所未有的加速工具，但他们必须主动把握，才能真正掌握软件的匠艺。就像任何手艺的学徒一样，哪怕有电动工具，还是要扎实练习。
在 AI 把简单的部分自动化之后，调试、代码阅读、系统设计和沟通这些核心技能，对初级而言更显重要。
工程圈有句话：“写代码是最简单的部分——真正难的是写完之后的那些事。” 在 AI 时代，这句话更对。生成式 AI 可以在几秒内输出代码，却无法确保这个代码在你的复杂系统中实际有效、满足用户需求且可持续维护。因此，初级开发者需要加倍关注那些 AI 无法替代的根本技能。调试 就是一大例子。
当 AI 生成的方案出现错误或表现异常（这并不少见）时，还是得靠人去诊断并修复。那些过于依赖 AI 写代码的新手往往在这里卡壳——然而学会调试是不可回避的。事实上，一些领导者注意到，“有的初级会难以调试 AI 生成的代码”，结果做出一堆他们并不真正理解的脆弱系统。读堆栈信息、找到缺陷、系统性地解决问题，这些都是人类依然要掌握的本事。阅读代码——特别是阅读别人写的（或 AI 生成的）代码——同样关键。AI 可能一下给出一大段，但你必须能跟下来，看看它到底在干啥、是否实现了你的意图、有没有隐性假设或漏洞。那些经常仔细读代码（不论是 AI 产出还是队友的）的初级，会脱颖而出。
这与代码审查和质量意识密切相关：把 AI 输出当成同事的代码来审查。更重要的是，系统设计和架构思维也越来越早地对初级提出要求。既然 AI 能拼出代码块，那初级就更有机会去思考_这些块如何组合_。Kesha Williams（某工程领导者）就指出，AI 减轻了他们团队（包括初级）的编码负担，让大家有更多时间关注“策略、系统设计和创造性问题解决”，甚至_“让他们更快地接触架构工作”_ 参见 Williams 观点。
换言之，初级现在更早就接触到高层次的设计考量。但要在这个层面玩转得好，必须先打好基本功（比如理解后端处理请求的方式、为什么某种数据库 schema 更佳等等），这些都不是 AI 会直接灌输给你的。
沟通和协作能力也变得更重要。既然基础编码不再是瓶颈，初级能否沟通协调、问对问题、解释思路、理解产品需求，就变成了其价值所在。AI 可不会自己上 Zoom 和设计团队讨论技术方案；要做这些的还是初级。而且在有 AI 参与的环境中，沟通还包含了“如何与 AI 进行对话”（即 prompt 工程）以及向团队汇报 AI 所做的事。
Anna Demeo 强调，在大量使用 AI 的团队里，剩下的开发者必须_“成为能批判性思考、理解业务需求并能跨部门协作的角色”_ 参见此处。这意味着初级应当练习把技术细节讲给非技术人员听，写清晰的文档，并能跨部门协同——这是确保他们不仅仅是写代码的人，而是真正的工程师。
Business Insider 组织的一次开发者圆桌指出，即使有了 AI，“软件工程的基本功仍然重要” 他们总结，例如理解编程语言、怎么扩展系统、如何处理数据等。这些核心能力是能够高效使用 AI 的基石。简而言之，作为初级开发者，你依然应该花时间学习计算机科学基础、设计原则和调试方法。
AI 可以一下子替你写出函数，但半夜两点上线报错要排故时——只有你自身的工程直觉才是不可替代的。而且很可能因为 AI 让大量代码生成更容易，代码库会迅速膨胀；如果没有良好的设计和明确的沟通，复杂度就会失控。未来的高级工程师（也就是今天的初级）将不再仅仅比拼代码敲得多快，而是看谁能在复杂的社会-技术体系里更好地理解、批判和演进代码。
过度依赖 AI 的风险不容忽视：如果初级把 AI 当拐杖而不是学习工具，他们的核心技能和工程直觉可能会逐渐退化。
生成式 AI 虽然很强，但对经验尚浅的开发者来说可能变成双刃剑。一大风险是我所谓的_“纸牌屋式的代码”_——看似正确但在真实环境下一碰就倒。这通常发生在初级盲目接受 AI 生成的方案，而不去深入理解或验证。短期看好像快速搞定了任务，但由于初级跳过了关键的思考环节，代码里可能埋了性能、安全或 bug 等各种坑，只有上线后才会暴露。
行业内已经观察到这样的现象：一些新开发者对 AI 建议依赖过度，把不甚理解的代码复制粘贴过去。
长此以往，他们自己的技能就会停滞不前。如果每次遇到问题都去问 AI，自己就没机会学会真正的解决思路。正如一位技术老手所说，“我们用迅速的修补换来深层理解的流失，现在看着挺香，日后要为此付出代价。” 有业界专家警示
他所说的“代价”就是知识债——当下不会显现，但将来一定得还。那些不练习独立编程，或者不深入研究 AI 产出代码的人，可能会陷入危险：表面上完成了不少任务，但当遇到真正新颖的问题或 AI 出错时，他们会不知所措。
调试技能的退化就是一个很具体的例子。调试像一块肌肉，要通过实践才能强壮。如果初级连排错也靠 AI——“AI，告诉我哪里不对”——他们可能无法形成系统化的故障排查思路。这就很危险，因为当 AI 给出错误或不相关的建议时（它经常这么干，因为并不真正“理解”代码意图），新人就会完全懵。
归根结底，过度依赖会破坏培养直觉的反馈循环。有经验的工程师常常提到“第六感”或对代码的“气味”，那是一种对 bug 潜在位置或设计不妥之处的判断，都是无数次尝试和失败积累出来的。如果初级每次只要打字问 AI，就省去一切摸索，他们就错失了形成这种本能的过程。不少工程领导也在担心：如果 AI 把所有简单的 bug 和小任务都完成了，初级会没有机会练手，失去锻炼机会。更糟糕的是，他们可能会产生一种错误的自信。
想想看，如果每次 AI 都能给出 70% 的方案，你会觉得“搞定了”，却不知道还缺了 30% 的工作自己没做。
我把这叫做_“知识悖论”：“高级开发者用 AI 来加速他们已经会的东西；初级则想用 AI 来学会做什么……结果差别会很大。”_ 正如我所解释。在实践中，高级工程师引导 AI，然后用自身判断去修正或改进输出；而初级常常不加分辨地接受，导致写出的代码自己都云里雾里。另一个潜在的坏处是丧失持续深入学习的习惯。
过去，初级若遇到新问题，会去看文档、试验或请教同事，这些动作都会强化学习。但如果现在一遇到就问 AI，AI 会直接给出答案。虽然同样可以学到东西，但非常容易变得被动。“AI 在你没真正理解的情况下就替你处理了复杂度，” 我在某处也写过d。没有经历“摸索”，缺乏好奇心和韧性，学习就不够扎实。
另外，AI 可能输出过时甚至不安全的做法。一些模型会因为训练数据里混杂着陈旧或糟糕的代码而“学坏”。如果初级没经验分辨，就可能把 bug、漏洞带进系统里。我也观察到，新人经常接受 AI 的错误或过时方案，遗漏了重要的安全与性能考虑。见研究。如果缺乏怀疑精神，初级会很开心地实现看似可行、但在生产环境会闯大祸的功能。
总之，不加节制地依赖 AI，会导致技能退化。就好比只会用计算器却从没学过算术，一旦计算器出错或碰到必须理解方程本质的情况，就会束手无策。关键在于平衡：无论对初级还是资深来说，都要把 AI 当工具，而不是替代大脑。要时刻提醒自己：如果某个功能离开 AI 你就不会做，那说明还需再回去研究。一些团队已经明确规定：不要让“凭感觉地使用 AI”取代扎实的工程实践。有专家告诫。
理想是利用 AI 的效率优势，同时保留工程的严谨。公司如果看到初级对 AI 依赖过头，会通过加强基础培训和严格代码评审来防范 AI 带来的错误。对初级个人而言，意识到问题是第一步：如果你离不开 AI，那就意味着你需要回头深入学习那块知识。把过度依赖当作一种“代码异味”来对待，早发现早纠正——未来你自己和团队都会感谢你。
想要在新环境中立足，初级必须培养 AI 时代的新技能——从提示（prompt）工程和验证 AI 输出，到理解 AI 的伦理边界。
AI 在软件开发中的崛起，不仅给开发者添加了新工具，也带来了新要求。其中之一就是提示工程（prompt engineering）——和 AI 有效沟通的艺术。怎么“提问”或“提示”AI（无论是自然语言还是注释）对最终产出是垃圾还是黄金有巨大影响。正如某位工程负责人所说，“能清晰地把需求告诉大型语言模型（LLM）已经是一项非常重要的技能。” 业界观点。这意味着初级要练习如何准确描述问题，并在提示或问题表述上不断迭代，以便从 AI 那里获得更优的回答。从某种意义上说，这和代码里的问题分解类似——只是现在把它用在了与 AI 的对话上。
在编写高质量提示的同时，初级也需要批判地评估 AI 生成的代码。可以把这视为质量管理或“AI 产出素养”。包括测试 AI 的代码、检查边界情况、与需求对照等。别以为 AI 永远是对的（其实经常出错或简化过度），所以优秀的初级会带着怀疑的眼光去检查：这个代码能处理无效输入吗？符合团队的规范吗？算法选择合理吗？把这些问题当习惯，才算是合格的 AI 辅助工程师。
事实上，很多团队采用“信任但要验证”的心态：享受 AI 提升速度的好处，但在合并之前必须审查和验证输出。
对初级而言，可以在每次看到 AI 建议时有意进行审视，就像在给 AI 做代码评审。另一个新需求是要了解AI/ML 的基本原理。当然，不是说想当后端工程师就必须拿 ML 博士学位，但掌握一点模型是怎么运行、有哪些局限，会有帮助。有人指出，开发者应_“懂点机器学习概念和模型原理，不一定要能从零构建模型”_ 行业专家建议。比如，知道大语言模型并不真正理解含义，会产生“幻觉”式错误，这样你就知道关键之处要仔细核对。
在 AI 语境下的软技能同样关键，比如_学会如何与 AI“结对编程”。这需要你反复与 AI 交流，评估回答，然后提供进一步细节进行修正。有点像带一个超级快但时而神经质的实习生（只不过它是硅基生命）。 我建议把 AI 当“你团队里一个特别积极但是需要大量监督的新手”_，它很快但需要不断校正。如何监管和引导 AI 助手，是需要练的能力：可能需要熟悉工具的各种命令、参数，或知道何时该关掉 AI 自己上阵。
熟练掌握 AI 工具有助于在面试和工作中胜出。事实上，一些公司已经在招聘要求里写了“有 AI 编码工具使用经验”。 我们还看到有新涌现的“AI engineer” 或“提示工程师”之类的岗位几年前还不存在，主要负责把 AI 集成到产品里，或优化团队使用 AI 的方式。现在的初级如果有兴趣，也可以往“软件+AI”这个交叉方向发展。想往那条路走，可以先学着玩 AI 的 API、做数据和提示调优、评估模型输出，这会是需求旺盛的职位。
总之，要让初级在 AI 时代成为既能用 AI，又拥有工程实力的开发者，须持续升级技能：
提示工程能力 ——清晰有效地给 AI 提需求（提供上下文、明确任务、迭代 prompt）。
批判性评估 ——永远别盲目信任 AI 的产出；测试它，调试它，并确保你理解它。
AI 工具熟练度 ——熟悉你所用的 Copilot、Cursor、CLI 工具或代码生成 API 的功能，掌握最优用法。
ML 基础知识 ——知道 AI 的能与不能（擅长模式匹配，不擅长逻辑规划），以及训练、偏差等概念。
伦理与安全意识 ——警惕数据隐私（别把客户数据往公共 AI 上扔）、开源许可问题、可能的偏见输出等。
适应力 ——AI 工具在不断演进，学会与时俱进。2025 年的 AI 和 2022 年差别巨大，保持好奇心并愿意调整工作流。
拥有这些本领，初级就不会被 AI “卷”下去，反而能借 AI 之力，成为 1+1>2 的工程师。
在 AI 时代，辅导和入职培训也需要更新，强调对 AI 工具的正确使用、主动学习，以及“信任但要验证”的准则。
随着生成式 AI 成为开发者常备军火，我们对新人的辅导方式也得随之调整。以前，对初级的很多辅导都集中在如何写循环、如何用 Git、如何避免上线出事故等基础操作。如今，初级进来时可能已经有 AI 帮他们处理一部分“基础体力活”了，他们更需要在更微妙的领域接受指导：如何明智地使用这些工具、如何掌握工具无法替代的技能。优秀的导师会专门教新人怎么把 AI 融入开发流程，又避免过度依赖。
例如，导师可以和初级结对编程，演示自己怎样用 Copilot：“看，我先用描述函数名和注释来提示它，再看它产出的片段。接下来，看我如何评估这段代码——我会写单元测试看看是否覆盖到边界，再调一下以符合我们的风格。” 通过展现思路，让初级学会如何引导和检查 AI。辅导的核心是灌输“要验证” 的思维。从第一天开始就告诉初级：AI 是伙伴，不是权威。
一个切实可行的办法是要求初级在代码审查时解释所有 AI 生成的部分。
比如，如果初级用 AI 写了个函数，导师可以问：“给我讲讲这段代码是做什么的，为什么你觉得它是对的？” 如果初级答不上来，就可以及时引导他/她下次更深入理解。这样的做法鼓励初级带着理解去使用 AI。 团队也会更新入职文档。可能会加入一个“AI 助手指南”，告诉新员工哪些 AI 工具是公司许可的，常见的坑是什么，以及使用技巧。也会写上比如“所有 AI 生成的代码都要跑我们的测试套件”有专家推荐或者“敏感代码部分不要用 AI ，至少得经过二次审查”等规定。从一开始就树立“合规、审慎” 的观念，免得新人养成坏习惯。
入职任务可能也会有所变化。原本经典的“找个小 bug 修修”之类的新手任务，现在可能会设计成既让新人熟悉代码库、又让他们体验如何在具体场景下用 AI 的东西。比如，要求新人用 AI 助手实现一个小功能，然后写个简单报告说明 AI 哪些做得好，哪些地方要手动改。这样既能让他们熟悉代码库，又能让他们思考 AI 的作用与局限。
导师也需要关注心理层面：很多初级会担心使用 AI 会不会被认为是“作弊”，或者反之，担心不用 AI 自己就比别人慢。
好的导师会让他们放心地用 AI，但要点在于正确使用。Kesha Williams 在一次圆桌中提到，她会帮助团队“别把 AI 看成威胁，而是伙伴”，并建立学习路径，让大家在拥抱 AI 的同时不必害怕被取代。这种领导力很关键。导师和团队负责人应该鼓励新人敢说“AI 给我的建议是这样，这么做行吗？”或者“AI 在这个地方错了，你能帮我看看吗？”
在 AI 时代的辅导，还意味着要加强基础理论教育，补上 AI 掩盖的不足。
如果你是个高级工程师带一个初级，可能会发现初级并没有学过某些算法或设计模式，因为 AI 直接给出了答案。这时你就要提点他们：“AI 给的代码其实用到的是动态规划，你了解这个概念吗？如果不熟，我们来聊聊或找些资料看看。” 换句话说，导师要更主动地帮新人避免“技能萎缩”。有时可以要求初级在某些小任务上先不用 AI，自己动手实现，再和 Copilot 给出的做法做对比。通过这种练习，可以让他们看到差异，理解为什么 AI 会那样写。
团队的求助文化也需要保持。 有了 AI 随时可问，一些新人可能会更少去向人求助，觉得“我应该能用 AI 自己搞定。” 但导师要提醒他们：问同事依旧值得鼓励。毕竟，与人讨论问题往往会产生 AI 提示不到的收获。Charity Majors 指出，团队里有初级反而能_“打造一种鼓励提问的氛围”_，这对整个团队都健康。在充斥 AI 的环境中，这一点更不能丢。甚至要更积极让初级知道：AI 并不能取代人与人的讨论。
最后，辅导“搭档”模式也可能升级：或许让一个高级同时带一个初级和“AI 工具”，组成三方学习圈。高级负责看着新人如何使用 AI，并在必要时纠正。某些公司正把这变成制度化，通过培训高级成“AI 导师”，成为团队里 AI 问题的权威：比如“这里可以相信 Copilot 吗？”或“为什么这个 AI 建议不太理想？”。
总之，在 AI 时代，要辅导出既懂 AI 又有扎实基础的工程师，需要做的事包括：教授AI 素养、强化被 AI 跳过的基础训练，以及营造团队氛围，让初级把 AI 当作多种工具之一，仍从人类导师身上受益。我们的目标是培养出既精通 AI 又基本功扎实的工程师，而不是二选一。
传统评估初级绩效的指标已经在改变——现在更注重理解代码、解决问题和有效使用 AI，而不是单纯产出多少行。
有了 AI，工程经理们正在重新思考如何衡量初级工程师的表现。以前可能会看你在前几个月交付了多少功能，修了多少 bug。但如果很多代码都是 AI 帮忙生成的，那产量数字就没那么能代表个人能力了。毕竟写 10 个 CRUD 接口借助 AI 只需几小时，并不像过去那么让人惊叹（或有价值）。
质量和理解正成为新的标尺。初级是否能解释自己提交的代码？他们是否理解边界情况？在评审他们的工作时，能否发现问题并修正？相比之下，管理者更加看重代码审查和设计讨论来评估初级的成长。
比如，一个初级可能在审查中如何吸收反馈？如果有人指出 AI 生成方案有缺陷，下一次他/她能不能改进？这就体现了学习能力。另一个关键指标是解决问题的思路：他们知道什么时候用 AI，什么时候要自己思考？一个敏锐的初级也许会先让 AI 生成思路或样板，再认真测试并打磨。
遇到完全陌生问题时，他们会分步骤分析，还是把整个问题都丢给 AI 祈祷奇迹？
经理在一对一面谈时可能会问：“你是怎么得出这个解决方案的？” 如果回答是“Copilot 自动写的，我就直接通过”，除非后面补充“然后我写了测试验证并做了重构，因为我发现它有不足”，不然肯定不被认可。换言之，过程跟结果一样重要。在绩效评估里，可能会多了诸如“这位开发者有机智地使用 AI 提升效率，并且能从 AI 给出的答案中学习吗？”这种指标。
有些团队也会在结对编程或家庭作业环节特意允许或鼓励使用 AI，看对方如何利用它。更有公司在面试中会让候选人使用 AI 做题，并观察他们的操作流程：是一键复制还是反复提示、测试、修正？同理，在日常工作中，管理者也可能关注迭代次数：只 prompt 一下就贴过来，还是来来回回调 prompt、测试、迭代多次？后者往往代表更深度的思考。
管理者更关心学习曲线和解决问题的过程，而不只是最终那次提交。有没有形成正确的习惯，在遇到 AI 给的错误答案时怎么应对？如果初级能及时发现问题，再寻找替代方案（不同的提示、问同事或查文档），就是进步快的信号；如果整天卡住或不知道 AI 毫无根据，就比较危险。
有 CTO 打趣道，“为什么花 10 万美元请个初级来拖慢进度，不如花 20 万请个高级把速度提起来？” 某位领导曾说，听上去很残酷，但实际上透露的意义是：初级必须证明自己不会拖后腿——也就是别写一堆 bug 或技术债让高级来擦屁股。
因此，如果一个初级能借助 AI 产出高质量、bug 少的功能，性价比还是很明显的。从绩效角度来看，可以考察他们代码的缺陷率、对反馈的响应度，以及独立度的提升。总的来说，作为初级，你的绩效会更多体现在“智慧”而非“速度”：看你能否聪明地用工具、解决难题、快速学习以及协同合作。做得好的人会发现 AI 反而是他们大显身手的工具；做不好的，那些只依赖“重复劳动”吃饭的人就需要赶紧提升。
从初级到中级的职业晋升路径正在加速和改变，AI 能帮助你更快成长，但也要有意识地避免知识漏洞。
在以往，也许要花两三年时间，初级工程师才能稳稳迈入中级，因为需要在不同项目和挑战中累积足够多的经验。现在，我们看到这种进程可能会更快——但这并不是说 AI 会自动给你铺平道路，关键还在于如何正确地利用这些技术并完善自己的知识。 乐观地说，生成式 AI 就像“职业加速剂”。一个有上进心的初级，如今能在短期内接触到广泛的场景，因为 AI 工具让他们可以尝试一些本来需要更高段位才会涉及的任务。
举例而言，初级可能会用 AI 搭建一个完整的微服务（这是以前要中级才能做的事），在这个过程中见识到各种组件如何衔接。他们也许会失败，但这次失败比过去等到升中级才碰到更早。Slack 就观察到，一些充分利用 AI 的初级_“进步非常快，也不担心被 AI 取代”_ Slack 所言。他们把 AI 当成工具去解决更高级别的任务，并从中学习如何思考整体结构。
另外，由于一些编码体力活可以交给 AI，初级就有精力更多参与系统架构或设计讨论，这在以往可能是对中级或高级才开放的领域。正如 Kesha Williams 所说，AI 让开发者更快摆脱低层琐事，从而能更早关注架构性的问题。这意味着初级更早就能锻炼中级所需的思维模式（系统思考和取舍判断）。
也许不久的将来，“中级”或“高级”的定义不再只是凭多年写码的经验，而更多关乎能否处理复杂性和承担责任。Camille Fournier 提到，她更愿意用“早期职业”和“高级”来区分，不只看年限，而是看独立性和判断力，这些无论 AI 在与不在，都需要时间和经验来积累。
一个大的不确定因素是：当许多公司缩减初级招聘（似乎确有其事）后，未来几年可能会出现中级工程师短缺，因为没有足够初级做后备。某 IT 主管就警告说，如果初级岗位减少，“就没有自然的‘学徒->资深’的通道了。” 有人担忧。对整个行业来说，需要保持这个人才漏斗的健康。如果一个初级在一家不愿培养新人的公司（以为 AI 可以替代所有 mentoring），也许他们要寻求其他渠道（社区、开源项目等）来成长。另一面，一些人预测未来团队会变得更小更精，可想而知中级岗位也会减少，如某些观察。届时竞争会更大。
能晋升的那些初级，是能证明自己胜任中级职责的：不仅能写代码，还能主动解决问题，甚至带新人或“带 AI”。也可能出现两极分化：部分初级成为“通用软件+AI”型，另一些走向特定领域（如数据工程、DevOps），因为 AI 无法替代对这些领域的深度钻研。
展望未来 3-5 年，或许一个在 AI 时代入行的初级，一年内就能达到过去两年才有的熟练度——前提是他们和团队同时重视真正的学习而非只靠 AI。这可能带来更快的晋升或更早承担关键项目。但是，也意味着“初级”和“中级”的分界会更早模糊。有人一年级就做着中级难度的工作，但在一些角落知识还没补上。
许多工程领导对此都在密切关注。有人相对乐观：
“我们现在所熟知的初级角色确实会发生终结或巨变……再过几年，初级的职责和期望就完全不同了。” 有人预言
可能的结果并不是“初级”这个头衔消失，而是“早期职业阶段”会变得更紧凑、更丰富。你需要用前所未有的速度处理原本只有中级才能触及的挑战（有 AI 帮忙），但同时也要时刻自省：自己到底有没有真正提升，而不是 AI 在背后撑着。 如果做得好，你也许只需两年时间就能达到过去三四年才能拥有的能力：能设计中等复杂的功能、有效引导 AI 工具、甚至指导更新的新手如何用 AI。
但如果做得不好（只靠 AI 混日子），你迟早会撞墙，到中级门槛时会发现自己根本没积累足够的基础，尤其在 AI 也没见过的全新问题面前会束手无策。
总之，初级晋升到中级的“路程”对有些人会压缩，对另一些人则会分叉。最好建议是：拥抱 AI 提供的加速机会，但要主动弥补知识空白。多找机会锻炼直觉和韧性。你前几年的职业生涯可能会经历前所未有的技术更迭——得保持适应力。那些能把这关卡迈好的，可能在相对年轻的时候就成为非常强的工程师，这很令人期待。
在接下来的 3-5 年里，初级开发者的角色还会继续演变——可能会有更小规模的团队、新的“AI 工程师”岗位，以及对适应性的更高要求。
展望未来，我们可以设想一些趋势。首先，很多人认为软件团队会更高效、更精简，因为 AI 会帮助写大部分常规代码。已经有数据显示，很多开发者（高达 97%）在工作中使用 AI 工具，随着这些工具升级，过去需要一个大团队才能做完的事，现在三五个人就搞定。Ed Watal（某技术顾问）预测一两年内三个人能干以前五六个人的活。如果真这样，初级岗位的数量也会相应减少。一个项目过去可能 2 名初级、2 名中级、2 名高级，现在也许精简成 1 名初级、2 名高级就够了。
另一个即将发生的变化是入门人才的培养方式。如果公司减少直接招聘初级，可能会转向实习转正、学徒等途径，保证未来依旧有人才来源。一些大公司或许会投入更系统的培养项目，让新人在不同部门轮岗，学习如何正确地和 AI 工具配合，并积累项目经验。过去那种“先修一年小 bug，做打杂”的入门方式，可能会被更结构化的培训替代。微软、谷歌等大厂已经在内部推行 prompt 工程和 AI 素养培训，相信再过三五年，AI 相关的入职培训会成为大多数企业的标配。
当然，也有可能三年后我们发现许多老问题依然存在。项目依旧会延期，bug 依旧会滋生。AI 只能搞定部分重复劳动，复杂系统里的那些“硬骨头”还是需要人来啃。
正如 Charity Majors 所说，AI 让写代码更快，但并没有解决软件开发最难的那些部分——理解和维护系统——而且_“它甚至让那些艰难的事情变得更难了。”_ Majors 写道。所以，在未来 3-5 年，初级也许会更快地被扔进“痛点问题”，因为简单的都被 AI 干了。于是我们或许会看到初级很快就要面对运维或站点可靠性等高级议题。
长远来看，不少专家认为尽管有 AI，对优秀工程师的需求还会增长，因为软件项目会越来越多、规模更大。我和很多人都指出，从汇编到高级语言、从本地到云，每一次自动化浪潮都没有减少开发者需求，反而拓宽了这个行业，只不过让技能重点发生了变化。
到了 2030 年，写代码（或者说“用 AI 写代码”）的人也许会更多，包括许多非传统开发者。但资深工程师（也就是今天的初级成长起来）则可能负责管理、整合几十个 AI 代理或“公民开发者”的工作。在那种场景里，“初级开发者”或许会演变为“AI 驱动协调人”或“软件指挥家”——懂足够的编程和工具使用，来 orchestrate 大规模的软件创作，而 AI 负责“大多数具体操作”。
虽然有点科幻，但沿着趋势并不离谱。总之，未来的初级角色可能包括：身处规模更小、更跨学科的团队；从第一天就使用高端 AI 工具；或走向“AI + 软件”的专门领域；且学习速度比以前更快。关键字就是适应性——谁能不断更新技能，谁就能在角色和工具快速变化的环境下生存下来。某位工程 VP 感慨，“每个人都需要持续适应……在 AI 出现之前就是这样，有了 AI 更是如此。” 许多领导认同。对于职业初期的人，这更是双倍的考验。
对工程领导来说，与 AI 并行地投资初级开发者的招聘与培养，是保障团队健康和保持创新力的关键。
对技术经理和团队负责人来说，AI 的出现并不意味着不需要初级——而是要改变招聘、培养、管理的方式。以下是一些建议：
不要停止初级招聘，而是进行优化。 也许有人会想“有了高级 + AI，初级就没必要了”，但这非常短视。正如之前提到的，你会失去未来的中坚力量。即便在一个 AI 密集的环境里，初级仍有新鲜思路、潜力和团队文化的延续作用。正如 Camille Fournier 建议领导者重新审视“全员高级”的做法：对早期人才的成功才是我们未来的基石。与其不招初级，不如重点招那些“适应力强、学习主动”的新人，看看他们有没有自学（项目、在线课程）或 AI 工具经验，可以预见他们会在有 AI 的团队里如鱼得水。
更新你的入职和培训体系。 在新员工培训中加入 AI 素养相关的内容。让初级明白如何有效、合规地使用公司认可的 AI 工具，比如演示成功的使用场景，明确哪些行为（把机密信息上传到公共模型）是不被允许的。给新来的初级分配“导师”或“伙伴”，不仅带他们熟悉代码库，也要教他们如何把 AI 融入日常开发。或许还可以写个内部 “AI 使用手册”，比如“我们把 AI 输出当成新人代码，需要认真审查”之类的团队约定。
营造“信任但验证”和持续学习的团队文化。 明确鼓励大家用 AI，提高效率，同时也强调不能盲目依赖。让资深工程师在例会上分享 AI 出错的案例，说明大家都需要保持警惕。也要表扬那些巧用 AI 又能理解方案的新人，以激励正确的行为。领导者可以定期组织基础知识培训或读书会，补充 AI 可能省略的原理和算法。最终的目标是——人和 AI 相辅相成，而非人变成机器的附庸。
重新定义绩效标准与反馈机制。 修改对初级成功的衡量方式，不再只看“做了多少任务”，也要看“对 AI 生成的代码是否理解到位”、“在不知道时是否积极寻求帮助”、“在合并前是否经过严谨测试”等。在一对一会议上，不要只问“这个冲刺完成了什么”，还可以问“AI 给的解决方案里你学到了什么？”、“这个月有没有遇到 AI 出错的情况，你怎么处理的？”——让新人知道学习比产量更重要。一旦发现新人直接粘贴 AI 输出却没检验，要及时纠正。
强化导师制并鼓励双向学习。 导师永远是关键。确保每个初级都有一个可以随时提问的资深，帮助他们不仅学会怎么做，也学会思考过程。同时也别忽视新一代对 AI 工具的熟练度——他们或许能给团队带来新插件或新 prompt 技巧。让新人也能向资深“反向辅导”AI 的使用，既能让团队收益，也能增强初级的成就感。可以开个内部论坛或群聊分享“AI 编码技巧”，初级往往是最积极的贡献者。
让初级获得多样化的经验。 不要只让他们做 AI 特别擅长的那些“模板活”，也要安排他们处理 AI 不那么擅长的事情，比如疑难 bug 调试、排查竞争条件、或者做客户支持工单，让他们多方面锻炼。如果你团队因为精简而初级更少了，那就尝试让每个初级在多个代码模块或多个开发阶段都转一转，让他们看到 AI 在哪些地方得心应手，哪些地方力有不逮。
警惕过度激进的“准高级化”导致新人压力过大。 有些新手在 AI 帮助下看似能做出中级难度的东西，但一旦出问题，他们可能心理准备和经验都不足。领导需要适度把关，不要因贪图效率就把他们推到风险过高的项目里。AI 并没有让初级“等同高级”，经验的价值仍在。也要关注初级的工作量和心理健康，高强度的成长节奏可能会让他们疲惫。早点发现苗头并给予支持。
谋划长期职业发展。 或许该重审你的工程师职级体系，看看是否需要加上“AI 工具使用能力”等新条目。明确告诉初级，晋升到中级需要什么：比如更侧重系统思考、独立判断，而不是看敲了多少行代码。也可以考虑建立“双通道”，让人既可以往 AI 或数据领域深耕，也可以往产品工程师方向发展。给新人一个 3-5 年的发展愿景，让他们知道该如何利用 AI 学习，而非图一时之快。
保持以人为本的团队氛围。 最后，要不断提醒大家，人类的创造力、好奇心、团队合作和共情，都是 AI 所不能替代的。初级开发者往往带着好奇和对新事物的开放态度——别因为有 AI 就让他们变得机械化。可以组织团队 Hackathon、结对编程或复盘，让大家在面对面或线上面对面的交流里学到“人和人”层面的东西。Camille Fournier 指出，很多最优秀的工程师都成长于“混乱而不确定”的环境她谈到，他们学会如何应对实际世界的复杂性。别让初级只在自己电脑前与 AI 独处，而要给他们更多交流和碰撞。
总而言之，生成式 AI 对软件开发带来深刻影响，但并不会消灭初级开发者——而是重新定义他们的角色。
初级工程师依旧是未来的高级和技术领导者。抓住这个事实的组织，会把 AI 当作放大他们潜力的手段，而不是替代。通过调整招聘、辅导、评估方式，我们能打造一个让初级在 AI 的帮助下茁壮成长的环境。
这些初级也将成为更适应时代、技能多元的工程师，将我们的行业持续推向前进。正如我和其他人所强调的，AI 只是帮助开发者的工具，而不是替代他们。让早期工程师与 AI 并肩成长，才能保护我们团队的创造力和竞争力。
能将人力潜能与 AI 辅助有效结合的公司，必将领先——而得到良好培养的初级开发者，会是这之中关键的一环。
很高兴在这里分享我正在为 O’Reilly 写一本与 AI 协作的工程实践新书。如果你喜欢这篇文章，也许会对这本书感兴趣。
原文：AI Won't Kill Junior Devs - But Your Hiring Strategy Might