馬斯克的DOGE再想奇招：數月內重寫完美國社保系統6000萬行COBOL代碼
根據外媒《連線》最新報道，馬斯克領導的美國政府效率部（DOGE）目前正在展開新一輪的技術革新，其計劃是升級美國社會保障局（SSA）的核心支付系統，將原本用COBOL 編寫的舊代碼遷移到另一種更為現代的編程語言如Java 上，並希望在幾個月內完成。
這項消息引發了技術圈的熱議。要知道，作為一門「上古」程式語言，COBOL 雖然並非不可取代，但在銀行、保險、政府機構等大型業務系統中依然廣泛使用。如今DOGE 計畫在短短幾個月內完成遷移遺留程式碼，這也讓眾人好奇它究竟該如何完成？莫不是想要靠著Grok 這樣的AI 大模型？
超6,000 萬行程式碼，外媒：DOGE 計畫在幾個月內遷移完成
眾所周知，COBOL 誕生於20 世紀50 年代末，它的起源可以追溯到美國國防部主導的一個項目，旨在開發一種通用的、高度可讀的程式語言，以用於政府和企業的資料處理任務。彼時，隨著美國國防部和大型企業的推廣，COBOL 迅速成為商業運算的標準語言之一。
時至今日，這門語言依然活躍在上述提及的多個應用中，甚至在本月它還闖進了TIOBE TOP 20 之列，位居第20 位。
《連線》報道稱，截至2016 年，SSA 的軟體系統中包含超過6,000 萬行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 的開發人員可能會跳過關鍵的品質保證環節，從而增加技術風險。
也有技術專家警告說，即使在最理想的情況下，完成如此大規模的系統遷移也極具挑戰。而現在匆忙推進，可能會導致超過6,500 萬人的社保福利發放出現問題。
「一旦系統出錯，不僅僅是有人收到的錢不對，更可怕的是，可能有人根本收不到款項，而我們甚至意識不到。」一位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.wired.com/story/doge-rebuild-social-security-administration-cobol-benefits