AI 明明让程序员提效了，为什么大家反而加班更狠了？问题可能不在工具，而在老板量生产力的尺子歪了

AI 编程工具这两年最吊诡的一幕，不是它没提效，而是它明明提效了，很多程序员却并没有因此更轻松。

按理说，代码写得更快、文档补得更快、测试生成更快，正常结论应该是节奏变松一点，或者同样的人能做更多更有价值的事。

但现实恰恰相反。很多一线开发者感受到的不是下班更早，而是交付更赶、对标更狠、指标更怪，甚至连“你到底用了多少 AI”“你烧了多少 token”“你一天产出了多少行代码”这种东西，都开始若有若无地进入评价体系。

这说明问题可能根本不在 AI 本身，而在组织开始拿一把本来就不太准的尺子，去量一个已经被 AI 改写过的工作世界。

AI 提效是真的，但“整体更高效”经常是错觉

InfoQ 这篇采访里有个很关键的点，就是很多企业和一线开发者都同时承认了一件事：

AI 确实让编码这件事更快了。

腾讯说九成员工用了编程助手，编码时间缩短 40%，整体提升 20%；快手披露不同阶段团队的提效区间，深度进入交付链路后，某些标杆团队需求交付周期下降 58%；金融和银行软件场景里，测试用例、文档补全这些局部环节提速也已经很明显。

这些都不是幻觉。

但问题在于，编码只是软件研发里的一段，不是全部。

需求对齐、评审、联调、测试、发布、回滚、线上问题处理、跨团队沟通，这些东西并不会因为 AI 会写代码就自动变快。结果就是，局部环节提速了，但整体节奏未必真跟着顺下来。

于是最常见的结果反而是：

老板看到“你这段明明快了”，就把交付预期往上提； 而那些没被同步优化的环节，则继续卡在那里； 最后被压缩掉的那部分时间，就重新转嫁给了人自己去补。

这就是很多开发者体感越来越累的根源。

真正危险的，不是 AI 提效，而是把局部提效误读成“人可以少一点”

我觉得这篇最扎心的一点，是它把一个大家都隐约感觉到、但很少被摊开讲的逻辑说透了：

一旦某些活明显变快了，组织很容易往一个更残酷的方向滑。

也就是：既然 AI 已经让这部分工作更便宜、更快、更容易量化，那是不是人可以少一点？

这种逻辑在小团队、小应用、短生命周期项目里尤其容易成立。因为这些场景本来协作链条就短，系统复杂度也没那么高，技术债和长期维护成本还没来得及爆发，老板最先看到的自然就是“一个人现在能顶过去一小队人”。

问题是，这种经验一旦被神化，就很容易错误外推到所有研发团队。

而大型复杂系统根本不是这么回事。银行核心系统、工业软件、大型企业软件、历史包袱重的复杂业务平台，真正难的从来不是把代码敲出来，而是让系统长期可维护、可演进、可背责。

AI 可以让一些单点工作更快，但不等于它已经能替代那些沉在架构、经验、质量责任里的复杂劳动。

把“局部提效”直接翻译成“人可以少”，本质上是一种非常危险的误判。

旧时代就不太靠谱的指标，到了 AI 时代只会更歪

如果说组织对 AI 的使用开始走偏，最典型的信号是什么？

我觉得就是那些本来就很粗暴的指标，在 AI 时代又被重新捡起来，而且还变本加厉。

比如代码行数。

这玩意儿本来就不是什么靠谱指标，软件行业这么多年几乎都知道它噪音极大。高价值改动不一定行数多，行数多也不代表产出真有价值。

可 AI 一进来，这种指标反而更容易回潮。原因很简单，它最容易量化，最容易排名，也最容易制造一种“看起来大家都能被统一衡量”的幻觉。

但问题也更严重了，因为 AI 本来就容易让代码写得更膨胀、更冗长、更像是“能跑就行”的大块输出。

所以你如果继续拿代码行数、PR 数量、token 消耗这些东西去量人，结果就很容易跑偏：

• 比的不是谁更有工程价值，而是谁更会刷显性产出
• 看见的不是更好的系统，而是更容易被数字化展示的工作痕迹
• 放大的不是优秀工程师的判断力，而是组织的短视冲动

说得更直接点，AI 时代最怕的不是没有指标，而是旧尺子还在，刻度已经变了。

真正该量的，应该是交付质量、协同质量和认知负担

InfoQ 这篇里我特别认同的一点，是 DORA、SPACE 这类老框架并没有过时，真正要变的是你怎么解释它们。

到了 AI 时代，生产力不该只是“写得更快”，而应该看更完整的东西：

• 需求交付周期有没有在不牺牲质量的前提下缩短
• 上线后的故障率有没有上升
• 恢复时间有没有变短
• 开发者的认知负担有没有下降
• 团队协作是不是更顺，而不是更乱
• AI 生成内容被采纳和被驳回的比例到底怎样
• 代码进生产后，维护税和技术债有没有被提前透支

也就是说，AI 时代的生产力，不该只量产出速度，还得量代价结构。

如果你只是更快地产出了一堆以后更难维护的东西，那不是提效，那只是把账往后挪。

AI 时代的研发组织，正在从“衡量人”变成“衡量人和 Agent 的组合”

这也是一个特别大的变化。

过去我们量的是人。一个工程师一天写了多少、交了什么、上线什么。

现在越来越真实的情况是，最小生产单元已经不是“人”，而是“人 + AI + 工具链 + 上下文”。

这意味着，单独去看某个人到底敲了多少代码，其实已经越来越失真。

更合理的做法，应该是看这个组合单位创造了多少有效交付，又消耗了多少真实成本。

这里的成本不只是工资，还包括 token、算力、上下文成本、校验成本、返工成本和风险成本。

说白了，AI 让一些环节变快之后，组织真正该学会的，不是怎么催人更快，而是怎么重新给“有效生产力”定价。

一个更直接的判断

AI 提效没有错，错的是很多组织在看到提效之后，第一反应不是重构流程、释放人力做更有价值的事，而是直接把那部分速度差拿去压指标、压周期、压人数。

这就是为什么我们今天会看到一种很怪的局面：

工具更强了，开发者却不一定更轻松； 代码写得更快了，整体交付未必更健康； 指标更多了，组织却未必更懂生产力。

如果这把尺子不改，AI 时代的软件工程很可能会变成这样：

局部越来越快，整体越来越累； 表面越来越高效，系统越来越脆； 数字越来越漂亮，人却越来越像被数字驱赶。

真正成熟的组织，应该把 AI 省出来的人效拿去承接更多价值、更复杂项目、更高质量交付，而不是简单换算成更狠的对标和更紧的考核。

因为人真正值钱的地方，往往恰恰在那些最不容易被 token、代码行数和排行榜算出来的地方。

顺手说一句，如果后面真要把 AI 编程、日志、评估指标、任务编排和交付系统一起跑起来，底层环境也得稳住。像雨云这种偏实干型的云服务，拿来挂对象存储、自动化任务、日志链路和轻量工作流，其实挺合适。很多团队以为自己缺的是更强的 AI，实际上缺的是一套不把人逼进错误指标里的工程环境。