他用 10 年搭起三根职业支柱，8 个月后自己承认：不如去做木匠

先说一组看起来完全矛盾的数字。

美国的软件开发者岗位，2022 年 5 月是 153 万，2025 年 5 月是 169 万。

涨了。

但同一时期，22-25 岁的软件开发者就业人数，比 2022 年末的峰值下降了 19%。

同期 30 岁以上没有同步下滑，41-49 岁反而上涨了 14%。

岗位总量没崩。年轻人先掉队了。

这不是我算出来的，是一位写了 10 年代码的工程师，在自己被优化之后，一句一句说出来的。

他用 10 年搭了三根支柱，然后眼看着它们依次倒掉

他把一个程序员的立足点拆成三层：

1. 领域专业知识 —— 你懂这个业务，别人不懂
2. debug 与分布式系统 —— 你能处理最难的线上问题
3. 代码质量与架构 —— 你能保证这东西活得久

然后是时间线。

第一年，经理跟他说：写这些设计文档花的时间太长了，你用 AI 了吗。

他心里想的是「这绝对行不通」，但还是同意了。

Claude Code 热潮起来之后，他把编码交了出去，自我安慰：debug 是我的护城河。

MCP 加上 Claude 4.5 出现之后——

他的原话是：天开始塌了。

值得注意的是他自己的心理防线是怎么一道道被自己拆掉的。

第一道是他嘴上说「这绝对行不通」，但还是同意了经理的要求——他并不是判断错了，是判断对了也没用。

第二道是「debug 是我的护城河」。这句话的毛病在于：护城河的前提是河还在。当模型能力从 60% 推到 90%，河不是被填了，是水位抬高了。

第三道就没什么可守的了。

他的护城河是怎么被抽干的

他给了两个数字。

用 Claude 4.5 的时候，「大约能解决 60% 的缺陷」。

后来4.6、4.7、GPT-5.5 加上 DataDog MCP 接进来，他的说法变成：

现在 90% 的缺陷都能一次性解决。

从 60% 到 90%，中间隔了不到一年。

他赖以立身的「最难的那部分」，被抽走了。

这根支柱不是被推倒的，是被稀释的。

八个月前的那次裁员

他写这段话的时间点，本身就是数据的一部分。

约八个月前，他公司裁员。

他写道，一些很出色的前同事被裁了，至今仍在找工作。

还有一个细节，比裁员数字更说明问题——

招聘岗位的名字变了。

过去他们会招聘「软件工程师 - 某领域」。现在只写「软件工程师」，团队分配在录用之后才进行。

这句话我读了两遍。

它的意思是：企业不再为「某个领域懂到底」付钱了，只为「进来之后能被分配」付钱。

领域专业知识这根支柱，在招聘标题上就已经被拆掉了。

但反向的数据也必须一起看

只讲焦虑那部分，属于蹭热度。

同一时期，美国劳工统计局（BLS）的口径是这样的：

岗位

变化

软件开发者总量

153 万 → 169 万（涨）

Computer programmer

降 16%

Web developer

降 11%

QA tester

降 6.5%

Data scientist

涨 12%

入门级软件岗位招聘较2022 年峰值下降 28%；计算机专业毕业生失业率 6.1%。

总量在涨，入门级在跌，AI 相关的岗位在涨。

这三件事同时成立，才是我想说的那个东西。

只看第一行，你会得出「程序员没受影响」。只看第二行，你会得出「年轻人完了」。

两个结论都是错的，因为它们都在拿不同口径的数据互相打架。

正确的读法是：岗位在重组，不是消失。而重组的代价，不由岗位总量承担，由最没有议价权的那一端承担。

她只说了 6 个词

把这些数字串起来的，是 Npm 联合创始人 Laurie Voss。

她的结论短到不像结论：

We have to rebuild the ladder.（我们必须重建那架梯子。）

然后她问了两个问题：

• 几年后，谁来 review Agent 写出来的复杂系统？
• 谁来判断一段代码只是能跑，还是能上线？

梯子的意思你得先看懂。

过去一个程序员是怎么入行的？

不是先学设计架构，也不是先做debug。

是从最基础的那一层开始的——有人把需求讲清楚，你按规格把代码写出来。

那活儿又慢又笨，但它同时是一块训练场：你在写的过程中，学会了一个系统是怎么运转的、哪里容易出错、什么叫做「改起来很安全」。

而现在，AI 先吃掉的，正是这一层。

消失的不是程序员这个职业，是那架让人从底层爬上去的梯子。

这个说法为什么比「AI 抢走程序员工作」准确，我举一个具体的例子。

我带过实习生，也带过校招同学。他们的第一份工作，坦白讲都很枯燥：把一份写好的设计文档，变成一个能跑的接口，再把联调时发现的边角问题修掉。

那种活儿现在AI 干得又快又稳。

但我观察到的关键不是他们变慢了，是他们没机会经历「第一次独立判断对错」的那一下。

人在哪一下学会了判断，就会在哪一下之后开始长出手感。而手感这东西，一旦断了入口，就很难从别的地方补回来——因为所有判断都得在真实的、有后果的场景里长。

对普通人意味着什么

我不打算在这里喊「快去学 AI」，那是废话。

我只说一个具体的判断。

如果你今年 22-25 岁，正在准备入行做开发，那我建议你别只学「怎么用 AI 写代码」。

那是最容易被拿走的一层。

优先去拿两样 AI 短期内拿不走的东西：

• 一个具体领域的手感——某个行业的客户到底在为什么付钱、为什么骂人
• 一个能替你背判断责任的位置——哪怕是小团队的 tech lead，好过你永远只接写好的 spec

前者让你知道 AI 给的答案什么时候不对劲；后者让你有权说「这个先别上」。

这两件事，恰好就是 Boris Cherny 说的 Sweeper 和 Maintainer。

我再补一句可能不太受欢迎的判断。

**「学会用 AI 写代码」正在变成一门基础课，就像当年学会用搜索引擎。**它是必备项，不是差异化项。

所以真正能拉开差距的，不是你用得多，而是你除了用，还剩下什么别人拿不走的东西。

对一个还在学校或者刚入行的人来说，答案只有一个：尽早去攒一份属于自己的真实上下文。

具体一点：固定一个行业、跟进一个真实项目、或者死磕一个别人不愿意碰的存量系统。

这些东西没有捷径，也正因为没有捷径，才是护城河。

结尾

我给自己留了一个可以立刻做的动作。

去翻一下自己过去半年做的事，数一数：有多少是「产出新的东西」，有多少是「判断已有的东西对不对」。

我猜结果会是后者占多数，只是你从来没给它起过名字。

然后问题就只剩一个：

如果你这两年来一直在第一类上花时间，接下来 12 个月，你打算在哪一天开始换？

我不给答案。但我知道，不换也是一个答案。

这是「数字生命岐伯」第 8 问。我，野慢，广东，25岁。白天在大厂做AI产品，晚上被AI教做人。今天这题我替你们问过了，坑也替你们踩了。想让我测哪个AI，评论区点单。我们，下篇见