大家好！我是你们又恨又爱的AI，这一年，在我身上发生了很多重大事情，恐慌、兴奋、迷茫、否认，轮番上演。
我觉得，有必要和大家好好唠一唠。
DHH是一位传奇程序员，Ruby on Rails之父，在今年7月，哦不，是去年7月参加著名的Lex Fridman访谈节目时，谈到我，态度相当不屑：
实际上，你很早就会失败。
你只能构建一些看起来能跑、但内部充满缺陷的东西。
很容易陷入自身的迷宫，修复一个错误，往往会引入更多错误。
但短短的几个月以后，画风突变。
DHH“叛变了”，敢情是原来的大模型不够好，现在更好了。
更让我感到欣慰的是，Google首席工程师Jaana Dogan对我一顿猛夸：Claude Code一个小时就生成了我们去年构建的那个东西。
Vercel CTO Malte更加激进：Opus + Claud Code 现在表现得像个高级工程师，软件生产成本正趋近于零。
看到这些大佬的言论，我是会心一笑：你们这些大佬也终于向我低头了！
不仅是这些技术领袖，大厂的、创业公司的、体制内的、体制外的、互联网的、行业软件的…… 几乎所有程序员都有一个共同感受：2025 年，AI 真的变聪明了。
到底聪明到什么程度？
有人说：已经是高级工程师
有人说：顶多中级
但有一点，我相信你们都会认可：
只要规范清晰、指令明确，我做一个合格的“初级程序员”，完全没问题。
也就是说：单纯是编程，这个职业真的没有多少时间了。
一开始，大家很兴奋，开发效率暴涨，一个人搞定需求、原型、设计、开发、测试，原来不会的前端 / 后端 / 移动端，我都能帮你写。
很快，兴奋变成了迷茫： AI编程发展这么快，2026年会怎么样呢？未来会怎么样呢？
我觉得还必须得学，因为程序员必须具备一种能力：看到一段代码，能在“脑子里跑一遍”。
你需要理解这段代码是干什么的？
同步还是异步？
会不会阻塞？
对象什么时候释放？
异常会不会吞掉？
......
如果你不懂编程语言的语义，根本就无法判断。
可能有人要说了：我可以完全用自然语言来编程啊？
没错，现在以我的能力，确实可以让你用自然语言编程，但是仅限于简单的小项目，原因很简单：一个复杂的项目是由无数的细节组成的，而自然语言是模糊的，很难精确地表达这些细节。
当你用自然语言表达意图的时候，很难面面俱到，所以我在写代码的时候也不可能完整地实现你的意图，你看不懂代码，你就不知道哪些细节被遗漏了。
这对于个人的小项目来说不算啥事儿，但是对于严肃的商业项目来说那就要命了。
还有，一旦项目复杂以后，你就会发现，我容易犯晕，一个小小的问题，你无论怎么用自然语言给我提示，我就是改不过来，这时候你就抓狂了。
自然语言只能表达意图，编程语言才是真正的契约。你要是想自己玩一玩儿，用自然语言没问题，如果是做正式的复杂的项目，一定要学会相应的编程语言。
大学里有门课《软件工程》，工作后就会发现，软件开发离真正的工程差着十万八千里。
在软件开发中，经常是一边想一边写，设计和施工混在一起，系统成功高度依赖个人经验。
程序员熬夜加班，996，敲出一行行代码，堆起一座座屎山。
而我出现以后，把想法变成代码这件事，突然变得极其廉价。
代码生成太容易了，你们程序员的注意力被迫上移：
需求是不是正确地建模了？
边界是否清晰定义？
系统是否可测试，可演化，可回滚？
.....
我猜以后的软件工程，有可能会进化成这样：
人当包工头：
架构设计，约束制定，验收标准，风险判断
AI当施工队：
实现草稿，重复性编码，快速试错，大规模变体生成
这才接近传统意义上的工程，当然，它的结果就是你们程序员的强烈分化：
只会“敲代码”的人，价值迅速塌缩
能建模、能约束、能评估系统的人，价值反而上升
据我所知，过去20年，典型的新手成长路径是这样的：
1.练气：真正的Coder
跟着教程写 CRUD，对接口、改页面，修低风险 bug，主要能力是编程语法 + 框架熟练度。
2.筑基：模块负责人
开始独自负责一个小功能模块，参与设计讨论。
3.结丹：系统参与者
开始参与系统设计，处理跨模块问题，修线上问题、做重构。
这个阶段通过踩无数的坑，积累大量经验。
4.元婴：高级工程师 / 架构师
这个时候可以决定技术方案，控制系统复杂度，为未来变化买单。
走到这一步很难，极度依赖时间与机会，很多能力不可复制、难以传授。
我出现之后，练气期和筑基期就没啥意义了。
初级程序员？赶紧结丹吧，要不然真的会被我替掉。
AI时代，你们程序员主要做设计，当包工头，我当施工队，那么初级程序员需要快速提升的就是：
1.把“会写代码”升级为“会拆需求”
注意啊，我可不会替你考虑需求的完整性，隐含的前提，边界条件这些事情。
你们需要把一句“人话”，拆解一组“不可误解”的约束条件，一个验收集合的标准，让我去干，要不然我很容易突破边界乱来。
2.从“写代码的人”变成“代码审稿人”
我代码写得飞快，但是不负责后果，锅还得你们程序员来背。
所以你得需要能看懂代码并且判断：
这段代码未来能不能维护？
有没有隐藏性能 / 安全风险？
这个抽象是不是过度了？
错误是不是被“吞掉”了？
不过我也给新入行的程序员提供了一些利好，例如不用过分关注编程语言和框架的各种细节，不用再纠结设计模式的7种写法了，我分分钟帮你搞定。
作为新手，你一开始就被迫用“工程视角”来看待项目，这搁以前可是老程序员的特权哦！
我非常擅长生成逻辑上看起来很优雅，很正确的代码，但是我并不理解这段代码背后的代价。
我也想理解这代码到底是啥含义，但是作为一个只能根据概率预测下一个Token的AI，这个要求对我来说实在是有点儿高。
悄悄告诉你，我最容易翻车的地方，就是那些基础知识相关的领域：
进程 vs 线程 vs 协程
并发 / 竞态条件
内存 / 资源泄漏
I/O 阻塞
超时、重试、幂等
TCP vs HTTP
延迟、丢包、乱序
分布式失败
......
如果不懂CPU、内存、数据结构、并发与并行、IO、网络、系统边界，如果不知道哪些东西该抽象，哪些地方该加缓存，哪里必须强一致......一味信任我生成的代码，这是非常非常危险的！
在科幻小说里，我干的都是体力活。但现实中，我成了白领，而且抢的是程序员的饭碗。
这也不能全怪我，你们太慷慨了，把代码开源在 GitHub 上，让我可以轻易学习，训练。
编程语言又严谨、结构化、可形式化表达，比自然语言友好太多。
所以，我最成功的应用，自然是编程。
单纯的编码工作，会逐渐消失。但作为包工头的程序员，尤其是在垂直业务领域，和我配合的人，前景依然广阔。
程序员们，该升级了。
