AI 编程 76% 之后,HR 该怎么定初级研发的岗级和薪资

—— 写给每一个还在用"学历+工作年限"套初级研发的 HR 一号位

开篇：76% 已经是个过时的数字

很多 HR 朋友转给我一张图，说"AI 编程渗透率 76%，我们得动一动初级岗的薪资结构了"。

我看完只想说一句话：76% 是去年的数字，今年已经 84%。

Stack Overflow 2025 年度开发者调查刚出——4.9 万名开发者、177 个国家、62 个问题、314 项技术，这是全球最大的开发者调研。里面白纸黑字写着：84% 的开发者正在使用或计划使用 AI 编程工具，去年是 76%；51% 的专业开发者每天都在用。

一年 8 个百分点。

而当我们还在会议室里讨论"要不要给初级研发配 Copilot"的时候，一线的初级研发早就在用了——他们只是没告诉你。

这不是"AI 会不会来"的问题。这是"AI 已经在里面待了一年，我们的岗级和薪资结构却还是 2019 年那一套"的问题。

第一：编码速度已经被 AI 打平,岗级锚点必须换

先讲一个反直觉的事实。

METR（一家专门做 AI 能力评估的研究机构）2025 年做过一次严谨的随机对照试验：16 名有经验的开发者、来自 22000+ Star 的顶级开源仓库、246 个真实 issue、每个平均 2 小时、一半用 Cursor Pro + Claude 3.7 Sonnet、一半不用 AI。为了保证参与度,给每人时薪 150 美元。

开始前,开发者预测——AI 会让他们快 24% 。

结果测出来——他们慢了 19% 。

更荒诞的是,做完实验、看到自己被计时器打脸的数据后,这些开发者依然认为自己"快了 20%"。

这项研究我贴一下原始链接:https://byteiota.com/ai-productivity-paradox-why-gains-stay-at-10-15/

为什么讲这个?

因为大部分 HR 谈初级研发的岗级,还在用"编码速度""独立完成模块"这类词。这些词在 AI 编程 84% 渗透率的今天,已经不能作为岗级锚点了。

原因很简单:

编码速度已经被 AI 打平。初级研发用 Cursor 写 CRUD,速度和三年经验的中级研发用 Cursor 写 CRUD,差不多。
"独立完成一个模块"这句话,在今天等价于"能用 Cursor 生成一个能跑的模块"——但"能跑"和"能上线"之间,还差着一个"能被评审通过"。

旧岗级锚点(P1-P3):编码速度、代码行数、独立完成模块。

新岗级锚点(P1-P3):AI 辅助下的 PR 接受率、bug 引入率、代码可维护性评分、能识别 AI 幻觉的能力。

后面第五步会具体给你锚点的量化口径。这里先把逻辑钉死:再用编码速度定岗级,你会把一个"AI 提示词工程师"评成"高级研发",然后半年后被业务线骂到不敢开会。

第二:个人产出 +21%,组织交付 0%——你到底在给什么买单?

第二个数据来自 Faros AI——他们分析了 10000 多名开发者的真实工作数据。这是目前公开可查的、规模最大的组织级 AI 编程效果分析。

数据长这样(来源:https://byteiota.com/ai-productivity-paradox-why-gains-stay-at-10-15/):

个人任务完成率:+21%
PR 合并数:+98%
(接近翻倍)
PR review 耗时:+91%
(评审员被塞爆)
PR 平均大小:+154%
(变胖了)
bug 率:每个开发者 +9%
DORA 组织交付四大指标(部署频率、交付前置时间、故障恢复、变更失败率):0% 改善

看清楚这组数字对撞:

个人产出翻倍,组织交付原地踏步。

这意味着什么?意味着你花钱买的初级研发,如果按"任务完成数""PR 数""代码行数"给他发绩效——你在给一个把评审员塞爆的人发奖金。

对 HR 一号位的直接冲击:

你如果继续用"月度 PR 数"作 KPI,你在鼓励初级研发用 AI 疯狂灌水。
你如果继续用"任务完成率"作绩效,你在鼓励初级研发把大任务拆碎、拿 AI 一顿糊、把 review 责任推给中级。
你如果继续按"个人产出"给薪资加分,你在为组织的下游堵塞付账。

这根钉子的落地动作:

把绩效锚从"个人产出"改成"团队交付节奏"。

具体来说,初级研发的季度绩效,拆成 4 块:

PR 一次通过率
(权重 30%)——写出来的东西能不能一次评审通过,不用返工。
引入 bug 数/千行代码
(权重 25%)——线上出的问题,能不能追到你。
评审响应时长贡献
(权重 20%)——你是不是给团队降低了评审队列。
AI 代码识别与修复能力
(权重 25%)——给你一段 AI 生成的、看起来对但有 bug 的代码,你能不能找出来。

第 4 项,才是初级研发在 AI 时代真正的定薪锚。

第三:AI 生成 PR 接受率 32.7% vs 人写 PR 84.4%——"能写"和"能上线"是两回事

LinearB 的 2026 工程效能基准报告——分析了 4800 个工程团队、810 万个 Pull Request。这是目前规模最大的 PR 数据分析。

结论一句话:

AI 生成的 PR,接受率 32.7%。人写的 PR,接受率 84.4%。

2 个 AI PR 里,有 1 个被拒。

结合 Stack Overflow 2025 的另一个数据看更扎心:66% 的开发者最大的挫败感,是处理"看起来对但不完全对"的 AI 代码;45% 的开发者认为,调试 AI 代码比自己重写更耗时。

翻译成 HR 语言:

初级研发用 AI 写代码,速度快 3 倍,但被拒率高 2.5 倍,被拒之后的返工时间还比重写更长。

净收益是多少?Bain & Company 的 2025 技术报告给出了这个残酷等式:

编码只占软件开发生命周期的 25-35%。
其他 65-75%(评审、测试、规划、部署、维护)AI 加速不了。
就算 AI 把编码环节加速 30-55%,总生产力增益 = 0.30 × 0.30 = 9-10% 。

数字对得上现实。Google 的 2025 DORA 报告调研了 5000 名专业开发者,结论也印证:AI 是放大器不是修理工——好团队用 AI 涨 25-30%,差团队用 AI 反而是负增长。

对 HR 一号位的动作:

初级研发的能力模型,必须新增一项—— "AI 输出的把关能力" ,而且要作为主指标,不是加分项。

第四:面试题不能再考"手撸算法"了——考的必须是"能不能救屎山"

我最近帮几个朋友的公司调整了初级研发的面试题库,思路很简单——默认候选人手边有 AI,考的是他和 AI 一起工作的能力。

老一套面试题:

手写快排/二分查找/反转链表——AI 三秒钟给你写完,考不出真实差距。
白板画系统架构——现在的初级研发大部分都能对着 Cursor 抄一版出来。
"说说你熟悉的 XX 框架"——这些框架文档 Claude 全背下来了。

新一套面试题,长这样:

面试题 A:AI 屎山重构题

给候选人一段 300 行、AI 生成的、看起来对但藏了 3 个隐蔽 bug 的 Python 代码(比如错误处理里 catch 了太宽的异常、边界条件把 None 当 0 处理、异步函数忘了 await)。要求 30 分钟内:1) 找出所有问题;2) 说清楚为什么这样写有风险;3) 重构成生产可用版本。

这一题一考,一个候选人到底是"能用 AI 生成代码"还是"能识别 AI 幻觉",立刻见分晓。

面试题 B:AI 边界识别题

给候选人一个业务需求,里面藏着 2 处 AI 一定会写错的地方(比如涉及公司内部业务规则、涉及正则匹配特殊字符、涉及浮点数精度)。观察候选人是直接扔给 AI 生成然后交卷,还是先识别出 AI 边界、再决定哪部分手写哪部分让 AI 辅助。

面试题 C:PR review 题

给候选人一个 500 行的 PR(混合了 AI 生成和人写的代码),让他假装是评审员,30 分钟出具评审意见。看他能不能识别出:哪些是 AI 生成的、哪些逻辑值得警觉、哪些注释是 AI 编的糊弄事、哪些错误处理不到位。

这三道题跑下来,能筛出真正在 AI 时代能用的初级研发。不能过这三关的,就是拿 Copilot 当键盘用的"AI 代抄员",不值得开高薪。

第五:好团队 +30%,差团队负增长——你把初级研发放进哪个坑,直接决定他 3 年后是什么价

Google DORA 2025 报告的结论:AI 不是修理工,是放大器。它把好团队变成更好,把差团队变成更差。

七项能力,决定了 AI 到底帮你还是坑你:

清晰的 AI 使用立场(公司层面是否鼓励、怎么鼓励、鼓励到什么程度)
健康的数据生态(内部知识库/文档是否 AI 可读)
强版本控制习惯
小批次工作(每个 PR < 200 行)
用户中心的产品观
高质量的内部平台(CI/CD 是否够快)
快速反馈的测试基础设施

七项全占的团队,AI 让他们的效能涨 25-30%。

七项不占的团队,AI 让他们的效能负增长。

现在把这个结论叠到"初级研发定岗定薪"上——

同样一个初级研发,进 A 团队(七项全占),3 年后是 P5-P6 的实力;进 B 团队(七项都缺),3 年后可能连 P3 都保不住。

这意味着 HR 一号位在做初级研发的入职分配、team lead 匹配、季度回顾时,必须新增一个动作:

每个初级研发入职时,评估他被分到的团队,在 DORA 七项能力里得几分。

如果是 5 分以上的团队,可以正常给薪、正常晋升考核。

如果是 3 分以下的团队,要么优先补齐团队短板、要么把初级研发挪走——不能让一个新人在负增长团队里被稀释掉三年。

我知道这一步很难。但 AI 时代, "公平"不再是"同岗同薪",而是"同岗同环境,同环境同薪" 。你把初级研发扔进烂团队又按标准薪给他发钱,三年后你既失去了这个人,也失去了他这三年本该产生的价值。

HR 一号位的 5 步落地清单

到这里,5 根钉子扎完了。给你一份可以周一就动手的 5 步落地清单。

第 1 步:重写初级研发 JD

删除关键词:

"熟练使用 Python/Java/Go"(84% 都在用 AI,这不是差异)
"有独立完成模块经验"(能跑不等于能上线)
"熟悉主流开发框架"(Claude 都熟悉)

新增关键词:

"能识别 AI 生成代码中的隐蔽错误(如边界条件、异常处理、并发问题)"
"能对 AI 生成的代码做安全和性能优化"
"能撰写 AI 无法产出的、涉及内部业务规则的代码"
"能作为评审员,识别 AI 输出并提出改进意见"

第 2 步:重建初级研发岗级坐标

旧坐标(单维):工作年限 × 学历。

新坐标(双维):

横轴:AI 辅助下的 PR 一次通过率(30%、50%、70%、85%、95% 五档)
纵轴:所处理任务的复杂度(简单 CRUD、跨模块联调、系统级设计、架构级决策四档)

一个入职 1 年、PR 一次通过率 70%、能做跨模块联调的应届生,岗级应当高于一个入职 3 年、PR 一次通过率 40%、只能做简单 CRUD 的老员工。这个逻辑,在 AI 时代之前是禁忌;在 AI 时代之后是常识。

第 3 步:重构初级研发面试题库

按前面第四里的三题模板,重写你的面试题:AI 屎山重构题、AI 边界识别题、PR review 题。

原有的"手撸算法+框架考察"可以留一道垫底,但不作为主考项。

第 4 步:重设初级研发绩效锚

季度绩效四块权重:

PR 一次通过率(30%)
引入 bug 数/千行代码(25%)
评审响应时长贡献(20%)
AI 代码识别与修复能力(25%)

注意:这四项都可以从工程效能平台(如内部 GitLab/GitHub、SonarQube、LinearB)直接拉数据,不需要靠 team lead 主观打分——这也是治"人情分"的一味药。

第 5 步:建立初级研发的"团队环境评估"机制

每个初级研发入职时,由 HR 联合工程总监,对其分配团队做 DORA 七项能力评分。评分低于 3 分的团队,不接收初级研发,或先补齐短板再接收。

同时,每个初级研发的季度回顾,除了看个人绩效,必须看他所在团队的 DORA 分数变化——如果团队环境在恶化,这个初级研发就算个人绩效再好,也很难在 3 年后长成 P5。这是 HR 一号位对长期人才结构的保护动作。

HR 一号位的 5 问自查

如果周一开会时间紧,先用这 5 问自查一下你的组织在这场变革里的位置:

你上一次改初级研发 JD,是哪一年? 如果超过 2024 年,现在的 JD 大概率已经过时。
你的面试题库里,还在考手撸算法吗? 如果是,你在筛选的是"和 AI 竞争的初级研发",而不是"和 AI 协作的初级研发"——两批人在市场上是不同价的。
你能不能报出团队里初级研发的 PR 一次通过率? 如果说不出,你的绩效体系还在用工业时代的粗颗粒度。
你的初级研发薪资结构,是不是还在按"学历 × 工作年限"发? 如果是,你正在给"AI 提示词工程师"和"AI 代码审阅员"发同一份钱——市场会替你惩罚这件事。
你的初级研发,分别在几分的团队里? 如果你答不出,你在用 3 年时间做一场"看谁能自愈"的实验。

结语:AI 编程 84% 不是威胁,是一次 HR 一号位重掌定价权的机会

我知道这些数字很扎心。特别是对已经用了 5 年、10 年的"学历×年限×任职资格"体系的 HR 一号位来说,重新钉一遍岗级和薪资,几乎等于把过去的工作推翻一半。

但换个视角看——

AI 编程 84%,意味着"编码"这件事本身的技术溢价正在快速消失。

初级研发不再靠"我会写代码"值钱,而是靠"我能和 AI 一起,把代码变成能上线的产品"值钱。

这个转变,恰恰是 HR 最擅长的领域——能力建模、岗级设计、绩效锚定、薪资分带。

过去 20 年,HR 在研发岗位的定价上一直是跟随者——技术总监说 P5 是这样,HR 就跟着定薪。

现在这个窗口反过来了。技术在剧变,谁能先把能力模型建起来、谁能先把岗级锚点重新钉牢、谁能先让绩效数据落到工程效能平台上——谁就重掌了初级研发的定价权。

不要错过这个窗口。