马斯克“查账”曝 150 岁老人领福利，竟是 COBOL 惹的祸？

最近，马斯克表示他领导的“政府效率部”（DOGE）查账时发现了一些很离谱的事：比如美国财政部每年给一群连身份都说不清的人发了 1000 多亿美元的福利金，他看到的记录里，有大约 150 岁的人。

对此，马斯克不无嘲讽地表示：“有些事情太荒谬了。比如，只是粗略检查了一下社会保障系统，就发现里面有些人的年龄大约 150 岁。你认识 150 岁的人吗？我不认识。他们要么早该被列入吉尼斯世界纪录，却错过了机会；要么，我猜他们已经去世了。总之，肯定有问题。”

马斯克在说这些话时，他的表情是一脸的不可思议，而原本认真倾听的特朗普，也是忍不住笑了出来。

这是个编程问题吗？

美国媒体事实核查员表示，他们无法证实或否认马斯克的说法，但也指出他们目前“没有发现任何 150 岁老人申领福利的具体证据。”

有不少人对马斯克的说法表示怀疑，还有人给出了一种既简单又搞笑的解释：据说马斯克的 DOGE 团队成员都很年轻，但这些年轻人可能不知道，美国社会保障系统用的是非常老旧的计算机，而这些计算机运行的是古老版本的编程语言 COBOL。1875 年 5 月 20 日，一些国家成立了国际度量衡局，制定了统一的质量和长度标准。后来，该机构也制定了日期标准，并以 1875 年 5 月 20 日作为起始日期，以纪念这一历史事件。老版本的 COBOL 就采用了这个日期作为基准。美国社会保障系统的计算机沿用了这种设计。

那么，如果社会保障系统中某人的出生日期未知，会发生什么情况呢？那一栏就会是空的，而系统会默认这个人出生于 1875 年 5 月 20 日——也就是大约 150 年前。这正是马斯克团队发现 “150 岁老人” 的原因。

于是，围绕着这是否是编程语言导致的 bug，大家展开了激烈讨论，各方说法不一。有自称是 COBOL 程序员认为这就是由于 COBOL 缺少出生日期导致的。

我是一个老程序员，用今天的说法就是“Coder”。许多老程序员都知道 COBOL，而年轻的编程人员则不太了解。我觉得应该有人告诉马斯克，在 COBOL 中，如果缺少日期，程序会默认使用 1875 年。例如，2025 - 1875 = 150。

是真的，因为我的公司在 COBOL 系统上工作，当客户没有日期时，它就是 1875。

但还是有更多程序员不断提出质疑，主要是大家找不到任何能够支持这一结论的技术资料。毕竟大家见过的默认日期主要是 1970-01-01，甚至也有程序员指出 COBOL 并不使用 ISO 8601 日期格式。

我见过的唯一默认日期是 1970-01-01，这是 Unix 时间中的 0 点，肯定早于 ISO 8601 的制定。上个月我在看 Brian Goetz （甲骨文公司的 Java 语言架构师）的演讲时还在思考默认日期的问题，但他并未提到 1875 年。我觉得 1875 年这个说法是胡编乱造的。

我曾在 COBOL 系统上工作过......COBOL 不使用 ISO 8601 日期格式。

大家莫衷一是，密歇根大学经济学教授 Justin Wolfers 从统计学角度指出，确认这个问题并不需要成为一名程序员，只需输入：tab age，你会发现有一些 99 岁的人，少数 100 岁的人，几位 101 岁的人，以及一堆 150 岁的人，但没有人在 130 岁或 140 岁之间。这至少清楚地表明，这是一个编码问题，而不是欺诈行为。

如果确实是一个编程问题，而且 COBOL 不使用 ISO 8601 日期格式，那还有什么其他原因可能导致这个现象的出现呢？

昨天，有一名“年轻程序员”在 StackExchange 上发出了灵魂提问：“是否有确凿证据表明，COBOL 规范或者实现在以这种方式运行？如果没有，那是否存在某些与 COBOL 相关的软件（例如 DBMS）能够解决这种默认设置？”这个问题的最佳答案给出了一个不一样的解释：1875 年作为日期基准的起源并非技术规范要求，而是基于社会保障制度的实施时间（1935 年）结合存储优化需求设计的经验性方案，它体现的是早期程序员在硬件限制下"空间换逻辑"的设计哲学。

简单的说，这取决于具体要记录什么样的数据。

 

曾有一段时间，数据结构是为了满足特定目标而制作，并非围绕编译器特性。通过下面的描述，可以清晰地看到有效日期的限制条件：社保制度于 1935 年推出。要想领取福利，必须满足以下条件：至少支付 40 个季度，即 10 年；年龄至少为 65 岁。这意味着，第一批定期领取社会保障金的人群是 1945 年时 65 岁的群体，也就是 1880 年出生的人。而 1880 年之前出生的人不符合条件，因为他们的年龄太大，大多数因未缴纳足够年限的社保而无法享受政策。而年龄较小的人（即仍在支付社保的人群）将在未来退休时享受待遇。因此，考虑到 5 年的容错空间，我们最终将 1875 年定为最早的年份起点。这个日期区间的判断过程看起来是相当合理的，对吧？

 

所以从严格意义上讲，这并不是 COBOL 的问题，而是为了适应任务数据。当然，这样的细节很难与公众沟通。所以既然 COBOL（包括汇编语言）程序中确实经常出现这类问题，那么将其归咎于语言本身也没啥大问题。毕竟这种编程方式在 COBOL 中算是一种良好实践，当时就这要求。

 

那么，COBOL 是否会将损坏或缺失的日期默认设置为 1875-05-20？并不会，而且这事的核心其实在于如何优化数据存储。这是一种如今几乎失传的手艺，毕竟如今的程序员们会使用最强大的类型来处理所有事务（例如用 float 来存储 bool）。那时人们不仅关心过程逻辑，还需要关心代码和数据的最佳实现。

 

当然，人们会用 1875-05-20 是《米制公约》的签署日期还有这是“老程序员们”的独到智慧来强行解释，但这只是对结果的解释、而非根本原因。事实上，这完全只是个随意取值的巧合，随机碰上了《米制公约》的签署日。

 

哪怕找不到任何技术资料来支持这个说法，相信有经验的程序员也很清楚，根据某些固定点来确定日期是种常见做法。毕竟所有日历系统都要设定这样一个锚点，比如公元 1 年；或者以 Unix 为例，其日历以 1970 年作为基准。这项技术标准中从来就没明确提到过 1975 年的意义，而且我也不是唯一持这种“随机取值”观点的人。毕竟 1875 年最大的意义，就是前面提到的跟社保制度的落地时间相匹配。

 

“那么作为一名‘年轻程序员’，我们不禁要问：是否有确凿证据表明，COBOL 规范或者实现在以这种方式运行？”这跟 COBOL 或者任何其他数据无关，而是一种常识性的数据结构设计思路。

 

“如果答案仍然是否定的，那有没有一些虽有力的论据能够支持或者驳斥这种说法的合理性？”恰恰相反，任何对结构化数据拥有最底限了解的人，都能理解为什么要这样做。再次强调，这是一种常识。

 

请注意，我们这里讨论的是上世纪 30 年代到 50 年代期间设计出来的系统。当时的主流存储方案是打孔卡，每个字符都对应着很高的成本。将日期存储为 8 个字符代表着极大的浪费，因此当时大多数商业应用程序会将日期存储为 5 个字符。其中 3 个字符表示日期，2 个字符表示年份，这明显是在用糟糕的编码实践来换取成本节约。

 

现在，社保制度需要覆盖超过 100 岁的群体，因此将合理的截止年份定义为基准有助于节约后续字符需求量。所以说，出生日期确实可以用 6 个字符、而非 8 个字符来编码，其中 3 个字符表示日期，加上 3 个字符表示年份（减去 1875 后的数字）。

 

反过来说，未填写的日期（例如出生日期未知，也就是数值缺失）代表内容为空。按照以上逻辑，该值会输出 1875，确保不致报告异常。

 

整个问题的逻辑，就是这么简单。

马斯克的 DOGE 团队可能真需要恶补 COBOL 课

网友们经过了两天的激烈讨论，发现马斯克又在今天晒出了一个更详细的年龄/人口表，夸张的是超过 150 岁的人还不是少数。

不管是不是编程的问题，都说明老古董社会保障系统的数据管理和监管问题很大，不仅仅是一个 COBOL 语言缺省日期的问题。

而且这些年轻工程师们已经在“大动干戈”，DOGE 表示，他们的目标是实现政府系统“现代化”，这意味着需要对系统内的代码加以修改。也就是说，效率部的成员们很可能正在面对自己从未见过的东西：COBOL，即面向业务的通用语言。

COBOL 语言由五角大楼及 IBM 等公私合作组织于上世纪 50 年代开发而成，其目标是为商业应用程序构建一种通用且与英语相似的编程语言。在之后的几十年间，私营企业已经不再使用这种语言。而该语言的代码维护起来难度大、成本高，且主要面向批处理需求所打造，因此无法与其他基于云环境的现代实时应用程序进行良好集成。但在华盛顿特区，情况则完全不同。尽管最近几十年来也在陆续推动各项现代化进程，但 COBOL 语言仍在政府部门内用于管理各类金融交易的大型机系统中广泛存在，具体涵盖纳税、退税、社会保障、福利政策乃至医疗保险报销等业务流程。

只要维护得当，这些系统其实相当可靠。正如一位专家所言，COBOL 是在各大型机组件之间充当“粘合剂”，靠代码协调硬件同应用程序及数据库之间的协同运作。大型机本身就具备冗余和容错等能力，因此永远不会发生故障。所以时至今日，基于 COBOL 语言的大型机系统仍在金融服务、电信和医疗保健等受到严格监管的行业中发挥作用。

有些人担心这群年轻工程师可能会闯入 COBOL 代码库，并在尚不了解影响情况的同时草率动手。一般来讲，涉及到系统底层代码的任何变更，都必须遵循其他机构工作人员编写的详尽业务需求。而这些系统中的任何延迟或者停机，都会对现实生活中人们的生活产生直接影响。面对马斯克和他的效率部顾问们，软件工程师和机构内的其他人员当然会给予指导并强调尊重既定规范的重要性。但马斯克的这支队伍显然相当难以预测。如果效率部工作人员贸然重写 COBOL 代码中的某些部分，很可能会导致意想不到的后果，包括对关键服务的严重破坏。而且哪怕不是必然出事，引发意外后果的可能性也相当之高。

从某种意义上讲，COBOL 语言象征着这批年轻理想主义者与真实世界之间的脱节。维护 COBOL 代码是一个将新法规逐步转化为具体业务需求、将需求整理为计算机代码、在安全环境中全面测试代码、将最终产品投入生产，并在系统中记录其用途的漫长过程。但由于自上世纪 90 年代以来 COBOL 不再作为计算机科学课中的学习内容，因此从事这项工作的人们往往年龄较大，且整体人员数量也在不断减少。

技术服务商 Very Little Gravitas 的负责人 Don Hon 表示，马斯克和他的效率部成员大多是来自硅谷文化圈的年轻软件工程师。他们习惯于以一种极具特色的“快速行动、打破常规”流程作为指导，来实现复杂服务与产品的现代化。

Hon 强调“看看特斯拉早期开发全自动驾驶软件的方式就能明白，我们科技行业具有一种通行文化，即「让我们一起想办法，先得到一套能够运行起来的东西。它会崩溃，之后我们再想办法修复」。”可以肯定的是，这样的理念在过去已经为马斯克这样的企业家们带来了巨大成功。但这样的计算风险对于由数亿人依赖的政府系统来说，则意味着完全不同的情况。整个职业生涯都在开发面向消费者软件的工程师们，恐怕并没有能力为变更政府支付系统而绘制出正确的风险曲线。

Hon 解释道，“有人可能会说，最多就是错过一笔医疗补助之类的，那有什么大不了，我们可以稍后解决嘛。”但实际上，COBOL 软件其实很脆弱。比方说，一旦代码更新了与现有策略相冲突的新策略，则整个系统会彻底崩溃。有些系统还缺少自动测试程序，因此软件工程师必须手动编写测试，并在合并新代码之前一遍遍完成耗时的测试任务。而对于那些缺少正确记录的代码片段，很多之前没接触过项目的人很可能搞不清这些代码是做什么的，最终导致情况进一步复杂化。

所以鉴于现在的情况，美国人能做的只能是希望 DOGE 能三思而后行，保留那些掌握 COBOL 语言并了解项目历程进程的资深员工。毕竟，COBOL 那些难以理解和不够健壮的要素只能算是特点，而非纯粹的缺陷。

参考链接：

https://www.threads.net/@ashmore_glenn/post/DGDfmj6TsZS

https://x.com/i/trending/1890706819724824578

https://x.com/JustinWolfers/status/1890836472174924143

https://retrocomputing.stackexchange.com/questions/31288/does-or-did-COBOL-default-to-1875-05-20-for-corrupt-or-missing-dates

https://www.fastcompany.com/91278597/elon-musk-doge-COBOL-language