夜雨聆风⬆️关注Twinkle公众号进AI专属讨论组⬆️
当代码行数、PR 数量和 Token 开始变成新尺子，打工人的下一轮内卷已经到了。
AI 本来该让人更轻松，但很多公司做的第一件事，却是把“提效”翻译成“你应该更快、更多、还可以更少”。
如果说过去两年，AI 编程还是“会不会用”的问题，那么到了现在，很多公司已经默认进入下一个阶段：既然 AI 能提速，那人是不是也该少一点？
这才是这轮 AI 真正让打工人发冷的地方。大家嘴上聊的是效率，真正落到一线身上的，却是更快的周期、更高的预期、更隐形的考核，以及一种说不出口的焦虑：当所有人都在被量化，下一个被算掉的人，会不会就是自己？
原文里几位程序员的感受其实很一致。AI 来了之后，他们并没有更轻松，反而更忙了。原因并不复杂：老板看见了“写代码更快”，于是很多原本还能按正常节奏推进的事，突然都被要求更快给结果。于是，提效没有换来下班，反而换来了新一轮集体提速。
更微妙的是，很多公司虽然没有把这些东西明明白白写进绩效，但新的“隐形信号”已经出现了。谁写了多少代码、谁的 PR 数量更高、谁更会用 AI、谁消耗的 Token 更多，这些原本不该直接代表价值的数字，正在变成某种被默默围观的排行榜。久而久之，大家比的就不再是谁真的解决了问题，而是谁看起来更像一个被 AI 放大的高产机器。
这也是为什么，越来越多人开始对“AI 提效”这四个字产生复杂情绪。因为真正的问题，从来不是工具本身，而是工具被管理层拿去重新定义人的边界。
配图 1｜效率工具一旦进入排行榜语境，就很容易从“助手”变成“压力放大器”
从企业视角看，这种兴奋又完全可以理解。小团队最先感受到这种冲击。过去需要一个小组做完的功能，现在也许几个熟练的人带着模型就能快速跑通。Design to Code、对话式生成、Agent 自动补全流程，这些展示一旦做得足够惊艳，就特别容易让负责人产生一种错觉：既然演示这么快，那实际生产也应该一样快。
互联网公司当然最吃这一套。原文里提到，腾讯曾披露九成员工使用编程助手，编码时间缩短 40%，整体效率提升 20%；快手则把核心指标直接盯在需求交付周期上，一些 AI 深度介入的团队，交付周期下降更明显；昆仑万维也公开谈过 AI 使用后的大幅提速。站在管理层角度，这些数字足够让人兴奋，因为它们意味着一件非常诱人的事：同样的时间，也许能做更多的项目。
但问题恰恰出在这里。AI 确实能让“写代码”这件事更快，可软件研发从来不是只有写代码。需求要对齐，方案要评审，测试要覆盖，联调要排队，上线要兜底，线上问题还要有人扛。很多企业看到的是编码段提速，却忽略了全链路并没有同步变快。于是组织最容易犯的错，就是把局部提速，误当成整体提效。
这也是原文最有价值的提醒之一：AI 让人快起来了，但真正的效率，常常断在中间。开发者被压缩掉的那部分时间，并没有真的从流程里消失，而是转移成了新的补位成本，最终还是由人自己把它补回来。白天靠 AI 快速产出，晚上再去对齐、返工、验收、兜错，这才是很多一线人真正经历的现实。
更危险的是，短期的“快”有时候是借来的。AI 生成的代码，也许能让功能先跑起来，但它未必符合现有架构，未必遵守团队长期积累下来的工程规范，更可能把不该重复的东西再写一遍。眼下看起来像提效，后面却可能变成技术债、维护税和更复杂的后续返工。也就是说，今天省下来的时间，未必不是明天放大的代价。
所以，真正最容易把 AI 提效直接换算成裁员依据的，往往不是那些大型、复杂、强合规的系统，而是结构更轻、链条更短、生命周期也更短的小团队和小项目。因为这类场景最容易跑出“一个人顶几个人”的观感，却来不及在短期内暴露技术债、维护难度和系统复杂性的后果。老板只会记住一句话：人少了，活好像也没停。
但在银行核心系统、工业软件、复杂金融系统这类场景里，事情完全不是一个逻辑。原文提到，像复杂账务、一致性控制、7×24 小时运行机制这类关键能力，靠的依然是长期经验、责任链条和对稳定性的敬畏。AI 可以在测试用例、文档补全、简单代码生成这些单点环节上显著提速，却很难在高复杂度、高责任成本的系统里，直接替代掉真正扛责任的人。
换句话说，AI 省出来的人效，最合理的用法本来应该是承接更多项目、覆盖更多场景、把工程师从重复劳动里解放出来；而不是简单粗暴地把“效率提升”翻译成“人可以更少”。两者之间，看起来只差一句话，背后却是完全不同的组织观。
一句话看透这轮焦虑： AI 提高的是局部产出速度，但很多公司提高的，却是对人的整体期待值。 |
配图 2｜最该警惕的不是 AI 写得快，而是组织开始只相信那些最容易被统计的数字
也正因为这个矛盾越来越尖锐，另一个问题被重新摆到了台面上：到了 AI 时代，我们到底该怎么衡量一个开发者的价值？
这几年行业一直在反复争论这个问题。原文里提到，从 DORA 到 SPACE，再到后来的 DevEx、DX Core 4，软件行业其实一直在寻找更接近真实价值的度量方式。因为一个工程师到底有没有价值，从来都不是看他一天写了多少行代码，而是看他有没有把业务价值更稳定、更高质量地交付出去。
但 AI 一来，最老土、也最危险的那把尺子，反而重新流行了：代码行数。再加上 Token 消耗、PR 数量、AI 调用次数，这些最容易统计、最容易做榜单、也最容易制造“谁更努力”幻觉的数据，正在重新占领很多管理视角。问题是，这些数字越好量化，往往离真实价值越远。因为低质量的堆砌同样可以冲高代码量，低价值的调用同样可以烧掉海量 Token，而真正困难的判断、架构思考、质量把关和责任承担，恰恰最难被数字直接捕捉。
所以更可怕的不是排行榜本身，而是排行榜背后的组织冲动：当管理只迷恋那些最显眼的数据，就会越来越看不见那些真正构成复杂系统价值的东西。工程师不再被鼓励“把事情做对”，而是被诱导去“把数字做高”。一旦这种文化形成，AI 就不再是提升生产力的工具，而会变成放大浮躁、放大短视、放大内卷的加速器。
原文最后那句话其实特别值得记住：人的价值，恰恰藏在那些算不出 Token 的地方。真正稀缺的，从来不是几秒钟吐出几百行代码的能力，而是在复杂问题面前，愿意花几小时把架构看透、把风险想透、把责任扛住的能力。AI 越往前走，这种“看起来更慢”的能力，反而越像奢侈品。
所以，这篇文章真正该刺痛的，不是程序员会不会被 AI 取代，而是每一个团队都该想清楚：我们到底是想用 AI 解放人，还是想用 AI 把人逼成更便宜的机器？如果答案是后者，那被淘汰的也许不只是某些岗位，而是整个组织对长期价值的判断力。
AI 当然还会继续进步，排行榜也不会消失，关于提效的神话甚至会越来越多。但真正决定一家公司会不会在这波浪潮里跑偏的，不是它买了多少模型、烧了多少 Token，而是它有没有能力分清：哪些速度是价值，哪些速度只是幻觉。
结尾观点： 真正高级的组织，不是用 AI 去证明“人还能再压一压”，而是用 AI 把人的判断力、创造力和责任感，从低价值重复劳动里解放出来。
