最近圈里被一句话刷了屏——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说出来的那句话，本质上是一回事。
