最近圈里被一句话刷了屏——AWS的CEO Matt Garman公开表态说“用AI裁掉新人是企业最愚蠢的操作”。这句话乍一听像是大厂高管输出价值观但仔细琢磨分量很重。AWS的CEO站在全球云计算风向标的位置上亲口说“AI替代不了初级岗位的人才储备”这跟很多人想象中的“AI一来新人全滚”完全是两个方向。这个话题适合所有带团队的技术管理者、创业公司老板以及正在纠结要不要用AI做人员决策的HR和业务负责人看。我结合自己这些年在技术团队管理里踩过的坑把这件事的来龙去脉、背后的管理逻辑和可落地的做法拆开聊一聊。1. AWS CEO这句狠话到底戳中了谁的痛点1.1 那句话是怎么说出来的先还原一下背景。Matt Garman在最近的公开场合被问到AI对入门级工程师岗位的影响他没有顺着“AI会消灭初级码农”的论调往下说反而把矛头指向了企业管理者本身。他的核心观点是如果一个公司因为用了AI工具就急不可耐地把新人裁掉那这个公司等于亲手切断了自己的人才供应管道。他强调的是初级工程师的价值不在于他们当前能写多少行代码而在于他们经过三到五年的培养后能成长为架构师、技术负责人、业务核心——如果公司永远只留熟手、只依赖AI来填补初级产能那么五年后这个组织会发现自己根本没有能扛大旗的人。这句话之所以引发广泛讨论是因为它同时踩中了两个敏感神经。一边是打工人对“AI取代岗位”的焦虑另一边是管理者对“降本增效”的冲动。当一个人公开说“用AI裁新人是最愚蠢的操作”时等于把这两股力量直接对撞了。我身边不少做技术管理朋友的反馈是听完其实有点五味杂陈——因为大家心里都清楚现在确实有公司正在这么干而且干得理直气壮。1.2 为什么“裁新人”这个话题会引爆讨论过去一年很多公司确实把AI用成了“裁员加速器”。我见过不止一个案例公司上了AI代码辅助工具之后发现原来需要三个初级工程师干的活现在一个高级工程师加AI就能扛下来。于是管理层做出决策——缩编初级团队把人力预算集中到高级岗位和AI工具订阅费用上。这个逻辑在财报上非常好看人力成本立减人均产出甚至还能往上走。但问题恰恰出在“短期好看”上。技术团队跟流水线工人不一样新人不是完不成流程才需要被裁的“残次品”。新人进团队的第一年看起来是在“拖后腿”实际上是在吸收上下文、理解系统架构、积累业务认知。这个过程没有产出上的捷径AI能帮你生成代码片段但生成不了“一个新人脑子里的系统地图”。当企业把新人当成成本项而不是资产项时往往就已经在为两三年后的技术断层买单了。我从管理的实际体验出发觉得大多数裁新人的决策不是因为AI太强而是因为管理者太懒——懒得分清楚“短期人工成本”和“长期组织能力”的关系懒得多花半年去设计一条新人成长路径干脆一刀砍掉最容易被量化考核的部分。AWS CEO把这事说成“自掘坟墓”话说得难听但逻辑上一点没夸张。2. 用AI裁新人账面上省的钱和你看不见的代价2.1 裁新人为什么短期内看起来很“合理”先替那些做这种决策的管理者说句公道话裁新人这件事在报表上确实很“划算”。刚毕业或工作一两年的工程师薪资往往只有资深工程师的零头培养期又长头半年几乎不产生正向业务价值。公司每年为新人付出的成本包括工资、社保、导师时间、内部分享资源还可能因为一个小bug导致线上事故。把这些成本列出来任何一个被季度KPI追着跑的Leader都会动“不如用AI顶一顶”的念头。而且AI工具现在确实能cover掉一部分初级活。比如写CRUD接口、写单元测试、生成实体类、处理简单脚本这些曾经是新人入门期的主要磨炼内容现在AI几分钟就能给出版本。很多团队实测下来一个高级工程师加AI工具确实可以顶掉一到两个初级工程师的日常产出。于是管理层得出结论既然“简单劳动”可以被机器替代保留新人就没有意义了。但这里有一个偷换概念的陷阱。AI能替代的是“任务的执行”替代不了“人的成长”。新人做的那些简单任务真正的目的从来不是把代码写完而是让他在写代码的过程中理解业务规则、熟悉工程规范、学会排查问题、建立起“这个系统为什么会这样设计”的全局观。你把这些任务的执行交给AI就等于取消了新人学习成长的载体表面上是效率提升实际上是釜底抽薪。2.2 新人的价值不在产出而在“技术债的消化能力”这些年我带过大大小小不少团队一个特别明显的感受是一个组织里如果长期没有新人进来老员工会迅速陷入一种“只维护、不重构”的状态。原因很简单老员工对系统太熟了熟到能预判每一个坑在哪里所以会本能地绕开坑而不是填掉坑。但新人不知道坑在哪里他们会踩进去然后花力气去理解坑为什么会存在最后大概率会提出一些让老人眼前一亮的重构方案——哪怕方案很幼稚至少让团队重新审视了问题。技术债这个词听起来抽象我用一个生活化的例子解释。一个小区的水管系统老维修工知道哪段管子容易漏水天天带着胶带去补项目组觉得“稳得很”。来了个新人他不认识这些管子按图纸核对了一遍发现有两段旧管本可以整体换掉虽然更换期间会影响几户人家用水但换完之后三年不用再补。老维修工不是不想换而是他习惯了“可用的现状”新人没有这种习惯所以他是唯一一个愿意动手术的人。企业把这类新人裁了等于整个组织再也找不到“愿意动手术”的人技术债只会越滚越深。2.3 组织发展的断代危机三年后你拿什么拼再来算一笔时间账。假设一家公司每年招一批新人培养周期两年第三年这批人刚好能独当一面到了第四第五年就能带新人、做架构决策。如果现在因为AI裁掉了这批“正在被培养”的人那么公司现在的技术骨干还在能应付当下但两年后骨干可能跳槽、可能转管理、可能因为精力下降退出编码一线到那时候你发现中间层已经空了——上面是资深下面是刚招的应届中间断层了两代人的组织记忆。这种断代的后果在行业里其实有前车之鉴。有些公司经历过“优化老员工、只留管培生”的阶段结果老员工走了之后系统出问题没人敢碰管培生只能一边看文档一边给客户道歉。而那些坚持每年稳定进人的公司哪怕业务有波动技术团队始终有新鲜血液顶着遇到转型往往能更快掉头。AWS CEO说裁新人是在“自掘坟墓”本质上是提醒大家你的组织现在能运转靠的是几年前招进来的那些“新人”已经长成了骨干你现在不招新人就等于把未来的骨干提前枪毙了。3. 为什么新人恰恰是AI最难替代的资产3.1 新人不是“便宜编码器”而是组织的学习引擎AI和新人最根本的差异在于“学习的目的”。AI的学习目的是完成一个给定的任务它的知识边界是训练数据和上下文窗口决定的。新人的学习目的是理解一个系统如何运作以及如何让这个系统变得更好他的知识边界是无限扩展的而且他会把这种理解沉淀为组织的长期能力。我举一个实际的例子。我们团队曾接手一个老项目代码里有一段逻辑注释写着“不要动这段代码改了会出问题”。AI工具处理这种代码时唯一的策略就是保持原样。但一个认真钻研的新人会先去搞清楚为什么这段代码不能动、它依赖了什么隐性条件、关联了哪些不为人知的业务场景。他研究完可能会小心翼翼地重构也可能最终得出结论——确实不能动但至少他把“为什么不能动”写成了文档这本身就是组织资产的增值。AI永远不会主动去做这件事因为AI不会“好奇”。所以新人更像是一个学习引擎他的输入是业务上下文、技术架构、同事的经验输出是团队整体认知水位的提升。组织里有一个新人在认真成长老员工为了教他会重新梳理自己的知识、主动文档化、把隐性经验显性化。这个过程对老员工的提升也很大。一旦没有新人老员工就失去了梳理经验的动机团队的认知会逐渐封闭。3.2 技术传承的真相文档替代不了人经常有管理者觉得只要把知识沉淀成文档、wiki、代码注释人走了也无所谓AI甚至可以帮你做知识管理。这个想法有道理但忽略了一个关键事实真正的技术决策能力是无法被文档固化的。一个系统的核心知识往往分布在无数个微小的上下文里——某个字段为什么叫这个名字、某个接口为什么设计成异步、某个依赖为什么不升级这些内容没有文档会写只有在师徒、结对、评审这些“人际接口”中才会传递。新人恰好是这些“人际接口”的最佳接收者。他们的存在逼着老员工讲出那些“我知道但是没说过的”经验。我自己的体会是每次给新人做code review都要比平时认真三倍因为你要把脑子里那些“凭直觉就改掉了”的东西翻译成新人能理解的逻辑。这个过程比AI生成一段注释有价值得多。如果组织里只剩AI那就等于所有人都默认“代码能跑就行”而没有人去追问“代码为什么长成这样”。3.3 AI杠杆与新人杠杆的关系最后说一个更积极的角度。AI确实是可以撬动效率的杠杆但它杠杆的落点最好是在“提升新人的成长速度”上而不是在“减少新人的数量”上。我给团队配AI工具的时候最看重的指标不是“编码效率提升多少”而是“新人多久能独立上手”。一个新人用了AI辅助之后三个月就能达到以前半年才能达到的理解水平这才是AI真正的价值。用一句话概括就是AI是放大器你用它放大一个有潜力的新人他会迅速成长为独当一面的人才你用它放大一个只剩熟练工的组织它只会加速这个组织的钝化。这也是为什么我坚定地认为AI与新人从来不是替代关系而应该是组合关系。4. AI在人才管理里的正确打开方式不是裁决机器而是辅助工具4.1 招聘环节用AI做结构化面试和潜力评估说完了“为什么不能裁”再聊聊AI应该怎么用在人才管理上。第一个可以落地的场景是招聘。现在很多HR团队用AI做简历初筛、做面试题目的动态生成甚至有些人尝试用AI全程面试候选人。我个人的建议是AI可以用在“结构化面试”和“潜力评估”的辅助环节但绝不能让AI做最终裁决。实操中做得比较好的一种方式是让AI根据岗位JD生成一套结构化评分卡面试官按照维度打分AI负责汇总数据、识别各维度的一致性、标记异常信号。比如AI可以发现某位候选人笔试成绩突出但设计沟通分数偏低或者发现某位面试官的评分曲线长期偏离团队基线。这些信息对招聘决策非常有价值但最终“要不要这个人”的判断应该永远由有经验的管理者结合现场感受来完成。再具体一点对于应届生或初级岗位我建议在题目设计上不要只考算法和语法而是用AI生成一些“开放性问题场景”。比如给一个残缺的系统描述让候选人指出现有问题并提出改进方向。这种问题没有标准答案但能真实反映一个人的系统思维。AI在这里的作用是快速生成多个场景变体避免候选人背题同时通过对话接口记录候选人的回答逻辑为面试官提供参考素材。这套做法我们用了半年多招进来的新人质量比之前纯粹靠“手写算法题”更稳定。4.2 培养环节用AI给新人定制学习路径新人入职之后AI最该发挥价值的地方是“个性化培养”。传统的新人培训往往是“一锅炖”三周培训、两周轮岗、然后扔到项目上自学成才。这种方式效率很低因为每个人的基础不一样有人卡在编程语言有人卡在业务理解有人卡在工具链操作。用AI辅助做培养路径规划就能针对性地解决这个问题。我们的做法是这样的新人入职第一天先让AI生成一份自测问卷覆盖语言基础、工程工具、业务领域三个维度。问卷结果出来后AI会把新人自动分到不同的训练模式里——比如基础薄弱的先走“脚手架项目”工具不熟的先走“环境搭建代码走读”业务理解弱的则优先安排业务文档精读。训练过程中AI还会根据新人在代码仓库里的提交情况、在知识库里的搜索行为动态调整学习内容。这里有一个容易被忽略的细节学习路径绝不能是静态的文档列表。我给团队设计过一个简单的规则——“每周学习产出必须包括一个改进了现有系统的提案”。新人可以是任何层级的小改动比如优化一个接口的响应时间、清理一段死代码、完善一条链路日志。AI在这个环节的作用是帮新人判断提案的可行性并给出风险提示。新人看到AI反馈再去跟导师聊讨论质量会明显提升。4.3 赋能环节AI是给新人用的不是用来裁新人的说得扎心一点同样一套AI工具你发给新人用和发给HR做裁员分析产生的组织效果完全不同。让新人用AI他能加速成长减少初期的挫败感。让HR用AI去分析“哪些岗位可以被替代”本质上是在制造组织内部的恐惧氛围一旦员工觉得自己随时可能被AI替代会本能地不配合AI应用——甚至故意破坏AI工具的效果比如在代码里加注释让AI分析不到关键信息。这个现象我从几个朋友的公司里都听到过。他们公司引入了非常先进的AI代码分析工具用于“代码质量评估”但员工普遍抵触原因是这套工具输出的报告会被管理层用来做绩效排名。最后的结果是报告数据失真团队氛围变差AI工具沦为摆设。反观有些公司把AI工具定位为“给工程师配的免费助手”鼓励大家用AI解释不熟悉的代码、生成测试用例、写提交说明工具使用率反而是前者的好几倍。所以核心原则是AI在人才管理中的角色应该是“教练”而不是“法官”。凡是涉及“评估一个人是否应该被裁掉”的场景AI可以提供数据和分析但决策必须由管理层基于长期价值判断来完成。AI做的应该是帮助优秀的人变得更好而不是帮助公司更快地甩掉暂时不够好的人。5. 技术团队新人培养的实操清单管理者可以直接抄5.1 建立“新人导师”的绑定机制而不是“新人文档”很多团队的新人培养失败不是因为没有文档而是因为新人遇到问题不知道该问谁。我比较推荐“双轨绑定”机制每位新人入职时分配一位业务导师和一位技术导师。业务导师负责讲清楚行业逻辑、用户场景、项目背景技术导师负责代码规范、架构讲解、工具使用。导师每个月至少安排四次固定的一对一交流时间固定到日历上不允许被临时会议冲掉。有管理者会问这样导师投入的时间成本谁来买单我的答案是把“带新人”纳入导师的绩效和晋升指标。在晋升review里明确写清楚“培养了哪些新人效果如何”否则导师天然会觉得“带新人是额外负担”。我们团队实行这个制度之后老员工带人的积极性明显提高因为带出有成果的新人对他们自己的title和影响力都有直接帮助。5.2 前三个月不考核产出只考核学习轨迹新手期最怕的就是管理者用“老员工的产出标准”去要求新人。我的经验是前三个月的新人考核应该关注三件事有没有提出过有价值的问题、有没有独立完成过一个小任务、有没有形成对系统全貌的基本描述能力。产出数量一律不看bug率可以看但不作为负面指标毕竟新人写bug是正常的重要的是他能不能从bug里构建出自己的排查方法。具体操作上我给团队设计了“学习轨迹周报”模板新人在飞书或Confluence里填写本周学了什么、卡在哪里、下周计划导师每周review并给出反馈。AI在这个环节可以做周报的初步分析——比如把新人提到的卡点自动归类发现哪类问题反复出现提醒导师重点关注。这样一来新人不是被考核压着走而是被一套清晰的成长节奏带着走。5.3 给新人安排“带WIP的活”而不是边角料很多团队给新人的第一个任务是“改改文档”“写个测试”“调调配置”这些边角料活对业务没有真实价值新人做完也提升不了什么。正确做法是给新人一个“已经做了一半的项目”。这个项目有一定复杂度但已经有人在维护新人进入时先花一周熟悉代码然后尝试提交第一个真实的功能或修复。因为项目是有人维护的有了问题不会全砸在新人一个人头上他可以随时找维护者求助。这个设计叫“带WIP的活”WIP就是Work In Progress。核心逻辑是让新人在一个真实的、有人兜底的场景里犯错和成长而不是把他丢到一个无人区里自生自灭。我观察下来这种方式的留存率和成长速度比“先学习两周再上真实项目”要高很多。因为人从第一天起就在跟真实的业务逻辑打交道学习的动机完全不一样。5.4 把“带新人”变成组织文化的KPI最后一条建议听起来有点虚但恰恰是被most公司忽略的把“带新人”变成组织文化的最高优先级事项。AWS CEO能说出“用AI裁新人是自掘坟墓”前提是AWS作为一个技术组织骨子里认可“人才培养是企业最深层的护城河”。落到团队管理上这意味着现金流的波动、短期业务压力、技术选型的调整都不应该成为牺牲新人培养节奏的理由。具体执行时可以设置一些简单但硬性的规则。比如任何一个两周五以上的迭代都必须包含至少一个“新人可讲解的技术主题”任何一次线上事故复盘如果有新人在场必须有专门环节让新人提问每季度评选一次“最佳新人培养奖”奖金和绩效挂钩。这些动作看起来琐碎但会把“珍惜新人”从一句口号变成一套人人看得见的制度。6. 我踩过的坑AI辅助人才决策的实战记录6.1 翻车案例完全依赖AI评估导致的误判说一个我自己真实经历过的翻车故事。前两年我负责过一个数据组当时团队里有两个应届生一个平时话不多但代码提交非常规范AI代码分析工具给他的评分离谱地高另一个新人想法很多、经常重构代码但因为提交频繁导致AI报告里显示“变更范围大稳定性风险高”被HR列入了低绩效名单。我当时差点就基于AI报告做了处理决定。幸好有个老工程师提醒我说“那个代码规范的其实一直在复制粘贴真正在思考的是那个经常重构的”。我花了一下午仔细review了两人的代码发现确实如此——AI只能看到提交记录和代码静态指标但它看不到代码背后的思考深度。从那以后我定了一条规矩AI评估报告只能作为review的参考素材绝不允许直接作为人员淘汰依据。6.2 在AI和人心之间的平衡第二个坑是节奏问题。AI工具上线之初我一度非常兴奋觉得可以替代很多机械的人力管理工作比如试用期评估、任务分配、进度追踪。结果用了两个月发现员工开始用“对付工具”的方式对待日常工作——比如为了让AI报告好看大家都在优化“可以被量化的指标”而不是真正把事做好。反而是那些无法被AI量化的软性能力比如跨团队协调、业务洞察、内部影响力被悄悄弱化了。我后来调整了做法AI工具只用来处理“信息密集但判断简单”的工作比如汇总周报、识别任务风险、生成候选问题列表凡是涉及“对人的评价和判断”的工作一律回到真人会议里用结构化讨论解决。这个界限划清楚之后团队对AI工具的信任度反而提高了因为大家知道AI不是用来盯人的。6.3 给管理者的三条行动建议最后结合这几年的实操给同样在做技术管理的朋友三条行动建议都是我付过学费换来的。第一从今天起重新审视你的新人编制。不管公司预算多紧至少要保留一条“每年稳定进应届生或初级工程师”的人才线数量可以少但绝不能断。断一次再次恢复要付出的成本高得多。第二把AI工具的预算和新人培养预算绑定在一起。你给团队买的AI工具如果最终没有落实在每个新人头上说明这个工具不是用来提效的而是用来降薪的——那它迟早会反噬组织文化。第三给每个新人配一个“技术引路人”最好是在公司待了三年以上、对系统全貌有认知的工程师。这个人不需要做新人的考核官他只需要在关键时刻回答一个问题——新人应该往哪个方向长。我自己的亲身体会是AI确实让很多初级工作变得“看起来可替代”但正因为这样那些仍然愿意耐心培养新人的团队未来会在人才密度上拉开巨大的差距。当多数公司在用AI简化管理、压缩成本、淘汰“短期不划算”的年轻人时你愿意花心思把新人一颗一颗磨成螺丝钉和承重墙这样的组织才真正握住了长期主义的入场券。如果放在两三年前我可能会觉得“人才密度”这个词太虚。但这两年被AI工具反复冲刷之后我越来越确信技术团队的护城河根本不在于你用了多先进的模型而在于你身边有没有那些“三年前还是新人、今天已经能扛事”的伙伴。这个道理跟AWS CEO说出来的那句话本质上是一回事。