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

　　AI 替岗，不能直接降薪

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

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

　　月薪从 25000 元降到 15000 元。

　　他不同意，公司直接解除劳动合同。

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

　　这事一下就有意思了。

　　因为过去大家聊 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. 如何设计一个秒杀功能？