资讯详情

AI 正在吃掉程序员的职业阶梯：以后初级开发者该怎么成长？

最近我看到一个非常值得讨论的观点。

在 QCon London 2026 上，Alasdair Allan 做了一场题为：

The Ladder Is Missing Rungs: Engineering Progression When AI Ate the Middle

的演讲。

翻译过来大概就是：

职业阶梯正在失去台阶：当 AI 吃掉了中间层。

这场演讲讨论的并不是一个我们已经听烂了的问题：

AI 会不会取代程序员？

而是一个我觉得更加可怕的问题：

如果 AI 把初级程序员原本应该做的工作都做掉了，那么未来的高级程序员从哪里来？

QCon 官方对这场演讲的概括非常直接：

过去工程师成长有一条相对稳定的路径：

Junior↓
Mid-level↓
Senior↓
Staff / Architect

初级任务让你掌握基本功，中级任务培养判断力，高级工程师则开始从整个系统的角度做综合决策。

但 AI 正在同时做两件事情：

一方面：
AI 消灭了每一级职业阶梯原本提供的学习机会另一方面：
AI 又让一个经验不足的人，
能够暂时完成远超自己实际能力的工作

于是一个非常奇怪的时代出现了：

Junior 可以交付 Mid-level 的代码，
却不一定拥有 Mid-level 的能力。

Mid-level 可以让 AI 帮自己设计 Senior 级别的架构，
却没有 Senior 工程师经历过的那些事故和教训。

而 Senior 工程师也开始思考：

当实现代码越来越多地由 AI 完成以后，我到底应该做什么？

这可能会成为未来几年软件行业最大的问题之一。

---

01

AI 最先消灭的，恰恰是培养程序员的工作

很多人讨论 AI 编程的时候喜欢算一个东西：

效率。

以前一个程序员一天写 500 行代码。

现在用了 Claude Code、Codex、Cursor、Copilot，一天可能生成 5000 行。

于是：

开发效率 = 10x

然后公司老板一看：

那还要那么多程序员干什么？

一个高级程序员 + AI，不就可以顶以前一个团队了吗？

从短期商业逻辑来说，好像完全正确。

问题在于：

我们以前到底是怎么培养出一个高级程序员的？

答案其实非常朴素。

就是不停干“脏活累活”。

比如：

写 CRUD
写接口
改 Bug
补单元测试
读日志
排查线上问题
写 SQL
优化慢查询
改别人留下来的祖传代码
处理空指针
处理并发问题
看监控
查内存泄漏
改部署脚本
处理各种奇怪边界条件

这些事情放到今天看，会觉得：

这种东西为什么不用 AI？

确实。

AI 特别擅长。

但问题是：

这些工作虽然低效，却一直是工程师的训练场。

你写过几十个接口以后，才逐渐知道什么叫好的 API 设计。

你踩过事务的问题以后，才真正理解数据库事务。

你经历过几次线上事故以后，才知道为什么有些代码“理论上没问题”，实际上绝对不能上线。

你改过几年祖传代码以后，才开始理解：

为什么有些代码看起来很丑，
却不能随便动。

这就是经验。

而经验的形成，本质上是：

实践
↓
犯错
↓
反馈
↓
修改
↓
再次实践
↓
形成模式识别
↓
形成工程直觉

AI 最大的问题在于，它可能直接跳过了中间这一整段。

变成：

提出需求
↓
AI 生成
↓
代码可以运行
↓
提交

表面效率高了。

但学习过程没了。

---

02

Junior 正在拥有 Mid-level 的产出，却没有 Mid-level 的能力

我觉得 Allan 演讲里最准确的一句话是：

Juniors who ship like mids but can't debug like them.

意思就是：

初级开发者可以像中级开发者一样交付功能，但却没有中级开发者解决问题的能力。

这个现象其实现在已经非常明显了。

假设现在让一个刚工作半年的程序员开发：

用户系统
+
JWT 登录
+
Redis
+
MySQL
+
Docker
+
Nginx
+
CI/CD

五年前，这可能已经算一个完整项目了。

现在直接告诉 AI：

帮我设计一个用户认证系统。技术栈：
Go
Gin
MySQL
Redis
JWT要求：1. 支持登录注册
2. JWT Access Token + Refresh Token
3. Redis 保存 Refresh Token
4. MySQL 保存用户
5. Docker Compose 部署
6. Nginx 反向代理
7. 给出完整目录结构

几十分钟以后，一个能跑的项目就出来了。

所以这个程序员可以说：

“我开发过 Redis + JWT + MySQL 的认证系统。”

这句话 technically 没错。

但是继续问：

JWT 为什么不能直接永久有效？Refresh Token 为什么需要 Redis？Refresh Token 泄露怎么办？多个设备登录怎么处理？Redis 挂了怎么办？Redis 和 MySQL 数据不一致怎么办？Token 如何吊销？JWT 使用 HS256 还是 RS256？为什么微服务环境更适合 RS256？Nginx 什么时候会导致 SSE 断流？连接池应该设置多少？数据库事务隔离级别有什么影响？

他可能一个都解释不清。

这就是一个新的工程师类型：

Output-rich, experience-poor。

产出很多。

经验很少。

---

03

更麻烦的是：AI 对初级开发者的学习能力可能真的有影响

Allan 在演讲中引用了 Anthropic 的一项随机对照实验。

52 名以初级工程师为主的开发者，需要学习一个新的 Python 异步库 Trio。

一组使用 AI。

另一组不使用 AI。

结果非常值得注意：

使用 AI 的人在完成任务速度上并没有获得统计意义上的明显优势。

但随后的知识测试中：

AI 辅助组：约 50%
非 AI 组：约 67%

AI 辅助组低了大约 17 个百分点。

而差距最大的一项能力，恰恰是：

Debug。

也就是调试能力。

于是出现了一个非常有意思的悖论。

Allan 把它叫：

Supervision Paradox

监督悖论。

逻辑是这样的：

AI 越强
↓
程序员越不需要亲自写代码
↓
但是 AI 仍然需要人类监督
↓
监督 AI 又需要很强的工程能力
↓
而这些工程能力
原本恰恰来自亲自写代码和 Debug

最终就变成：

使用 AI 需要工程能力，但过度使用 AI 又可能让你失去获得工程能力的机会。

这是一个非常麻烦的闭环。

---

04

AI 可以帮你 Debug，但可能让你永远学不会 Debug

以前我们遇到一个线上 Bug。

比如：

panic: runtime error:
invalid memory address or nil pointer dereference

第一反应是什么？

看 stack trace。

然后：

grep log
↓
找到请求
↓
定位代码
↓
打印变量
↓
复现
↓
看数据库
↓
看缓存
↓
猜原因
↓
验证

两个小时过去。

终于发现：

user, err := userService.GetUser(id)
if err != nil {return err
}fmt.Println(user.Name)

某种特殊情况下：

user == nil
err == nil

于是炸了。

以后你看到类似代码，脑子里会自动冒出来：

if user == nil

为什么？

不是因为看过《Effective Go》。

而是因为：

你被线上事故教育过。

这种东西叫：

Pattern Recognition。

模式识别。

真正的 Senior 工程师大量能力其实来自这种东西。

一个高级工程师看到：

for _, item := range items {db.Query(...)
}

可能立刻觉得不对。

Junior：

有什么问题？

Senior：

这里可能是 N+1。

为什么 Senior 知道？

因为以前吃过亏。

同样看到：

SELECT *
FROM orders
WHERE DATE(created_at) = '2026-08-17';

Senior 第一反应：

这个索引可能废了。

这些都是长期实践形成的工程直觉。

而现在 Junior 可以直接问：

Claude，这段代码有什么问题？

AI：

这里可能存在 N+1 Query，
建议批量查询……

问题解决了。

但人的大脑并不一定真正建立了那个模式。

这就是区别。

---

05

Senior 工程师真正值钱的，从来就不是打字速度

这也是这场演讲非常重要的一个观点。

Allan 提到：

Writing code was never the point.

写代码从来不是软件工程真正的核心。

这句话我非常赞同。

一个工作十年的程序员和一个工作一年的程序员之间的区别，从来不是：

Senior 每分钟能写 100 个字符Junior 每分钟只能写 60 个字符

甚至很多 Senior 写代码比 Junior 还慢。

真正的区别是：

Senior 知道：

什么东西不应该写。什么需求需要拒绝。什么时候应该重构。什么时候千万不要重构。什么架构看起来漂亮但会把项目搞死。哪些数据必须做幂等。哪些操作必须限流。哪些接口不能同步执行。什么地方未来一定会成为瓶颈。什么时候应该简单一点。什么时候必须提前设计。

这种东西很难通过 Prompt 得到。

因为它不是知识。

而是：

Judgment。

判断力。

---

06

AI 最大的问题不是不会写代码，而是不理解“生产环境”

这里我觉得 Allan 提出的一个观点特别重要。

他说：

AI Agent 可以读取：

代码
测试
文档
README
Git 历史
Issue

但是它无法真正：

read production

读取生产环境。

什么意思？

假设你看到一个代码：

if user.Region == "JP" && user.Version < 103 {useLegacyPayment()
}

AI 看了以后可能觉得：

这是 Legacy Code。建议删除。

因为：

Version < 103

看起来已经很老了。

单元测试也没有覆盖。

Git blame 显示：

2019 年写的。

于是 AI：

// deleted

代码更漂亮了。

覆盖率更高了。

lint 全通过。

CI 全绿。

上线以后：

日本某个渠道突然全部支付失败。

为什么？

因为这段代码虽然：

只影响 0.1% 用户

但每天可能有：

300 万请求 × 0.1%
= 3000 用户

这就是生产环境知识。

而这种知识很多时候根本不存在于：

README.md
CLAUDE.md
代码
注释

它存在于：

某个干了 8 年的老程序员脑子里。

他说：

这个不能删。

你问：

为什么？

他说：

2019 年删过一次，炸过。

这句话值多少钱？

可能值几百万。

---

07

AI 正在吃掉的其实不是代码，而是 Institutional Memory

这也是未来企业会遇到的大问题。

我们经常讲：

Context Engineering。

给 Agent：

CLAUDE.mdAGENTS.mdArchitecture Decision RecordsCoding GuidelinesAPI Documentation

这些东西确实越来越重要。

Allan甚至提出：

我们可能正在进入一个 Documentation-first Programming 的时代。

也就是：

文档优先编程

以前流程：

人理解系统
↓
人写代码
↓
顺便写文档

未来可能是：

人整理系统知识
↓
形成 Context
↓
AI 读取 Context
↓
AI 写代码
↓
人审核

于是文档从：

附属品

变成：

基础设施

这其实也是为什么现在：

CLAUDE.md
AGENTS.md
Rules
Skills
Memory
MCP
Context Engineering

突然变得非常重要。

因为我们正在尝试做一件事情：

把 Senior 工程师脑子里的东西结构化出来。

---

08

更现实的问题来了：公司正在减少 Junior 招聘

如果问题只是 Junior 学得慢，其实还不算最严重。

真正严重的是：

Junior 的岗位本身正在减少。

Allan 在演讲中引用的研究数据显示，在 AI 暴露程度较高的职业中，22～25 岁年轻人的新就业率，相比 ChatGPT 出现前的水平出现下降。

他引用的 Anthropic 劳动力市场分析估算，这一群体进入高 AI 暴露职业的 job-finding rate 下降约 14%；对于 25 岁以上劳动者，并没有看到同样的下降模式。不过研究也明确提醒，这一结果存在统计与因果解释上的限制。

这个现象特别值得关注。

因为 AI 对就业市场的第一阶段冲击可能不是：

公司：裁掉 50% Senior

而是：

去年：10 Senior
10 Mid
10 Junior今年：10 Senior
8 Mid
3 Junior

Senior 暂时不会被裁。

因为 Senior 需要：

Review
Architecture
Debug
Production
Decision Making
AI Supervision

真正先消失的是：

简单 Bug
CRUD
基础测试
脚手架
文档
简单前端页面
简单 API

也就是：

Junior Job。

---

09

然后十年以后会发生什么？

假设这个趋势一直持续。

2026：

Senior 很多
Junior 很少

2030：

Senior 仍然很多
Mid 开始减少

2035：

老 Senior 开始退休但是……新的 Senior 呢？

这就是 Allan 整场演讲最核心的问题：

Where does the next generation of engineers come from?

下一代工程师从哪里来？

以前是：

100 Junior
↓
50 Mid
↓
20 Senior
↓
5 Staff

以后可能：

20 Junior
↓
？
↓
？
↓
？

职业阶梯的入口断了。

---

10

这件事情其实很像医生培养

Allan 举了一个我非常喜欢的例子：

医学住院医师。

为什么医学训练还要求年轻医生做大量基础工作？

有些工作明明：

机器可以做
高级医生可以做
护士可以做

为什么还是让住院医师做？

因为：

做这些事情的目的不只是完成任务，而是在培养医生。

软件工程以前其实也是这样。

Junior 改 Bug。

公司的目的当然是：

Bug 修掉。

但还有一个隐藏产出：

Junior + Debug
↓
几年以后
↓
Senior

以前企业没有意识到这个隐藏产出。

因为它天然存在。

现在 AI 把第一个产出优化掉：

AI 修 Bug

企业非常开心。

但是第二个产出也一起没有了：

Junior 没 Debug
↓
没有经验积累
↓
Senior 断层

所以 Allan 的建议之一非常反直觉：

有些工作，即使 AI 做得更快，也应该故意让 Junior 自己完成。

因为目的不是效率。

而是训练。

---

11

未来企业可能需要重新设计“程序员培养体系”

过去企业的培养体系基本上是：

招 Junior
↓
给任务
↓
工作几年
↓
自然变成 Senior

未来很可能不够了。

必须变成：

招 Junior
↓
设计训练任务
↓
限制 AI 使用
↓
要求独立 Debug
↓
参与 Code Review
↓
参与 Production Incident
↓
学习 Architecture
↓
再允许大规模 AI Delegation

也就是：

Deliberate Practice

刻意练习。

比如以后可能出现：

AI-Free Debugging Day

或者：

Junior 必须先自己分析 30 分钟
才能询问 AI。

甚至 Code Review 不再只是问：

代码能不能运行？

而是问：

为什么这么设计？如果 Redis 挂了会怎么样？这个 SQL 为什么需要索引？这里为什么需要事务？如果请求重复发送会怎么样？这个服务如何水平扩展？这里最大的风险是什么？

评价指标从：

Output

变成：

Understanding

---

12

对程序员来说，以后最危险的不是“不会 AI”

而是：

只会 AI。

现在网上有一种非常危险的观点：

以后不需要学习编程基础了。直接学 Prompt 就好了。

我觉得可能恰恰相反。

AI 越强：

基础能力可能越重要。

因为以后写代码越来越便宜。

真正昂贵的是：

判断代码对不对。判断架构对不对。判断 AI 有没有理解错。判断这个修改会不会造成事故。判断需求本身是不是错误的。

所以未来一个高级工程师的工作越来越像：

AI 输出
↓
人类判断
↓
AI 修改
↓
人类验证
↓
生产观察
↓
继续调整

程序员从：

Code Writer

慢慢变成：

AI Supervisor + System Engineer

---

13

未来真正稀缺的程序员，可能有三种能力

我认为至少有三种。

第一：Debug 能力

AI 非常擅长：

Generate

但真实世界最难的是：

Why doesn't it work?

真正厉害的人能够从：

日志
Trace
Metrics
代码
数据库
网络
系统调用

一步一步缩小范围。

这个能力未来反而会越来越贵。

---

第二：系统设计能力

AI 可以给你生成：

微服务架构
Redis
Kafka
Kubernetes
DDD
CQRS

但真正的问题是：

到底该不该用？

很多项目最大的技术能力不是：

如何使用 Kafka？

而是：

为什么这里根本不应该使用 Kafka？

这是 Senior 的价值。

---

第三：Taste

品味。

也就是：

什么是好代码？什么是好 API？什么是好架构？什么是过度设计？什么东西虽然能跑，但以后一定会出事？

AI 可以生成 10 个方案。

真正值钱的人是：

知道哪个方案不应该选。

---

14

所以，以后 Junior 应该怎么学习？

我自己的建议反而会越来越“传统”。

AI 可以用。

甚至必须用。

但不要只做：

需求
↓
Prompt
↓
Copy
↓
Run
↓
能跑
↓
结束

而应该变成：

需求
↓
自己设计
↓
让 AI 给方案
↓
比较
↓
生成
↓
阅读代码
↓
自己解释
↓
测试
↓
故意破坏
↓
Debug
↓
重构

最重要的一条：

永远不要提交一段你解释不清楚的代码。

AI 可以给你写：

func retryWithExponentialBackoff() {}

没有问题。

但你至少应该知道：

为什么需要 Retry？为什么需要 Backoff？为什么要加 Jitter？什么错误不应该 Retry？最大重试次数为什么不能无限？Retry Storm 是什么？

否则代码虽然是你的 Git Commit，

能力却不是你的。

---

15

AI 最终可能创造一种非常奇怪的人才结构

以前的软件行业像金字塔：

        Staff/     \Senior/       \Mid-level/         \Junior Junior

以后可能越来越像：

        Senior / Staff││AI Agent││少量 Junior

也就是说：

AI 吃掉了中间层。

一个 Senior + 一群 Agent 可以完成过去一个团队的工作。

商业效率非常高。

但人才培养问题却没有解决。

---

16

这可能才是 AI 编程时代真正的大问题

AI 会不会写代码？

这个问题其实已经没有讨论价值了。

答案非常明确：

会。

而且越来越会。

真正的问题已经变成：

当人类不再需要通过写代码来学习软件工程以后，我们应该如何培养软件工程师？

这是两个完全不同的问题。

以前：

Learning by Doing

现在：

AI is doing.

那人类：

Learning by what?

这才是最麻烦的地方。

Allan 最后给出的态度也并不是抵制 AI。

相反，他认为 AI 的采用几乎已经不可逆。

真正需要解决的是：

如何培养能够监督 AI 的工程师，而这些工程师可能从来没有亲自完成过 AI 正在替他们完成的那些工作。

这句话值得所有 CTO、技术负责人，以及正在学习编程的人认真想一想。

---

最后

我一直认为：

AI 不会简单地把程序员这个职业删除。

但它一定会重新定义：

什么叫程序员。

以前我们评价一个程序员：

代码写得好不好？

未来可能越来越变成：

问题定义得好不好？上下文整理得好不好？系统理解得深不深？AI 指挥得好不好？结果验证得准不准？出了问题能不能接管？

写代码本身正在快速商品化。

但：

判断力没有。

系统理解没有。

生产经验没有。

工程直觉没有。

而这些东西恰恰是一个 Senior Engineer 真正值钱的地方。

所以对于今天正在学习编程的人，我觉得最危险的一件事情，不是不用 AI。

而是：

AI 帮你把所有题都做对了，但你自己从来没有学会做题。

短期看，你的效率可能提高了十倍。

长期看，你可能永远跨不过 Junior 到 Senior 的那道门槛。

AI 吃掉的也许不是程序员。

它正在吃掉的是：

程序员成长为真正工程师的过程。

而未来十年，整个软件行业必须想办法重新把这个过程设计回来。

我是王仕宇，AI 是带我们一起成长。