COBOL 是什麼？從銀行核心系統到 AI 程式現代化，讀懂一門仍在運作的老語言

TARAISG｜資料查閱：2026 年 10 月 31 日｜程式語言、金融科技、企業系統現代化

本文以公開原始文件、台灣企業公開招募資訊及技術文件為依據；架構與示例屬教學設計，不代表任何特定銀行的內部實作。文中程式片段為簡化教學示例；本文未執行銀行系統遷移或產品實測。

一家銀行要推出新的手機功能，看起來只需讓使用者按下轉帳按鈕，再由後端 API 回傳餘額。但如果真正記帳、計息與交易結算的核心系統已有數十年歷史，工程團隊遇到的問題可能不是「怎麼寫 App」，而是「如何在不改變帳務結果的前提下，讓新的介面與舊有系統合作」。

在這類系統裡，COBOL 不是歷史課本中被遺忘的語言，而可能是企業每天執行的重要商業規則。2026 年，中國信託商業銀行公開的核心系統工程職務說明，直接列出 IBM Mainframe、AS400 與 COBOL，並提及既有系統維運及 Open Platform 現代化工作。這不是對台灣所有銀行的普遍估計，卻是足以說明 COBOL 在本地產業仍有實務需求的具體證據。[S11]

另一方面，生成式 AI 正在改變理解舊程式與系統遷移的方法。IBM 的 watsonx Code Assistant for Z 與 AWS Transform for mainframe 都將程式分析、文件化、轉換或測試納入現代化流程。這帶來一個值得企業決策者正視的問題：如果 AI 可以協助把 COBOL 改寫成 Java，企業是否就該立即汰換既有系統？[S6][S8]

答案並不簡單。COBOL 的真正價值不在程式碼的年齡，而在程式碼承載的商業語義；現代化的首要成果不是語言變新，而是在可控制的風險下，讓業務能力更容易維護、擴充、驗證與交付。

一、COBOL 是什麼？先從名稱與用途理解

COBOL 是 Common Business-Oriented Language 的縮寫，通常譯為「通用商業導向語言」。它是為商業資料處理而設計的高階編譯型程式語言，傳統語法接近英文敘述，特別重視結構化紀錄、批次處理及十進位數值運算。IBM 在 2026 年更新的介紹中，也將高精度定點十進位計算列為 COBOL 的重要特性。[S1]

「商業導向」不代表 COBOL 只會算加減乘除，而是它把當時企業最重要的處理需求直接放在語言設計中心：輸入大量固定格式的交易紀錄、依條件逐筆檢查、計算應收應付金額、更新帳務資料、產出報表，以及在出錯時留下可追蹤的處理結果。當企業一天有許多交易必須依相同規則執行時，這些能力往往比漂亮的前端介面更根本。

可以用一個分層的比喻理解。手機銀行的使用畫面像商店櫃台，API 像送件窗口，而核心帳務程式像後方會計室。顧客可以使用新版櫃台，但如果會計室的規則決定什麼時候扣款、何時認列交易、如何計算利息，就不能只替換介面便宣稱完成整間商店的改造。

必須區分 COBOL 與大型主機。COBOL 是程式語言，Mainframe 是一種企業運算平台。 許多 COBOL 應用運行在 IBM Z 與 z/OS 環境，但 COBOL 並不只能在大型主機使用。開源的 GnuCOBOL 可以在 Linux、Windows、macOS 等系統編譯 COBOL 程式，顯示語言與硬體平台並非同義詞。[S5]

這也解釋了為什麼「把 COBOL 改成 Java」與「把大型主機搬到雲端」是兩個不同決策。企業可能保留大型主機而改造應用，也可能把 COBOL 程式移到其他執行環境，或以 API 方式延續現有核心服務。決策必須先釐清哪些部分需要改變，而非預先假設整套系統應被取代。

二、1959 年的問題，為什麼今天還有意義？

1959 年的電腦產業與今日截然不同。不同廠商的電腦常使用各自的語言與工具，企業若更換機器，既有程式可能需要大幅重寫。當時政府與商業機構希望建立一套更容易閱讀、且能在不同品牌電腦間移植的商業程式語言。

美國國家歷史博物館與電腦歷史博物館的資料指出，COBOL 在 1959 年由政府與產業人員合作研擬，1960 年已有跨不同廠商電腦執行同一套 COBOL 程式的展示。早期設計受到 FLOW-MATIC 等語言影響，Grace Hopper 對前身技術與整個發展方向有重要貢獻，但把 COBOL 說成由她單獨創造，會忽略實際參與規格形成的委員會及多位設計者。[S2][S3][S4]

這段歷史留下兩個長期課題。第一，企業希望使用不被單一硬體廠商完全綁定的業務程式。第二，企業需要讓程式碼可以被後來接手的人理解。COBOL 的英文式描述，正是對這兩種需求的回應。

由於語言具有跨平台的企圖，它並沒有因最初使用的電腦退役而一同消失。企業逐年加入新的帳務規則、產品條件、異常處理與介接系統，讓原本的程式逐漸成為龐大的業務知識庫。今天的現代化難題，往往是數十年業務決策被累積在程式碼與作業流程中，而不是單純因為當年工程師選擇了一門老語言。

讀到這裡，應該修正一種常見說法：COBOL 並非「1959 年發明後完全沒更新」。ISO／IEC 公開標準資訊顯示，ISO/IEC 1989:2023 是規範 COBOL 語法與語義的國際標準版本；截至本文查閱時，ISO 網頁也顯示新一輪標準草案正在進行。標準持續演進不代表每家企業都升級到最新語言特性，卻足以反駁「COBOL 已經沒有正式標準」的錯誤印象。[S12]

三、COBOL 到底怎麼寫？認識四個主要區段

COBOL 經典程式常由四個 Division 組成：Identification、Environment、Data 與 Procedure。它們分別負責描述程式本身、執行環境、資料結構與處理程序。初學者可以先理解這種結構化思考，再決定是否深入版本差異、編譯器方言與大型主機工具鏈。

下面是一段刻意簡化的教學範例。它從時薪與工時算出薪資，不涉及任何真實企業帳務規則。實際開發時還需處理變數精度、稅額、異常值、輸出格式及程式部署環境。

       IDENTIFICATION DIVISION.
       PROGRAM-ID. PAYCALC.
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01 HOURS-WORKED PIC 9(3) VALUE 160.
       01 HOURLY-RATE  PIC 9(4) VALUE 200.
       01 TOTAL-PAY    PIC 9(7) VALUE 0.
       PROCEDURE DIVISION.
           COMPUTE TOTAL-PAY = HOURS-WORKED * HOURLY-RATE
           DISPLAY TOTAL-PAY
           STOP RUN.

PIC 9(3) 描述三位數的數值欄位，PIC 9(7) 則描述七位數的數值欄位。WORKING-STORAGE SECTION 是工作資料定義區，PROCEDURE DIVISION 則是實際執行邏輯的所在。這種寫法以完整敘述告訴程式如何操作資料，和 Python 常見的短小語法風格很不同。

在實際的金融資料裡，難點通常不是乘法，而是資料定義。金額有多少整數位、多少小數位？負值如何表示？不同檔案是否使用相同編碼？四捨五入與截位有何區別？IBM 的 Enterprise COBOL 文件指出，COMP-3 對應 packed decimal，採用十進位壓縮儲存；它與一般二進位或浮點欄位不能只從名稱推定結果相同。[S9]

假設系統要計算每筆交易的手續費，且業務規定「未滿某門檻免收費、特定帳戶另有費率、海外交易使用不同幣別小數位」。即使只有一段簡短程式，背後也可能包含合約、作業規則、法遵要求以及多年後新增的例外條件。這些條件如果沒有被完整辨識，換一種語言撰寫仍可能算出錯誤結果。

一個容易被忽略的技術細節：小數不等於浮點數

某些程式語言的二進位浮點運算，無法精確表示所有十進位小數。金融運算若沒有明確採用適當的十進位表示、精度及捨入規則，就可能在大量交易或逐步累計時產生差異。COBOL 強調十進位資料處理，是它受到企業帳務應用重視的重要理由之一。[S1][S9]

這不表示 Java 或 Python 不能正確計算金額。Java 的 BigDecimal、Python 的 decimal 等方法，都可以在正確設計下實現精確的十進位計算。真正的重點是：遷移時必須明確指定數值語義，而不是只翻譯表面上的運算式。

四、COBOL 與銀行核心系統的關係

銀行的核心系統包含帳戶、存放款、轉帳、帳務結算、對帳及相關交易處理。不同銀行的架構差異很大，不能將某一種大型主機流程描述成全部金融機構的共同架構。但從功能角度來看，核心系統的基本要求相近：對每一筆交易有一致的規則、可追溯的狀態，且異常情況不得任意重複扣帳或遺漏記錄。

以轉帳為例，使用者在手機介面輸入金額後，交易可能要經過身分驗證、可用餘額檢查、交易限額檢核、帳務處理、紀錄保存、通知及後續對帳等步驟。真正複雜的是各步驟之間的狀態關係，特別是網路中斷、操作重試、部分流程完成或外部系統無回應時，究竟該如何確保最後帳務一致。

這個複雜性並非 COBOL 獨有。用 Java 寫的新系統同樣會遇到重試、交易一致性及對帳問題。只是 COBOL 系統經常承載長期累積的規則，而原始需求文件可能早已散落或不存在。當資深工程師退休、組織改制、產品規則多次調整時，工程團隊若只看使用畫面，往往看不見完整業務脈絡。

台灣的可核實案例提供了一個具體觀察點。中國信託公開的核心系統工程師職務提到既有 IBM Mainframe／AS400、COBOL 開發維運，也涵蓋國內存放款、通匯、國際匯款及貿易融資等業務。這份公開職缺只說明該職務範圍，不代表我們得知銀行內部各子系統的精確架構、程式碼比例或實際遷移進度。[S11]

換言之，如果有人宣稱「台灣全部銀行都使用 COBOL」，需要特定的可靠調查才能支持；如果有人宣稱「COBOL 完全沒有新人才或新開發」，同樣忽略公開招募資訊中的持續維運與優化需求。比起二選一的論述，較有用的做法是釐清哪些業務功能仍依賴它，以及這些依賴能否逐步降低。

五、為什麼企業不直接把 COBOL 全部換掉？

真正的企業系統不是一個可以獨立替換的程式檔案。它通常連接資料庫、批次排程、交易處理中介軟體、訊息交換流程、身分驗證、報表與其他內外部系統。AWS Transform 的官方文件所列處理對象，就包含 COBOL、JCL、CICS、BMS、Db2、VSAM 與相關程式資產，說明現代化範圍遠超過某一種程式語言的文字檔。[S7]

假設某銀行想更新一個手續費模組。工程師不只要理解費率公式，還要知道交易何時被認列、補帳是否重跑、月結批次是否調整金額、舊資料如何回溯，以及與其他系統的欄位長度是否相容。若忽略其中一部分，新的程式即使可編譯、可執行，也未必能產生與原系統一致的業務結果。

企業不急於全面汰換，通常可以從五種條件理解。第一是轉換風險，包括帳務與服務中斷。第二是相依關係難以一次盤清。第三是現有系統已滿足重要的可靠性要求。第四是新系統未必能立刻提供足以抵銷轉換成本的業務收益。第五是人員同時具備舊系統、現代架構及金融規則專業的組合不易建立。

這些理由並非永遠不轉型的藉口。企業若因技術能力不足而每次改動都要等待數月，或無法對外提供安全可控的介接方式，那麼維持現狀同樣是風險。不能只問「更換有多危險」，也要問「繼續不更換會造成哪些機會成本與控制缺口」。

IBM 在 2026 年的現代化說明中，特別區分「程式碼翻譯」與「平台現代化」。前者是把某段邏輯換一種語言表示，後者涉及架構、交易韌性、安全、資料、營運模式及長期治理。這個區分應成為任何現代化提案的起點。[S10]

六、COBOL、Java、Spring Boot、Python，彼此應如何定位？

COBOL 以商業資料與交易處理為核心；Java 是廣泛使用的通用企業應用開發語言；Spring Boot 是建立 Spring 應用的框架工具，不是一種新程式語言；Python 則廣泛用於資料分析、自動化與 AI 開發。這些技術不是互相排斥的年代標籤，而是可能一起存在於同一套企業資訊架構。

一個合理的組合可能是：手機介面呼叫 Java／Spring Boot 建立的 API 服務，API 經過授權與交易檢查，再與既有核心交易服務互動；資料分析團隊則使用 Python 整理匿名化後的營運資料。這是概念性情境，不代表所有金融機構都採用該架構。

這種方式的好處是可以改善新產品交付速度，同時將最敏感的核心系統變更縮到可控範圍。但相應的代價是多一層介接與維運複雜性，必須處理端到端觀測、權限、版本相容及異常追蹤。企業不能只計算 API 新增速度，卻忽視中介層帶來的長期治理成本。

七、現代化不是一條路：保留、封裝、重構、重寫與替換

系統現代化常被誤認為「把一種語言改成另一種語言」。實際上，先決定業務能力應如何持續提供，才有辦法選擇適當的技術路徑。IBM 的應用現代化指引介紹過 Rehost、Replatform、Refactor、Rearchitect、Rebuild 與 Replace 等不同類型；COBOL 現代化也不應跳過這種分類思考。[S13]

第一種路徑是保留並優化現有核心。適用於系統仍穩定、改動需求低、交易能力具關鍵性，而且現有平台服務水準符合要求的情況。行動包括更新編譯器、補齊測試、清理程式相依、建立知識文件與改善操作監控。這不是完全不做事，而是優先提高可維護性和可驗證性。缺點是對新業務需求的彈性可能仍受舊架構限制。

第二種是封裝為服務。先讓現有核心透過受控 API 或服務介面與新通路合作。適用於使用者體驗急需改善、核心邏輯短期難以變動的情境。優勢在於可以分階段交付業務功能，並讓新的產品團隊與核心系統有清楚契約。風險則是介接層若沒有設計良好，可能形成更多相依與單點故障。

第三種是重新部署或移轉執行平台。部分企業希望將既有語言與商業邏輯保留，但調整底層執行環境。這類選項必須評估編譯器方言、檔案格式、資料庫介接、批次排程、效能與授權成本。不能因為「原始碼不用全部重寫」就假設遷移容易；環境差異本身可能引發大量隱性問題。

第四種是局部重構或重新設計。選擇一個相依可控的業務領域，例如對外查詢服務、報表計算或特定規則引擎，重新建立模組與服務邊界。優點是可以把複雜的舊系統逐步分解。難點是先要知道模組間的真實資料與作業依賴，否則原本共享的狀態會被拆散，卻沒有可靠的替代協調機制。

第五種是重寫或以套裝產品替換。如果既有系統的功能已難符合商業需求、或相關業務具有成熟可採購的產品，企業可能考慮從新設計。這並不必然比較差，但必須承擔重新定義業務規則、資料轉換、雙系統運行、使用者教育與切換的成本。尤其在金融業，所謂「完整重寫」往往包含大量特殊交易情境的再驗證。

這張表不是購買建議，也不代表其中某一種選項普遍較省錢。實際選擇要回到業務價值、現有風險、資料相依、團隊技能和測試能力。更重要的是，許多大型企業會採取混合路線：核心帳務保持穩定，外圍服務逐步抽離，某些元件另行重構，已無商業價值的舊功能則停止維護。

決策案例：如果管理階層要求「一年內全部改成 Java」

首先應問的不是要找幾名 Java 工程師，而是這個要求想改善什麼。如果企業的首要問題是新增產品功能緩慢，可能只需要抽出可重複使用的服務介面；若問題是關鍵工程師退休，應先建立知識轉移、測試資產與關鍵服務文件；若是硬體或授權成本難以負荷，才需要進一步計算平台替代方案。

當不同問題都被包裝成「語言落後」，管理者很容易核准規模巨大卻缺少明確驗收依據的轉型專案。相反地，若先定義具體成果，例如「新增一項交易查詢服務所需的交付時間」或「核心批次在故障後可恢復的能力」，才能知道重構、封裝或換平台哪個選擇更值得做。

八、AI 如何幫助 COBOL 現代化？2026 年有哪些可查證進展？

生成式 AI 對 COBOL 專案的價值，首先是降低理解成本。面對缺少註解、跨檔案、跨批次、跨交易程式的舊系統，工程師往往必須反覆追查資料欄位與呼叫關係，才能回答一個看似簡單的問題。AI 若能在受控程式庫內輔助整理相依圖、摘要程式邏輯與產出待確認的文件，便有機會讓知識移轉效率提升。

其次才是程式轉換。當企業已知某個領域的輸入、輸出與業務規則，AI 可以協助將部分 COBOL 程式轉成 Java 或其他形式，並提出測試案例。但產生看似合理的程式碼，與維持金融交易的功能等價，是兩個不同的品質門檻。後者需要測試資料、真實邊界條件與可以被重現的驗收證據。

IBM 的方向：分析、重構、轉換與測試

IBM watsonx Code Assistant for Z 是面向大型主機應用現代化的工具。IBM 在 2025 年公布可建立或更新 COBOL 程式碼的能力，並於 2025 年底發布、2026 年更新的產品公告中介紹以代理式工作流程整合相關現代化操作。[S6][S14]

更具研究價值的是 IBM Research 於 ICSE 2026 發表的 COBOL 轉 Java 方法：它沒有只把完整 COBOL 程式丟入大型語言模型，而是先用靜態分析推導類別、方法與控制流程，再使用 LLM 輔助轉換程序邏輯。論文摘要描述的研究樣本包括 20 個 GenAPP 程式及 10 個客戶應用，並使用自動化 LLM-as-Judge 框架，依研究定義的結構與功能品質指標進行比較。這類模型評分不等於正式系統的功能測試通過率。這些測試結果屬於論文特定樣本與方法，不應延伸成所有銀行程式都能達成相同轉換品質。[S15]

這種混合式技術路線反映出一個重要原則：程式結構分析負責約束，AI 生成負責提出候選解，測試與工程審查負責驗證。 對大型程式庫而言，單一對話直接生成所有新程式並不是有根據的最佳實務。

AWS 的方向：依目標進行盤點、分解、重構和驗證

AWS Transform for mainframe 在 2025 年正式推出，官方文件描述其可分析主機應用資產、產生文件、規劃業務領域分解，並將部分 COBOL 工作負載轉成 Java。2025 年底的功能說明又加入更完整的重構、重新設計與測試支援。[S7][S8][S16]

AWS 文件特別強調使用者需要提供相關來源資產，例如 COBOL、Copybook、JCL 以及相依文件；在部分流程中，工具也會要求人員確認規劃結果或中間產物。換言之，產品並不是在沒有上下文的情況下「自動理解所有銀行系統」。使用者仍須確認資料來源、權限、支援範圍、目標架構及驗收要求。[S7]

對台灣企業而言，還應將資料駐留、雲端上傳授權、跨境傳輸、採購規範與內部資安要求納入評估。AWS 文件指出，服務處理位置可能涉及與使用區域不同的資料處理條件；是否可以使用某項雲端 AI 工具，不能只以功能清單判斷。[S7]

AI Coding 助手能不能代替專用現代化平台？

Claude Code、Codex 或一般 IDE 內的 AI Coding 助手，可以協助閱讀程式、搜尋相依、提議測試及產生說明文件。對規模較小、可在授權環境內取得完整程式上下文的模組，這是值得測試的輔助方法。但在大型金融核心系統，往往還涉及 JCL、CICS、資料庫、批次排程、特定編碼及平台服務等相依性。通用 Coding 助手並不會因能生成 Java 程式，就自動具備所有平台遷移、資料轉換與金融法遵能力。

更精確的選型問題應是：工具能閱讀哪些實際資產？是否能從程式建立可驗證的相依關係？能否追蹤它是根據哪些原始碼和規則提出轉換？如何產生可重跑的測試？人工審查發生在哪一個階段？若其中一項缺乏明確答案，就不能把「成功示範了一支程式」視為可大規模正式遷移。

九、AI 轉換的最大陷阱：程式相似，不代表商業結果相同

開發者常以程式可以編譯、測試通過、表面流程一致，判斷轉換是否成功。但核心交易最終需要的是對同一組有效輸入，能產生正確的業務結果及可接受的系統行為。這包括數值結果，也包括紀錄順序、失敗狀態、重試規則、並行處理與副作用。

以下列出六種值得列入轉換驗收的差異。它們不是某一個工具的已知缺陷，而是跨語言、跨執行平台遷移常見的技術風險類別。

第一，十進位精度與捨入。 舊程式可能以固定十進位儲存金額。若新程式把欄位轉成不適合的浮點型態，或採用不同四捨五入方式，少數案例也許看不出差異，但大量運算或結算就可能偏離。必須明訂金額資料型態、精度、尺度、溢位處理與捨入時機。[S9]

第二，欄位格式與字元編碼。 固定長度紀錄的空白補齊、前導零、正負號、編碼與日期格式，都可能影響與上下游的對接。新程式若以一般 JSON 欄位替代傳統檔案紀錄，必須確認資料契約及其消費者是否同步修改。

第三，批次處理的順序。 一筆資料在日結前處理或日結後處理，對利息、手續費或報表可能不同。更換系統後，若排程順序被改動，即使每個獨立模組的計算都正確，整體業務結果仍有可能不一致。

第四，例外處理。 原系統碰到無效帳號、負值、重複交易或缺少檔案時，可能有特定回覆碼和補救流程。AI 在翻譯程式時若把不常見的分支視為可以刪除的冗餘邏輯，就可能造成最難發現的事故。

第五，並行與交易一致性。 一個批次式作業改造成同步 API 後，原本不會同時執行的流程可能被並行呼叫。資料鎖定、重試與原子性必須重新設計，不能以原程式邏輯相同推論系統行為相同。

第六，非功能需求。 即使對帳完全一致，仍須確認交易吞吐量、延遲、可用性、備援、資安、稽核紀錄、監控、恢復時間及災難復原。對某些系統來說，這些條件比程式碼可讀性更直接影響服務可否上線。

IBM 在 2026 年討論 AI 程式轉換時，也提醒市場不應把程式碼翻譯直接等同平台現代化。[S10] 對採購單位而言，廠商展示轉換成功的畫面只是起點，真正需要確認的是如何證明差異已被完整盤點、如何處理無法證明的部分，以及何時必須停止擴大部署。

十、企業如何驗證新舊系統一致？從 Golden Dataset 做起

最實用的現代化起點，往往不是馬上購買新工具，而是建立一套可以驗證舊系統實際行為的測試資產。對開發團隊來說，這包括 Golden Dataset、Reference Output、差異報告與可追溯的規則來源。對業務主管來說，它則是明確的交付驗收標準：同一類交易在新舊系統中，結果應在什麼條件下相符。

1. 先列出可辨認的業務情境

例如以一個虛構的手續費計算模組為練習，列出一般交易、零金額、門檻邊界、上限金額、特定會員等級、不同幣別、無效交易、同一交易重送與結算時段差異。這些情境不應從 AI 隨意生成後就直接當正式測試。業務單位需要確認每個條件代表的實際政策和規則。

2. 建立可重複輸入的資料集

每筆資料應含測試案例 ID、輸入欄位、假設的業務條件、預期處理結果與資料來源。若需使用真實交易，必須先評估個資、金融資料及商業機密處理規範。實際客戶資料不應為了方便測試，直接交給未獲授權的外部模型。

3. 執行舊系統並保存參考輸出

Golden Dataset 的參考答案，應由經授權且可控制版本的舊系統、已確認的業務規則或雙方核可的測試基準產生。若舊系統本身存在已知錯誤，就要將「保留舊行為」與「依法規或新需求修正行為」分開。不能讓有缺陷的歷史輸出自動成為不可質疑的唯一正解。

4. 執行候選新系統，建立差異表

測試應至少比對處理狀態、金額、手續費、稅額、交易時間與必要的狀態變更。差異報告要指出哪一個案例、哪一個欄位、哪一個版本不一致。對帳不能只有整批總額相等，因為兩筆交易互相抵銷的錯誤也會讓總額看似正確。

5. 分類差異，再決定是否接受

可以將差異分類為 MATCH、EXPECTED_CHANGE、UNEXPECTED_DIFFERENCE 及 BLOCKED。EXPECTED_CHANGE 必須具有已核准的新業務規則，不是開發者單方面覺得合理；BLOCKED 則表示因環境或資料不完整而無法判定，不能被算入成功案例。

6. 追蹤測試覆蓋與變更證據

測試通過率不能單獨代表系統安全。至少還要記錄哪些規則已測試、哪些例外分支尚未測試、哪些上下游系統尚未介接、由誰核可，以及哪個版本完成驗收。可採用程式碼版本、規則版本、測試資料版本與測試執行紀錄組成完整證據鏈。

下面是可供教學或專案啟動使用的示意紀錄，數字為人工虛構，不是銀行實測資料。

實務上，還需依風險建立不得通過的條件。例如任何未經核准的帳務差異、重複記帳、資料遺失或交易權限繞過，都應阻擋正式切換。反過來，顯示格式的非關鍵差異，可能只需要人工確認。不應以單一的「99% 通過率」取代風險分級的上線決策。

十一、一個具體的示意專案：將舊手續費計算服務逐步現代化

假設一家虛構金融服務公司有一支運行多年的 COBOL 手續費程式。行動應用團隊希望新增即時試算功能，但既有核心只有每日批次計算紀錄。高層提出「把 COBOL 改寫成 Spring Boot」的要求。若直接開發，可能很快完成一個可回傳試算值的 API，卻無法確保它和實際入帳金額一致。

專案首先應重新定義目標：在不影響既有正式結算的情況下，提供能準確反映目前核准費率的試算能力，並降低未來改動費率規則的工作時間。這個目標比更換語言更清楚，因為它指向使用者真正想要的結果。

第一階段，工程與業務共同盤點現有計費程式。整理費率來源、優惠條件、幣別、起訖日期、批次觸發方式與例外檔案；將找不到規則文件的分支列為待訪談。這時 AI 可以協助為 COBOL 程式建立摘要與候選規則清單，但每一條規則都必須連回原始碼位置或業務文件。

第二階段，團隊使用經確認的歷史樣本、特殊邊界條件及人工設計案例建立 Golden Dataset。每個案例都保存原始輸入、舊系統參考輸出、規則版本及核可紀錄。團隊應刻意加入容易出錯的時點：跨日、跨月、費率生效日、免收條件結束日，以及同一交易由不同通道送入的情境。

第三階段，開發團隊在受控環境中產生候選 Java 計算模組。轉換過程不能假設原始程式中所有資料欄位都可以直接映射為相同型態；應明訂十進位精度、負數表示與計算結果格式。如果使用 Spring Boot 建立 API，也要定義授權、重試、錯誤回傳與版本契約。

第四階段，採用影子執行或離線對帳方式測試。正式結算仍由既有 COBOL 系統處理，新服務則讀取經授權的測試或鏡像請求，輸出獨立比較結果。必須確保影子流程不會重複寫入正式帳務。這個階段的成果不是「新服務已上線」，而是形成一致性報告與尚未解決的差異台帳。

第五階段，只有在業務規則、資安、效能、異常與營運恢復都達到核准門檻後，才考慮讓新服務承擔正式功能。若目標只是新增試算 API，原本的 COBOL 結算程式也許完全不需要被立即汰換；相反地，若新服務已經被證明可靠，企業可再評估下一段改造。

這個示意專案最重要的啟示是：每個階段都要產出可驗收的工作資產，而不是只產出更多程式碼。 可驗收的資產包括系統盤點表、規則對照表、測試資料、差異報告、上線門檻及回復計畫。當這些資產完整，後續要保留 COBOL、改寫 Java，或更換平台，決策才有依據。

十二、成本應該怎麼算？不要只比較 COBOL 工程師與雲端費用

管理者評估 COBOL 系統轉型時，最容易看見的是現有大型主機費用、軟體授權與工程人力；最容易低估的則是業務規則重新確認、測試環境、資料遷移、雙軌運行和切換失敗後的恢復成本。若只把原系統每年的維運支出，和新雲端服務的運算費用並排，就等於比較了不同範圍的成本。

一份有決策價值的商業評估，至少應建立兩個相互對照的情境。基準情境是假設未進行此次大型現代化時，企業仍需要投入多少維護、升級、資安與人才接班成本。候選情境則是在明確改造範圍內，新增的開發、遷移、驗證、資安、資料轉換、教育訓練與日後運營支出。兩者必須使用相同時間範圍、相同功能需求與一致的成本口徑。

另外，不應把帳面成本降低當成唯一收益。若新架構可以讓企業更快推出新商品、減少跨部門等待、縮短事故恢復時間，這些改善有可能產生更重要的商業價值。但企業必須先確立實際的基準測量方法，而不是從供應商的行銷案例中直接套用效益百分比。

例如某個系統目前每年需要大量人工處理批次失敗。候選方案宣稱能降低操作負擔，管理者應先確認每月有多少次失敗、每次需要多少人時、哪些失敗其實來自業務資料品質，然後再評估新的監控及自動恢復是否能處理。若問題根源是上游欄位錯誤，單純改寫 COBOL 並不能解決。

對高關鍵性的系統，風險成本也必須納入。不是任意假設事故發生機率，而是依企業有記錄的事故類型、恢復要求和治理政策設計測試與備援。不能量化的風險應清楚列為決策限制，不能因難以換算成金額就視為不存在。

以下提供管理階層使用的比較架構。它是方法範本，沒有套用任何特定企業的金額。

當企業使用這種方法，討論會從「COBOL 很老，應該換掉」轉變成「哪些問題已經造成業務損失，哪些改造能用可接受的風險改善它」。這才是系統現代化的合理投資邏輯。

如何避免轉型專案成為沒有終點的成本中心？

一個可行方式，是以業務領域而不是整個系統為單位規劃投資。每個領域設定明確入口、交付項、前置相依及退出條件，例如某類資料查詢、某一段計費邏輯或某個報表產出。每次完成後重新檢查成本、風險與收益，再決定是否擴大到下一批。

如果企業在一開始就要求「所有程式都必須轉成相同技術堆疊」，卻無法說明每個模組的業務價值，容易產生大量改寫工作，並把工程團隊的時間耗在低價值但難以驗證的功能上。相反地，若每一批次都能留下更好的業務文件、可重跑的測試和可追蹤的流程，即使最後選擇保留部分 COBOL，也已經降低未來維護與交接的風險。

十三、人才問題的核心，不只是找不到會 COBOL 的人

提到 COBOL，經常會出現「工程師即將退休」的敘述。這可能反映某些組織的真實挑戰，但不能未經調查便推論整個產業只剩高齡工程師，也不能因此主張年輕工程師不願學習。企業真正需要盤點的，是哪些知識只存在少數員工腦中，而不是用語言誕生年份推測人才狀況。

有些資深工程師熟悉特定批次、查核流程與多年例外處理；新進工程師可能熟悉 Java、API 與現代部署流程，卻不了解每個交易狀態的金融意義。若公司僅要求前者把程式改寫交給後者，可能交出了程式碼，卻沒有交出支撐系統運作的知識。

比較有效的知識移轉應該以工作案例為核心。請資深同仁從最近的異常帳務、重大改版與高風險規則開始說明：為什麼當年做出某個設計？遇到失敗時怎麼恢復？有哪些不能違反的順序？哪些輸出要交給會計、稽核或其他系統？年輕工程師則將這些資訊轉成可搜尋、可版本控管與可測試的知識資產。

AI 在這裡可當輔助整理者。它能提出程式流程圖草稿、把程式中的條件分支整理成候選規則、根據既有文件生成訪談問題，甚至建立測試案例初稿。但若原本程式就有不合理或未註記的行為，AI 未必能知道那是刻意設計、歷史相容要求還是應被修正的錯誤。因此每一項重要解釋仍需要領域專家確認。

更完整的能力組合應分為四個面向。第一是語言與平台能力，包括 COBOL、JCL、交易中介軟體、資料儲存及作業控制。第二是商業領域知識，例如存放款、利息、交易生命週期及對帳。第三是現代架構能力，例如 API、雲端整合、測試自動化及安全設計。第四是協作能力，包括需求訪談、文件化、跨團隊審查與事故處理。

從人才發展角度，培訓不必讓每個新進工程師都成為所有系統的專家。比較合理的是建立角色分工與共同語言：核心維運人員能理解新介面需求，現代服務開發者能閱讀必要的核心規則，業務分析師能辨認驗收案例，而主管知道哪些證據足以支持上線。這是一個跨職能學習問題，不只是教會幾條 COBOL 指令。

新手還值得學 COBOL 嗎？

如果有志投入銀行核心資訊、保險、政府大型資訊系統、主機維運或應用現代化，認識 COBOL 有直接的實務價值。台灣的銀行公開職缺也顯示，相關能力在特定職務仍被明確要求。[S11]

但如果主要目標是一般網站、AI 模型、資料科學或手機應用開發，COBOL 通常不會是第一個應學的語言。這不代表它沒有價值，而是學習順序應與職涯任務一致。對想進金融科技的新手，較合理的組合可能是先建立程式設計、資料庫、SQL 與 API 基礎，再依實際職務需求接觸 COBOL、主機作業和交易處理。

在徵才上，企業也應避免用「會 COBOL」一項條件取代完整職能評估。兩位都能看懂 COBOL 語法的工程師，一位能處理大型主機批次故障，另一位熟悉企業帳務對帳，仍是不同的工作能力。真正需要透過工作樣本與情境題辨識候選人能否在特定系統中安全完成任務。

十四、使用 AI 分析 COBOL 程式時，資料安全應先於效率

程式碼可能包含商業邏輯、資料結構、介接位址、內部檔案格式、錯誤代碼，甚至不應被分享的設定資訊。若工程團隊為求方便，直接把完整核心程式、真實交易記錄或機敏配置貼到未經企業核准的 AI 服務，可能在還沒取得開發效率以前，就先產生資料安全與合約上的問題。

正確的順序，是先辨別資料類型及允許處理方式，再選擇能符合企業要求的工具。對某些組織而言，使用經核准的企業雲端服務是可行選項；對另一些組織，可能需要隔離環境、私有部署或完全不允許外部模型接觸來源碼。兩者沒有單一標準答案，必須由實際的資訊安全與法遵要求決定。

有些團隊以為「程式碼沒有客戶姓名，就沒有敏感資訊」。實際上，交易控制條件、內部錯誤碼與權限邏輯也可能具有商業與資安敏感性。即使把個資欄位刪除，仍要檢查程式與測試資料是否保留可識別的線索或可利用的系統資訊。

實作時可建立三層輸入控制。最低風險的是自行編寫的簡化程式與虛構測試資料，適合公開教材與初步工具能力比較。第二層是經企業審查且已去識別化的受控程式片段，適合進行局部分析。第三層是包含核心邏輯或真實資料的完整系統資產，須依組織政策在授權環境內處理，並保留誰存取、何時處理、輸出去了哪裡的稽核證據。

此外，要評估模型是否會保留輸入內容、系統是否跨境處理資料、管理員能否設定權限及日誌、是否允許使用第三方外掛、能否限制外部連線，以及供應商對資料保存和刪除的具體承諾。這些屬於服務條件與組織治理的查核項目，不應假設任何工具預設符合所有金融機構要求。

最後應建立「AI 產出不得直接進正式核心環境」的控制。AI 可以生成候選程式碼，但是否有權合併、部署與更改關鍵交易規則，應由程式碼審查、測試、變更管理及授權流程決定。自動化可以協助加快重複性檢核，不能取消風險責任的歸屬。

十五、企業第一個 30 天可以做什麼？以診斷與證據為主

若企業正在討論 COBOL 相關系統的改善，第一個月不必以「完成大型遷移」為目標。更可行的是建立管理者看得懂、工程師能繼續使用的系統診斷與測試基礎。以下是一般性規劃範本，實際工作時程需依系統規模、授權、資安與人員可用程度調整。

第 1 週：定義要解決的業務問題。 管理者與業務負責人選定一個領域，說明目前困難、受影響流程及希望改善的結果。工程團隊列出該功能相關程式、批次、資料表、檔案、介接與主要操作窗口。若無法取得完整程式碼，直接標記資料缺口，不要以 AI 推測缺少的程式。

此週建議的交付品是一份單頁系統問題定義，附上功能邊界圖。內容至少包含業務目的、使用者、主要處理流程、現有風險、明確排除範圍、不可改變的要求與決策者。這可以避免專案在技術研究途中無限擴張。

第 2 週：整理商業規則。 由工程師與領域專家共同閱讀核心程式。AI 可協助產生候選規則與流程摘要，但每一條規則要連接到實際程式位置、批次設定或正式文件。遇到不同版本相互衝突時，保留衝突並指定負責人判定，不以模型產出的答案直接定案。

此週交付品是規則台帳。每條規則可用 rule_id、說明、來源、啟用條件、例外、業務負責人、驗證狀態及相關程式版本紀錄。若一條規則無法對應原始依據，就仍是推測，不應在正式改寫時被視為已核准的需求。

第 3 週：建立小型 Golden Dataset。 依選定範圍建立一般與例外測試，並取得可驗證的舊系統參考輸出。測試資料至少包含門檻值、空值、日期邊界、重複請求及失敗條件。對於無法安全重現的正式情境，建立模擬限制說明，避免誤判測試覆蓋。

這一週最重要的不是產生幾百條 AI 測試題，而是確認每條案例代表哪一個業務規則，以及測試結論能由哪些人驗收。若測試沒有業務代表簽認，工程團隊即使完成技術驗證，也可能無法判斷是否符合正式作業要求。

第 4 週：完成受控概念驗證與決策。 在隔離環境中，選擇一個小範圍試做文件化、局部重構或程式轉換。比較新舊結果，記錄未完成情境與控制缺口。最後回到最初的業務目的：這次示範是否證明某種改造路線值得進一步投資？如果沒有，保留研究結果並修正計畫，也比盲目擴大專案更有價值。

此週的決策報告不應只有示範影片與主觀感想，而應包含：已盤點的系統範圍、已確認的商業規則、測試覆蓋、差異類型、尚未解決的安全與平台問題、資源需求，以及下一階段是否可以啟動的判斷。這些資料可以成為專案採購、企業內訓及技術顧問討論的共同基礎。

一張可直接使用的系統診斷表

這張表可以先用一般試算表建立，不需要為了現代化本身再先開發一套大型管理系統。成熟的專案管理工具固然有價值，但只要缺乏清楚的規則、測試基準和核可責任，工具再完善也無法取代問題定義。

十六、常見的五個判斷錯誤

誤解一：老程式語言等於不安全

安全性與語言年代並不是相同概念。資訊安全取決於架構、存取控制、補丁管理、漏洞、設定、權限、監控與運維流程等因素。COBOL 系統可能有長期未修正的弱點，現代 Java 應用也可能因依賴套件、身分驗證或 API 設計錯誤而暴露風險。合理的討論應以系統實際控制狀態為證據。

誤解二：只要有 AI，就不必再理解 COBOL

AI 對於程式碼摘要、文件化與局部轉換很有幫助，但仍需要能解釋核心規則、判斷例外及管理營運風險的人。尤其當 AI 產生的程式通過表面測試卻漏掉業務規則時，缺少領域知識的團隊更難發現問題。工具降低了部分理解成本，並沒有取消知識驗證的責任。

誤解三：程式轉成 Java，就能直接上雲

把 COBOL 的程序邏輯翻成 Java，只是工作的一部分。原有系統可能依賴特殊資料格式、交易協調方式、批次排程及大型主機工具。新平台上必須重新設計或驗證同等能力，並完成效能、安全、資料與營運測試。IBM 與 AWS 的官方文件都顯示，現代化涉及比程式翻譯更廣的工作。[S7][S10]

誤解四：保留 COBOL 就等於拒絕創新

企業可以保留可靠的核心邏輯，透過新的 API、監控、資料服務與開發流程改善交付能力。若企業改造後能更快速、安全地提供新功能，技術上是否全面使用最新語言未必是最有價值的績效指標。真正要管理的是業務能力與技術風險，而非語言的名聲。

誤解五：一次全部重寫，一勞永逸

即使新系統成功切換，也會隨時間累積新需求、例外條件和維運責任。重寫不會讓複雜的金融業務消失，只會把它重新表達在其他架構與程式語言上。若沒有規則文件、測試基準和持續治理，新的系統仍可能逐步變成下一代難以維護的系統。

十七、把 COBOL 當作企業知識資產，而非單純技術負債

傳統的技術負債討論，常把難以維護的程式碼視為應被消除的對象。但在大量 COBOL 系統裡，程式碼同時可能是唯一完整記錄某些商業規則的地方。若企業只估算重寫成本，卻沒有辨識其中的規則與例外，便可能在清除技術負債的同時，意外丟失重要的營運知識。

因此，系統盤點需要兩本帳。第一本是技術負債帳，記錄難以修改、缺少測試、相依複雜與人才風險。第二本是業務知識帳，記錄重要規則、契約、法遵要求、異常處理、歷史決策與仍需保留的行為。這兩本帳必須相互連結，才能讓轉型決策同時看到改造成本與保留價值。

例如，一段程式可能使用難以閱讀的巢狀條件，屬於維護負擔；但其條件背後包含特定商品的歷史優惠、不同法域下的收費限制與合約約定。管理者真正希望處理的是程式結構難以維護，而非把規則本身一起刪除。若先整理成可測試的業務規則，後續即使重寫程式，也能更清楚區分既有義務與新業務需求。

另一種情況是系統裡存在不再使用的產品或歷史流程。這些功能不一定都值得原樣保留。企業需要對每條規則確認實際使用情況、保存要求和停用條件。當某段功能已無商業需求、也沒有必須保存的操作義務時，停止投入可能比花大筆成本改寫更合理。好的現代化不是無差別保存，也不是無差別推翻，而是辨識哪些能力值得持續投資。

這個思考可以延伸到許多企業系統。舊版 ERP、Excel 巨集、Visual Basic、Access 資料庫、手工批次報表，都可能藏有難以移轉的工作知識。COBOL 之所以值得理解，不只因為銀行使用它，更因為它是一個清楚的案例：當技術載體與商業規則長期綁在一起，轉型首先是一項知識重建與風險控制工程。

進階延伸一：一個 COBOL 服務背後，還有哪些容易被忽略的元件？

對不熟悉大型主機的讀者來說，容易把「COBOL 系統」想成一大堆 COBOL 原始碼。但企業資訊服務常由許多不同層次協作而成。要判斷一個模組能否抽離，必須從實際呼叫關係及資料流向觀察，不宜僅依檔名或語言分類。

COBOL 程式通常負責特定的資料與業務處理。它可能讀取資料、進行條件判斷、計算金額、呼叫其他程式，最後寫入紀錄或回傳結果。但同一個業務結果，可能需要多支程式共同完成，甚至在不同時間點被補帳或結算。只閱讀其中一支主程式，未必可以確定交易的完整生命週期。

Copybook可以理解為重複使用的資料或程式定義片段，常用於維持不同程式對共同資料結構的理解。它看似不是主要業務邏輯，但只要欄位長度、排列方式或型態發生變化，就可能影響所有使用該定義的程式。因此轉換工具若只閱讀主程式、缺少相關 Copybook，便可能失去正確理解資料的基礎。AWS 的主機現代化文件即明確要求在輸入資產中考慮 Copybook。[S7]

JCL在 IBM z/OS 的批次工作中具有重要角色。它不是另一種商業計費語言，而是協助說明作業如何執行、使用哪些資源及工作步驟。對現代化而言，一支計算程式即使被正確轉成 Java，如果原有批次執行順序、檔案配置或失敗處理沒有被重建，仍可能無法得到相同的業務結果。因此 JCL 的盤點通常與 COBOL 原始碼同樣重要。[S7]

CICS是大型主機交易處理環境中常見的技術，與線上交易應用相關。在某些既有架構下，使用者送入的一個請求需要由交易處理環境協調後，再交給相關應用邏輯執行。把程式改成一般後端 API 時，需要重新理解既有的交易上下文、錯誤回傳及資源管理方式。開發者不能直接假設兩者的執行模型相同。

Db2 與 VSAM則關係到資料如何儲存與存取。Db2 是資料庫技術，VSAM 涉及特定資料集與存取組織。當程式搬離原始環境，資料並不會自動變成適合新平台的關聯式表格；索引、鍵值、欄位編碼、資料轉換及交易一致性都可能需要重建。若只遷移程式而未處理資料語義，新的服務便可能在最關鍵的部分失敗。[S7]

這些元件共同說明：所謂「主機應用現代化」，其實是一個從程式、資料、控制流程到運維方式的連續改造。對技術架構師而言，最有用的初步產出不是某種語言的行數統計，而是一張說明業務動作如何穿越各元件的依賴圖。對業務主管而言，則應確認其中有哪些步驟必須保留原本語義、哪些可以重新定義，以及哪些相依屬於已過時的歷史負擔。

為什麼只靠搜尋程式碼中的關鍵字不夠？

工程師可能利用程式庫搜尋快速找到某個欄位或費率名稱，但這不能保證找到所有間接使用它的程式。某些規則可能透過共用資料結構、批次產出的中間檔或資料庫欄位傳遞；另一些則可能由外部參數控制。即使 AI 能整合多個檔案的搜尋結果，也需要有系統地查明呼叫關係、資料讀寫位置與執行時間。

因此，盤點報告應將證據分成三類：直接引用的來源碼、可追蹤的系統配置與經業務確認的作業流程。缺少其中一類時，可以先形成假說，但應保留待驗證狀態。這種做法比要求 AI 輸出一張「完整系統架構圖」更慢一些，卻有助於避免把不確定的推論當成確定事實。

進階延伸二：如何設計真正能抓到問題的測試，而不是只有漂亮的通過率？

如果測試只包含一般情境，AI 轉換的程式往往很容易展示看似成功的結果。真正具有辨識力的測試，應該讓系統在邊界、例外及狀態改變的條件下接受檢驗。這一原則不只適用於 COBOL，也適用於其他高關鍵性業務系統。

以費率生效日為例，系統可能規定某項交易在指定日期後改採新費率。這時至少要測試生效前最後一刻、生效日第一筆交易、跨時區資料、延遲送達的交易以及事後補入的歷史資料。單純把交易日期改成新的一天，不代表已經覆蓋所有實務情境。團隊還必須確認規則究竟依「交易建立時間」「入帳時間」或其他正式業務時間判斷。

以金額計算為例，團隊應建立門檻上下界、最大允許金額、最小幣別單位、負值、退款、零金額與溢位等案例。對容易累加的小額差異，還要測試長時間或多次交易後的彙總結果。即使新系統使用精確十進位型態，若捨入發生在不同計算步驟，最後結果仍可能不同。[S9]

以重複送件為例，測試應確認第一次請求成功後，相同識別碼的第二次請求如何被處理；第一次請求超時但後端其實已完成時，重試會產生什麼結果；不同識別碼卻代表同一業務意圖時，如何由業務規則判定。這些測試應同時檢查回覆結果與實際資料狀態，不能只看 API 回傳成功或失敗。

以失敗恢復為例，團隊可以在經授權的隔離環境內模擬處理中斷、連線失敗、部分紀錄寫入及批次重新啟動。驗收應確認系統是否依規則恢復、能否識別已完成的作業，並留下足夠紀錄供追查。這些情境通常不適合在未經核可的正式環境直接進行故障注入。

以資料轉換為例，不能只核對記錄總筆數與總金額。還需要確認唯一鍵、主從關係、編碼、空值、歷史版本、查詢條件及時間欄位。若資料由固定長度紀錄轉向新資料庫，應對每一項欄位定義進行映射驗證，並檢查轉換後是否出現截斷、補零、補空白或排序差異。

Golden Dataset 的限制與解法

Golden Dataset 也不是萬能。第一，它的品質取決於範例是否涵蓋真正重要的規則。第二，若把舊系統已知錯誤當作唯一標準，便可能把錯誤一起移植。第三，若資料是從高度相似的案例大量複製而來，看似有許多筆測試，實際覆蓋卻非常有限。

因此，資料集應由三類案例組成。第一類是已確認的歷史正常案例，提供日常行為基準。第二類是根據規則設計的邊界與例外案例，用來檢查不常見的分支。第三類是由事故回顧、問題單與業務審查提出的風險案例，用來避免重蹈覆轍。每一類都要記錄來源與限制，並隨業務變更更新版本。

當團隊提供通過率時，還要同時呈現覆蓋分母。例如「已執行 500 個案例，其中 498 個符合預期」與「已涵蓋所有重大業務規則」是兩個不同主張。若其中 2 個失敗案例恰好涉及重複扣帳，就不能用整體通過率掩蓋風險；若某些關鍵情境根本未建立，成功率更不能代表正式上線的安全性。

這也改變了管理者應詢問廠商的問題。不要只問「AI 轉換準確率多少」，而應問：準確率使用什麼樣本？測試中是否包含真實商業規則？有沒有跨平台完整介接？誰負責確認預期輸出？例外案例有多少？未通過的部分如何處理？只要這些問題還沒有可追溯答案，就應把展示結果定位為概念驗證，而不是正式部署保證。

進階延伸三：企業如何比較 AI 現代化工具與顧問服務？

市場上提供的現代化服務可能使用不同工具與術語。某些供應商著重 COBOL 程式理解，某些專精特定主機平台，某些擅長跨語言重構，也有團隊主要提供系統整合與後續維運。採購方若只比對「有沒有 AI」或「是否能轉 Java」，可能選到功能看似豐富、卻無法處理實際系統相依的方案。

首先應定義輸入資產。企業需要列出真正擁有或可合法提供的程式碼、Copybook、批次作業、資料結構、介接說明、測試環境與操作文件。供應商則應說明哪些資產已被工具支援，哪些必須人工分析，哪些完全無法處理。這個範圍界定，將直接影響概念驗證是否具有實際代表性。

其次是輸出成果。只產出新程式碼的服務，與同時提供規則台帳、相依圖、測試案例、差異報告及維運交接文件的服務，並不處於相同的比較基礎。採購方應先規定必要交付物，再請供應商說明如何產生、如何驗證及如何更新。對大型專案，輸出成果的可追溯性往往比單次轉換速度更重要。

第三是資料安全。工具是否必須把來源碼上傳外部雲端？能否限制使用區域？是否能在企業核准環境執行？如何管理帳號、權限及紀錄？會否使用所輸入的資料進行其他用途？這些問題必須依個別方案的實際合約與設定查核，不能把通用產品文件當作企業已取得的特定保證。

第四是技術驗收。供應商是否接受由企業挑選、而非僅由供應商準備的測試案例？是否願意揭露未能處理的語言或平台特性？轉換後的程式是否具備可維護結構？是否有可重跑的測試流程？是否能回溯每個主要規則的來源？這些條件比任何單一展示更能反映實際導入能力。

第五是治理與責任。若 AI 生成程式造成業務結果偏離，專案如何界定發現、分析、修正和重新驗收的責任？由誰核准部署？資料遷移後多久保留舊系統作為回復方案？專案結束後誰持續維護？若廠商服務終止，企業是否有足夠文件與程式資產接手？沒有這些答案，採購方案就尚未形成可控的營運計畫。

最後才進入經濟性比較。價格應包含盤點、轉換、測試、資料遷移、整合、雙系統運行、資安、培訓及後續維運，並確認哪些項目由企業自行承擔。若不同方案的範圍不一致，不能只比較報價總額。較低的初期費用未必代表較低的長期持有成本，較昂貴的產品也不必然產生更好的轉換品質。

採購會議應要求看到哪些實際證據？

一個有價值的概念驗證，應能追蹤以下鏈條：選定的業務功能、實際分析的原始資產、確認的業務規則、轉換產物、測試資料、比較結果，以及未解差異和下一步處置。若供應商只能展示「COBOL 原始碼進去，Java 程式碼出來」，就只能證明某部分程式生成能力，不能證明正式系統現代化已完成。

同樣重要的是安排適當的內部人員參與驗證。技術主管應檢查架構及可維護性，資安人員檢查資料與存取控制，業務代表核對規則與例外，營運團隊檢查部署、回復和操作流程，採購與法務則確認責任及資料權限。這不是為了增加會議，而是避免只有單一角色以自己熟悉的指標判斷整套系統是否可用。

比較結果最後應形成明確決策，而不是只有供應商評分排名。企業可能發現某項工具很適合文件化，但不適合處理關鍵交易轉換；另一項工具對特定平台具備完整支援，但資料處理方式不符合組織要求。這些結論可以導向不同的採用範圍。成熟的選型不是找一個承諾解決所有問題的產品，而是讓不同工具承擔自己有能力被驗證的任務。

十八、常見問題 FAQ

COBOL 是什麼的縮寫？

COBOL 是 Common Business-Oriented Language，中文一般稱為通用商業導向語言，是為商業資料處理而設計的高階編譯型程式語言。[S1]

COBOL 是誰發明的？

COBOL 是 1959 年由政府與產業界組成的團隊共同研擬，早期受到 Grace Hopper 參與發展的 FLOW-MATIC 影響。將創作完全歸於某一人並不精確。[S2][S3]

COBOL 現在還有人用嗎？

有。銀行、保險及其他企業仍存在 COBOL 系統與相關職務。台灣中國信託的公開徵才內容明確提到 COBOL 核心系統維運及現代化工作。但這不足以推估全部企業的採用比例。[S11]

COBOL 一定要用 IBM 大型主機嗎？

不一定。許多企業 COBOL 系統確實與大型主機有密切關係，但 GnuCOBOL 等編譯器也支援一般作業系統。語言和平台應分開理解。[S5]

COBOL 為什麼適合金融業？

它強調商業資料處理、固定結構資料與十進位運算；許多金融機構也已累積大量既有核心規則。是否適合特定新專案仍須看架構、團隊和業務需求，不能因此認定所有金融軟體都應新寫 COBOL。[S1][S9]

COBOL 和 Java 哪個比較好？

沒有不依賴場景的答案。COBOL 可持續承載已驗證的核心業務，Java 則有成熟的現代企業應用生態。選擇應考慮維護能力、平台、測試、商業需求及風險，而不是只比較新舊。

COBOL 和 Spring Boot 的關係是什麼？

COBOL 是程式語言；Spring Boot 是 Java 生態系中協助建立應用程式的框架。企業可以讓 Spring Boot 服務透過適當介接與既有 COBOL 系統合作，不一定需要一次替換後者。

AI 可以把 COBOL 轉成 Java 嗎？

可以協助，且 IBM、AWS 已公開提供相關產品與方法。然而，能產生 Java 程式碼不等於已保留所有商業規則、交易語義及系統營運特性。必須以完整資產、規則與測試證據進行驗證。[S7][S8][S15]

直接讓 AI 把整個核心系統改寫，是否更快？

速度必須與可驗證性一起評估。若無法辨識批次、資料庫、交易處理及例外規則，程式生成得再快也無法證明遷移成功。對高風險系統，分階段盤點、重構和對帳通常更利於控制風險。

COBOL 有最新的國際標準嗎？

ISO／IEC 公開的 ISO/IEC 1989:2023 規範 COBOL 的語法及語義；2026 年查閱的 ISO 頁面顯示下一版草案作業仍在進行。這與企業是否使用最新編譯器是不同問題。[S12]

學習 COBOL 對找工作有幫助嗎？

對目標為銀行核心資訊、大型主機、主機維運或舊系統現代化的求職者，有可能具備專業價值。若目標是一般 AI、Web 或數據分析，通常先學習對應基礎技術會更直接。職缺數量及待遇應依當期市場資訊查核，不宜以個別招募頁推論整體行情。[S11]

COBOL 會被 AI 淘汰嗎？

AI 正在改善舊程式的理解與轉換方式，但是否停止使用 COBOL，取決於企業的技術路線、投資回報、人才與風險控制。無法從 AI 工具進步推論某個固定年份 COBOL 就會消失。

管理者的最後檢核：十個問題，判斷專案是否真的準備好了

在完成技術研究之後，管理階層仍需要一份可用於決策會議的簡明檢核。以下問題的答案不應只是一句「已完成」，而應有對應文件、版本、負責人與驗證證據。若答案暫時不完整，應註明缺口和風險，而不是為了符合時程把問題從報告中刪除。

問題一：我們為什麼要改？ 請具體說明是為了降低風險、增加新服務、改善維運、處理平台成本，還是縮短開發交付時間。若同時有多個目標，應標示首要目的及不能犧牲的條件，避免工程團隊以不同標準判定成功。

問題二：我們究竟要改哪一段？ 請以可辨認的業務能力描述範圍，並列出直接相依與暫不處理的功能。如果專案名稱只有「核心系統更新」，而沒有第一批實際要交付的業務能力，便難以控制成本和驗收責任。

問題三：哪些既有行為必須完全一致？ 交易金額、利息、費率、時點、狀態轉移、授權與對帳等項目，應有明確規則來源。若存在已知的舊系統缺陷，應區分必要相容行為與正式核准的修正，不能要求新系統同時做到完全相同又修正所有錯誤。

問題四：我們是否真的掌握相依資產？ 除原始碼之外，還需要了解資料庫、檔案、批次、交易處理、介接及運維作業。盤點不完整時，應先縮小概念驗證範圍，或投入必要的依賴分析，而非假定 AI 能在缺少資料時自動填補真相。

問題五：業務負責人是否已參與？ 工程團隊可解釋程式如何運算，卻不一定有權判斷業務規則是否仍有效。需要由實際負責產品、帳務或作業的人核對規則，並在必要時請法遵或稽核確認正式義務。

問題六：測試資料是否足以支撐上線決策？ 應確認是否包含一般、邊界、例外、失敗恢復與高風險狀態，並區分已實測、只模擬及尚未覆蓋的部分。每項重要測試應能重跑，不能只保留某次展示的畫面截圖。

問題七：資料安全與使用授權是否清楚？ 應查明哪些來源碼和資料能夠輸入 AI 工具、哪些可以放在外部環境、哪些必須經過去識別化或隔離處理。缺少權限確認，即使工具本身再有效率，也不構成可以立即投入正式資料的理由。

問題八：新系統由誰長期維護？ 專案交付時需要明確的維運人員、操作手冊、監控方式、異常處置、授權配置、備份與更新責任。不能只把完成程式轉換視為專案結束，卻讓正式環境的日常營運處於無人負責的狀態。

問題九：如果切換失敗，我們如何恢復？ 對重大系統而言，應確認資料同步、回復時點、停機程序、使用者通知及切換後的對帳方式。有些變更可以快速還原，有些資料轉換則可能不可逆；不能只用一般軟體部署的回滾想像取代正式演練。

問題十：完成以後，哪些業務結果會變好？ 若專案已產生可讀的程式碼、詳細的架構圖與大量新服務，卻沒有改善原本提出的業務問題，就仍需要重新檢討投資價值。相反地，如果最終只改造一小部分功能，但能明顯降低事故、縮短新功能交付或減少關鍵人員依賴，也可能是一項成功而克制的現代化決策。

另一項值得在決策會議中明確約定的原則，是不要讓採購時程取代業務風險評估。當供應商完成示範、預算即將到期或管理階層期望迅速公布成果時，團隊可能傾向把尚未確認的需求寫成「後續處理」。這種安排有時合理，但必須分辨它究竟是非關鍵改善事項，還是會直接影響交易正確性、資訊安全或日後回復的重大限制。前者可以排入追蹤計畫，後者則應成為明確的上線阻擋條件。將重大風險寫入決策紀錄，不代表專案失敗；恰恰相反，它是避免短期進度壓力轉換成長期營運事故的必要治理能力。

這十題可以放入每一次階段審查的固定議程。隨著系統資訊逐漸完整，答案會更加精確，也可能讓團隊修正原本的改造順序。它們的目的不是製造一份勾選完就能保證安全的表格，而是迫使不同職能把未經確認的假設攤開，將最容易造成損失的問題轉換成可追蹤的決策工作。

若只能選一項最值得現在開始的行動，應是讓技術、業務與測試人員共同完成一個小範圍的規則與對帳基準。這份基準可同時用來評估 AI 工具、訓練新進同仁、核對供應商產物及規劃後續改造，比起直接指定新程式語言，更能持續降低企業對單一技術和個人的依賴。

十九、結論：真正需要現代化的，是企業交付與驗證業務能力的方法

COBOL 從 1959 年的跨電腦商業語言構想，走到今天銀行與大型企業持續維護的重要系統，反映的是資訊技術中一個不容易被新工具取代的事實：企業需要長期保存可被信賴的商業規則，而每次改動都必須維持正確性。

在 2026 年，討論 COBOL 已不只是程式設計史。IBM 與 AWS 公開的 AI 現代化工具與方法，展示了分析、記錄、分解與轉換部分傳統應用的能力；個別企業能否提高效率，仍須實測。然而，AI 的價值必須由實際可驗證的業務成果決定，不能由生成的程式行數、轉換畫面的速度或行銷口號決定。[S6][S7][S15]

如果企業正要啟動改善，最好的第一個問題不是「我們什麼時候能擺脫 COBOL」，而是「哪一項商業能力目前最難變更、最容易出錯，或最妨礙下一步成長」。確認問題後，盤點依賴、整理規則、建立 Golden Dataset，接著比較保留、封裝、重構與替換的不同方案。這是一條可以從有限範圍開始、累積證據再擴大的路線。

對工程師而言，理解 COBOL 是理解大型企業如何把規則寫進系統。對管理者而言，理解 COBOL 是學會區分語言、平台、業務知識與轉型投資。對正在規劃 AI 培訓的企業而言，更應把教學重心放在真實工作情境，例如閱讀舊程式、文件化、跨角色審查及新舊測試結果比對，而不是只教員工把原始碼丟給聊天機器人。

值得保留的，不一定是每一行舊程式；不能遺失的，是仍然有效的商業規則、交易正確性與組織對系統的掌控能力。

企業下一步：從系統診斷與跨職能能力建立開始

若您的企業正在評估老舊系統維護、AI 輔助程式分析或系統現代化，可先以本文的「30 天診斷表」確認工作邊界、可用資料、主要風險及預期驗收成果。若需要安排跨職能培訓，可進一步與技術、業務、資安、人資共同定義符合企業環境的實作任務，而不是直接套用單一通用課綱。

延伸閱讀與服務：天地人學堂 企業培訓服務；知識與實務專題。上述連結提供一般培訓與內容資訊，並不表示天地人目前已有公開販售或已承諾交付的「COBOL 專班」。實際技術範圍、講師資格與服務能力需要專案確認。

資料來源與查核註記

以下編號對應本文各段引註。官方產品文件涉及持續更新的服務版本與支援範圍，正式採用時應重新檢查。資料查閱日：2026 年 10 月 31 日。

[S1] IBM，〈What is COBOL?〉，2025-05-08 發布、2026-02-25 更新。https://www.ibm.com/think/topics/cobol

[S2] Smithsonian National Museum of American History，〈COBOL〉。https://americanhistory.si.edu/explore/exhibitions/artifact-walls-cobol

[S3] Computer History Museum，〈1960：COBOL〉。https://www.computerhistory.org/timeline/1960/

[S4] Smithsonian，〈First Draft of the Programming Language COBOL〉。https://americanhistory.si.edu/collections/object/nmah_1389377

[S5] GnuCOBOL 官方專案，〈GnuCOBOL〉，頁面標示 3.2 版。https://gnucobol.sourceforge.io/index.html

[S6] IBM，〈Agentic AI for smarter mainframe modernization with IBM watsonx Code Assistant for Z〉，2025-12-16 發布、2026-03-02 更新。https://www.ibm.com/new/announcements/agentic-ai-for-smarter-mainframe-modernization-with-ibm-watsonx-code-assistant-for-z

[S7] AWS Transform 官方使用者指南，〈Modernization of mainframe applications〉。https://docs.aws.amazon.com/transform/latest/userguide/transform-app-mainframe.html

[S8] AWS，〈AWS Transform for mainframe is now generally available〉，2025-05-15。https://aws.amazon.com/about-aws/whats-new/2025/05/aws-transform-mainframe-generally-available/

[S9] IBM，〈Controlling how numeric data is stored〉，Enterprise COBOL for z/OS 6.4 文件。https://www.ibm.com/docs/en/cobol-zos/6.4.0?topic=arithmetic-controlling-how-numeric-data-is-stored

[S10] IBM，〈Lost in Translation: What the AI code debate keeps getting wrong〉，2026-02-23，屬 IBM 公司立場文章。https://newsroom.ibm.com/blog-lost-in-translation-what-the-ai-code-debate-keeps-getting-wrong

[S11] 中國信託商業銀行，〈科技金融_軟體開發工程師（法金國內銀行核心系統）〉，公開職缺頁，查閱時在站。https://ctbcholding.wd3.myworkdayjobs.com/en-US/External/job/-COBOL–_JR203

[S12] ISO／IEC，〈ISO/IEC 1989:2023 Programming language COBOL〉。https://committee.iso.org/standard/74527.html?browse=tc

[S13] IBM，〈What is application modernization?〉，介紹 Rehost、Replatform、Refactor、Rearchitect、Rebuild 與 Replace。https://www.ibm.com/think/topics/application-modernization

[S14] IBM，〈IBM watsonx Code Assistant for Z Adds AI Code Generation and Assembler Support〉，2025 年產品公告。https://www.ibm.com/new/announcements/ibm-watsonx-code-assistant-for-z-adds-ai-code-generation-and-assembler-support

[S15] IBM Research，〈Enterprise-Scale COBOL-to-Java Translation: LLMs Augmented with Program Analysis〉，ICSE 2026 論文，2026-04-12。https://research.ibm.com/publications/enterprise-scale-cobol-to-java-translation-llms-augmented-with-program-analysis

[S16] AWS，〈AWS Transform for mainframe introduces Reimagine capabilities and automated testing functionality〉，2025-12-01。https://aws.amazon.com/blogs/aws/aws-transform-for-mainframe-introduces-reimagine-capabilities-and-automated-testing-functionality/

編輯說明： 本文刻意不使用「COBOL 支撐全球多少百分比 ATM 交易」等廣泛流傳但較難確認當期母體、測量方法與來源年度的數據；避免將供應商主張誤寫成獨立統計。文中示意案例、教學數字、方法框架不是客戶實績。