編譯完美無瑕的 COBOL 遷移，為何仍毀掉了整本帳本
程式碼完美無缺。這正是整個問題所在。
一支電匯程式已從 COBOL 轉譯成 Java。它能編譯通過。單元測試也全數通過。它通過了我們為攔截錯誤所建立的每一道關卡。接著，在使用者驗收測試中，第一筆交易就觸發了資料庫的一致性檢查，整套系統隨之崩潰。
這場事後剖析花的時間比它應有的更久，因為 Java 裡沒有任何地方看起來有問題。罪魁禍首是一個名為TRN-LIMIT的變數。轉譯工具把它讀成一個普通數字，並賦予它標準的整數型別。但TRN-LIMIT從未在工具所查看之處被定義。它宣告於一個 copybook——一個共用的標頭檔——在執行鏈中早了數千行才被引入，而那個 copybook 帶有一個REDEFINES子句：一種 COBOL 結構，能讓同一塊記憶體位置，依據別處某個旗標的設定，被讀取成兩種截然不同的資料型別。在主機上，那個位址存放的是一個封裝十進位。新的 Java 程式碼把損毀的二進位資料寫入了資料庫欄位，帳本的參照完整性就此崩解。
這段程式碼在語法上毫無瑕疵。失敗是脈絡性的。工具漏掉了一個存在於其視野之外的相依關係——而在舊有 COBOL 現代化中，金錢幾乎總是這樣消失的。
現代化專案通常不會死在你看得見的程式碼上。它們死在工具看不見的那些程式碼上。
這是一個故事，講的是我為何不再相信更好的轉譯就是答案，以及我們改而在 Veriprajna打造了什麼。
為什麼「貼上 COBOL，取得 Java」總是能展示得很漂亮？
如果你在過去兩年裡參加過任何一場主機現代化會議，你一定聽過這套推銷詞：貼上你的 COBOL，換回 Java。它之所以誘人，是因為展示總是奏效。有人丟進一支整潔的 200 行程式，模型回傳乾淨、地道的 Java，房間裡的每個人都鬆了一口氣。終於。
有一陣子，我也相信過。當我的團隊初次著手處理時，我們做了顯而易見的事——我們試圖讓轉譯更好。我們餵給模型更多脈絡，針對 COBOL 的怪癖進行調校，並對輸出品質做基準測試。甚至有一個專為此打造、名為 XMainframe 的微調開源模型，在 COBOL 任務上的得分比通用程式碼模型高出約 30%。轉譯變得更乾淨。Java 也更易讀。
然而它在 UAT 中依然出錯。一次又一次，正是那種讓電匯程式沉沒的隱藏相依關係。就在那個月，我意識到我們一直在打磨錯誤的東西。轉譯的品質從來都不是瓶頸。能編譯通過的程式碼是簡單的部分。困難的部分是工具看不見的程式碼。
圍繞這件事的數字既殘酷又一致：70% 到 80% 的主機現代化專案未能達成目標。不是 70% 進度延誤——而是 70%失敗。慣常的診斷歸咎於被低估的測試或雜亂的資料遷移，這些確實存在。但在幾乎所有案例底層，都藏著我剛剛親眼目睹的同一個根本原因：工具把程式碼庫當成一段要轉換的文字，而它其實是一個需要被理解的拓撲結構。
「貼上 COBOL，取得 Java」看不見什麼
一旦你開始尋找脈絡性盲點，就會發現它無處不在。有三種模式最常擊垮我們，而它們沒有一個會出現在轉譯器盯著看的原始檔中。
先從我已經描述過的 copybook 問題說起。單一支 COBOL 程式可以參照超過四十個 copybook，而那些 copybook 又包含其他 copybook，因此一個變數的真正定義可能位於引入鏈中好幾層深的地方。以文字為基礎的工具讀取眼前的敘述並推斷型別。它無從得知，在一個封裝十進位欄位中，這個推斷是悄然錯誤的。
再來是算術。COBOL 的 COMP-3 封裝十進位在 Java 中沒有原生的對應物。若伸手去用一個 double，你就在一個搬運金錢的系統裡引入了浮點捨入。就連 BigDecimal——正確的工具——預設下也不匹配 COBOL；你必須明確地把它的捨入模式固定為 HALF_EVEN，才能對應 COBOL 的 ROUNDED 子句。弄錯了，你每筆交易就會差一分錢。這一分錢會在數百萬筆交易中累積，直到數週後，一份對帳報告標記出一個沒人能解釋的差異。
幾乎所有人都會忘記、卻真正會讓正式環境垮掉的模式是這個：你的 COBOL 不會自己執行。一個排程器——CA-7 或 TWS——負責調度介於兩千到五千支之間的批次作業，並在其中穿插相依鏈。作業 A 在凌晨 1 點寫入一個資料集，作業 B 在凌晨 2 點讀取它。你可以完美無瑕地遷移每一行 COBOL，卻仍在午夜搞垮整間銀行，因為沒人繪製過作業網路。正式環境的圖從來不在原始碼裡。它在 JCL 裡。
在凌晨 2 點搞垮正式環境的那支作業，從來不是你當時盯著看的那一支。
這就是我所說的拓撲。真正在運轉你業務的產物，是一張關係之網——程式、copybook、資料集、排程作業、DB2 資料表、CICS 交易——而 COBOL 原始碼只是其中的一縷。
為什麼我不再信任轉譯器，開始繪製地圖
對我們而言，轉捩點是決定：地圖就是產品。
在轉譯任何一行之前，我們會為整個程式碼庫建立一張知識圖——每一支程式、每一條 copybook 邊、每一個 JCL 相依、每一次資料集交接、每一個 DB2 接觸點——並解析出原始檔所隱藏的遞移關係。當你能看到某支程式有四十多條 copybook 邊，而其中一條帶有一個REDEFINES，位於兩個模組之外，那個 TRN-LIMIT 災難根本不會發生，因為早在你敲下任何一個 Java 字元之前，你就知道那個欄位是封裝十進位。
我想精確說明為什麼這與這個領域其他人所販售的不同，因為這個領域很擁擠，而其中大部分在它們所解決的那一環上確實表現優異。
IBM 的 watsonx Code Assistant for Z 是最重量級的現任者——一個代理式系統，具備協調、架構與程式碼代理，能處理 COBOL 到 Java、甚至 PL/I 與 IMS，並將 CPU 耗用分析一路深入到 copybook 之中。它同時也是一筆 200 萬美元以上的承諾，運行於 z/OS 上，並倚賴 IBM 的 ADDI 工具鏈，這在無形中把你鎖進主機——就在那場本該讓你擺脫主機的遷移過程中。它不做行為等價測試，也不繪製你的 JCL 作業網路。
接著是重塑整個市場的那一刻。2026 年 2 月，Anthropic 發布了一份針對 Claude Code 的 COBOL 現代化操作手冊；IBM 的股價在宣布當天下跌了 13.2%，一個一億美元的合作夥伴網路則在 3 月隨之而來。Claude Code 在探索、文件化與閱讀陌生程式碼方面表現出色——在早期階段確實有用。但它是一個通用工具。它沒有內建用來解析遞移相依的知識圖，也不假裝能解決 JCL 排程、行為等價，或一間受監管銀行必須產出的稽核軌跡。
Microsoft 的 Azure 遷移工廠瞄準 Java Quarkus，並把你的目標平台鎖進 Azure。大型系統整合商——擁有專利轉換引擎的 DXC、有 MasterCraft 的 TCS、有 Cobalt 的 Infosys、Accenture——執行的是 50 萬到 500 萬美元以上的專案，並且是導入廠商工具，而非建立關於你的系統的智慧；Accenture 主導了澳洲聯邦銀行的核心遷移，該案花費約 7.499 億美元、歷時五年。而 Micro Focus 的 Visual COBOL，常被推銷為一個起點，根本不是現代化——它是重新託管。你的 COBOL 依然是 COBOL，只是換到新的執行環境上。技術債與人力問題還原封不動地待在你留下它們的地方。
這些工具每一個都做了某件真實的事。它們沒有一個做到的，是把完整的相依拓撲——JCL、CICS、DB2、copybook，一應俱全——最先建立起來，獨立於任何目標平台，並把那張地圖當成其他一切所立足的基礎。
大多數廠商賣給你的是一個更好的轉譯器。而轉譯從來就不是失敗的那一環。
沒人能停下的時鐘
接下來這部分，把它從一個工程問題變成了一場緊急事件。
懂得這些系統的人正在離開。美國 COBOL 開發者的平均年齡約為 55 歲。這批人力每年約有 10% 退休，而 85% 的大學早在 1990 年代就把 COBOL 從課程中移除，因此幾乎沒有人來接替他們。如今有 60% 的組織表示，找到有技能的 COBOL 開發者是它們最大的單一現代化挑戰——而仍懂這些技術棧的開發者中，有 58% 表示他們正因這些系統而考慮辭職。
我曾親身站在那個至今仍縈繞我心頭的版本前：為那位唯一真正懂得批次視窗的人所辦的退休派對。每個人都在微笑，有一塊蛋糕，而在我腦海深處，有個聲音正說著那份知識剛剛走出了門，而且它沒有被寫在任何地方。除了其他作用之外，知識圖也是一種方式，能在派對之前捕捉那個人腦中的東西——讓相依地圖比那些把它記在腦中的人活得更久。
而且風險並不小、也不抽象。仍有約 2,200 億行 COBOL 處於活躍的正式運行中。它運行著 95% 的 ATM 交易，每天清算約 3 兆美元。43% 的銀行系統建立在它之上。美國的技術債估計達 1.52 兆美元，而平均每家企業每年因舊有系統的低效率而燒掉約 3.7 億美元，金融服務公司更是把 70% 到 75% 的 IT 預算，僅僅用來維持舊系統的運轉。做對這場遷移的團隊回報了 114% 到 225% 的報酬，以及每年約 2,500 萬美元的節省——但這份上檔空間只存在於一場沒有失敗的遷移的彼岸。這是一場罕見的現代化，其中什麼都不做才是昂貴的選項。
新的 AI 工具難道不會直接解決這個問題嗎？
這是我最常被問到的問題，而它很合理，尤其是在 Anthropic 的宣布讓這個問題看起來像是剛剛被宣告解決之後。
我誠實的回答是：新工具讓探索階段大幅加快，這是實實在在的進展——我自己也在用。但代理式 AI 變得擅長閱讀 COBOL，並不會改變那個真正殺死專案的東西。Gartner 預期到 2026 年，40% 的企業應用程式將內含特定任務的 AI 代理；然而，如果它們全都對同一個 JCL 相依視而不見，那麼更多代理更快地轉譯程式碼也於事無補。在錯誤問題上的速度，只是更快地抵達 UAT 並在那裡失敗的方式而已。
我被問到的另一個問題是關於監管，而這正是中型銀行低估的一點。歐盟的《數位營運韌性法案》——DORA——於 2025 年 1 月生效，要求進行舊有系統從未被設計來通過的營運韌性與威脅導向滲透測試。美國 FFIEC 與 OCC 的檢查人員把老化的基礎設施視為一個現實的合規缺口，而使用超過十年的系統，其遭入侵的機率大約高出三倍。一場無法產出稽核軌跡、證明新系統與舊系統行為完全一致的遷移，不是現代化——而是一項語法更好看的新負債。
這就是為什麼行為等價測試與那張地圖同等重要。這項技術描述起來很直接，做好卻很難：從舊有系統擷取真實的輸入與輸出——一個黃金資料集——並對新系統重放它們，直到行為相符，逐一比對每一個邊界案例。這些歷經數十年累積的邊界案例，往往編碼了一種監管邏輯，而這種邏輯存在於別無他處——不在規格書中，不在某個人的腦中，只存在於運行中的程式碼裡。我親眼見過這件事對一家保險公司的傷害比對銀行更重：那條只在一份 1998 年保單批註上才觸發的費率規則、那個沒有活人能解釋其捨入方式、卻是每次稽核都依賴的理賠準備金計算。悄無聲息地弄丟它們，你會在監管機構開口詢問的那天，才發現哪些才是要緊的。
你先抽哪一塊磚？
一旦你有了地圖，它會告訴你一件轉譯器辦不到的事：從哪裡開始才安全。
如今的主流策略——理由充分——是絞殺榕：不做一次性大爆炸式重寫，而是一次抽取一項能力，讓新舊系統並排運行，並把舊有系統保留為可用的後備，直到新的那塊贏得信任。但每一個推薦絞殺榕的廠商，都略過了最困難的問題——你要先絞殺哪個模組？挑一個高度耦合的，你就用額外的步驟重現了大爆炸式的風險。
知識圖直接回答了這個問題。它會浮現出耦合度最低的模組——那些擁有最少入向相依的模組——讓你能抽取系統中真正的一塊，證明這套做法，並在你觸碰危險的核心之前建立起組織的信心。這張地圖不只是防範 TRN-LIMIT 失敗的保險。它就是那份排序計畫。
我們把這一切——相依知識圖、絞殺榕排序、行為等價測試框架，並刻意獨立於任何目標平台——全都建進了Veriprajna 的舊有 COBOL 現代化實務中，直接瞄準那些被 200 萬美元起跳的現任者與七位數的系統整合商視為太小、不值得費心的中型銀行與保險公司。
我坦誠以對的部分
我不會假裝這項技術能解決一切，因為我見過最昂貴的那些失敗，根本一點也不在技術上。
沒有任何工具——包括我們的——能修好組織的認同、清理多年來的壞資料，或打贏那場說服兩百名開發者改變工作方式的政治仗。這個市場預計將從 2026 年的約 90 億美元，成長到本十年末的兩倍左右，正是因為如此多的支出流向了人與組織的層面，而非編譯器。而且世上沒有任何解析器，無論開源或商用，能完美涵蓋 IBM Enterprise COBOL 中的每一種結構——1985 年之前的 ALTER 陳述式、最深層的 REDEFINES。任何告訴你並非如此的人，都是在把那道缺口賣給你。這項技術是必要的。但它從來都不是充分的。
但技術能夠掌握的那一部分，它就必須完全掌握。遷移之所以燒掉數百萬美元卻交付不出任何東西，原因很少是有人寫了糟糕的 Java。而是他們轉譯了一個他們從未真正繪製過的系統——轉換著一張網中的縷縷絲線，而那張網本身始終隱形，直到它撕裂的那一夜。
先繪製地圖。一個比撰寫它的人活得更久的系統，不會原諒一個被漏掉的相依關係，而且在你能看清什麼連著什麼之前，這項工作沒有任何一個版本是安全的。我們是從一份被一個沒人知道存在的封裝十進位欄位所毀掉的帳本上，學到這一點的。在那些欄位找上你之前，先找出它們。
