投稿或寻求报道 | zhanghy@csdn.net
在计算机技术七十余年的演进史上，一个幽灵始终在行业上空徘徊——“程序员即将被机器取代”。
然而，这并非 ChatGPT 爆火后才出现的新近焦虑，而是贯穿整个信息时代、最具韧性的预言之一。
每当一项旨在简化软件开发、降低技术门槛的重大技术跃迁出现时，“程序员末日论”便会应声而起，以不同的技术名义，在每一个时代向同一个职业宣判死刑。从 1950 年代编译器的诞生，到今天大语言模型的崛起，历史已经上演了整整八轮几乎一模一样的“替代”故事。
所以，让我们一起追溯历史上这八次主要的“程序员替代论”浪潮，看看程序员如何“死而复生”，探究程序员们“不死的秘密”。
自动化的黎明（1950 年代）
没有显示器，没有键盘，更没有我们熟悉的 IDE。
这个年代所谓的“程序员”，是一小群数学家和逻辑学家。他们的工作，是在一张张表格上手动填写一长串令人费解的八进制码，每一个数字都对应着机器的一条指令、一个内存地址。然后，这些编码被送去穿孔，变成一叠厚厚的卡片。
约翰·巴克斯，后来 FORTRAN 语言的发明者，如此形容那段经历。
“你必须像了解自己的掌纹一样，了解 CPU 的每一个寄存器和指令集。任何一个微小的疏忽，比如一个内存地址写错，都可能导致程序崩溃。”
就在这个背景下，第一位“终结者”登场了。她是一位名叫格蕾丝·霍珀的海军少将，一位计算机科学家。她提出了一个在当时听起来近乎天真的想法：为什么我们不能用更接近自然英语的语言来编程呢？
她的愿景并非要用机器取代人，而是想让更多的人能够驾驭机器，特别是那些处理商业数据的普通职员，她认为这些人并不擅长操纵抽象的数学符号。当她首次提出这个想法时，立刻遭到了同行的嘲讽：“我很快就被告知，我不能这样做，因为计算机不懂英语。”
但霍珀坚持了下来。她和她的团队在 1952 年开发了 A-0 系统，这被认为是历史上第一个编译器。它的作用，就是把那些相对友好的、类似英语的指令，自动“翻译”成机器能够理解的二进制码。
与此同时，在 IBM，约翰·巴克斯的团队也在进行一场平行的革命。他们开发 FORTRAN 语言的目标非常明确：让科学家和工程师能够直接用他们熟悉的数学公式来编写程序，从而摆脱对那一小撮“硬件专家”的依赖。
这两项发明的出现，立刻引发了第一轮“程序员替代论”。人们相信，既然机器可以自动完成最困难的翻译工作，那编程的门槛将不复存在，那些掌握着机器神秘知识的专家，自然也就没有存在的必要了。
然而，历史的走向出乎了所有人的意料。编译器非但没有终结程序员，反而催生了我们今天所熟知的、一个全新的、庞大的职业群体——“软件程序员”。
它将开发者从与硬件寄存器搏斗的泥潭中解放出来，让他们第一次可以集中精力去思考更高层次的问题——“我要解决什么问题”，而不是“我该如何指挥这台机器”。一个过去需要耗费数周去编写的核反应堆参数计算程序，用 FORTRAN 可能只需几个小时。
软件的应用成本急剧下降，应用范围空前扩大。银行、航空公司、制造企业……各行各业都开始涌现出对软件的巨大需求。而这种需求的增长速度，远远超过了生产力提升所能“节省”的人力。
所谓的“替代”，第一次露出了它的真面目：它不是角色的消亡，而是角色定义的重塑。旧的、面向硬件的“编码员”，被新的、面向应用的“程序员”所取代。
而整个行业的规模，爆炸式地增长了。
意大利面条仍然是意大利面条（1960-70 年代）
没霍珀的梦想在60年代被推向了行业政策的高度。在美国国防部的主导下，COBOL（通用商业导向语言）诞生了。
它的设计哲学被贯彻得极为彻底：使用基础的英语单词，语法结构冗长得像一篇散文（比如用 MOVE X TO Y 来替代 Y = X），以期达到“自文档化”的效果，让非专业的管理人员也能轻松读懂，甚至编写程序。
这被视为解决日益严重的“软件开发积压”问题的终极方案。当时的设想是，如果业务经理能够自己编写或者至少修改程序，那对专业程序员的依赖自然会大大降低。
但现实很快给出了另一份答案。企业的业务经理们并没有开始亲自编写公司的薪酬系统。恰恰相反，COBOL 的普及，催生了一个全新的、庞大的、且高度专业化的职业群体——COBOL 程序员。他们遍布在银行、保险、政府等各个机构，成为了信息时代的第一代“码农”。
人们痛苦地发现，语言的“可读性”并不能消除逻辑的“复杂性”。一句流传至今的俏皮话精准地概括了这一切：“意大利面条仍然是意大利面条。”
无论语法多么像英语，一个糟糕的、充满了 GO TO 跳转的程序，其逻辑依然像一盘搅乱的意大利面，难以理解和维护。
想象一下，一位在 80 年代入职的年轻程序员，他的工作是维护一个在 60 年代末上线的、拥有数百万行代码的银行核心交易系统。他面对的挑战，不再是机器的指令集，而是深埋在代码深处、盘根错节的业务规则。
这些规则可能是二十年来无数次政策调整、特殊客户豁免、临时补丁的层层叠加。代码的原始作者早已退休，文档缺失不全。他必须像一个考古学家一样，从这些被称为“屎山”的遗迹中，小心翼翼地挖掘出一段逻辑，修复一个 bug，同时祈祷不会因为自己的改动，而导致某个看似无关的模块在午夜结算时崩溃。
这成了一项全新的、极具挑战性的专业技能。
所谓的“简化”，只是将困难从一个层面迁移到了另一个更高的层面。程序员的认知负担，从“机器复杂性”转向了“领域和应用复杂性”。
编程的困难并未被消除，它只是换了一副面孔。
你只需说“要什么”，而不用管“如何做”（1970-80 年代）
软件积压的问题愈演愈烈，业界开始寻求一次范式上的飞跃。第四代编程语言（4GL）应运而生，它的承诺极具诱惑力：从“过程式”编程转向“声明式”编程。
当时的宣传话语充满了乐观主义。它们描绘出一幅生动的图景：你不再需要像使用 COBOL 或 FORTRAN 那样，一步步地告诉计算机“如何”完成任务（打开文件、循环读取、判断条件、写入结果），你只需要简单地声明你“想要什么”结果。
比如，在一个报表生成器里，一个普通的办公室文员，只需通过图形界面“点击几下”，选择需要的字段、过滤条件和排序方式，就能自动生成一份精美的销售报表。
这种叙事被刻意包装成对传统 IT 部门的一种挑战，直接推销给那些对开发效率感到沮丧的业务经理。数据库查询语言 SQL 的诞生，也遵循着同样的哲学，它最初的名字 SEQUEL，就是“结构化英语查询语言”的缩写，旨在为非程序员提供一种访问和操作数据的直观方式。
“程序员将被绕过”，这个论调再次响起。
然而，尽管市场声势浩大，4GL 最终并未实现其宏伟目标。它们在特定的领域，比如报表生成、数据查询等场景取得了巨大成功。SQL 更是大获全胜，成为了关系数据库交互的事实标准。但 SQL 的成功也恰恰证明了 4GL 的局限性——它是一种强大的领域特定语言（Domain-Specific Language），而非能够取代 C 或 COBOL 等通用语言的全能选手。
让非开发者构建一个完整、复杂的企业系统的承诺，基本上未能兑现。现实情况是，那位办公室文员确实可以快速生成报表，但他所查询的那个庞大、稳定、安全的核心数据库系统，依然是由一队专业的数据库管理员和程序员，使用C或PL/SQL等“过程式”语言，精心设计、构建和维护的。
这一轮浪潮，并未消灭程序员，而是催生了一类新的“混合型”角色。大量的业务分析师、数据分析师和其他领域的专业人士开始学习 SQL，不是为了成为全职的软件工程师，而是为了增强他们自身的核心工作能力。与此同时，专业的程序员则必须学习并掌握 4GL 和 SQL，以便构建和集成那些“超级用户”们所依赖的系统。
技术技能在整个组织内实现了分层，而非简单的替代或消除。一个清晰的双轨体系开始形成：“超级用户”使用高层工具解决局部问题，而“专业开发者”则负责构建和维护底层的技术基础设施。
“画图”就能编程的宏大幻想（1980-90 年代）
如果说 4GL 是对编程过程的简化，那么计算机辅助软件工程（CASE）工具，则体现了对整个软件开发生命周期进行彻底改造的雄心。这是结构化设计方法论时代的顶峰，其叙事核心是将传统工程学的严谨纪律引入当时仍被视为“手艺活”的软件开发领域。
CASE 工具的终极承诺，就是“按图拉程序，编码 100% 自动化”。
这个理念听起来无懈可击：开发者不再需要直接编写代码，而是像建筑师画蓝图一样，使用上层 CASE 工具绘制出精确的实体关系图、数据流图、状态转换图等一系列复杂的模型。然后，下层 CASE 工具会读取这些完美的“蓝图”，自动生成完整、无错、高效的应用程序代码。
IBM 的 AD/Cycle 框架，Rational 公司的 Rational Rose 工具，这些当年的行业巨头，都投入了巨资推广这一愿景。它们的目标，是建立一座座“软件工厂”，将软件开发从一种充满不确定性的创造性活动，转变为一个可预测、可管理的工业化生产流程。在这个流程中，人的作用是定义模型，机器的作用是生成代码。
然而，这场声势浩大的运动，最终在很大程度上以失败告终。
这些大型 CASE 系统被证实非常昂贵、极其僵化，且使用起来困难又耗时。更致命的是，它们生成的代码往往效率低下，且无法覆盖所有复杂的业务逻辑。程序员仍然需要花费大量时间，去修补、优化自动生成的代码，并手动编写那些模型无法表达的“例外”逻辑。
这一轮失败，深刻地揭示了软件开发的内在本质。它雄辩地证明了，软件开发中最核心的困难，从来就不是编写代码这一行为本身，而是精确、完整地定义需求这一智力活动。
CASE 工具只是将开发者肩上的负担从“编写形式化、无歧义的代码”，转移到了“绘制形式化、无歧义的图表”。然而，为一个复杂的现实世界系统创建一套完美、完整且毫无二义性的图表，其认知难度甚至超过了直接编写代码。它本质上只是换了一种语法形式的编程，并没有消除最困难的部分——思考。
这场宏大幻想的破灭，让行业第一次集体认识到：软件开发的瓶颈，是认知性的，而非语法性的。
像搭积木一样编程（1990 年代）
进入 90 年代，个人计算机（PC）的浪潮席卷了全球。Windows 系统的图形界面取代了冰冷的命令行，鼠标点击成为新的交互语言。
在这样的背景下，一类全新的编程范式——快速应用开发（RAD）——横空出世，其中最耀眼的明星，莫过于微软的 Visual Basic（VB）。
VB 带来了一种革命性的体验。编程不再是面对一个漆黑的屏幕，逐行输入深奥的文本代码。取而代之的，是一个可视化的设计界面。开发者可以像搭积木一样，从工具箱里“拖拽”各种现成的控件——按钮、文本框、下拉列表——到窗体上，然后“画”出应用程序的用户界面。每一个控件都封装好了自己的行为和属性，你只需为它们编写少量的“事件处理”代码，比如“当用户点击这个按钮时，执行这段逻辑”。
VB 之父 Alan Cooper，看发量见实力
这种“所见即所得”的开发模式，极大地降低了编程门槛，并承诺能带来惊人的生产力提升。它将编程能力赋予了远超传统程序员的更广泛人群，包括企业里的技术爱好者、数据分析师，甚至一些胆大的部门经理，他们被称为“超级用户”（power users）。
VB 一经推出便大获成功，在其鼎盛时期，全球有近 350 万名 VB 开发者，数量是当时被视为“正统”的 C++ 程序员的十倍以上。
C++ 之父 Bjarne Stroustrup，看发量也能见实力
这种巨大的成功，恰好与当时企业界盛行的 IT 部门“精简规模”（downsizing）的趋势不谋而合。在许多管理者看来，既然业务部门的“超级用户”可以自己快速构建所需的应用，那么庞大而昂贵的中心化 IT 部门，似乎就显得多余和低效了。
“拖拽组件即可完工，IT 部门将被裁减”，这个论调在当时的商业杂志和管理层会议中广为流传。
然而，现实的演进再次展现了它的复杂性。RAD 工具确实赋能了新一代的开发者，让他们能够快速构建出大量的、满足部门级需求的客户端/服务器应用程序。但这并未消除对使用 C++ 等“系统级”语言的程序员的需求。恰恰相反，它在行业内创造了一种新的、清晰的分工。
一个典型的场景是：一位 VB 程序员，正在使用一个功能强大的第三方图表控件来展示销售数据。他只需几行代码就能调用这个控件，设置一些参数，一个精美的图表就呈现在用户面前。但他可能并不知道，这个小小的图表控件背后，是另一家软件公司的 C++ 程序员们，耗费了数月甚至数年的时间，去解决图形渲染的效率问题、处理复杂的坐标系转换、优化内存占用，最终才将这一切封装成一个简单易用的“黑盒子”。
行业因此被清晰地划分为两个世界：应用开发者和系统开发者。
前者使用 VB、Delphi 等 RAD 工具，站在后者的肩膀上，快速地响应业务需求，构建用户直接可见的应用；而后者，则使用 C++ 等更底层的语言，为前者打造那些可被拖拽、可被调用的高性能组件、核心算法库、数据库引擎以及操作系统本身。
程序员的角色再次被分层，而非被消除。更重要的是，RAD 的成功催生了一个繁荣的第三方组件市场。一个全新的软件产业生态和一种新的程序员专长诞生了：“为程序员服务的程序员”，或者叫“工具构建者”。他们不直接服务于最终用户，而是服务于其他程序员。
旨在简化一部分人编程工作的技术，为另一部分人开辟了一个全新的、更为复杂的专业编程领域。
世界是平的，代码是商品？（2000 年代）
21 世纪初，互联网泡沫破灭的寒意尚未散去，企业开始疯狂地削减成本。
与此同时，全球化的浪潮在宽带网络的推动下，以前所未有的速度席卷而来。在这样的背景下，第六轮“程序员替代论”登场了。这一次，它的驱动力并非来自某一项具体的技术突破，而是源于深刻的经济变革。
其核心叙事，由《纽约时报》专栏作家托马斯·弗里德曼在其畅销书《世界是平的》中得到了最经典的阐释。
弗里德曼认为，个人电脑、光纤网络和工作流软件的融合，已经“抹平了”全球的竞争场地。在这一背景下，软件开发，特别是那些被认为是常规和重复性的编码工作，成了一种可以被“外包”（Outsourcing）到全球任何最具成本效益地方的“商品”。
这一论述在 IT 行业内部催生了一种新的分工理念：将高价值的“架构设计”和“客户沟通”工作保留在美国、欧洲等发达国家（在岸），而将那些被认为是低价值的、机械的“编码实现”工作，转移到印度、中国等劳动力成本更低的国家（离岸）。
这种模式的根本驱动力是“劳动力套利”。一家美国公司在国内雇佣一名程序员的成本，可能是在印度雇佣五名程序员的成本。这种巨大的成本差异，对追求利润最大化的企业来说，具有致命的吸引力。
一种带有贬义的标签开始流传，将离岸的程序员称为“代码苦力”（code coolies），认为他们从事的是机械的、缺乏创造性的“代码搬运”工作。
“国内只需保留少数顶尖架构师，编码工作可以全部外包”，这成了当时许多企业高管深信不疑的信条。
离岸外包确实深刻地重塑了全球 IT 产业的结构。它加速了角色的分层，形成了在岸团队（架构师、项目经理、业务顾问）和离岸团队（实现、测试、维护）的合作模式。然而，它并未像恐慌者预言的那样，摧毁发达国家的编程行业。更重要的是，这个过程以一种痛苦但有效的方式，让整个行业重新认识了软件开发的本质。
项目开始出现各种意想不到的问题。由于时区差异，一个简单问题的澄清，往往需要等待一整个晚上。由于文化和语言的隔阂，在岸架构师精心设计的微妙细节，在传递给离岸团队后，常常被误解或简化。项目的失败率和意料之外的管理成本，远高于最初的乐观估计。
企业很快就认识到一个深刻的事实：在软件开发中，最关键、最难以标准化和商品化的部分，并非编码本身，而是沟通、协调和共享上下文。
一个优秀程序员的价值，远不止于他能写出没有 bug 的代码。更在于他能听懂客户话语中隐藏的真实需求，能向上级清晰地解释一个技术决策的利弊，能和同事高效地协同解决一个复杂问题。这些所谓的“软技能”，在这个全球化协作的时代，被证明是不可或缺的、处于核心地位的硬实力。它们无法被简单地打包和外包。
这一轮由经济力量驱动的“替代论”，最终并未替代程序员，而是倒逼整个行业重新评估了程序员的价值，将沟通、协作和业务理解等能力，提升到了前所未有的高度。
当业务员开始自己写“程序”（2010 年代）
进入 21 世纪的第二个十年，随着云计算和 SaaS（软件即服务）模式的成熟，那个“让终端用户自己编程”的古老梦想，以一种全新的形式高调回归。
低代码/无代码（Low-Code/No-Code, LCNC）平台，如Mendix、OutSystems 和微软的 Power Platform，成为了 4GL 和 RAD 工具承诺的现代继承者。
这一次的叙事核心，是“公民开发者”（citizen developer）的崛起。
在以 Gartner 为代表的行业研究公司的积极推动下，一种新的愿景被广泛传播：企业中那些懂业务但不懂编程的员工，现在可以利用可视化的、拖拽式的 LCNC 平台，自行构建和部署企业级应用，而几乎无需编写任何代码。
比如，市场部经理可以自己搭建一个营销活动管理应用，人力资源专员可以自己创建一个员工入职流程自动化工具。这些预测极为大胆，Gartner 曾预测，大型企业中的公民开发者数量将以 4:1 的比例超过专业开发者。
这听起来像是对专业程序员的最终围剿。如果连业务员都能自己开发应用了，那还要专业的 IT 部门和程序员做什么呢？
然而，现实的发展轨迹再次偏离了预言。
LCNC 平台并未取代专业开发者，反而成为了 IT 部门解决一个长期头痛问题的有力武器——管理“影子 IT”（Shadow IT）。
几十年来，企业中一直存在着一个现象：当业务部门有一个紧急的需求，而 IT 部门的开发排期遥遥无期时，业务人员就会用手边的一切工具来自己解决问题。其中最典型的，就是功能无比强大的 Excel。他们用 Excel 做数据管理、做项目跟踪、做复杂的财务模型，甚至用 VBA 宏语言编写出一些堪比小型软件的“怪物表格”。这些自发的“影子 IT”虽然解决了燃眉之急，但也带来了巨大的风险：数据不一致、安全漏洞、版本混乱，而且一旦创建者离职，这些“怪物表格”就成了无人能懂的“天书”。
LCNC 平台恰好提供了一个两全其美的解决方案。它为业务用户提供了比 Excel 更强大、更规范、更直观的可视化工具，让他们可以安全地“自己动手，丰衣足食”；同时，又将整个开发过程置于 IT 部门可以批准、治理和保护的统一框架之内。IT 部门可以控制数据接口、设置权限、确保合规，从而将原本混乱、无序、充满风险的自发过程，纳入到正式的管理体系中。
“公民开发者”运动的本质，并非要取代专业开发者，而是 IT 部门主动赋权，以便更好地进行治理和控制。它代表了之前所有分层趋势的最终明确化和正式化。
软件开发行业至此已经正式承认并划分出了不同层次的开发活动：“无代码”专为纯业务用户设计；“低代码”面向可以进行少量脚本编写的“超级用户”；而“专业代码”（Pro-Code）则是传统软件工程师的领域。
回到现在（AI 来了！）
第八次，也是迄今为止最极端的一轮“替代论”浪潮之中。由大语言模型（LLM）驱动的生成式人工智能，引发的叙事不再是简化或辅助，而是编码本身的终结。
它带来的冲击是具体的、可感知的。
一位程序员可能刚刚花了一个小时，吭哧吭哧写完一个复杂的正则表达式，而 ChatGPT 只用了三秒钟；另一位程序员可能正为一个算法的实现细节苦思冥想，而 GitHub Copilot 已经给出了一个近乎完美的实现方案。这种体验带来的震撼，甚至夹杂着一丝恐惧，是前面七次浪潮都无法比拟的。
这次的影响力也非同凡响。硅谷的巨擘与学者们众说纷纭，每一位都迫不及待给出了自己对 AI 编程和氛围编程（Vibe Coding）的看法。
然而，任何一位在实际工作中深度使用 AI 编程工具的工程师，都会很快触及其能力的边界。AI 生成的代码，常常缺乏对项目全局的上下文理解，它不知道这个函数背后的商业目标是什么，也无法预见这个改动可能对整个系统的其他部分产生什么连锁反应。它在创造性和设计新颖架构方面表现不佳，其能力更多是基于海量训练数据的“博闻强识”，而非真正的创新。
最严重的是，AI 生成的代码常常包含细微的逻辑错误和重大的安全漏洞，比如不安全的数据库查询、权限控制疏忽等，这些都需要人类专家进行严格的审查和修复。
最终，对产品质量、安全性和可靠性承担最终责任的，仍然是那位人类工程师。
回顾这八次浪潮，程序员的“不死”，源于一个简单而深刻的逻辑：
每一次技术浪潮都带来了一次抽象，将开发者从更底层的、更机械的劳动中解放出来。
而每一次解放，都极大地降低了软件创新的成本，从而打开了软件应用的新大陆，催生出远超以往的、更宏大、更复杂的系统性需求。
这种新需求的增长速度，永远快于生产力提升所“节省”的人力。
这是一个不断向上攀登的循环。程序员的阵地一直在变，但他们从未离开战场。
那些只会机械地将产品需求翻译成代码的“纯粹编码员”，他们的价值确实正在被 AI 迅速稀释。但软件工程师的恒久价值——深刻的业务理解、严谨的系统设计、批判性的思维能力，以及为最终结果负责的职业精神——从未像今天这样稀缺和重要。
未来，“程序员末日论”还会和幽灵一样继续徘徊，它或许会换上我们今天无法想象的新马甲。但不死的程序员们，其生命力正源于这种拥抱变化、直面挑战，并在此过程中完成自身进化的能力。
· · ·
📢 AI 产品爆发，但你的痛点解决了吗？
2025 全球产品经理大会
8 月 15–16 日
北京·威斯汀酒店
互联网大厂、AI 创业公司、ToB/ToC 实战一线的产品人
12 大专题分享，洞察趋势、拆解路径、对话未来。
立即扫码领取大会PPT
抢占 AI 产品下一波红利
（文：AI科技大本营）
