开发岗 -52%、AI 应用岗 +60%：团队的技能矩阵，该重排了

「AI 能写 80% 代码」这句话，最近在好几个内容平台同时刷屏。我刷到第一条越想越觉得哪里不对。

大家讨论的落点，都在「我会不会被替代」。但把视角从个人拉到团队，问题其实变了。不是团队不需要人了，是需要的人变了。

一份岗位结构数据把这件事说得很直白，三个数字摆在一起看（出处：新快报 A15 版汇总智联招聘 2026 一季度报告、脉脉《2026 春招求职行为洞察》、翰德《2026 人才趋势报告》）：

• 普通开发岗，预计缩减 52%
• AI 应用开发岗，预计增长 60%
• 新人岗，入口收窄 20%

这三个数讲的不是「裁员」，是「换人」。塌掉的是只会单一动作的人，涨起来的是能把多种能力组合到一起的人。

普通开发岗塌掉 52%，塌的是「把需求翻译成代码」这个单一动作。这件事 AI 做得越来越快，单价自然往下走。我前阵子和一位做 SaaS 的朋友聊，他说现在招人看「能不能独立写完模块」这条标准在快速贬值。

AI 应用开发岗涨 60%，涨的是另一件事。把模型、接口、业务流程串成一个能跑的东西，它要的不是会写，而是要会「摆」——摆清楚什么交 AI、什么留人、边界画在哪。这活儿新人干不了，老开发如果不愿意走出舒适区也干不好。

新人岗收窄 20%，是最容易被忽略的一条。它意味着「先打杂三年再上主战场」的梯队在变窄，新人得直接贴着高价值环节。一个带教十年的前辈说：以前新人前半年基本在旁边看，现在看不起学了，进来就得上手 Agent 编排辅助。

团队技能矩阵，从来不是墙上贴的一张能力清单。它写在每个人每周的工时里。

过去我们默认一套技能矩阵。编码为王，谁写得快、bug 少、能扛复杂模块，谁就是团队核心。

现在这套在松动。新矩阵里有四把钥匙，共同点很清晰——都不是「写」出来的，是「判」出来的。

• 需求定义：把业务问题翻译成能被实现的命题，边界比实现更重要
• 验收标准：AI 写的代码最怕没人验收、过不了线，标准要从需求阶段就定好
• 评审质量：同事写的、AI 写的、外包写的，怎么一眼看出不行
• Agent 编排：把多个 AI 工具、模型、流程串起来，让它真的能跑业务

这四把钥匙里没有一把叫「编码」。不是说编码不重要，而是它从「定价核心」变成了「基础动作」。一个资深后端跟我吐槽：现在他最值钱的时间，不是写代码，是帮团队把 AI 初版里藏着的三个坑挑出来。这把「判」的能力，恰恰是 AI 短时间替代不了的。

我一个带过三十人研发团队的朋友去年踩过坑。他看报表觉得「人不够」，想再招两个开发；后来拉了份工时分布，发现真正缺的不是写代码的人，是能做评审和验收的人——那两块占比低到离谱，活全压在编码上，AI 初版没人审，返工更多。

他那是典型的「把人换掉」思维，不是「把岗位重排」。

这事给我的结论很实：重排之前，必须先看清现状。谁在写、谁在审、时间到底花在哪——工时和任务数据，是唯一不撒谎的依据。拍脑袋说「我们缺 AI 人才」，不如先拉一份分布图看看，现有的时间是不是已经悄悄往那边挪了。

老板在这里最常见的盲区，是把「加人」当「解药」。可编码已占一半多、评审只有个位数时，再加写代码的人只会让编码更挤、评审更没人管。重排的本质是调时间分配，不是调人头。

说清楚道理之后，关键是怎么落地。下面这套做法，是我手头在用的研发协作平台里跑通的，每一步都贴一张真实界面，你照着做就能复现。

5.0 先把任务归到五个价值环节

别急着看数据，先让任务「说得清自己属于哪类」。把任务类型配成五个：需求定义、评审、编码、验收、AI 编排。这一步看着简单，却决定了后面能不能把「写」和「判」分开数——不少团队工时表一团糊，根子就在这：任务类型只有「开发」「测试」，编码和评审混在一起。

5.1 打开团队总览，先看全貌

配好之后，团队总览页会把需求、任务、问题汇总出来，连带一张工时雷达图。我一般先看雷达图。哪块凸、哪块凹，不用算就有感觉。如果只有「编码」那一根刺特别长、其他都趴着，重排方向基本不用猜。

5.2 把任务按价值环节归档

接着把任务逐条归到那五个类型里。归档完，你大概就能回答：团队到底谁在写、谁在审。归档不是一次性动作，是每周例会前的例行，不然数据很快糊回去。

5.3 拉一份工时分布，看时间花在哪

最关键的一步。进工时汇总按任务类型切维度，能看到每人、每环节各占多大比例。我那个朋友的问题，就在这张表里现原形：编码占了一半多，评审只有个位数。数据不替你做决定，却能把「感觉不对」变成「看得见的不对」。拿这张图跟老板聊「要不要加人」，比拍脑袋有底气。

5.4 用甘特图看时间的流向

最后补张时间维度的图。甘特图把任务铺在时间表上，看清哪些环节连续堆、哪些长期空着。到这儿四个问题齐了：谁在写、谁在审、时间花在哪、趋势往哪走。拿这几张图去周一例会，重排就有了共同的底。

像 YesDev 这类研发协作平台，已经把任务类型、工时报表、看板内置好了，套个现成模板就能起步，不用从零搭。这也是我手头直接用它的原因——重排最重要的是先动起来看数据，而不是先花两周搭系统。

回到开头三个数字，它们真正在说时间分配要变。

你嘴上说「要重视评审」，但工时表里评审还是 5%，那这句话就没有重量——矩阵是用时间写出来的，不是用口号贴出来的。

重排的顺序很重要。先看清现状，再讨论怎么调，最后才加人减人。顺序反了，重排就是赌。

我见过最快见效的做法，不是大动干戈重组团队，而是先选一两个塌陷环节做试点——比如把评审节点前移、给 AI 编排明确职责，用一两周看数据有没有改善，再决定推不推广。小步快跑，比整体推翻稳得多。