这一消息引发了技术圈的热议。要知道，作为一门“上古”编程语言，COBOL 虽然并非不可替代，但是其在银行、保险、政府机构等大型业务系统中依然广泛使用。如今 DOGE 计划在短短几个月内完成迁移遗留代码，这也让众人好奇它究竟如何能完成？莫不是想要靠着 Grok 这样的 AI 大模型？
超 6000 万行代码，外媒：DOGE 计划几个月内迁移完成
众所周知，COBOL 诞生于 20 世纪 50 年代末，它的起源可以追溯到美国国防部主导的一个项目，旨在开发一种通用的、高度可读的编程语言，以用于政府和企业的数据处理任务。彼时，随着美国国防部和大型企业的推广，COBOL 迅速成为商业计算的标准语言之一。
时至今日，这门语言依然活跃在上述提及的多个应用中，甚至在本月它还闯进了 TIOBE TOP 20 之列，位居第 20 位。
《连线》报道称，截至 2016 年，SSA 的软件系统中包含超过 6000 万行 COBOL 代码，并且还有数百万行其他遗留编程语言编写的代码。
此外，SSA 软件的“核心逻辑”部分也是用 COBOL 编写的，这部分代码负责颁发社会保障号码、管理支付、计算受益人应获得的总金额等关键任务。
对于政府机构使用的系统及软件，其实鲜少会升级，以防影响日常业务处理，SSA 内部亦是如此。回看 SSA 代码库上一次重大迭代升级还要追溯到 20 世纪 80 年代，当时该机构引入了一个名为 MADAM 的数据库。该数据库不仅采用 COBOL 编写，还使用了汇编语言。
多年来，随着现代编程语言的崛起，COBOL 程序员日渐稀缺，且 COBOL 程序多为单体架构，难以适应云计算、微服务、API 等现代技术趋势，不少人也想过尽早替换掉 COBOL 这样的过时语言，然而，实际实施的难度极高，毕竟如今已有的 COBOL 系统运行数十年，代码庞大、文档缺失，原开发人员大多已退休，导致维护和升级极具挑战性。此外，不少 COBOL 应用依赖专有数据库。
一位曾在 SSA 首席信息官办公室工作的前高级技术专家表示，即便是对这些代码的微小调整，也可能引发系统级的连锁故障。
话虽如此，2017 年，SSA 还是做了一份 97 页的 PDF 文档（https://www.ssa.gov/open/materials/IT-Modernization-Plan.pdf），想要将内部系统进行现代 IT 升级改造，其中就提到过要将用数亿美元的资金来更换其核心系统，包括一些 COBOL 旧代码的改造。彼时该机构预测，这些系统的现代化大约需要五年时间。只不过，由于 2020 年“黑天鹅”事件的影响，该机构放弃了这项工作，转而专注于更多面向公众的项目。
可是随着 DOGE 对 SSA 调查的深入，他们也发现 COBOL 旧代码带来的遗留问题似乎到了不得不解决的时刻。
此前，我们曾报道过，DOGE 团队就掉入过 COBOL 代码的“坑”中。其中，马斯克自去年 11 月接手 DOGE 部门后，大刀阔斧地改革政府机构，目标是削减开支。而在一次检查中，DOGE 团队竟然发现社会保障系统里居然还有“150 岁”的人在领福利。马斯克调侃道：“你认识 150 岁的人吗？反正我没见过。如果他们真活着，早就该进吉尼斯世界纪录了。”
然而，技术专家很快指出，这可能并不是什么惊天骗局，而是 COBOL 这门“上古编程语言”惹的祸。不少技术人认为，早期 COBOL 版本在处理缺失的出生日期时，默认会填上 1875 年 5 月 20 日，并用这个日期作为计算基准。换句话说，如果某人的出生日期缺失，系统就会自动认定他“出生于 1875 年”，也就是“150 岁”。
由此被 DOGE 误以为“150 岁的人还在领取保障金”。而之所以会产生这场闹剧，很多人将其归咎于 DOGE 年轻的技术团队对 COBOL 语言不够了解导致。或许也是眼看着 COBOL 旧代码已经成了政府效率的绊脚石，DOGE 这才有了“急着换掉社保系统”的心思。
借助 AI 来完成？
据《连线》透露，DOGE 已经开始组建团队，该项目由埃隆·马斯克的亲信史蒂夫·戴维斯（Steve Davis）组织。他曾是 SpaceX 的早期员工，近期被《纽约时报》称其为 DOGE 的实际负责人。目前，据说至少有 10 名 DOGE 员工在 SSA 工作。
不过，具体的迁移计划何时启动还不清楚。据报道，SSA 最近给员工发了一份内部文件，列出了 5 月前的重点任务，但里面并没有提到这次迁移，而是更关注削减“非必要合同”，以及引入 AI 来优化行政和技术文档处理等。
有消息人士透露，DOGE 的首要任务是改进社保福利的在线身份验证系统。SSA 内部人士预计，一旦他们完成身份核查，并把分散的政府数据库整合起来，迁移项目就会正式启动。
事实上，项目启动倒也没什么，真正让人担心的是 DOGE 计划在几个月时间内完成项目迁移。
SSA 前技术专家指出，仅 DOGE 计划的 COBOL 重写项目的测试阶段就需要数年时间。而如果在几个月内完成整个迁移，DOGE 的开发人员可能会跳过关键的质量保证环节，从而增加技术风险。
也有技术专家警告说，即使在最理想的情况下，完成如此大规模的系统迁移也极具挑战。而现在匆忙推进，可能会导致超过 6500 万人的社保福利发放出现问题。
“一旦系统出错，不仅仅是有人收到的钱不对，更可怕的是，可能有人根本收不到款项，而我们甚至意识不到。”一位 SSA 技术专家说道。
《连线》报道称，知情人士透露，如果想在几个月内完成 COBOL 代码的迁移，DOGE 可能要依赖生成式 AI，把数百万行代码自动翻译成现代语言。一位 SSA 技术专家表示：“DOGE 的想法是，如果他们能在几个月内清理掉所有 COBOL 代码，那就说明他们是对的，而我们这些没敢‘乱搞’的人就是废物。”
“SSA 的 IT 系统就像是用铁丝和胶带拼起来的。”一位曾在 SSA 首席信息官办公室工作的前技术专家告诉《连线》，“领导层得明白，他们面对的是一座‘纸牌屋’或者一局‘叠叠乐’。如果他们开始随便抽掉某些关键部分——而他们已经打算这么做了——整个系统可能会崩盘。”
重写 COBOL 代码难度如何，多位开发者现身说法
这样的担忧并非空穴来风，不少技术专家在听闻此消息后纷纷现身分享自己编写和维护 COBOL 代码的经历，其中 @Skytooeen 表示：
我曾在多年前担任项目经理，为我的雇主——一家财富 50 强公司——负责一个迁移项目，目标是摆脱我们的主机系统。当时的 COBOL 代码规模与这次的差不多。我可以告诉你，这绝对不可能在三个月内完成，不管有没有 AI。
从集中式系统迁移到分布式系统，会遇到各种问题和复杂情况，比如竞态条件（race conditions）、批处理与流处理的差异、完全不同的应用间通信方式等。而 COBOL 本身也是一门难搞的语言，里面有许多其他语言没有的“坑”。
最理想的情况是，他们在尝试折腾新系统的同时，仍然保持旧系统的正常运行。最糟糕的情况则是，他们在没有彻底测试新系统的情况下，就开始关闭旧系统的部分（甚至整个系统），然后直接“在生产环境中测试”。考虑到马斯克的风格，我实在不抱太大希望。
另一位开发者 walnut close 现身评论道：
我在企业平台迁移方面有 30 年的经验，既从系统供应商的角度参与过，也曾作为企业 IT 架构师和高管负责相关工作。我可以毫不夸张地说，从服务交付、一致性、安全性和业务连续性的角度来看，这次迁移注定会失败。
系统和编程语言的选择确实重要，但它们本身并不是决定成败的关键，甚至通常都不是最主要的因素。架构设计、项目管理、测试、范围和质量控制、过渡与上线规划……这些才是影响成败的核心。而现在这些家伙谈论的那些技术问题，远远没有这些因素重要。选错技术确实会毁掉一个项目，但光是选对技术，绝对无法保证项目成功。
还有——这一点我必须强调——即使他们在技术、架构和项目管理上做得滴水不漏，也不会因此减少欺诈和错误，除非他们真正理解欺诈和错误的来源，并在项目需求中明确设计出检测和纠正机制。COBOL 既不是欺诈的根源，也不会天然导致系统性错误。而 DOGE 至今没有拿出任何有说服力的欺诈证据，甚至连系统性错误的实际问题都几乎没找到，所以在这方面，他们注定也要失败。
这让我想起过去那些由大型咨询公司主导的企业级系统迁移灾难——只是这次的规模被无限放大了。唯一的区别是，这次涉及的金额高达数万亿美元，影响范围遍及整个国家，而负责这个项目的“专家”对他们要替换的系统几乎一无所知，这种错配的程度，比以往任何一次大型企业咨询灾难都要严重几个数量级。
不仅如此，开发者 Lemon640 此前在深入研究 COBOL 后尝试升级自家的旧项目，但现实却给了他当头一棒。他直言：“我遇到了难以逾越的障碍。” 以下是他列举的一些严重问题：
1. 真实 COBOL 代码的复杂性远超预期
Lemon640 称，自己最初接触的 COBOL 代码仅限于入门级教材中的“玩具”版本，而实际应用中的 COBOL 代码与任何标准（包括 1985/2002 版本）都存在巨大差异。这些差异并非源于对新标准的遵循或现代编程实践的引入，而是由于长期积累的各种自定义扩展。统一不同版本的 COBOL 代码到一个通用转换目标语言，几乎是不可能完成的任务，尤其是当关键字、语法结构（如 PICTURE 句法）被广泛修改，甚至引入了全新的关键字和数据类型时。
2. COBOL 生态系统鼓励通过修改语言本身来扩展功能
与现代编程语言主要依赖库或模块来扩展能力不同，COBOL 生态更倾向于直接修改语言，引入新的动词或 PICTURE 类型。这种做法导致在构建兼容的目标语言时，必须考虑如何处理大量的自定义扩展，而相比之下，现代语言通常通过库、函数和内置数据类型实现类似功能，以确保更好的可维护性。
3. 函数和子程序调用机制极其混乱
在 COBOL 中，变量是按值传递或按引用传递并非由函数定义决定，而是由调用位置决定。这意味着，一个接受 4 个参数的函数，实际上可能有 16 种不同的调用方式。
函数调用时没有类型检查，甚至连参数大小都不验证。这就好比 JavaScript 或 PHP 的弱类型机制，但实际上更类似于 FORTH——调用者只是将数据填充到一段原始内存中，而被调用的函数则随意解释这段内存内容。如果调用者和被调用者的理解不一致，程序就会崩溃。
默认情况下，局部变量是持久化的，除非手动使用 CLEAR 语句清除状态，这意味着所有函数默认都是有状态的，并且数据全局可见。
4. 程序的控制流设计极其落后
GOTO 仍然广泛存在，令人堪忧。
PERFORM THRU 语句的存在，使得程序逻辑混乱不堪。
ALTER 语句允许动态修改代码逻辑，导致代码的可维护性极差。
5. COBOL 语言的动词设计极为复杂
COBOL 的核心动词（如 UNSTRING）的行为可能根据使用方式的不同而发生变化，且返回结果会直接修改变量，而不是通过返回值的方式处理。
由于 COBOL 语言本身缺乏良好的函数调用机制，因此大量复杂功能被塞进了动词系统中，导致解析和转换难度陡增。
6. COBOL 的数据结构设计混乱
尽管 PICTURE 句法的基本设计勉强可以接受（尤其是对十进制数的支持），但字符串处理方式已完全过时。
由于 COBOL 早期是基于字符串存储所有数据的，其复合类型（Group 数据项）非常原始，远远无法与现代编程语言的结构体或对象系统相比。
正因此，Lemon640 认为，“这一切仍然是一个巨大的技术债务问题——COBOL 代码本身的问题只是表象，真正最大的技术债务，是那些深埋在 COBOL 代码中的业务逻辑和知识体系，它们仍然难以访问、难以理解、难以变更。”
最后，尽管不少人推荐 IBM 早前推出的 watsonx Code Assistant for Z，这一生成式 AI 工具能够将 COBOL 代码重构为 Java，以加速 COBOL 应用现代化，但它仍只是整体解决方案的一部分。
同时，也有人设想马斯克可能会对 AI 说：“Grok，我需要你非常努力，为我编写一个新的 SSA 系统。” 然而，现实是这样的任务远非几个月内能够完成，重写代码也绝非“发射火箭”那么快。
真正的现代化进程，仍依赖于技术积累、系统设计与长期优化的协同推进。
参考：
https://www.reddit.com/r/programminghorror/comments/1jlwbyj/doge_moving_ssa_from_cobol_to_java/
https://www.reddit.com/r/cobol/comments/10kqonw/i_tried_upgrading_cobol_heres_what_happened/
https://www.wired.com/story/doge-rebuild-social-security-administration-cobol-benefits/
https://arstechnica.com/tech-policy/2025/03/what-could-possibly-go-wrong-doge-to-rapidly-rebuild-social-security-codebase/