← #804

不招初级工程师，解决不了你以为存在的那个问题

文章摘要

作者 Francisco Trindade 是工程管理方面的作者（著有《Leading Effective Software Teams》）。他的写作缘起是听到一档播客里主持人问某家超大型科技公司的 CTO：你们还招初级工程师吗？他说自己无法接受这居然是个严肃的问题。

他先给出背景判断：AI 给软件工程带来的变化仍处在迷雾期，公司都在试验，有些放出豪言，多数觉得自己落后了。这种焦虑催生了简单化的论证和决策（他顺手嘲讽了一句「tokenmaxxing」），公司急于找到一个能让自己领先的简单赌注。「我们该招初级工程师吗？」就是其中之一。他承认新入行者面临的困难是真实的——行业增长放缓、工具能完成他们本该做的任务——但他认为这个框架本身对候选人有害，对公司更有害。

这不是新话题。 他指出，回避招聘资历较浅的员工的动机由来已久：科技公司长期以来只想招资深员工，理由是每个人都要端到端地为自己的工作负责，因此投资经验更划算。他讲了自己的亲身经历：某家公司当时的政策是只招 senior 及以上，理由是系统复杂，初级工程师可能成为负债、把东西改坏。这个决定的一个显眼且讽刺的后果是——管理者要让简单的活被完成变得极其困难，因为所有人都觉得自己不该干这些。他们后来改了政策，先小规模尝试招几个资历浅的人，接着设立实习生项目作为毕业生的入口。几年后，其中一些实习生成长为中级工程师，表现超过了一些当初以 senior 身份招进来的人。他的结论是：AI 版本的这套论证不是什么新洞见，而是一个旧的、错误的偏好换了身新衣服。

三个错误假设。 文章的论证主体是拆解这个问题背后的三个假设。

第一个是人才留存问题。你必然会因为自然流失而失去人：工程师会变得更有经验、去寻找更大的挑战，你就需要再招人。到那时你要么去市场上招，付出时间和招聘成本换来一个需要六个月熟悉你系统的人；要么提拔一个已经熟悉这些系统的人。AI 确实在影响团队规模，但那个规模会大于零。

第二个是「行业变化太快，现在招没经验的人是浪费，因为他们可能适应不了变化」。他用自己刚入行做咨询时的经历反驳：那时项目第一周是用来搭环境的，客户按全套工程团队的高价付钱，让他们花一周把源码仓库和 CI 构建跑起来——而且这还是运气好的时候，有时候机器要等好几周才能配好。今天这活大概是一个提示词加十分钟等待。他说自己活下来了，但他搭 Subversion 仓库的技能没有。他给出的反转很有力：如果行业变化真有那么快，那么经验才是那个正在贬值的资产，而主张初级工程师无法适应的那些人，恰恰是需要「反学习」最多的人。

第三个也是最根深蒂固的：如果工程师的工作变成写提示词和管理执行任务的 agent，那初级工程师还能干什么？他认为这种想法的主要问题在于把工程工作简化成了交付代码。AI 之前，工程师的角色是通过构建软件交付客户价值；AI 之后，工程师的角色仍然是交付客户价值，只不过是通过写代码的 agent。目标没变，判断力依然必要。当下技术判断仍是这份工作的主要部分；也许未来它会被压缩，但那时取而代之的会是以价值为中心的判断——这真的解决了问题吗？这个改动和已有的功能是否契合？他推出的结论很直接：如果工程师的角色是通过编排多个 agent 独立主导一个项目，那么初级工程师的工作就是通过编排多个 agent 独立主导简单的项目。无论未来如何，任务总会有更简单和更复杂的版本。

隐藏的问题。 文章最后转向他真正想说的：这些假设暴露了一个更深的问题——科技公司之所以看不到初级工程师的位置，是因为它们坚持把工程当作产品开发中一个孤立的学科。他指出，都 2026 年了，在行业否定瀑布模型作为软件交付方法的几十年之后，我们还是不断退回去。软件团队常常仍然长得像流水线：产品经理孤立地产出需求，交给孤立工作的设计师做设计，再交给技术负责人把工作切成简单任务分配给资历较浅的成员。如果流程真是这样，那么认为可以用 agent 替换最后一步就是自然而然的。

但他认为问题不在初级工程师的角色，而在这个系统。产品开发应当是产品、设计、工程在交付客户价值上的协作，工程师不只是写代码，他们提供关于如何最有效解决客户问题的视角与备选方案。他用一个例子说明区别：一个简单任务不应该是「加一个 CSV 导出端点」，而应该是「让客户能导出他们的账单历史」——这包含了思考导出里该有什么、在有 10 年数据的前提下什么样的性能是可接受的、以及它如何与产品里其他导出功能整合。如果你这样界定工作，即便在 AI 优先的世界里，也仍然会有更复杂的工程问题（比如如何在你公司的技术环境下交付一个复杂的战略性举措）和更简单的工程问题（比如上面这个例子）。

他的收尾判断是：如果你团队的工程师在做的是技术任务，那问题就不是关于初级工程师和 AI，而是关于你工程组织的有效性。你会有少数几个工程师在管理复杂度并成为其他人的瓶颈，而你的竞争对手会让每一个成员都在贡献客户价值。一个高产的团队，无论现在还是未来，都有容纳各个级别工程师的空间，包括初级。

HN 评论精华

uberman 给出了最被认同的批评（也顺手概括了文章的结构问题）：他不确定这篇文章到底就它提出的主题说了什么——它想谈的是不招初级人才（顺带说一句，这不是科技行业独有的现象），但最后变成了对「想用瀑布式流水线」的批评。
标题引发了一场意外的语言学争论。1970-01-01 说自己盯着这个「冒犯性的、双重半否定」的标题就决定跳过这篇文章。foldr 解释说这并不真的是双重否定，因为两个否定在不同的从句里，去掉两个否定得到的是一个完全不同的陈述：「招初级工程师会解决你以为存在的那个问题」。teach 一开始不理解「冒犯」从何而来，后来接受了对方的抱怨，并解释了为什么自己觉得标题很清楚：当下的时代精神里有一条很强的叙事——没人在招入门级岗位了，因为他们被 AI 取代了，而且至少对 CS 毕业生有相当扎实的招聘数据支持这一点（即便控制了整体经济下行）；所以「不招初级工程师」是很清楚的，这是写给正在做这类招聘决策的公司的。
jerf 写了整场讨论最完整的一篇「站在对立面陈述」的分析。他认为要先看到：说服公司招初级工程师本来就已经越来越难了。公司不想为「必然存在的、全速工作前的几个月培训」买单，他们要的是花钱立刻见到产出；而且按每美元产出算，资深工程师很可能比初级工程师更划算，哪怕薪水更高。行业里很多人喜欢每两年跳一次槽（这又被公司宁可招新人也不愿加薪的做法进一步助推），意味着你很可能只是付了培训费，好处被别的公司收走。而上市公司希望决策在下一个季度就有回报。以前至少初级工程师在职期间还会做一些真实的、对公司有益的工作，天平的「收益」一侧还有点东西。AI 造成的问题是它倾向于把这点收益也消掉：他本会分配给初级工程师的第一个任务——他预期对方要花几周，因为不只是完成表面任务，还要习得周边的技能和知识——现在变成了一个提示词，加上资深工程师间歇性地检查 AI 的完成情况。他声明这是从一个对他而言陌生的视角写的，他本人不接受这套论述，认为长期培养组织内部人才极其重要（毕竟你的组织除了组织内的人才和你为他们搭建的系统之外还剩什么），但他看到的现实是大多数人和公司的运作方式更接近他描述的第一种视角，而那个「长期会被击败」无论多长，肯定长过一个季度甚至一个财年。
DetroitThrow 指出了文章没有正面处理的「房间里的大象」：瓶颈越来越不在初级工程师能帮上忙的那一段。他认识的每一家招了一些初级工程师并鼓励他们用 AI 的创业公司，都发现自己卡在了代码评审的瓶颈上——卡在基本的代码质量和架构决策上；他认识的很多创业公司因此基本放弃了初级工程师。代码在可演进性、可靠性、可维护性上的质量仍然是开发流程的一部分，而几个月前在 Twitter 上宣称源码不过是新的汇编的那批人，已经开始承认自己错了。
lbriner 从另一个方向表达了对这套逻辑的困惑：初级工程师在做的哪些工作是 AI 现在能做的？他不会让初级工程师去做整个网站或者复杂的 agent 工作，多数时候招初级是为了补充人才池，指望他们几个月后有产出。他认为对初级工程师而言最糟糕的变化其实是远程办公：他不希望新入行的工程师的体验是整天坐在卧室里、在 Teams 上跟人聊天、不知道什么时候可以打断别人。玩笑、办公室、观察、无意间听到的对话，都是学工程和学「如何成为职场一员」的关键部分。这条引出了一片附和：danielvaughn 说即便作为 senior 也感觉远程削弱了自己的一些技能；johnsmith1840 认为远程办公让人与人之间零连接，很容易变得「公事公办」，因为彼此毫无关心或联系——很少有人愿意把朋友推下水，但远程让人不太可能建立真实关系。linkjuice4all 反对：你的客户也不坐在你旁边，照样付钱、照样期待你把活干完；问题多半不是距离。
a2ff6eeb0 提出了整场讨论最有争议的观点：招 senior 是浪费钱，你需要的是懂得足够多能驱动 LLM、但也别懂太多的人；LLM 已经足够好，能做调试、写代码，以及很大一部分设计和系统架构工作，今天的工作大部分是手动测试并把 bug 喂回给 LLM。被追问时他说这是亲身经历：「我的管理层在我快到没时间真正注意问题、也没时间动用我的专业判断时最高兴，而产出好到没人真的抱怨。构建大多数软件已经不再是技能型工作了，只是行业还没跟上。」sumanthvepa（自己开公司）激烈反对：我要的是质量，不是盲目的速度；我要速度作为一个好产品和好构建系统的副产品，而不是一堆扔过墙来、让我去调试和修补的垃圾。bgilroy26 补了一句：这种做法在累积「代码库理解债」，还债的传票随时可能到来。danielvaughn 给出了最具体的反例：他编程 15 年，一直想做 3D 却从没深入；如今 coding agent 这么强，他认真做了三次实验，结果全部很糟——原因是技能问题，他不懂 3D 的行话，不知道怎么描述问题，也不知道 agent 什么时候在搬石头砸自己的脚。他对「你只需要学会行话」的回应是：这恰恰证明它是技能型工作——如果一个有 15 年编程经验的人不能横向切换到另一类编程而不摔跟头，那说明存在的不只是行话，每个问题域都有需要人去理清的独特细微之处。
alephnerd 从供给侧提供了一个不那么受欢迎但被认真讨论的解释：新毕业生太多了，而目标院校之外的质量标准要么已经下滑、要么从来就不存在。他举了自己大学时一个同学的例子——为了躲一门难的操作系统课，用 transferology 找到得州某所宗教大学开的同名课，作业要么是给内存管理这类系统编程概念写圣经类比，要么是 fizzbuzz 级别的题；他母校的 CS 项目在审查该课程大纲后把那所学校列入了黑名单。他认为在这个价位（入门 SWE 薪资中位数约 14 万美元总包，25 分位约 10 万）上，除非是真正的异类，很难justify招一个非目标院校的毕业生。
frmersdog 给出了一个结构性的反驳，指向资本而非毕业生：如果不是所有资本都被锁在几个「死星」里，就不会有「毕业生太多」这回事。一个健康的就业市场需要成千上万家愚蠢的、注定失败的小公司和创业公司去追逐永远不会长期成功的傻产品和服务——它们雇的不只是顶尖毕业生，还有平庸的毕业生、靠图书馆几本书自学的人，甚至那个什么都造不出来但极擅长指出缺陷和潜在障碍的家伙——这些人在这些公司里从错误中学习，长成有知识、有恒心的工作者。而现在，所有的钱都锁在追逐同样几家公司、同样几种技术、同样几批申请者的 VC 和被动基金里，连时间点都一模一样，没有人在场边等着某个当红模式失败好去投另一条路线。他把这称为「我们只把一颗大蛋放进了孵化器，然后不惜一切代价不让它坏掉」。
pelagicAustral 从学术界补充了一个观察：大学似乎在全球范围内决定按经济激励而非学术激励运行，太多人在读自己毫无学习兴趣的学位，因为大学只是通往更好工作的路径——而那个「更好的工作」已经不存在了；与此同时，年复一年有越来越多的人，对自己文凭声称他们应当烂熟于心的东西一无所知。
MattGaiser 提出了「留存」这一侧的现实：这在很大程度上取决于你是否把初级工程师视为自己人才池的一部分——如果你留不住他们，那只是在补贴整个行业替它培训人；他自己头两份工作待了不到一年，公司赌错了。suzzer99 解释了机制：一个刚入行的开发者工作一年后在公开市场上的价值大约翻倍，而多数公司不会给 100% 的涨幅（会引发其他员工的连锁诉求），所以初级开发者必须跳槽才能拿到自己值的钱。throwaway2037 对「翻倍」这个说法表示强烈怀疑，认为这只对最好的初级开发者、在最有竞争力的市场才成立。
gopalv 给出了一条相当坦率的、从自私角度出发的反思：他过去用新人来「持有专业知识」，好让自己周末去海滩不被 call——那才是他在「教比自己做还费时间」的负产出上投入的真正激励。「AI 吸收知识，而公司可以在我离开时留住它。」他补充说这本来是容量和带宽问题，也是时间问题——他不可能在某个周四晚上 9 点到 11 点跟一个人做这件事。
zug_zug 从另一侧发言：也许你遇到的初级工程师池比我的好——我共事过的那些人要的恰恰是 AI 要的：完全定义、没有歧义的工单，大量刻意的评审，且不保证产出无 bug；至少 AI 不行的时候你关掉就完了，而如果那是一个人的生计，这个过程对所有相关方都是巨大的负担。ochronus 反驳说，如果你的招聘和后续的辅导做对了，即便是这样的初级工程师也能在一两年内一飞冲天，而 AI 做不到这一点。