从 COBOL 到 AI：六十年了，「消灭程序员」这场梦还在做

△△微信关注"Python猫"，回复"1"领取电子书

导语： 从 COBOL 到 AI，软件行业六十年来一次次放言"消灭程序员"，又一次次落空。本文梳理了这段历史，几个要点值得关注：

1. 1. COBOL 的设计初衷是让业务经理自己写程序——结果它成了最长青的程序员就业制造机
2. 2. METR 实验室研究发现，有经验的开发者用 AI 后反而慢了 19%，却仍坚称自己快了 20%
3. 3. 真正不可替代的从来不是"写代码"，而是理解需求、做出权衡、维护长期演化的能力

无论你是否焦虑"被 AI 取代"，这篇文章都值得一读。

回顾软件行业的历史，有一个模式以惊人的一致性反复出现：号称能简化软件开发、降低成本，最终消灭对程序员的需求。这绝非新鲜事——自 1960 年代以来，它一直是驱动整个行业前进的野心。每一代人都以为自己在见证史无前例的变革，但实际上，他们不过是在重演一场已经循环了六十多年的老剧本。

今天，当 AI 智能体自动编程时，我们又听到了那些熟悉的论调：编程即将终结，软件开发将被"民主化"，很快任何人都能构建复杂系统，一行代码都不用写。这些说法值得审视，因为它们和 1959 年、1973 年、1985 年、2015 年的那些豪言如出一辙。想看清现状、预判未来？这段历史就绕不过去。

一切的缘起：COBOL 与「业务人员也能编程」之梦

故事始于 1950 年代末。那时编程是真正的玄学——程序员写汇编语言或机器码，直接操作寄存器和内存地址。这项工作要求深厚的技术功底，开发速度慢得让人绝望。企业迫切需要软件，但懂业务的人不懂计算机，懂计算机的人又不懂业务。

于是 Grace Hopper 和 CODASYL 委员会登场了。1959 年，他们创造了 COBOL（通用商业语言）。其目标明确且具有革命性：创造一种和英语如此接近的编程语言，让业务经理不仅能读懂，最终还能自己写程序。COBOL 的语法刻意设计得冗长直白——用 MOVE、ADD、MULTIPLY、PERFORM 这样的单词代替晦涩的符号，一段程序读起来几乎像一份行政备忘录。

当时的宣传口径十分明确：COBOL 将打破专业程序员的瓶颈。业务分析师将亲自编写程序。技术专家的"技术壁垒"将被打破。软件开发将走向民主化。

然而事与愿违。

作为一种编程语言，COBOL 取得了惊人的成功。它成为全球银行、保险和政府系统的支柱。至今仍有数十亿行 COBOL 代码在运行，处理着数万亿美元的交易。但 COBOL 并没有消灭程序员。相反，它创造了一个全新的职业——COBOL 程序员。语言确实可读了，但写出正确、高效、可维护的 COBOL 程序，仍然需要专业技能、对底层系统的深刻理解和多年经验。

讽刺之深，令人莞尔。一门旨在消灭程序员需求的语言，反而成了计算机史上最长青的就业创造机器。 如今，COBOL 程序员之所以供不应求，恰恰是因为学这门语言的人太少，而他们维护的系统又太关键，无法轻易替换。

第一次 AI 寒冬：专家系统与 1970 年代的狂热周期

今天大谈 AI 的人，多数似乎忘了我们早就经历过这一切。1960 年代和 1970 年代初，对人工智能的乐观情绪曾一度爆棚，以至于当下来看当时的预言都显得保守。

1965 年，AI 研究的奠基人之一赫伯特·西蒙（Herbert Simon）预测，二十年内机器将能胜任人类所能做的任何工作。1967 年，另一位 AI 先驱马文·明斯基（Marvin Minsky）预测，在一代人时间内，创造人工智能的问题将基本得到解决。资金如潮水般涌入。政府机构——尤其是美国的 DARPA——对 AI 研究投入了巨资。

这对软件开发意味着彻底的颠覆。如果机器能思考，它们当然也能自己编程。研究人员致力于"自动编程"——将自然语言规格说明直接转化为可工作代码的系统。专家系统（Expert Systems）号称能将人类专家的知识编码到基于规则的引擎中，无需人工干预就能做出决策、解决问题。

愿景令人神往：用普通英语描述你想要的，计算机自己琢磨怎么实现。编程变成了写规格说明，而写规格说明变成了对话。

然而到了 1970 年代中期，现实给了所有人一盆冷水。 1973 年的 Lighthill 报告系统性地揭露了 AI 豪言与成果之间的巨大鸿沟，直接扼杀了英国的 AI 资金。报告指出，早期在狭窄领域的成功制造了不切实际的期望——在玩具问题上运转良好的系统，到了真实世界的复杂性面前全面溃败。组合爆炸的可能性耗尽了当时的所有计算资源。

随之而来的便是第一次"AI 寒冬"。资金断崖式下跌，研究项目被取消。在某些圈子里，"人工智能"这个词甚至成了耻辱。研究人员纷纷将自己的工作重新包装为"专家系统""知识工程"或"计算智能"，以此与声名狼藉的炒作划清界限。

那个教训本应足够清晰：将人类意图转化为可工作的软件，这件事本质上极其困难。 自然语言描述与正确实现之间的鸿沟，不是一个等待解决的技术问题，而是一个反映人类沟通与软件复杂性之深层真相的概念性挑战。

第四代语言：1980 年代的豪言

到了 1980 年代初，新的希望出现了：第四代语言（4GL）。推理听起来相当诱人——汇编语言是第一代，FORTRAN 和 COBOL 是第二代，Pascal 和 C 等结构化语言是第三代。第四代将抽象掉更多复杂性，让非程序员通过高层声明而非过程式代码来创建应用程序。

FOCUS、NOMAD、Ramis，以及后来的 PowerBuilder 和 Microsoft Access，纷纷号称要革新软件开发。用户无需编写代码，只需定义数据结构、指定业务规则、通过图形界面设计界面——底层代码会自动生成。

当时的营销材料与今天无代码平台的宣传惊人地相似：终端用户将自行构建应用，IT 部门从瓶颈变成使能者，开发时间缩短到原来的十分之一。

4GL 在特定领域确实取得了真正的成功。报表生成、简单数据库应用和部门级工具在这些技术的加持下得以更快交付。特别是 Microsoft Access，让数百万用户无需传统编程就能创建功能应用。

但那个根本性的豪言再次落空了。复杂应用仍然需要复杂思维。 当业务逻辑变得错综复杂，当性能变得至关重要，当系统需要与其他系统集成时，4GL 的局限性暴露无遗。生成的代码往往效率低下，定制困难重重。而且，最精通 4GL 的用户不是业务分析师，而是那些既懂工具又懂底层原理的专业开发人员。

历史再次重演：号称消灭程序员，结果只是创造了新的编程工种。

CASE 工具与「大教堂建造者」

1980 年代末到 1990 年代初，计算机辅助软件工程（CASE）工具兴起。其愿景宏大而全面：用图表和规格说明对你的整个系统建模，工具就能生成完整、可运行的应用程序。

企业在 CASE 工具套件上投入数百万美元，行业会议纷纷召开，方法学层出不穷。其口号是：软件工程终将成为"真正的工程"——结果可预测、过程可重复、代码由规格说明自动生成。

作者回忆道：咨询师带着庞大的数据字典和实体关系图登门造访，项目在建模阶段一耗就是数月，产出精美的文档，号称捕捉了一切需求和设计决策。随后，代码生成阶段会将这些模型转化为可运作的系统。

现实令人失望。 生成的代码通常臃肿低效，模型在需求变更时难以维护，而根本问题依然如故：把规格说明写对，至少和直接写代码一样难。那些图表和模型不过是另一种编程语言——只不过用方框和箭头代替了文字。

到 1990 年代中期，CASE 工具基本退出主流舞台。部分概念在 Rational Rose 等面向对象分析与设计工具中得以延续，但从规格说明自动生成代码的宏大愿景已被证明是空中楼阁。

第二次 AI 浪潮：专家系统卷土重来

1980 年代还见证了 AI 的第二波热潮，焦点是专家系统。Inference 公司、Intellicorp、Teknowledge 等企业号称能将人类专业能力编码进基于规则的系统，使其能像人类专家一样做出决策。

应用场景颇有说服力：医疗诊断、金融分析、设备配置，当然还有——自动编程。DEC（数字设备公司）的 R1/XCON 系统确实取得了真正的成功，通过自动配置计算机系统为公司节省了数百万美元。

日本于 1982 年启动的第五代计算机项目投入了巨额政府资金，目标是创建能用逻辑编程进行推理的计算机。其明确意图是超越西方技术，制造能够理解自然语言、实现自动编程和人工智能的机器。

到 1990 年，第五代计算机项目基本宣告失败。 专家系统暴露了脆弱性——一旦遇到超出其狭窄专业范围的情形，就会以意想不到的方式崩溃。随着系统规模增长，规则库的维护变得愈发困难。而最根本的挑战——知识获取，即让人类专家以机器可用的形式表达其知识——被证明远比预想中艰难。

第二次 AI 寒冬降临于 1990 年代初。资金再次崩溃，研究人员再次重新包装自己的工作。机器自我编程的根本宏愿再次退向遥远的未来。

互联网时代：Web 开发与民主化之梦

1990 年代中期，万维网登场，带来了简化软件开发的新希望。HTML 号称简单到人人都能建网页。而事实上，数百万人的确用一台文本编辑器和一些热情就学会了创建基础网站。

但 Web 迅速变得愈发复杂。 JavaScript 带来了交互性，CSS 带来了样式，服务端编程变成了必需，数据库撑起了内容，安全成了生死线，性能成了竞争焦点。

行业的回应一如既往：新的工具号称能简化 Web 开发。Dreamweaver、FrontPage，以及后来的 WordPress 和 Wix，都保证不用写代码就能建专业网站。内容管理系统将复杂性抽象掉。

这些工具成功地让非开发者也拥有了基础的线上展示能力。但专业 Web 开发没有简化，反而更复杂了。单页应用、移动优先设计、渐进式 Web 应用以及现代 JavaScript 生态的兴起，创造了新的复杂性层次，也创造了新的专业分工。

熟悉的模式再次浮现：简化了基础任务的工具，使得更有野心的项目成为可能；更有野心的项目又要求更高级的技能，进而催生了对更专业开发者的需求。

模型驱动架构与 UML 之梦

2000 年代初，模型驱动架构（MDA）再次尝试自动代码生成。对象管理组织（OMG）提出，平台无关的模型可以通过自动化工具转换为平台特定的实现。

统一建模语言（UML）成为标准符号。Rational Rose、Together 和 Enterprise Architect 等工具号称能从 UML 图生成完整应用。愿景是老配方了：在高层抽象上为系统建模，让工具处理实现细节。

MDA 在特定领域取得了一些成功——尤其是在从模型到代码的映射已被充分理解和生成的代码无需大量定制的场景。但对大多数应用而言，这条路走得太艰难了。保持模型与代码的同步令人头疼，而模型自身也变得复杂，需要专门技能来创建和维护。

到 2010 年代，MDA 已从主流实践中淡出，尽管其理念仍在现代代码生成和领域特定语言中留有痕迹。

无代码与低代码的复兴

大约从 2015 年起，新一代无代码和低代码平台陆续登场。Bubble、Webflow、Airtable、Zapier、Microsoft Power Platform 等产品号称让"公民开发者"通过可视化界面和拖拽组件来构建应用。

营销话术与每一代前辈如出一辙：业务用户将自行构建应用，IT 积压工作将消失，数字化转型将加速。程序员将被淘汰，或至少远不像现在这样不可或缺。

无代码工具在自己的主战场上取得了真正的成功。简单应用、工作流自动化、基础网站和内部工具在这些平台上确实比传统开发更快。对某些问题类别而言，它们是真正的进步。

但历史规律再次重演。复杂应用仍然需要复杂思维。 当需求超出平台能力范围，用户便会撞上高墙。与现有系统的集成常常困难重重，规模下的性能充满挑战。而且，最精通无代码平台的用户，往往是那些理解底层原理的前开发者。

更重要的是，无代码并没有减少对传统开发者的需求。恰恰相反——数字应用的大爆发反而推高了需求。即使在无代码平台遍地开花的今天，软件开发者市场仍在持续增长。

大语言模型：当下的浪潮

这把我们带到了当下。GPT-4、Claude、Gemini 等大模型能从自然语言描述中生成可运行的代码。GitHub Copilot 及类似工具实时辅助开发者，提供补全建议、生成样板代码。这些进步是真实且令人印象深刻的。

正如预料的那样，大胆的预言随之而至：编程岗位将大量消亡，软件开发将被民主化，任何人只需用普通英语描述自己想要的，就能构建复杂系统。

这些论调我们早就听过了。 1959 年，伴随着 COBOL。1973 年，伴随着专家系统。1985 年，伴随着 4GL。1995 年，伴随着 CASE 工具。2015 年，伴随着无代码。

这并不意味着当前浪潮与以往完全相同。大语言模型确实代表了能力上的真正突破。 它们能完成先前技术无法胜任的任务，生成的代码往往正确且实用，对熟练开发者的生产力提升也是实实在在的。

但那个根本性的挑战并未改变：将人类意图转化为正确、高效、可维护、安全的软件，这件事本身就是难的。 不是因为工具不够好，而是因为问题的本质就是复杂的。

为什么这些豪言总是落空

要理解为何每一波简化工具的豪言都不尽如人意，我们必须审视软件开发的本质。

软件不只是代码，它是对所有可能条件下系统行为的精确规约。 当你说"我要一个简单的电商应用"，你其实已经在隐含地制定了成千上万个决策——用户认证、支付处理、库存管理、运费计算、税务处理、错误恢复、可访问性、高负载性能、安全防护。这些决策的绝大多数，并不会从一个高层描述中自然浮现。

软件开发最难的部分从来不是敲击代码。最难的一直是搞清楚软件到底应该做什么，并确保它在所有情况下真的做到了。 这就是为什么规格说明语言和自动代码生成反复未能消灭程序员：它们不过是将复杂性从代码转移到了规格说明上，而写对规格说明，至少和写对代码一样困难。

进一步看，软件生存在一个生态系统中。它必须与其他软件集成、适应不断变化的需求、在持续演进的平台上运行、服务需求持续漂移的用户。长期维护和演化软件所需的理解力，超越了任何规格说明语言或生成工具所能提供的范畴。

最后，软件反映了人类对权衡取舍的决策——性能还是可维护性，安全还是易用性，灵活还是简单。这些决策需要判断力，而判断力无法自动化，因为它依赖上下文、优先级和价值观，而这些因素因场景而异。

什么被真正改变了

每一波简化工具确实改变了一些真实的东西——只是并非营销人员所鼓吹的那些。

COBOL 没有消灭程序员，但它确实让商业编程更加可及，并创造了一个庞大的产业。4GL 没有取代传统语言，但它们确实使某些类别的应用得以快速开发。无代码平台也没有让开发者变成多余的人，但它们确实赋予非开发者创建有用工具的能力。

规律是一致的：新工具降低了简单任务的准入门槛，从而增加了正在创建的软件总量，进而创造了对更复杂软件的需求，最终创造了对更高阶开发者的需求。

这不是失败，而是技术演进的真实方式。每一层抽象都能催生新的能力，每一次简化都能激发新的雄心。总体效果是积极的，哪怕具体的预测被证明是错误的。

从历史中学到的

当我们在当前 AI 驱动的开发工具浪潮中摸索前行时，这段历史能给我们什么启示？

第一，对极端预测保持怀疑是有充分历史依据的。 "几年之内编程将消亡"的论断，与过去每一个十年中回响的断言如出一辙。历史规律告诉我们，这类预测总是高估了变革的速度，低估了挑战的复杂性。

第二，真正的进步是真实存在的。 大语言模型确实提升了开发者的生产力，确实让某些任务变得更容易。因为以往的炒作周期失败了就全盘否定这些进步，跟不加批判地全盘接受最极端的预测一样错误。

第三，编程工作的性质将持续演变。 就像 COBOL 程序员做的工作不同于汇编语言程序员，Web 开发者做的工作不同于 COBOL 程序员一样，未来的开发者将做着不同于当前开发者的工作。工作会变，但不会消失。

第四，人类技能始终不可或缺。 理解需求、做出设计决策、调试意外行为、长期维护系统、与利益相关方沟通——这些技能在每一波自动化浪潮中都未被替代。随着工具承担更多例行工作，这些技能的重要性只增不减。

第五，能繁荣发展的开发者是那些善于使用新工具，同时保持对底层原理深刻理解的人。 工具来来去去，但算法、数据结构、系统设计和软件架构的基本知识跨越世代，价值不减。

理解力的永恒价值

或许，这六十多年来不断被反复鼓吹的"简化"所传递的最重要一课是：没有什么能替代真正的理解。

每一个成功的 COBOL 应用，都需要对业务流程和数据管理的深刻理解。每一个成功的 4GL 应用，都需要对数据库和应用架构的深刻理解。每一个成功的无代码应用，都需要对工作流设计和系统集成的深刻理解。而每一个成功的 AI 代码生成应用，都需要对软件原理、代码质量和系统设计的深刻理解。

工具会变，语言会变，平台会变。但对那些深入理解自己在构建什么、以及为什么这样构建的人的需求，始终未变。

这不是系统的 bug，而是反映了软件本质和问题解决本质的某些根本特性。软件是思想的结晶，创造好的软件需要好的思维。没有任何工具能够替代这一点。

以清醒之眼面向未来

展望未来，软件简化的历史提供了一个宝贵的视角。我们应当预期 AI 工具变得更强，应当预期新的革命性豪言不断涌现，也应当预期其中一些豪言会以出人意料的方式兑现，而另一些则会在炒作过后黯淡退场。

最重要的是，我们应当预期那个根本性的挑战始终存在：在一个需求持续变化、系统必须复杂协同的世界里，构建出真正满足人们需要的、可靠、高效且安全的软件。

这一挑战从来就不是关于敲代码有多难。它一直是关于清晰思考有多难、精确沟通有多难、在不确定条件下做出正确决策有多难。这些都是人类独有的技能，只要软件依然重要，它们就依然有价值。

未来的程序员可能会少写直接代码，可能在更抽象层次上工作，可能使用我们现在无法想象的工具。但他们仍将从事那项核心工作：将人类意图转化为真正能运转的软件。 这项工作将继续要求技能、判断力和理解力——至今没有任何工具能替代这些。

历史告诉我们，关于"编程之死"的报道，六十多年来一直被严重夸大，且反复如此。 没有理由相信这一次本质上有什么不同，却有充分的理由相信：那些持续投资于深度理解的人，无论新工具如何涌现，都将始终葆有价值。