2026年2月23日，IBM股價單日暴跌13%，創下自2000年10月以來最大單日跌幅。導火線是其人工智慧實驗室發布的公告，聲稱能夠實現COBOL的現代化改造。擁有大型主機系統的董事會看到公告後，紛紛詢問人工智慧是否能夠幫助他們轉換COBOL系統，從而關閉大型主機。 IBM當天發布的答案十分明確：轉換COBOL幾乎無法捕捉到真正的複雜性，真正的複雜性體現在資料架構、執行時間替換、事務完整性以及平台內建的非功能性需求等。市場混淆了兩個不同的問題，並根據一個解決方案的價格來衡量其對兩個問題的綜合影響。
這兩個問題分別是理解和翻譯，它們並非同一活動的不同階段。它們是截然不同的技術挑戰，人工智慧處理這些挑戰的能力和風險也截然不同。人工智慧顯著降低了理解 COBOL 系統的成本，但並未顯著降低替換成本。這種區別至關重要，因為制定現代化投資決策的組織需要了解他們付費是為了解決哪個問題，人工智慧在每個問題上實際發揮了哪些作用，以及無論是否採用人工智慧工具，剩餘的驗證工作將如何消耗因理解和翻譯節省下來的預算。
市場誤解的那個區別
理解和翻譯不是同一個問題。
理解是一門理解程式碼功能及其原因的學科，它從技術實現中提取出業務意圖。在 COBOL 環境中，理解意味著：該程式編碼了哪些業務規則？每個執行路徑遵循哪些條件？它讀取和產生哪些資料？哪些下游系統依賴它的輸出？業務分析師需要了解哪些關於該程式的資訊才能編寫替代程式的規格？理解關注的是語義，即意義，而不是語法。
翻譯是一門將程式碼從一種語言轉換為另一種語言，同時保持其行為不變的學科。在 COBOL 的脈絡下，翻譯意味著：產生一段 Java（或 Python、Go）程式碼，使其能夠處理所有輸入、所有條件，並保證輸出結果與下游系統在數值上完全一致。翻譯關注的是結構和行為的等效性，新程式碼必須通過原始程式碼能夠通過的所有測試，包括原始開發者考慮到的、你可能從未意識到的極端情況測試。
| 尺寸 | 理解 | 專業筆譯 |
|---|---|---|
| 問題已解答 | 這段程式碼是什麼意思？ | 這段程式碼究竟做了什麼？ |
| 輸出類型 | 自然語言文檔 | 可執行程式碼 |
| 錯誤後果 | 可透過人工審核糾正 | 生產事故 |
| 人工智慧能力 | 法學碩士（LLM）擅長散文寫作。 | 弱決定論 |
| 尺度約束 | 可透過上下文視窗進行管理 | 投資組合規模未能滿足上下文限制 |
| 風險狀況 | 低，錯誤可複核 | 高危險群錯誤在發生前是看不見的。 |
| 人類角色 | 驗證器和增強器 | 審閱者和驗證者 |
這些問題相互關聯，都需要一定的理解能力才能做好翻譯，但它們並非同一問題，人工智慧在解決這些問題上的能力差距顯著。人工智慧對 COBOL 程式碼的理解能力確實令人印象深刻。然而，將 COBOL 程式碼翻譯成符合生產環境要求的 Java 程式碼卻非常困難，而市場將這兩者混淆正是 Gartner 預測 2026 年啟動的大型主機退出專案中超過 70% 將無法實現預期收益的原因。
人工智慧理解力真正發揮作用的地方
理解問題具有一個使其非常適合人工智慧解決的特性：輸出是自然語言，而大型語言模型擅長產生自然語言。當人工智慧讀取 COBOL 程式並產生文件（包括程式功能描述、業務規則解釋和資料流枚舉）時，輸出就是文字。文本中的錯誤是可以糾正的：人工審核人員可以發現對業務規則的錯誤描述並進行更正，而不會造成任何後續技術後果。理解錯誤的代價只是文件更正，而不是生產事故。
業務規則文件。一個大型語言模型，透過 COBOL 的 EVALUATE 程式碼區塊呈現，其中可能包含數十年來監管變更累積的數百個 WHEN 條件，它可以產生結構化的描述，用業務術語解釋每個條件的含義。對於那些原始文件已遺失或從未存在過的程序來說，這尤其寶貴。例如，一個實現了跨 63 個司法管轄區稅收計算邏輯的 COBOL 程序，其 EVALUATE 結構中就編碼了這些司法管轄區的規則；人工智慧可以比任何人工流程更快地提取並記錄這些規則。雖然人工智慧產生的內容需要由領域專家進行驗證，但專家驗證的是人工智慧的輸出，而不是從頭開始重建知識，這大大加快了速度。
以下是人工智慧理解在實踐中的表現。給定以下 COBOL 原始碼：
科博爾
EVALUATE TRUE
WHEN CUST-COUNTRY = 'US' AND CUST-STATE = 'CA'
COMPUTE TAX-AMT = GROSS-AMT * 0.0725
WHEN CUST-COUNTRY = 'US' AND CUST-STATE = 'TX'
COMPUTE TAX-AMT = GROSS-AMT * 0.0825
WHEN CUST-COUNTRY = 'UK'
COMPUTE TAX-AMT = GROSS-AMT * 0.20
WHEN CUST-COUNTRY = 'DE'
COMPUTE TAX-AMT = GROSS-AMT * 0.19
WHEN OTHER
MOVE ZERO TO TAX-AMT
END-EVALUATE.
一個指導得當的法學碩士課程能夠產生：
Business Rule: Tax Calculation
This paragraph applies jurisdiction-specific tax rates to GROSS-AMT:
- US/California: 7.25% (CA state sales tax)
- US/Texas: 8.25% (TX state sales tax)
- United Kingdom: 20% (UK VAT standard rate)
- Germany: 19% (DE MwSt standard rate)
- All other countries: tax-exempt (TAX-AMT = 0)
Note: No rate exists for other US states. Orders from NY, FL, IL
will be tax-exempt under current logic -- likely a gap requiring review.這份產出確實很有價值：它記錄了四條業務規則，指出了一個可能的差距（美國某些州沒有明確的費率），而且只花了幾個小時就完成了。領域專家審核後確認了差距，並將其添加到測試案例中。理解任務圓滿完成。
依賴關係描述。靜態分析工具會產生依賴關係圖，圖中顯示了哪些程式呼叫了哪些程序，哪些副本共享，以及哪些資料集在程式之間流動。人工智慧可以根據該圖生成自然語言描述：「CUSTPROC 被 14 個程式調用，主要是在夜間批次視窗中調用。它與 47 個程式共享 CUSTMSTR，並將輸出寫入 CUST-REPORT-FILE，該檔案供監管報告工作流程使用。」與單獨的依賴關係圖相比，這種描述對於新程式設計對於人工智慧更有用的工具之間
基於已理解的行為產生測試案例。一旦人工智慧記錄了程式的行為，它就可以產生覆蓋已記錄執行路徑的測試案例。這與證明行為等效性不同，這些測試案例涵蓋的是人工智慧已理解的路徑，可能遺漏了它未理解的路徑。但是，透過人工智慧產生的測試案例覆蓋 60% 的執行路徑，總比許多遺留程式目前 0% 的覆蓋率要好得多，並且為行為等效性驗證所需的手動測試增強提供了一個起點。
跨相似程序進行模式辨識。大型 COBOL 程式庫通常包含許多結構相似的程序，它們可能對不同的實體應用相同的處理模式，或對相同的監管計算採用不同的參數化方式。人工智慧可以識別數千個程式中的這些相似之處，並按模式類型進行聚類，從而實現一種遷移策略：只需針對每種模式進行一次處理，並系統地應用解決方案，而不是將每個程式視為獨立的個體。
共同點在於：人工智慧理解的輸出是文本，文本可以由人類審核，而人類審核可以在錯誤造成技術後果之前將其發現。人工智慧理解的風險等級夠低，因此它帶來的價值是實實在在的，而且它所犯的錯誤也是可控的。
人工智慧翻譯過度承諾之處
翻譯的特性使其對人工智慧而言比理解更難：輸出的是可執行程式碼，而可執行程式碼必須完全正確。即使翻譯準確率達到 95%，產生的程式仍會在 5% 的輸入情況下出錯，這在金融交易處理系統中可能意味著監管報告錯誤、餘額計算差異或合規性問題。翻譯錯誤的代價並非文件更正，而是生產事故。
數值精度故障。 COBOL 的壓縮十進位運算 (COMP-3) 可以產生精確的十進位結果。 Java 的 double 以及 Python 的 float 使用 IEEE 754 二進位浮點數，它無法精確表示大多數十進位小數。一個計算的 COBOL 程序 0.1 + 0.2 使用 COMP-3 可以精確地產生 0.3同樣的計算在 Java 中也適用。 double 產生 0.30000000000000004對於一家每晚在提交監理文件時都要進行 10 萬次此類計算的金融機構而言，累積的誤差並非無關緊要的浮點運算問題，而是財務報告上的重大偏差。如果人工智慧在產生 Java 程式碼時沒有明確處理 COMP-3 到 BigDecimal 的映射，就會系統性地引入這種誤差，而人工智慧轉換的每個欄位都會出現這種情況。 double 而非 BigDecimal.
程式碼上的差異很細微，但後果卻不容忽視：
科博爾
* COBOL: COMP-3 packed decimal -- exact arithmetic
77 UNIT-PRICE PIC S9(7)V99 COMP-3.
77 QUANTITY PIC S9(5) COMP-3.
77 LINE-TOTAL PIC S9(11)V99 COMP-3.
COMPUTE LINE-TOTAL = UNIT-PRICE * QUANTITY.
* UNIT-PRICE = 19.99, QUANTITY = 3
* LINE-TOTAL = exactly 59.97 -- no rounding error
Java的
// Java: naive AI translation uses double -- introduces error
double unitPrice = 19.99;
int quantity = 3;
double lineTotal = unitPrice * quantity;
// lineTotal = 59.96999999999999... not 59.97
// Correct translation requires BigDecimal:
// BigDecimal lineTotal = new BigDecimal("19.99").multiply(new BigDecimal(3));單筆交易中的錯誤可能難以察覺。但如果每晚有10萬筆交易匯總到監管資本報告中，就會造成重大差異。如果人工智慧翻譯沒有明確處理COMP-3字段，那麼每次都會出現這種替換。
編譯器選項依賴性。相同的 COBOL 原始碼在不同的編譯器選項下可能產生不同的行為。 NUMPROC(MIG) 和 NUMPROC(NOPFD) 會改變數值異常的處理方式。 RMODE、AMODE 和 DATA 選項會影響尋址方式。如果人工智慧在不知道使用了哪些編譯器選項的情況下翻譯 COBOL 原始碼，它翻譯的是程式的原始碼，而不是程式的行為。翻譯後的 Java 程式碼可能與原始程式碼匹配，但其生產行為可能與原始程式碼不符。
大規模的幻覺問題。研究表明，GPT-4 類模型在一般的代碼翻譯任務中表現出 33% 到 60% 的幻覺率，它們生成的代碼看似合理，但實際上卻添加或刪除了源代碼中不存在的行為。對於一個包含 847 個 EVALUATE 條件的程序，5% 的幻覺率意味著大約有 42 個條件被錯誤翻譯。這 42 個條件代表著被翻譯悄悄破壞的業務規則。如果沒有一個涵蓋所有條件的完整測試語料庫，這些錯誤只有在觸發它們的特定輸入組合進入生產環境後才能被發現。
數字背後的利害關係：
Error Type | Detection Point | Cost Range
--------------------|--------------------|------------------
Comprehension error | Human review | Hours to fix
Translation error | Test suite | Days to isolate
Translation error | Production | $10K-$500K+ incident
Equivalence gap | Regulatory audit | $50K-$5M+ penalty這種不對稱性體現在：理解錯誤在造成技術後果之前就能被發現，而翻譯錯誤卻能通過審核，並在生產過程中，甚至更糟的是，在監管申報中引發問題。
上下文視窗上限。 IBM的 watsonx Code Assistant for Z 在上下文視窗內對單一程式進行 COBOL 到 Java 轉換時，結構準確率可達 80% 或更高。一個包含 5 萬行 COBOL 程式碼的 COBOL 專案包含數千個程序，這些程序之間存在跨程序依賴關係，而這些依賴關係跨越的程序無法同時存在於同一個上下文視窗中。如果一個程序呼叫了一個子程序，而該子程序的 AI 轉換結果與呼叫程序的預期不符，就會造成介面不匹配，而單獨進行任何一種轉換都無法發現這種不匹配。專案規模的轉換需要理解跨程式的邏輯，而不僅僅是理解程式內部的邏輯。
上下文無關翻譯問題。一個處理特定業務事件的 COBOL 程序，其運行依賴於嵌入在周圍系統中的上下文信息，例如決定程序運行時間的批處理計劃、啟動時必須可用的數據集、處理記錄的順序，以及下游程序在運行前讀取其輸出等。如果人工智慧在不理解這些上下文的情況下翻譯程序，它只能翻譯原始程式碼，而無法理解其作用。翻譯後的 Java 程式碼可能內部邏輯正確，但由於運行時間錯誤、順序錯誤，且缺少其 COBOL 前身程式所依賴的資料前提條件，仍然會在運行中失敗。
行為等效性差距
理解型人工智慧和翻譯型人工智慧都無法解決的最重要問題是行為等效性證明，即證明現代化系統對於企業及其監管機構關注的所有輸入都能產生與傳統系統相同的輸出。
行為等效性並非傳統意義上的測試問題。它並非詢問“新系統是否通過測試套件？”，因為傳統 COBOL 系統的測試套件通常不存在，或僅覆蓋程式執行路徑的一小部分。它詢問的是：對於生產系統曾經接收過的所有輸入，現代化的系統是否產生相同的輸出？對於生產系統未來可能接收的所有輸入，包括僅在罕見的市場狀況、監管報告期或特定客戶情況下才會出現的極端情況，現代化後的系統是否產生等效的結果？
要回答這個問題，需要：根據實際生產執行情況（而不是根據文檔，也不是僅根據源代碼）對現有系統的行為進行描述；一個能夠涵蓋該行為全部範圍的測試語料庫；以及一個能夠判斷表示方式不同的輸出（EBCDIC 與 UTF-8、壓縮十進制與 BigDecimal、批處理文件與數據庫記錄）的“等效”含義的比較框架。
人工智慧翻譯工具無法提供這些。 IBM 的評估很直接：翻譯幾乎無法捕捉現代化改造的真正複雜性。行為等效性工作、平行運作、協調框架以及監管審批，才是成本和風險集中的地方，也是人工智慧對專案總成本影響最小的地方。人工智慧可以縮短現代化改造專案的前端：理解和初步翻譯，但無法縮短後端：驗證、等效性測試和平行驗證。
正確模型：靜態分析基礎，AI語意層
最有效的AI理解能力並非AI本身，而是AI在靜態分析所提供的結構基礎之上運作。靜態分析可以彌補AI理解的限制（例如上下文視窗的限制、對複雜跨程式邏輯的誤解、機率性而非確定性分析），而AI則可以彌補靜態分析的限制（例如只能產生結構性事實，而無法提供語意描述）。
合理的分工：靜態分析提供結構上的確定性（確定性、完整性、無臆想），人工智慧提供語意上的豐富性（自然語言描述、模式辨識、測試生成）。兩者單獨使用均不足以滿足需求，必須結合使用才能全面理解。
靜態分析提供的結構基礎：
完整的程序清單。涵蓋程式組合中的所有程序，包括文件遺漏的程式以及人工智慧上下文視窗永遠無法同時容納的程式。靜態分析可處理整個程式組合，不受上下文限制。
精確的依賴關係圖。每個 CALL 關係、每個 COPY 關係、程式間的所有資料流，都應從原始碼中確定性地推導而來，而非從訓練資料中機率性地推導而來。當 AI 理解工具描述程式的依賴關係時，該描述應基於靜態分析產生的依賴關係圖，而非 AI 對程式通常依賴項的機率性記憶。
死代碼識別。無法從任何生產執行路徑存取的程式不屬於現代化改造的範圍。靜態分析可以準確識別它們；而人工智慧無法做到，因為人工智慧沒有運行時執行追蹤訊息，僅憑靜態分析無法區分有效程式碼和死程式碼。
資料模式清單。每個 FD 條目、每個副本、每個 COMP-3 欄位及其精確度規範，均從來源工件中提取，而不是從 AI 的訓練資料記憶中重建 COBOL 欄位定義的典型形式。
在此結構基礎之上，人工智慧理解添加了語義層：對每個程式功能的自然語言描述、業務規則文件、跨程式資料流的敘述以及將相似程式聚類的模式識別。這種結合——靜態分析帶來的確定性結構準確性和人工智慧帶來的自然語言語義豐富性——構成了現代化團隊真正可以信賴的理解輸出模型。
這對您的現代化計劃意味著什麼
基於此分析的人工智慧投資實際分配方案：
投資人工智慧理解能力。文件產生、業務規則提取、依賴關係描述、基於文件行為產生測試案例，這些都是高價值、低風險的人工智慧應用，能夠大幅縮短傳統上成本最高的人工現代化階段。在翻譯之前，請務必先完成這些工作，因為理解能力會影響後續的每個決策。
將 AI 翻譯用作草稿產生器，而非最終版本。 AI翻譯產生的是 Java 或 Python 的初始程式碼，需要開發人員進行審查、修正和驗證，而不是無需人工審核即可部署的生產就緒程式碼。將 AI 翻譯輸出視為草稿，既能降低翻譯成本，又能確保等效性驗證所需的人工責任。
不要將人工智慧翻譯節省的成本計入驗證成本。人工智慧可以縮短生成翻譯程式的時間，但無法縮短驗證翻譯程式與原程式等效性的時間。驗證階段的預算應獨立於人工智慧翻譯所節省的成本，因為翻譯速度的提升並不會縮小驗證範圍。
首先要建構結構基礎。缺乏結構基礎、精確的依賴關係圖、完整的程式清單和資料模式清單的AI理解工具，在程式碼最複雜的地方，其理解結果往往不完整。最需要AI理解的程式通常也是最複雜、跨程式依賴性最強，並且最有可能超出AI僅憑原始碼所能準確分析範圍的程式。
SMART TS XL 支援人工智慧增強型 COBOL 程式碼理解
SMART TS XL 提供結構分析基礎，使人工智慧對 COBOL 投資組合的理解是準確的，而不是機率性的。
靜態程式碼分析功能可以產生人工智慧理解工具所需的程式層級結構資料：列舉每個 EVALUATE 條件、擷取每個 COMPUTE 公式、描述每個資料存取模式。當人工智慧文件工具以這些結構資料為上下文處理原始程式碼時，它們產生的描述將基於程式碼的實際內容，而不是基於類似程式的典型行為。
應用程式依賴關係映射提供了人工智慧上下文視窗無法同時容納的跨程式上下文。依賴關係圖顯示了 CUSTPROC 的 14 個呼叫者、47 個副本共享者以及 3 個資料流輸出，使人工智慧理解工具能夠全面了解程式在專案組合中的角色，而無需所有依賴程式同時位於同一上下文視窗中。
遺留系統現代化分析能夠產生人工智慧理解無法單獨可靠產生的死程式碼清單和複雜性分佈：哪些程式無法從生產環境存取（排除在範圍之外），哪些程式的複雜性最高（理解錯誤代價最高），以及從實際 FD 條目而不是文件中得出的資料遷移範圍是什麼樣的。
企業搜尋功能使結構清單可查詢，從而支援 AI 輔助理解：尋找實現特定模式的每個程序、具有超過 N 個條件的每個 EVALUATE 區塊、存取特定資料集的每個程序，這些查詢將 AI 理解建立在結構證據而非訓練資料機率之上。
對於已經將人工智慧納入現代化工具鏈的組織而言， SMART TS XL的結構分析層使 AI 能夠準確地理解投資組合規模，解決了上下文視窗限制、跨程式邏輯的幻覺風險以及將結構分析與機率生成分開的確定性差距。
人工智慧改變了理解的成本，但沒有改變證明的成本。
2026 年發生的變化在於理解的成本。人工智慧極大地降低了理解 COBOL 程序的功能、記錄其業務規則、描述其行為以及確定其在產品組合中的位置的成本和速度。這對現代化經濟做出了真正意義上的重大貢獻。對於以往需要數週專家投入才能完成理解階段的程序，人工智慧可以在數小時內產生理解草案，供專家審查和完善，而無需從頭開始建立。
不變的是驗證成本。行為等效性驗證、平行運行、監管審批、資料遷移驗證，這些環節依然如人工智慧出現之前一樣，無論理解和轉換階段完成得多麼迅速，它們都會消耗現代化預算的40%到50%。 IBM在2026年2月23日的預言是正確的：轉換幾乎無法捕捉到真正的複雜性。真正的複雜性在於行為等效性的驗證，而這種複雜度並不會因為轉換速度的提升而降低。
在COBOL現代化改造中，那些能夠有效利用人工智慧的組織，會投資於人工智慧真正卓越的理解能力，並將人工智慧翻譯視為人工審核的起點，而非可直接部署的成品。他們明白，專案前期成本的降低並不意味著專案後期成本的降低。他們會建構必要的結構分析基礎，確保人工智慧理解能力在專案組合層面（即最重要的理解工作發生的地方）能夠準確無誤。
