追踪 AI 裁员整整一年，160 多家公司没一家勾"原因是 AI"

先抛个反直觉的数字。

美国一个州追踪"AI 相关裁员"的头一年，收到 160 多家公司的裁员报备。其中勾选原因是"AI"的，一家都没有。

AI 写代码已经快到让很多人睡不着，但它再快，也没直接换算成"程序员被它裁掉"。这中间断了一截。这篇就想把这一截掰开。

AI 代码写得越来越好，为什么还没把工程师换掉？

因为写代码从来不是软件工程的瓶颈。

写代码和软件工程，常被当成一回事，其实差得远。

写代码，是把已经想清楚的逻辑敲进电脑。这一步 AI 确实快，甚至比多数人手快。

但工程师每天真正耗时间的地方，是开不完的会、查不完的 bug。AI 能帮你查 bug、帮你过一遍会议纪要，可它替不了会和调试背后那个东西：判断。这个 bug 到底是症状还是病根？这个需求方拍脑袋提的，要不要做？

代码敲得再快，这些判断没人替你做。AI 加速的，是整条链路里最末端的那一步。

我把它拆成三层，这三层正好是 AI 现在都接不住的：

第一层，把模糊需求翻译成确定规格。 需求方说"用户希望更快"，到底是首屏更快、还是搜索更快、快到多少毫秒算达标？决定到底要造什么，这是工程师的活，也是最难的活。

第二层，对交付负责，验证方案真的解决了问题。 代码跑通不等于问题解决。它在真实流量下扛得住吗？边界情况漏了没？出了线上事故，半夜爬起来的是你，不是模型。

第三层，深懂代码库、业务上下文和线上环境。 为什么这段十年前的逻辑动不得、哪个下游服务一碰就崩、这个数据为什么历史上要这么存——这些散在系统褶皱和同事脑子里的东西，AI 没有。

会和调试之所以耗时，正是因为它们是这三层判断的载体。能自动化的从来不是判断本身，是判断之后的执行。

软件工程三层模型

它把每个人原有的水平，放大了。

对一个已经懂得很深的工程师，AI 是放大器——他知道要造什么、知道方案对不对、知道系统的雷在哪，AI 帮他把这些想法飞快落地。

对一个懂得浅的人，被放大的就是平庸：方向错的代码写得更多更快，错得更利索。AI 不会替你决定写什么，它只会照着你的判断使劲。

所以慌不慌，不取决于"它代码写得有多好"。

别盯着 AI 的代码能力看，盯着自己。

问三个问题：模糊需求来了，我能不能翻译成确定的规格？方案交付了，我敢不敢为它在线上的表现负责？这套系统和业务，除了代码，我懂得有多深？

这三层里，你占住的越多，越难被替。一行代码都不占、只会把需求原样转成代码的人，最先被这台放大器照出原形。

AI 接管了"把代码敲进电脑"这层，往上每一层，要的都是更稀缺的东西。它替不了那个决定写什么代码的人——前提是，你真的是那个人。