AI时代程序员到底应该焦虑什么？

共计 7489 个字符，预计需要花费 19 分钟才能阅读完成。

最近在网上看到那些天花乱坠地吹捧 AI 编程和 AI 工具的文章时，不禁陷入了沉思。作为一位在编程领域积累了十多年的经验的开发者，我深切体会到技术的每一次革新都伴随着无数的挑战与机遇。在这次关于 AI 编程的热潮中，我也不得不反思：AI 真的如同宣传中所说的那样无所不能，还是它能够真正为我们的工作带来革命性的变革？

过去半个多世纪，软件开发领域反复上演着一出熟悉的 " 狼来了 "：每当一种新技术诞生，总有人站出来宣布——" 程序员要失业了！"

从机器码到汇编，从 COBOL 到 C 语言，从 Java 到 Rails，从移动互联网到低代码，再到今天满大街的 AI 编程助手……这场 " 消灭程序员 " 的运动已经持续了五十多年。结果呢？程序员不但没死绝，反而越来越贵，越来越抢手。

经过两个多月的时间，我一直在利用 AI 辅助产品设计。在这段旅程中，我既是探索者也是挑战者，AI 带来的便利和挑战并存。我想，是时候分享我的观察与思考，与更多同道中人一起探讨 AI 在实际应用中的真谛。作为一个写了十多年代码，做了五年产品的老兵，我想从历史的角度，看看每一代 " 革命者 " 是怎么信心满满地登场，又是怎么悄悄调整自己的定位的。

1. 1950 年代：从打孔卡片到汇编，第一次 " 革命 "

故事要从上世纪 50 年代讲起。

那时候的程序员，活得像个人肉翻译机。他们面对的是一串串 0 和 1 组成的机器码，写程序就像用摩尔斯电码写情书——理论上能表达，实际上折磨人。

然后汇编语言来了。

它说：" 兄弟们，别再背那些鬼畜的二进制了！

MOV AX, BX

难道不比 10001001 11000011 好记多了？"

程序员们热泪盈眶。终于可以用人话（虽然是很僵硬的人话）来写程序了。

但很快有人开始担忧：" 汇编这么好用，以后是不是阿猫阿狗都能写程序了？我们会不会失业？"

结果当然是没有。因为大家很快发现：把 ADD 换成 01000000 只是省了查表的功夫，你还是得知道为什么要 ADD，什么时候 ADD，ADD 完了怎么办。

汇编语言像是给你换了支更顺手的笔，但作文还是得你自己写。

2. 1959 年：COBOL，让会计也能编程？

就在汇编语言流行的同时，商业世界也在做自己的梦。

1959 年，COBOL 语言诞生，名字里就写着野心——" 通用业务导向语言 "（Common Business-Oriented Language）。设计者的想法简单粗暴：既然程序员那么贵那么少，不如让语法看起来像英语，这样业务人员自己就能写程序了！

MULTIPLY UNIT-PRICE BY QUANTITY GIVING TOTAL-PRICE.

看，这不就是英语作文嘛！会计小张应该能学会吧？

会计小张试了试，发现：虽然每个单词他都认识，但连在一起他就不知道自己在干什么了。

原因很简单：看起来像英语，和真的是英语，完全是两码事。 就像你把法律文书翻译成白话文，普通人还是看不懂——因为复杂的不是语言本身，而是语言背后的逻辑、概念和规则。

最终，COBOL 培养出了一大批专业的 COBOL 程序员，而不是会写程序的业务人员。直到今天，全球银行系统里还跑着大量 COBOL 代码，养活了一批 " 活化石 " 程序员。

但这个 " 让非专业人士也能编程 " 的梦想并没有死。它只是换了个战场，等待下一次机会。

3. 1969 年：阿波罗登月，软件走向舞台中央

1969 年 7 月，尼尔·阿姆斯特朗踏上月球表面的那一刻，全世界亲眼见证了 " 有组织的人类智慧 " 究竟能够走多远。

而支撑这次壮举的，是阿波罗飞船上那台只有 4KB 内存的导航计算机，和控制它的软件。

这些软件是玛格丽特·汉密尔顿带领团队一行一行手写的。没有 IDE，没有调试器，没有 Stack Overflow，更没有 ChatGPT。每一行代码都经过反复推敲和人工审查，因为任何 bug 都可能意味着宇航员的生命。

阿波罗计划向世人证明了一件事：软件不是可有可无的配角，而是关乎成败、甚至生死的核心系统。

但它也暴露出一个此后几十年困扰企业管理者的问题：软件的编写需要高度专业的知识、长期的专注投入，以及难以压缩的时间成本。

如何让软件开发变得更简单？如何减少对这些昂贵而稀缺的专业人员的依赖？

这个问题，几乎在那一刻就成了挥之不去的执念。

4. 1972 年：C 语言，程序员的 " 瑞士军刀 "

1972 年，贝尔实验室的 Dennis Ritchie 在捣鼓 Unix 系统的时候，顺手发明了 C 语言。

C 语言对汇编程序员说：" 老铁，你看你写个循环要十几行汇编，我一个 for 就搞定了。你那堆寄存器操作，我用变量就能表达。而且——我还能跨平台！"

这简直是降维打击。

如果说汇编是手动挡拖拉机，C 语言就是自动挡轿车。你不用再关心每个轮子怎么转，只需要告诉它 " 往前开 "。

当时很多人预言：" 有了 C 语言，写程序会变得像写散文一样简单，程序员的门槛会大大降低！"

然后指针来了。

int *p = &a;
*p = 10;
**pp = 20;

新手程序员看着这些星号和取地址符，陷入了深深的沉思：这是编程还是占星术？

C 语言确实让编程效率提升了一个量级，但它同时也证明了一件事：工具再好用，复杂性不会消失，只会换一种形式出现。 以前你要和硬件搏斗，现在你要和内存泄漏、野指针、段错误搏斗。

魔鬼换了身衣服，但还是那个魔鬼。

5. 1980 年代：CASE 工具，画个图就能出程序？

进入 80 年代，计算机辅助软件工程（CASE）工具隆重登场。

它的卖点极具诱惑力：不用写代码了！只要画流程图，系统就能自动生成程序！

想象一下，产品经理再也不用和程序员吵架了，他自己画个图，系统就给他生成一个 App。多美好的世界啊！

企业为此投入了大量资金。厂商信誓旦旦地宣称，生产力可以提升 10 倍，甚至更多。

然而现实是：

• 画出来的图要是能直接生成好代码，那这个图本身就已经很复杂了
• 自动生成的代码性能堪忧，维护起来像在破译古埃及象形文字
• 一旦你需要做点图里没覆盖到的事情，就得回去写代码——而且是和生成代码纠缠不清的代码

这就好比你以为买了个自动作文机，只要列个提纲就能出高考满分作文。结果发现：列出一个足够详细的提纲，跟自己写作文差不多累；而机器生成的作文还经常跑题，改起来比重写还费劲。

CASE 工具最终没能 " 消灭程序员 "，但它推动了软件建模思想的发展，UML 图至今仍在使用——虽然主要是用来开会时装装样子。

6. 1990 年代初：Visual Basic 与 Delphi，拖拖拽拽的快乐

90 年代初，微软的 Visual Basic（1991 年）和 Borland 的 Delphi（1995 年）另辟蹊径。

它们说：" 好吧，我们不自动生成一切，但我们可以让界面开发变得超级简单！"

拖一个按钮，放一个文本框，双击写个事件——嘿，程序就跑起来了！

突然之间，开发一个 Windows 应用，看起来不再是少数高手的专利了。

这次确实管用了。很多人通过 VB 入了编程的门，做出了真正能用的软件。无数 " 部门级应用 " 就是这么诞生的。

但当这些软件变得越来越复杂，需要连数据库、做网络通信、处理并发……专业开发者又被请回来了。工具降低了入门门槛，但没有降低精通门槛。

就像美图秀秀让人人都能修图，但要修出专业级效果，你还是得学 Photoshop——或者找个会 Photoshop 的人。

7. 1995 年：Java，一次编写，到处 debug

同样在 1995 年，Java 带着 "Write Once, Run Anywhere" 的口号闪亮登场。

这次的承诺更诱人了：你写的程序可以在 Windows 上跑，也可以在 Linux 上跑，还可以在你家电冰箱上跑（如果它有 JVM 的话）。程序员再也不用为了不同平台写不同版本的代码了！

Java 还搞了个 " 垃圾回收 " 机制。它对 C 程序员说：" 你们天天追着内存泄漏跑，累不累？把这活交给我吧，我自动帮你收拾。"

C 程序员们感动得热泪盈眶，纷纷改行写 Java。

但很快他们发现了新的问题：

• "Write Once, Run Anywhere" 有时候变成了 "Write Once, Debug Everywhere"
• 垃圾回收是自动了，但你得学会看 GC 日志，调 JVM 参数，处理 OOM 异常
• 代码是少写了，但配置文件多了一堆，光 Spring 的 XML 就能写到你怀疑人生

Java 确实解决了很多问题，但它也创造了新的复杂性。企业级开发变成了一门玄学，架构师成了新的稀缺资源。

每一代技术都在消灭旧的复杂性，同时制造新的复杂性。 这就像打地鼠游戏——你按下去一个，又冒出来三个。

8. 2000 年代：Web 2.0 与框架狂潮，" 约定优于配置 "

千禧年的钟声敲响后，互联网泡沫破裂了，但 Web 没有死——它变得更强了。

2004 年前后，"Web 2.0" 这个词开始流行。网页不再是静态的电子传单，而是可以交互、可以社交、可以产生内容的平台。Ajax 技术让页面可以局部刷新，用户体验一下子丝滑了起来。

与此同时，一个叫 David Heinemeier Hansson 的丹麦小伙搞了个框架叫 Ruby on Rails，喊出了一句响亮的口号：" 约定优于配置 "（Convention over Configuration）。

Rails 对 Java 程序员说：" 你们写个 Web 应用要配置多少 XML？我这边，文件放对位置，命名按规矩来，框架自动帮你搞定一切！"

# 这就是一个完整的数据模型
class User < ActiveRecord::Base
  has_many :posts
end

Java 程序员看了看自己几十行的 Hibernate 配置文件，陷入了沉默。

Rails 掀起了一场 " 敏捷开发 " 革命。PHP 也不甘落后，WordPress、Drupal 等 CMS 让 " 人人都能建网站 " 成为现实。一时间，" 全栈工程师 " 这个词开始流行——一个人就能搞定前后端，创业公司最爱这种。

但你猜怎么着？当网站流量涨到一定规模，当业务逻辑变得足够复杂，那些 " 约定 " 就开始变成 " 约束 " 了。Rails 应用的性能问题成了段子，大公司纷纷把核心系统迁移到 Java 或 Go。

框架让简单的事情更简单了，但复杂的事情还是复杂。 这个剧本，是不是有点眼熟？

9. 2007-2015 年：移动互联网，程序员不够用了

2007 年 1 月 9 日，乔布斯掏出了第一代 iPhone。

那一刻，整个软件行业的游戏规则被改写了。

突然之间，每个公司都需要一个 App。不，是两个——iOS 一个，Android 一个。不对，还要有个移动端网页，还要有微信公众号，还要有小程序……

程序员们懵了：" 我刚学会写网页，你告诉我要学 Objective-C？刚学会 Objective-C，你又告诉我 Swift 出来了？"

移动互联网带来了前所未有的人才缺口。2010 年前后，会写 iOS App 的程序员简直是香饽饽，薪资水涨船高。企业喊着 " 招不到人 "，培训班喊着 " 四个月包就业 "。

与此同时，前端领域也在经历一场革命。

JavaScript 这门当年被嘲笑为 " 玩具语言 " 的东西，突然变得无比重要。2009 年 Node.js 诞生，JavaScript 可以写后端了。2013 年 React 发布，2014 年 Vue 问世，前端从 " 切图仔 " 变成了 " 前端工程师 "。

// 以前的前端
document.getElementById('btn').onclick = function() { ...}

// 现在的前端
const App = () => <Button onClick={handleClick}> 点我 </Button>

工具链也爆炸式增长：Webpack、Babel、ESLint、TypeScript……一个前端项目的 node_modules 文件夹动辄几百 MB，里面躺着成千上万个依赖包。

有人调侃："JavaScript 疲劳症 " ——你刚学会一个框架，它就过时了；你刚配好一套工具链，新的最佳实践又出来了。

但讽刺的是，在这个 " 人人都能做 App" 的时代，专业程序员反而更稀缺了。

因为移动互联网把软件的边界扩大了无数倍。以前一个网站够用，现在你需要 iOS、Android、小程序、H5、后端 API、数据分析、推荐算法……每一个领域都需要专业的人。

技术栈爆炸了，但能驾驭这一切的人，还是那么少。

10. 2015 年至今：低代码、无代码，这次我们是认真的

经历了移动互联网的 " 人才饥荒 " 后，企业开始认真思考：能不能让不懂编程的人也能做应用？

于是，" 低代码 " 和 " 无代码 " 平台在 2015 年后开始真正崛起。

它们的承诺听起来很耳熟：

• " 业务人员可以自己构建应用！"
• " 不写代码也能做系统！"
• "IT 部门的瓶颈将被彻底打破！"

等等，这剧本我好像在 COBOL 那章读过？

不过公平地说，这次确实比以前强。有了云计算的加持，有了成熟的组件生态，对于表单收集、审批流程、简单报表这类标准化需求，低代码平台确实快得多。很多 " 部门级小应用 " 不再需要 IT 排期了。

但问题在于：

1. 简单的需求确实简单了，复杂的需求还是复杂。 当你需要对接一个奇葩的第三方 API，或者处理一个非标准的业务逻辑，低代码平台要么做不到，要么做起来比写代码还痛苦。
2. 维护是个大问题。 当最初搭建这个 " 无代码应用 " 的业务人员离职后，接手的人往往一脸懵逼——这些七拐八绕的配置和流程，比代码还难读。
3. 它创造了新的依赖。 你不再依赖程序员，但你开始依赖平台厂商。想迁移？祝你好运。

低代码 / 无代码找到了自己的生态位，但 " 消灭程序员 "？还是算了吧。

11. 2022 年至今：AI 编程，这次真的不一样？

终于讲到今天的主角了——AI。

2022 年底开始，ChatGPT、Copilot、Cursor……各种 AI 编程工具像雨后春笋一样冒出来。它们展示的能力确实令人印象深刻：

• 你用自然语言描述需求，它给你生成代码
• 你贴一段 bug，它帮你分析原因并给出修复方案
• 你问它任何编程问题，它都能侃侃而谈

一时间，" 程序员要被 AI 取代 " 的声音再次响起，而且这次声势更大。

但作为一个亲身使用这些工具的人，我想说几点观察：

AI 确实很强，但它像一个特别热心、知识渊博、但有时候又是一个“胡说八道”的实习生。

它能帮你快速生成样板代码，能帮你查 API 用法，能帮你解释一段复杂的正则表达式。这些事情它做得比 Baidu，Google 搜索快多了。

但当你让它处理真正复杂的问题时——比如重构一个有十几年历史的遗留系统，或者设计一个高并发分布式架构——它生成的代码往往需要大量修改，甚至可能把你带进坑里。

为什么？

因为 软件开发真正困难的部分，从来不是 " 写代码 " 本身。

真正困难的是：

• 理解业务需求背后的真实问题
• 在无数种实现方式中做出正确的取舍
• 预见到系统规模扩大后会遇到的问题
• 在各种约束条件下找到可行的方案
• 和人沟通，理解他们没说出口的需求

这些都是 认知工作，需要理解力、判断力和经验。AI 可以加速你的编码，但不能替你思考。

就像计算器可以帮你算数，但不能帮你决定该算什么。

12. 复杂性守恒定律

回顾这五十年的历史，我发现一个有趣的模式：

每一代新技术都确实解决了一些真实的痛点。汇编比机器码好写，C 比汇编高效，Java 比 C 安全，AI 比搜索引擎快……这些都是实打实的进步。

但每一次，复杂性都没有真正消失，只是换了个地方藏起来。

• 汇编消灭了记忆机器码的痛苦，但引入了汇编语言本身的复杂性
• C 消灭了汇编的繁琐，但引入了指针和内存管理的复杂性
• Java 消灭了内存管理，但引入了框架配置和 JVM 调优的复杂性
• Rails 消灭了繁琐配置，但引入了 " 魔法 " 背后的隐藏约定
• 移动互联网消灭了地域限制，但引入了多端适配的复杂性
• 前端框架消灭了 DOM 操作，但引入了构建工具链的复杂性
• AI 消灭了大量重复编码，但引入了提示工程和结果验证的复杂性

这就是我总结的 复杂性守恒定律：软件系统的总复杂性不会因为工具的改进而减少，只会在不同层面之间转移。

为什么会这样？

因为 软件的复杂性本质上来自现实世界的复杂性。

你想做一个电商系统。看起来很简单：" 用户下单，付款，发货。"

但仔细想想：

• 库存不足怎么办？部分发货还是全部取消？
• 优惠券能叠加使用吗？哪些叠加哪些不行？
• 跨境订单的税怎么算？不同国家规则不一样
• 订单支付超时怎么处理？支付成功但回调失败呢？
• 同一商品同时有两人下单库存只有一件怎么办？
• ……

这些复杂性不是程序员发明的，是业务本身带来的。无论你用什么语言，什么工具，什么 AI，这些问题都需要有人去思考和决策。

而这个 " 有人 "，就是程序员——或者叫软件工程师、开发者、码农，随便什么称呼都行。他们的核心价值从来不是 " 会打字写代码 "，而是 " 能把复杂问题想清楚并转化为可运行的解决方案 "。

13. 几句大实话

如果你是一位技术团队的管理者，或者是一位负责数字化转型的决策者，这段历史应该能帮你建立更理性的预期。

每当有人跟你说 " 用了这个工具 / 平台 /AI，就不需要那么多程序员了 "，请回想一下：这句话在过去五十年里被说过多少次？结果又是什么？

我不是说你不该尝试新工具。恰恰相反，好的工具确实能提升效率，应该积极采用。

但在评估时，与其问 " 这能不能消灭程序员 "，不如问：

• 这个工具能帮程序员提升多少效率？
• 它在什么场景下效果最好，什么场景下不适用？
• 我的团队需要学习什么新技能才能用好它？
• 长期来看，它会带来什么新的复杂性或依赖？

最重要的是：投资在人身上，而不只是工具上。

好的程序员能用任何工具做出好东西，也能判断什么时候该用什么工具。而再好的工具，交给不懂的人，也只会制造更多问题。

14. 带着清醒的乐观前行

写到这里，我想澄清一点：我不是一个技术悲观主义者。

恰恰相反，我对每一代新技术都持开放态度。汇编、C、Java、Python、AI 工具……我都用过，也都从中受益。

每一代工具都在解决真实的问题，都在降低某些方面的门槛，都在让更多人能够参与软件创造。这是实实在在的进步。

只是，" 让编程变简单 " 和 " 消灭程序员 " 是两回事。

前者正在发生，而且会继续发生。入门的门槛确实在降低，很多以前需要专业程序员才能做的事，现在普通人也能完成了。这是好事。

后者不会发生，因为它基于一个错误的假设——以为软件开发的难点在于 " 写代码 " 本身。实际上，写代码只是冰山浮在水面上的部分，下面 90% 是理解问题、设计方案、处理边界情况、维护演进……这些才是真正需要人类智慧的地方。

也许有一天 AI 会真的具备这些能力。但那一天来临时，它改变的就不只是编程这个职业，而是人类社会的整个运作方式了。在那之前，程序员的饭碗应该还是稳的。

所以，放心大胆地拥抱 AI 工具吧。它是迄今为止最强大的编程辅助。但不要指望它替你思考。

用它来加速重复性工作，用它来学习新知识，用它来验证想法——然后把省下来的时间，投入到真正困难的、需要深度思考的问题上。

这才是 AI 时代程序员的正确姿势。

五十年来，每一代技术都想 " 干掉 " 程序员。结果是：程序员越来越多，越来越重要，越来越贵。下一个五十年，大概率还是这样。

因为复杂性不会消失，只会转移。而处理复杂性，永远需要人。

‍