Leader:“岗位被 AI 替代,降薪 1 万你接受吗?” 我:“不接受。” Leader:“恭喜你,那公司赔你 2N。”

0 阅读7分钟

AI 替岗,不能直接降薪

今天鸭鸭刷到一个特别适合打工人看的 AI 新闻:

杭州有个 35 岁员工,被公司以“岗位被 AI 取代”为由调岗降薪。

月薪从 25000 元降到 15000 元。

他不同意。

公司直接解除劳动合同。

最后法院判了:公司违法解除,按 2N 支付赔偿金,金额大概 26 万。

image-20260430120007803

这事一下就有意思了。

因为过去大家聊 AI 替代,很多时候都是嘴上焦虑。

“AI 会不会抢我饭碗?”

“程序员是不是要完了?”

“35 岁以后是不是更危险?”

但这次不是抽象讨论了。

它变成了一个很具体的问题:

公司能不能说一句“AI 替代你了”,然后让你降薪 1 万?

法院的答案挺明确。

不能这么简单。

先说下案子里的关键事实。

公开报道里提到,这位员工从事的是 AI 大模型问答质检相关工作,月薪 25000 元。后来公司说项目受到 AI 技术冲击,原来需要人工完成的质检工作,现在 AI 自己就能做,于是提出调岗降薪,月薪降到 15000 元。

员工不同意。

公司就解除劳动合同。

法院认为,企业主动引入 AI 技术属于技术革新,但不必然等同于劳动合同无法履行的“客观情况重大变化”。而且公司给的新岗位待遇大幅下降,也不能算合理协商方案。

所以公司输了。

AI 这下是直接伸手摸到你的工资卡了。

如果公司明天跟你说,AI 上线了,你这个岗位价值下降,月薪先砍 1 万,你认不认?

很多人第一反应可能是:不认啊。

但不认之后呢?

这才是重点。

过去公司想降本,常见说法是组织调整、业务收缩、绩效不达标、岗位取消。

以后可能会多一个特别顺手的新话术:

“不是公司针对你,是 AI 真的能做你的活。”

这句话听起来很先进。

但鸭鸭想说一句不太客气的话:

AI 可以改变岗位价值,但不能变成公司单方降薪裁人的万能理由。

公司当然可以升级技术。

公司当然也可以调整岗位。

但中间有个问题不能跳过去:员工原来的劳动合同还在,工资约定还在,协商程序还在。

你不能技术一升级,就默认员工必须自己吞掉所有成本。

这就像以前公司上了自动化流水线,不能因此直接跟工人说:

“机器能干一半活了,所以你工资也砍一半。”

AI 只是把这个问题换了一件新衣服。

底层逻辑没变。

技术进步带来的收益,不能全部归公司;技术调整带来的代价,也不能全部甩给员工。

……

那对程序员和技术岗来说,这件事意味着什么?

鸭鸭觉得有三点。

第一,别再只讨论“AI 会不会替代我”。

这个问题太大,也太虚。

更现实的问题是:AI 进入公司以后,你的岗位描述会不会被改,你的绩效指标会不会被改,你的薪资谈判筹码会不会被改。

真正影响你的,可能不是 AI 明天把你开掉。

而是公司先用 AI 重估你的岗位价值。

第二,遇到“AI 替岗式调岗降薪”,不要只靠情绪硬刚。

要留证据。

比如原岗位职责、劳动合同、薪资结构、调岗通知、降薪幅度、沟通记录、公司是否给过合理替代岗位、是否做过培训安排。

这类事情最后看的不是谁嗓门大,而是谁的证据链更完整。

第三,技术人确实要重新想自己的“不可替代部分”。

这不是鸡汤。

如果你的工作只是按标准答案做低价值重复检查,那确实会被 AI 压价。

但如果你能设计质检规则、定义评估指标、处理异常样本、搭建审核系统、判断模型风险,那你就从“被 AI 替代的人”,变成“管理 AI 质量的人”。

这两个岗位听起来都叫质检,工资差别可能很大。

所以鸭鸭最后的判断是:

未来最危险的不是不会用 AI 的人,而是工作内容被公司定义成“AI 用完后的残余人工”。

一旦你被放进这个框里,公司就很容易说:这部分活价值下降了,工资也该下降。

真正要做的,是把自己往上挪一层。

从做题的人,变成出题和判卷的人。

从人工执行,变成流程设计。

从“我来检查这条回答有没有问题”,变成“我来设计一套系统,让 AI 回答的问题能被稳定发现、记录和追责”。

这个方向,才更像技术岗后面的价值。

大家怎么看?如果公司明天说你的岗位被 AI 替代,要降薪 1 万,你会怎么处理?

……

今天鸭鸭和大家分享一道后端场景题面试题。

【如果要实现一个抢红包的功能,红包金额是如何计算的? 】

回答重点

抢红包的金额计算核心是公平性总额控制,核心逻辑分两种场景:

1)普通红包(固定金额):这个比较简单,每个红包金额完全相同。比如总金额 100 元,发 10 个红包,每个红包固定10元。逻辑很简单,直接用总金额除以红包数量即可。 2)随机红包:每个红包金额随机,但需满足两个条件:

  • 所有红包金额之和等于总金额
  • 单个红包金额不能为 0,且需保证“先抢和后抢的人有公平的随机概率”(比如不能让前面的人抢走大部分,后面的人只能抢几分钱)。

行业主流用实时计算结合二倍均值法实现随机红包:每次分配时,当前可分配的金额为剩余金额,剩余数量为 n 个红包,则当前红包的金额上限是 (剩余金额/剩余数量)*2,下限是 1 分。这样既保证了随机,又能让后续红包有合理金额。

除了实时计算外,还有预先生成的方案:在发红包时用线段分割法提前分配好所有金额存入队列,抢红包时直接按顺序取即可。

扩展知识

二倍均值法的具体例子

假设总金额 10 元(我们转成 1000 分),发 5 个红包:

  • 第一个红包:剩余1000分,剩余5个 → 上限是(1000/5)*2=400分 → 随机范围1~400分。假设随机到300分,剩余700分,剩4个红包。
  • 第二个红包:剩余700分,剩余4个 → 上限(700/4)*2=350分 → 随机范围1~350分。假设随机到200分,剩余500分,剩3个红包。
  • 以此类推,直到最后一个红包直接拿剩余所有金额(避免前n-1个红包分完后最后一个为0)。

线段分割法(预生成)

把总金额想象成一条长度为 M 的线段(如10元=1000分)

然后随机切 N-1 刀生成分割点(N=人数),最后按分割点位置计算每段长度作为红包金额。

实际开发中的细节

  • 最小单位:金额需用“分”(整数)而不是“元”(浮点数),避免浮点精度误差(比如0.1元用浮点数存储可能有误差)。
  • 并发控制:像群里面的红包实际上并发还好,微信群最多也就 500 人。
  • 红包过期:若红包未被抢完,超时后需退回原账户,此时需记录已抢金额和剩余金额,避免重复退款。

如果面试官追问并发相关的问题,可以参考:4680. 如何设计一个秒杀功能?

篇幅有限,更多 后端场景 相关面试题可以进入面试鸭进行查阅