为什么现在都招AI工程师了：职能在合并，但角色在分化

AI工程师的招聘热潮背后，是职能壁垒的打破与核心角色的重新定义。核心内容：1. 从传统职能分工失效，到AI降低执行成本带来的变革2. 未来团队真正需要的五种核心角色与心智模式3. 如何利用角色坐标系重新定位个人价值与发展方向

很多公司喊"AI 工程师"，难道是想用更少的人干更多的活？

一、你说不清自己是干什么的，不是你的问题你有没有发现，最近的招聘 JD 变了——以前分得清清楚楚：前端、后端、算法、测试、数据。现在越来越多公司只写四个字：AI 工程师。听起来很酷，好像职能壁垒被 AI 打破了，人人都能全栈。但你心里可能也闪过另一个念头：这会不会只是想让一个人，干过去三个人的活？两个念头其实都对。这正是这篇文章想讲清楚的事。先从一个你可能也有的感受说起——你有没有过这种感觉：简历上写着"前端工程师""产品经理""运营"，但你心里清楚，这几个字早就说不清你每天到底在干什么了。有时候你在想点子，有时候你在改bug，有时候你在纠结要不要砍掉一个刚上线的功能，有时候你盯着一个数据面板，不知道该继续投入还是及时止损。你不是不专业。你只是活在了一个职称正在失效的时间点上。最近看到Claude Code团队内部的一个思考框架，这个问题好像有答案了。他们发现：过去我们靠"职能"定位自己（工程师、设计师、PM、运营），但AI把"从想法到上线"的执行成本压到接近0之后，团队真正需要的，不再是职能齐全，而是角色齐全。这篇文章想讲清楚：

• 为什么"AI 工程师"会成为统称——职能确实在合并
• 但职能合并不等于角色消失，反而是

角色在分化未来真正定义你的 5 种角色到底是什么不同阶段该往哪补，以及你该怎么用这套坐标系重新定位自己看完你会明白：喊你"AI 工程师"，可能让你更值钱，也可能让你更便宜——区别就在于你想清楚了自己是哪几种角色的组合没有。二、职能在合并，但角色在分化过去的职能分工，本质是在分摊"专业壁垒"和"执行成本"。工程师不会做设计，所以需要设计师；设计师不懂用户，所以需要PM；PM不懂技术实现，所以需要前端来扣细节。这套分工体系能运转的前提是：每一环的执行成本都很高。但AI改变了这个前提。一个人可以借助AI，同时完成"想idea+写代码+做图+调运营策略"。当你不再需要三五人才能把一个想法变成可用的东西，团队里真正稀缺的就不再是"谁会用什么工具"，而是：

• 谁擅长

产出大量可能的想法谁擅长把想法快速变成能扛生产的东西谁擅长简化代码、界面、系统，敢于说"这个该砍"谁擅长缩短产品和市场之间的距离谁擅长在系统规模化后守住不出事的底线这5种能力，对应5种角色。它们不是5个岗位，而是5种心智模式。更重要的是，这5种角色不绑定任何职称。同样叫"设计师"，有人是Prototyper（不断产出新方案），有人是Sweeper（帮客户做视觉减法）；同样叫"PM"，有人是Grower（做GTM和增长），有人是Builder（快速搭MVP）。你以为自己在一个职能里，其实你已经在做某个角色很久了。这就是为什么你说不清自己"到底是干什么的"——不是你不了解自己，是职称这套坐标系，已经配不上你实际在做的事了。所以"AI 工程师"这个统称，藏着两层意思第一层，是我们前面说的：职能在合并。前端后端算法的执行壁垒被 AI 拉平了，一个人能覆盖的面变大了，公司当然乐意用一个"AI 工程师"的岗位把它们打包。但别急着高兴，还有第二层——很多公司喊"AI 工程师"，本质是成本导向：想用更少的人，干过去更多人的活。这不完全是技术进步的必然，更像是一笔算给你听的成本账。职能没有凭空消失，它只是被压缩、被合并、被塞进了同一个人的一天里。真正的问题不在"职能合并"这四个字，而在于：当所有人都被打包成"AI 工程师"，你靠什么区别于别人？答案是——角色。职能在合并，但角色在分化。同样是"AI 工程师"，有人擅长从 0 造东西，有人擅长守住庞大系统，有人擅长把产品推向市场。职称把大家拉平了，反而让"你到底是哪种角色"变得前所未有地重要。想清楚这一点，"AI 工程师"就能让你更值钱；想不清楚，它就只是让你更便宜的另一个说法。下面这 5 种角色，就是新的坐标系。三、5个角色到底是什么_{五种角色，各自的标志性动作与道具（Sweeper 全程橙色高亮）}

角色	一句话定义	最核心的能力	自问
Prototyper 原型师	批量产出想法，接受大部分不会上线	不怕浪费，用数量换那几个能成的	你上一次提出一个"可能很傻"的想法是什么时候？
Builder 构建者	把粗糙原型快速变成生产级产品/基建	速度快、质量能上线、一个人能闭环	你有没有能力独立把一个idea做成能跑、能抗压的东西？
Sweeper 清扫者	清理UI、简化代码和系统、敢于下线功能、做减法+提质	断臂求生的判断力，知道什么东西该留、什么东西该砍	你上一次主动说"这个功能别做了"或"这段代码可以删"是什么时候？
Grower 增长者	缩短产品和市场之间的距离——GTM、运营、看数据找PMF缺口	读懂用户、读懂数据、知道怎么让对的人用起来	你做的工作里，有多少是在"让产品被更多人知道、用起来、留下来"？
Maintainer 维护者	规模化系统下守住安全、可靠、快速、高效的底线	责任心+系统工程能力，风浪来了不慌	你有没有为一个不是自己犯的错，兜底到底？

一个关键洞察：只有Sweeper全阶段都需要看这三个阶段公式：新产品/未找到PMF：需要 Prototyper + Builder +Sweeper成长期/找到PMF：需要 Builder +Sweeper + Grower成熟期/强PMF：需要Sweeper + Grower + Maintainer只有Sweeper（清扫者），在三个阶段里都在场。这可能是5个角色里最不被表彰的一个——没人会给自己贴"我是做清理的"这个标签。但它恰恰是唯一的全阶段刚需。简化代码、清理UI、下线功能、优化性能……这些事没人喜欢做，但每个阶段都离不开。能力的真相是：不是越多人夸的能力越重要，而是越没人愿意做、但又离不开的能力，越稀缺。
为什么清扫的人更关键？ AI生成的太快太多。。。。四、不同阶段该往哪补_{三个阶段的角色组合 —— 只有清扫者（橙色）贯穿始终}这是全文最实用的部分，建议收藏。

你所在的阶段	团队最需要的角色组合	你该优先补的能力
0-1 探索期 项目刚启动，方向不明	Prototyper + Builder +Sweeper	练"多想少投入"的胆量 + "快速验证"的手速 + "敢于砍掉不靠谱的想法"
成长期 已经找到方向，开始有用户	Builder +Sweeper + Grower	练"看数据找PMF缺口"的敏感度 + "快速上线+快速迭代"的节奏 + "什么时候该说不"的判断力
成熟期 产品已经跑起来，用户量在涨	Sweeper + Grower + Maintainer	练"什么时候该说不"的判断力 + GTM和增长的能力 + 为规模化兜底的系统工程能力

一句话判断法则能力没有对错，时机和用对地方才是问题。如果你在0-1的团队里，却天天在做Maintainer的事——追求绝对稳妥、反复检查流程——说明你可能站错了位置。反过来，如果你在一个成熟的系统里，还在不断抛出新想法、拒绝做运维和优化，团队会被你拖垮。不是"我应该多学点技术"或"我应该多做增长"的问题。是你在哪个阶段、这个阶段需要什么角色的问题。五、你从来不是一个角色，而是一个组合_{你从来不是一个角色，而是 2-3 个角色的组合}看到这里，你可能已经开始对号入座了——但大概率你会发现，自己不止像一个。这很正常。事实上，大部分人本来就同时是2个角色，有些人能覆盖3个。变成“真正复合角色”一定价值翻倍的关键～有人是 Prototyper + Builder：想得出点子，也能自己把它做出来（AI时代最吃香的一类人，一个人就是半支队伍）。有人是 Builder + Sweeper：既能把东西快速做上线，又能回头把系统简化干净（工程师里最稳的一类）。有人是 Grower + Sweeper：一边做增长，一边敢砍掉数据不好的功能（最懂"少即是多"的运营/产品）。有人是 Prototyper + Grower：脑子里全是新玩法，又天然懂怎么把它推给对的人（很多做内容、做增长的人其实是这一类）。你不需要逼自己成为某一个纯粹的角色。真正有竞争力的，往往是那些能把2-3个角色打通的人——因为AI已经把每个角色内部的执行成本压下来了，一个人靠组合能覆盖的范围，比过去大得多。这也是"一人公司"能成立的底层逻辑：不是一个人干五个岗位的活，而是一个人靠AI杠杆，把2-3个角色的心智模式在自己身上打通。所以真正该问自己的不是"我是哪一个角色"，而是：我现在的组合是什么？（比如我是 Builder + Sweeper）我所在的阶段，还缺哪个角色？（比如成长期还需要 Grower，那我该往增长补）下一步我想把哪个角色也打通？六、你的坐标系该更新了回到开篇的问题：你说不清自己到底是干什么的。现在你可以换一种方式回答了。不是看职称，而是看你现在在做哪些角色的组合——

• 你是在不断产出可能的想法？（Prototyper）
• 你是在把想法快速变成能上线的东西？（Builder）
• 你是在帮团队做减法、简化系统？（Sweeper）
• 你是在把产品推向市场、让用户用起来？（Grower）
• 你是在守住规模化后的安全底线？（Maintainer）

你很可能勾中了2-3个。这不是不专注，这是你的组合。更关键的是，你所在的阶段还缺哪个角色，以及你下一步想往哪补。职称会过时，但角色不会。AI能替你执行，但替不了你判断自己现在该站在哪。每隔半年可能都不一样再来读读这篇，也许有不一样的思考——你的角色一定在不断的组合和变化。本文基于Claude Code团队内部思考框架扩展整理。

登录查看剩余 70% 内容