今天杭州天气不太好，上班路上下了一点小雨。从地铁站走到公司的路上，我一直在思考一个问题：AI的发展对程序员到底是好事还是坏事？
网络上到处在说“AI要取代程序员”“程序员的饭碗要没了”。这种说法是真的吗？
我的观点很明确：AI不仅不会取代程序员，反而会成为程序员极其强大的助手——甚至可以说是核武器级别的加速器。
要讲清楚这个问题，我们可以从三类人群的角度来分析。
一、没有任何计算机基础的人
对完全不懂编程的人来说，AI确实带来了巨大便利。你只需要用自然语言描述想法，AI就能帮你生成代码、做出原型、快速验证可行性。这在过去是不可想象的效率提升。
但问题在于：做出一个能跑的Demo，不等于能做出一个可以上线、稳定运行、可维护的产品。
比如，一个普通人用AI写了个程序，可能根本不知道：
- 这个程序在 Windows 和 Linux 上需要哪些运行环境？
.jar文件和可执行文件有什么区别？- 什么是服务器？怎么部署？怎么监控？
更不用说 JVM、GC（垃圾回收）、STW（Stop-The-World）这些概念了。你甚至可能都没听说过它们。当你的 Demo 跑起来时，你不会意识到它在线上可能因为内存溢出、线程阻塞或环境差异而崩溃。
对于一个完全没有程序员的团队来说，这些问题几乎是致命的。让他们从零开始系统学习计算机知识？这在现实中是不现实的。
这也让我想到《代码整洁之道：程序员的职业素养》中提到的一个历史案例——MDA（模型驱动架构）的失败。
书中写道：
“在20世纪90年代早期，我满怀希望地相信CASE工具行业将会彻底改变软件开发人员的工作方式。在那个冲动的年代，展望未来，我满以为到现在这个时候，每个人都应该已经在更高的抽象层次上用图形语言编程，而文本语言编程的时代应该已经一去不复返了。
我太幼稚了。不但这个梦想没有实现，连朝这个方向所做的每一次努力都不幸失败了。不是缺乏工具和系统来展示这种方法的潜能，只是，这些工具都不理想，很少有人愿意用。
在这个梦想中，软件开发人员将可抛弃基于文本编程的琐碎细节，采用一种更为高级的图形语言来编写系统。事实上，只要这个梦想成真，也许根本就不再需要程序员了。架构师能够通过UML图形创建整个系统。工程师们，那帮人数众多、冷酷、对非编程人士的困境缺乏同情的家伙，只需把这些图形转换成可执行代码就可以了。这伟大梦想就是‘模型驱动架构’（MDA）。
不幸的是，这个伟大的梦想有那么一点微小的瑕疵。MDA假设代码是问题之所在。但事实上，代码并不是问题。代码从来都不是问题。细节才是问题。
程序员负责管理各种细节，这是我们的职责。我们通过管理各种最微小的细节来规范系统的行为。之所以使用文本语言来编写代码，正是因为文本语言（例如英语）非常便利。
我们管理的是什么样的细节呢？
你知道\n和\r这两个字符之间的差别吗？第一个字符\n表示换行，第二个字符\r表示回车。回的是什么“车”（carriage）呢？
在20世纪60年代和70年代早期，电传打字机是计算机最常见的输出设备。ASR33型号的电传打字机最为常见。
这个设备有一个打印头，打印头每秒能够打印10个字符。打印头上有一个小圆筒，上面铸着各个字符。圆筒可以旋转升降，当正确的字符朝向纸面的时候，就会有个小锤子敲击圆筒，将字符打在纸面上。在圆筒和纸面间有一条墨带，这时墨水便会把字符印在纸上了。
打印头放在一个车架（carriage）上。每打印一个字符，车架会向右移动一个位置，带动打印头前进。每行有72个字符，当到达行末时，必须明确地通过发送回车字符（\r = 0x0D）执行回车，否则打印头会继续在第72个字符上打印，会让那个字符变成一个脏兮兮的黑块。
当然，执行这一个命令还不够。回车后纸张并没有上移。如果只回车但没有发送换行指令（\n=0x0A），那么新的一行会重复打印在旧的那行上。
因此，对于ASR33电传打印机，每行应该以\r\n结尾。事实上，还必须要注意，回车耗时有可能会超过100毫秒。如果发送了\r\n，紧接其后的下一个字符有可能刚好在回车的时候打印出来，这样就有可能在行中打印出一个污点。为了安全起见，通常会在每行末尾再附加上一到两个删除符（0xFF）。
在20世纪70年代，电传打印机用得越来越少了，像UNIX这些操作系统把行末序列简化为\n。但是，其他操作系统，如DOS，仍然使用\r\n作为行末的约定。
你最近一次处理文本文件时，因使用了“错误”的行末约定而遭遇到问题，是在什么时候？我每年至少要遇到一次。两个一模一样的源文件在比较时却发现不一样，生成的校验和也不一样，这就是因为它们使用了不同的行结束符。由于行末结束符有“错”，文本编辑器无法正确自动换行，或者文本里多空了一行。由于将\r\n解析为两行，没有预料到空行的程序崩溃了。有一些程序能够识别\r\n，但是无法识别\n\r。诸如此类的问题很多。
这就是我所说的细节。试试使用UML来描述解决行末问题的可怕逻辑！”
这段话非常关键。MDA 的失败，本质上是因为它试图绕过“细节”，而软件开发的核心恰恰就是处理细节。
今天的 AI 和当年的 MDA 其实有相似之处：都希望通过更高层次的抽象（图形或自然语言）跳过手写代码。但现实是，无论你写多少提示词，最终还是要面对设计、边界条件、异常处理和平台差异等具体问题。
写代码从来不是最难的部分，设计和理解系统才是。
所以，一个没有经验的普通人，即使能用 AI 做出一个“重要程序”，你敢用吗？比如银行转账、医疗诊断、工业控制——这些系统容不得半点模糊。
二、普通程序员
这里说的“普通程序员”，是指工作经验较少、对系统设计和底层原理理解不够深入的开发者。
对这类人来说，AI 是好事也是坏事：
-
对有进取心的人：AI 能极大加速学习过程。你可以快速理解新概念、生成示例代码、调试问题，从而更快积累经验。剩下的就是持续实践，稳步成长。
-
对只想混日子的人：AI 反而是威胁。如果你只会复制粘贴、调用现成接口、机械完成任务，那么 AI 很快就能替代你。在这个快速变化的行业里，不思进取就是慢性淘汰。
技术一直在演进。十年前和现在差别已经很大，而下一个十年的变化只会更快。年轻人学习能力强、精力充沛、没有技术包袱——如果你停滞不前，被后来者超越是必然的。
别以为“稳”就是安全。在程序员这个行业，逆水行舟，不进则退。
三、资深开发人员
对资深开发者来说，AI 是一个强大的“加速引擎”。
它可以帮你：
- 快速生成样板代码，减少重复劳动；
- 检查潜在 bug 或性能问题；
- 根据设计思路补全实现；
- 提供多种技术方案参考。
但必须清楚：AI 不能替代系统设计和架构决策。
软件开发从来不是一个人的事。一个人可以写出一个程序，但要让它长期稳定迭代，需要团队协作、流程规范、知识沉淀和持续维护。
未来更高效的模式，可能是由资深开发者组成的“特种兵式”小团队：
- 每个人专注一个核心模块；
- 借助 AI 提升个人产出效率；
- 通过紧密协作保证整体质量。
这样的团队迭代快、问题少、成本低，特别适合长期产品。即使是短期项目，稳定的团队也能爆发出更强战斗力。
频繁更换团队其实代价很高——上下文丢失、沟通成本上升、信任重建，这些都是隐形成本。在这方面，我也推荐《代码整洁之道》中的章节：“团队与项目——有凝聚力的团队”，里面讲得很清楚：高效来自默契，而非个体英雄主义。
总结：AI 是蒸汽机，不是原子弹
我认为，AI 是可以媲美蒸汽机的伟大发明。
蒸汽机出现之前，生产靠人力，效率极低；蒸汽机之后，人类学会了高效利用能量，开启了工业革命。
今天，AI 正处于初级阶段。如果说蒸汽机是对能量的合理使用，那么 AI 就是对知识的充分使用。
我们今天很多问题——比如学习门槛高、信息碎片化、试错成本大——本质上是因为缺乏可靠知识，或无法快速获取它。AI 正在改变这一点。
所以，AI 不会取代程序员。它取代的，是那些只做重复性编码、不思考系统、不理解业务、不持续学习的人。
而对真正理解软件本质、善于解决问题、持续精进的程序员来说，AI 是前所未有的助力。
与其担心被 AI 取代，不如学会用 AI 让自己变得更强大。
下一个十年，变化一定会比过去十年更大。你准备好了吗？
