遺留系統現代化： 以神經符號 AI 超越語法

執行摘要

企業遺留系統的現代化——具體而言，是將主機 架構遷移至雲原生環境——已在 2020 年代中期來到關鍵轉折點。數十年來，金融與政府部門一直在一種 悖論式典範下運作：現代化的必要性關乎存亡，然而此類 計畫的失敗率仍災難性地居高不下，徘徊在 70% 至 80% 之間。 ¹ 近期 大型語言模型（LLM）的問世承諾了一場革命，提供了誘人的 自動化程式碼翻譯可能性。然而，早期採用週期已揭示一項關鍵、系統性的 缺陷，出現在將標準生成式 AI 方法應用於複雜、單體式 儲存庫時。

我們目前正目睹一類新的工程失敗湧現，其典型 表現來自一個雖屬傳聞、卻高度寫實的情境：某大型銀行試圖改寫三十年 的 COBOL 為 Java，並使用商業程式碼助理。該 AI 作為一個 精密的局部翻譯器，完美轉換了語法。然而，產出的 應用程式在部署時卻讓資料庫崩潰。失敗不在語法，而在 脈絡。該 AI 受「中間迷失」（Lost in the Middle）症候群與基於文本的 軟體理解所限，漏掉了一項關鍵變數相依性，該定義在 執行區塊之前的數千行。 ³

本白皮書由 Veriprajna 提出，主張當前主流的「LLM 包裝層」 做法——把程式碼當作線性的文本 token 序列——根本上不適 用於企業現代化的非線性複雜性。軟體不是文本；它是圖譜。它 是一套高度結構化的邏輯相依、資料流與狀態變化系統， 存在於多維拓撲空間之中。 ⁵

我們主張，唯一可行的前進之路是採用 儲存庫感知知識 圖譜 。透過從隨機文本預測轉向基於圖譜的確定性推理， 我們可以跨越數百萬行程式碼對應變數相依性，解消「中間 迷失」現象，並將現代化從一場高風險賭博轉變為 可數學驗證的工程過程。 ⁷ 本文件概述這項技術 轉折：從表面層的語法翻譯，走向深層的語意結構轉換。

第 1 章：遺留基礎設施的無聲 危機

1.1 現代化悖論

在當前的數位經濟中，全球商務的基礎設施岌岌可危地仰賴 冷戰時期開發的技術。這是一個令人震驚、卻常被否認的現實： 到了 2025 年，全球金融、醫療與政府系統中相當大的多數 仍由遺留程式碼庫驅動——以 COBOL、 PL/I 與 RPG 等語言撰寫的單體應用，這些語言早已淡出主流電腦科學課程。 這些系統不僅是「舊的」；它們是全球經濟的奠基岩層， 卻正以驚人速度侵蝕。

統計數字為這種依賴描繪出嚴峻圖像。約 70% 的軟體 在 Fortune 500 公司運行的，是二十多年前開發的。 ⁹ 在銀行業， 情況更為嚴峻：43% 的銀行系統建置於 COBOL 之上，而這些 系統處理 95% 的 ATM 交易。 ¹ 我們實際上是在用一套早於網際網路的數位地基，運轉現代、 即時支付經濟。

維持現狀的成本正在飆升。技術債已累積至 僅美國就估計達 $1.52 trillion。 ¹ 組織陷入「維持燈火 通明」的循環，聯邦 IT 預算中有 80% 投入營運與維護，只留下 微薄的 20% 用於創新。 ⁹ 這項資源流失又因嚴重的技能短缺而加劇； 隨著撰寫這些系統的那一代開發者退休，維護所需的組織知識 也隨之消失。 ¹⁰

表 1：遺留系統的經濟負擔

指標	統計	來源
技術債成本（美國）	$1.52 Trillion	1
聯邦 IT 維護 預算	約佔總支出 ~80%	9
銀行業依賴	95% 的 ATM 交易 基於 COBOL	1

資料外洩機率	高出 3x，系統超過 10 年者	11
開發者流失	58% 考慮離職，原因是 遺留技術堆疊	1

這些數據顯示系統性脆弱。現代化的必要性不只關乎 降低成本；它關乎生存。超過十年的系統，在統計上是三倍 更可能遭遇資安事件，相較於現代應用。 ¹¹ 隨著監管 對資料隱私與即時申報的要求趨嚴（例如 GDPR、DORA），遺留系統無法調適 便成為最高等級的合規風險。

1.2 「銀行失敗」的解剖

為理解新方法的必要性，我們必須剖析這個已成為 AI 現代化失敗「零號病人」的情境。此案例研究由 Veriprajna 領導層援引，說明標準 AI 失敗的具體機制，發生在 企業環境之中。

某大型金融機構啟動專案，要將核心交易處理系統 從 IBM 主機（COBOL/DB2）遷移至雲原生 Java 微服務架構。該 銀行使用一款熱門 AI 程式碼助理——本質上是一層包裝，包在基礎 模型之外——來翻譯程式碼。

該 AI 攝入一支負責處理高額電匯的 COBOL 程式。該 程式含有複雜的 COMPUTE 陳述式，涉及我們稱為 TRN-LIMIT 的變數。 AI 完美翻譯了語法。它把 COMPUTE 陳述式轉成 Java BigDecimal 運算。程式碼編譯通過。單元測試——由同一套 AI 根據 本地程式碼區塊產生——也通過了。

然而，部署到使用者驗收測試（UAT）環境後，第一筆 交易就讓資料庫一致性檢查崩潰。

解剖： 變數 TRN-LIMIT 並未定義在 AI 所翻譯的原始檔中。它定義在一份 COPYBOOK（共享標頭檔）裡，該檔在執行鏈中早數千行就被引入。 更重要的是，那份 COPYBOOK 含有 REDEFINES 子句——一種 COBOL 構建， 允許同一記憶體位址被解讀為兩種不同資料型別，取決於 在完全不同模組中設定的旗標。 該 AI 在一段文本「區塊」上運作，把 TRN-LIMIT 看成簡單數值欄位。它沒有看到 REDEFINES 子句，因為該子句位於另一個檔案，不在即時 上下文視窗內。它「幻覺」出該變數的標準定義。在主機 環境中，該記憶體位址存放的是 packed decimal；在 Java 環境中，AI 卻把它當標準整數處理。此錯配導致 Java 應用把損壞的 二進位資料寫入資料庫欄位，觸發參照完整性失敗。 ⁴

失敗不在語法；Java 程式碼在語法上是完美的。失敗在於 脈絡盲視 。AI 漏掉了存在於其「視野」之外的相依性， 導致災難性的語意分歧。

1.3 「原樣搬遷」對重構的兩難

產業在現代化上的成績單極為慘淡，即使在引入 生成式 AI 之前。研究顯示，70% 至 80% 的數位轉型與 遺留系統現代化專案未能達成目標。 ²

傳統上，組織面臨二元選擇：

1.​ 重新託管（原樣搬遷）： 把已編譯的應用移到雲端模擬器。這 保留了「義大利麵程式碼」與債務，只是改了託管帳單。它無法 釋放雲端的敏捷性。 ¹⁴

2.​ 重寫（重構）： 以現代語言手動重寫程式碼。這 成本天文數字、緩慢，且因缺乏文件與「大 泥球」架構而風險極高——業務邏輯與資料存取糾纏難分。 ¹⁰

生成式 AI 本應提供「第三條路」——自動化重構。然而， 「銀行失敗」證明：若缺乏對軟體拓撲的更深理解，AI 只是 加速產出有缺陷的程式碼。

第 2 章：隨機性翻譯的 失敗

2.1 「包裝層」經濟及其限度

進入這個高風險環境的是「LLM 包裝層」。來自 軟體顧問市場對 GPT-4 發布的即時反應，是大量湧現充當 開發者與基礎模型之間薄軟體層的工具。 ¹⁵ 這些工具承諾可以 「與你的程式碼對話」，讓開發者貼上一段 COBOL 段落並收到一段 Java 方法作為回傳。

雖然這些包裝層降低了採用 AI 的門檻，但它們在根本上有缺陷 當應用於大規模系統再工程時。包裝層通常依賴 樸素 RAG（Naïve RAG） （檢索增強生成，Retrieval-Augmented Generation）。在此過程中，系統接受使用者查詢，搜尋 向量資料庫中與查詢 文本上相似 的程式碼片段，並把那些 片段餵給 LLM 作為上下文。 ¹⁷

此做法在企業情境中的限制極為嚴重：

1.​ 脈絡近視： 包裝層把程式碼看成文本片段。它不理解 在 SECTION-A 中被修改的變數 ACCOUNT-BALANCE 驅動著 五千行之外 SECTION-Z 中的決策邏輯。

2.​ 語法成功、語意失敗： 如前所述，LLM 可以產出 Java 程式碼， 編譯完美，卻無法複製原始 COBOL 的精確執行期行為， 因為它漏掉了全域狀態變化。 ⁴

Veriprajna 以拒絕「薄包裝層」哲學來自我區隔。我們主張，深度 AI 解決方案必須理解儲存庫的 結構，而不只是檔案的 文本。

2.2 「中間迷失」症候群

要理解為何標準 AI 在遺留系統現代化中失敗，我們必須理解 大型語言模型的認知架構。這些模型基於 Transformer 架構，使用「注意力機制」來權衡 輸入文本不同部分的重要性。 ¹⁸

雖然現代 LLM 標榜巨大的上下文視窗（高達 1 million tokens），它們 有效 使用 該上下文的能力並不均勻。實證研究已證明一種 稱為 「中間迷失」效應 的現象。當面對一段長 資訊序列時，LLM 呈現 U 型表現曲線：

●​ 首位偏誤： 它們對開頭資訊的回憶高度準確，位於 提示。

●​ 近因偏誤： 它們對提示末尾資訊的回憶高度準確。

●​ 谷底： 位於中間的資訊，表現顯著劣化。 ³

在現代化專案中，單一 COBOL 程式可能長達數千行，而且它 可能參照本身也長達數千行的 copybook（相依項）。若 關鍵變數的定義——例如 MAX-TRANSACTION-LIMIT——出現在這段 龐大上下文的中間，AI 在統計上很可能忽略它。 ²¹

當 AI 忽略變數定義時，它並不停下。它「幻覺」。它假設一個 該變數的預設型別或值，依據機率而非事實。在銀行系統中， 若假設變數是 Integer，而它其實是 Packed Decimal，可能導致捨入 錯誤，進而損壞財務資料。 ²²

表 2：標準 LLM 的認知限制

現象	描述	對現代化的影響
中間迷失	長提示中段的注意力 劣化。3	漏掉埋在大型檔案中的 變數定義。
幻覺	捏造看似合理但 不正確的事實。22	發明相依性或 邏輯以填補上下文缺口。
首位／近因偏誤	聚焦起／迄於 文本。20	忽略核心業務 邏輯，位於中段 的程序。
隨機生成	機率式文本 預測。	不一致的程式碼 生成；重跑 提示會得到不同的 邏輯。

2.3 「詞袋」對「邏輯樹」

標準 LLM 與向量 RAG 系統主要把程式碼當 token 序列處理。 它們依賴語意相似度——檢查查詢中的詞是否匹配文件 向量空間中的詞。 ¹⁷

然而，程式碼不是自然語言。在自然語言中，「貓坐在墊子上」的 意義大致獨立於五十頁之前的句子。在軟體中，x = y + 1 的意義為零 除非我們知道 x 與 y 的定義、型別與當前狀態。這些 定義可能存在於不同檔案、不同模組，或從父 類別繼承而來。 ⁵

當「包裝層」AI 為「重構付款邏輯」這類查詢檢索上下文時，它可能 抓到五塊含有「payment」一字的程式碼。它很可能漏掉名為 GlobalVarDef.cbl 的區塊，而該檔定義了付款邏輯所用的稅率，因為該檔從未 提到「payment」這個詞。

此斷裂代表 文本檢索 與 結構性 理解 之間的根本落差。要彌合此落差，我們必須停止把程式碼當文學，開始把它 當作圖譜。 ²³

第 3 章：軟體的物理 –

程式碼即圖譜

3.1 軟體作為關係系統

在 Veriprajna，我們認識到軟體儲存庫根本上是一座 關係資料庫 承載邏輯 。程式碼庫中的每個實體——變數、函式、類別、模組、資料庫 綱要——都存在於稠密的關係網絡中。

●​ 包含： 檔案包含類別；類別包含方法；方法包含 變數宣告。

●​ 繼承： Class B 繼承 Class A 的屬性與方法。

●​ 呼叫： Method X 呼叫 Method Y。

●​ 資料流： Variable Z 由 Function Q 修改、由 Function R 讀取。

這些關係構成應用的「地面真相」。它們不是機率性的； 它們是確定性的。若 Method X 呼叫 Method Y，那是硬事實，不是統計 可能性。標準 LLM 運作於機率域。要安全地現代化遺留 系統，我們必須把它們的機率生成能力錨定在確定性現實上，即 程式碼結構的現實。 ⁷

3.2 抽象語法樹（AST）

此結構性理解的基礎單元是 抽象語法樹（AST） 。 AST 是原始碼抽象句法結構的樹狀表示。不同於原始 文本字串，AST 捕捉語言的層級與文法規則。 ²⁴

例如，COBOL 陳述式： COMPUTE INTEREST = PRINCIPAL * RATE 不只是五個詞。在 AST 中，它是帶有 Target（Interest）與 Expression 的 AssignmentNode。該 Expression 是帶有 LeftOperand（Principal）與 RightOperand（Rate）的 MultiplicationNode。26 透過把遺留程式碼解析為 AST，我們超越文本的歧義。我們可以 以程式方式識別每一處變數使用、每一次算術運算，以及每一條控制 流分支。這讓我們能進行「往返」工程——把程式碼轉成 AST 再 轉回程式碼且無資料損失——確保結構分析準確。 ²⁷

不同於標準 RAG 使用的「文本分塊」——檔案被盲目切成 500-token 片段，經常把函式切成兩半——AST 解析尊重其邏輯邊界，即 程式碼。函式被視為離散的邏輯單元，而非隨機文本跨度。 ²³

3.3 呼叫圖與相依矩陣

AST 代表單一檔案的結構，而 呼叫圖 代表整個應用的神經 系統。它視覺化控制流，對應哪些段落或 子程式呼叫其他者。 ²⁹

在遺留 COBOL 系統中，呼叫圖常被動態呼叫或 GOTO 邏輯遮蔽，而那 會造成「義大利麵程式碼」。靜態文本分析不容易解析 GOTO LABEL_X 落在何處，若 LABEL_X 是動態或條件定義的。

透過建構嚴謹的呼叫圖，Veriprajna 識別「死碼」（從未被 呼叫的程式碼）與「上帝類別」（耦合過重的模組）。此分析對 把單體拆成微服務至關重要。若我們不知道完整呼叫鏈，我們 就無法安全抽出服務；我們可能留下「懸空參照」，將造成 執行期失敗——正是開篇案例中困擾那家銀行的情境。 ³¹

表 3：結構分析對文本分析

特徵	文本分析（標準 AI）	結構分析 （Veriprajna）
分析單元	Token／詞	節點（AST 元素）
上下文邊界	任意 token 上限	邏輯範圍 （函式／類別）
相依解析	關鍵詞匹配	圖譜遍歷
GOTO 處理	當文本字串看待	對應控制流邊
準確性	機率性	確定性

3.4 相依性注入與反轉

現代 Java 與雲原生架構高度依賴相依性注入（DI）與 控制反轉（IoC）。遺留 COBOL 則相反，依賴硬編碼相依 與全域狀態。從一端移到另一端，需要識別圖譜中的每一項相依 並「反轉」它。

我們必須把典範從「模組 A 硬編碼連到資料庫 B」改為 「模組 A 接受資料庫連線作為參數。」此架構轉變 若 AI 一開始就看不見該相依，便不可能。知識圖譜 讓這些相依顯性化，使 AI 能產生必要的 DI 樣板程式碼 自動地，確保新系統模組化且可測試。 ⁴

第 4 章：Veriprajna 語意 鍛造廠

4.1 儲存庫感知知識 圖譜的架構

「中間迷失」症候群與基於文本之遷移脆弱性的解方是 儲存庫感知知識圖譜 。這是一座統一的圖譜資料庫，結合 程式碼的靜態結構（AST、呼叫圖）與 業務邏輯的語意（文件、註解、變數意圖）。 ⁵

Veriprajna 採用專有管線，在進階研究中常被稱為 「Semantic Forge」，以建立此智能。這不是通用 ETL 流程；它是 為遺留系統現代化量身打造的引擎。 ³³

4.2 第一階段：以 Tree-sitter 進行智慧解析

我們使用強健的解析器，主要是 Tree-sitter，以攝入遺留程式碼庫。此過程 支援超過 13 種語言，包括 COBOL、JCL、PL/I 與 Java。解析器產生 儲存庫中每個檔案的 AST。

關鍵的是，我們採用 語意分塊 。標準 RAG 管線使用「樸素切分」， 每 n 個 token 切一次文本。這經常把函式簽章與其本體切斷，或把 變數定義與其使用切斷，摧毀上下文。語意分塊使用 AST 來 識別邏輯邊界。我們按 SECTION、PARAGRAPH 或 METHOD 分塊程式碼， 確保圖譜中每個節點代表一個完整、可執行的邏輯單元。 ²³

4.3 第二階段：實體與關係抽取

一旦產生 AST，Semantic Forge 便抽取實體與關係，以 填充圖譜資料庫（例如 Neo4j、Memgraph）。

●​ 實體： 類別、段落、變數、資料庫表、API 端點。

●​ 關係：

○​ CALLS：連接段落與其呼叫的子程式。

○​ UPDATES_TABLE：連接邏輯區塊與其修改的 DB2 表。

○​ IMPORTS_COPYBOOK：連接原始檔與其相依項。

○​ DEFINES_VARIABLE：連接資料部與其建立的變數。

此階段把靜態文本轉成動態拓撲。我們現在可以查詢圖譜： 「列出所有更新 CUSTOMER-ID 欄位的段落。」此查詢立即回傳精確 結果，這是 grep 或向量搜尋做不到的。 ¹⁴

4.4 第三階段：實體解析與合併

這是關鍵差異點。標準解析器把檔案 A 中的 ACCT-NUM 與 檔案 B 中的 ACCT-NUM 看成兩個不同字串。我們的系統執行 符號解析 。它 判定兩者指向共享 Copybook 中的同一條目。它把它們合併為一個 圖譜中的單一變數節點。

此外，我們執行 跨模態合併 。若程式碼庫含有一份 PDF 需求文件描述「User API」，而程式碼含有名為 UserAPI 的類別，系統計算嵌入以辨識它們是同一概念。它 把文件節點與程式碼節點合併。這把 意圖（文件）與 實作（程式碼）連結，讓 AI 同時獲得「為何」與「如何」。 ⁸

4.5 第四階段：傳遞閉包計算

「銀行失敗」由傳遞相依造成：A 依賴 B，B 依賴 C。 AI 看見 A 卻漏掉 C。

Veriprajna 知識圖譜計算 傳遞閉包 。當系統分析 模組 A 時，它不停在直接鄰居。它深入遍歷圖譜（A -> B -> C） 以識別每個變數的「真相之根」。這確保當 AI 產生 模組 A 的程式碼時，它從模組 C 匯入正確定義，即使模組 C 位於 不同目錄或儲存庫。 ⁸

第 5 章：圖譜檢索增強 生成（GraphRAG）

5.1 向量 RAG 的限制

向量檢索增強生成（RAG）是添加知識的產業標準，用於 LLM。它把文本轉成向量（數值表示）並尋找相似向量。 雖然極適於查詢 FAQ 這類非結構化文本，但對程式碼並不足夠。

●​ 變數重新命名： 若開發者把 Account 改名為 Acct，語意相似度 會下降，即使邏輯完全相同。

●​ 邏輯對關鍵詞： 搜尋「Interest Calculation」可能漏掉真正的數學，若 函式名為 FNC-001 且不含註解。

●​ 破碎的上下文： 向量 RAG 依餘弦相似度檢索「區塊」。它可能 檢索到單元測試與 UI 註解，卻漏掉核心業務邏輯，因為 變數名稱與查詢詞不匹配。 ³⁶

5.2 GraphRAG 的優勢

GraphRAG 運作於知識圖譜的結構，而不只是文本相似度。

1.​ 錨點識別： 當使用者問「重構付款邏輯」，系統使用 向量搜尋找出進入點（例如 ProcessPayment 段落）。

2.​ 圖譜遍歷（擴展）： 並不就此停止，GraphRAG 遍歷圖譜 邊。它拉入：

○​ CALLS 邊以找出子程式。

○​ READS 邊以找出變數定義。

○​ INCLUDES 邊以找出 Copybook。

3.​ 上下文建構： 這些相連片段——文本上可能不相似，但 在邏輯上不可分割——被組裝成連貫提示。

此 相關性擴展 確保 LLM 收到自足、可執行的邏輯 切片。它理解的不只是計算的 文本，還有其 機制。 ³⁶

5.3 多跳推理

研究顯示 GraphRAG 顯著優於向量 RAG，在需要 「多跳推理」的任務上——連接相隔數步的事實。在軟體中， 幾乎每個缺陷都是多跳推理的失敗（例如 A 呼叫 B，B 改變 X，C 讀取 X。若 A 改變，C 會不會壞？）。

GraphRAG 讓 AI 能回答複雜的影響分析問題：「若我改變利息 率邏輯於模組 A 中，模組 Z 中哪些報表畫面會受影響？」向量 RAG 無法回答，因為模組 A 與模組 Z 沒有文本相似度；它們只由 函式呼叫鏈連結。圖譜遍歷此鏈以提供確定 答案。 ³⁸

表 4：向量 RAG 對 GraphRAG

特徵	向量 RAG	GraphRAG
檢索鍵	相似度（餘弦距離）	關係（圖譜邊）
上下文品質	高召回、低精準 （雜訊）	高精度、連貫 上下文

多跳推理	差（漏掉間接連結）	優（遍歷 鏈）
幻覺風險	高（猜測缺失的 連結）	低（檢索到的連結是 顯性的）
最佳用途	非結構化文本（FAQ）	結構化系統（程式碼、 生物學）

第 6 章：工程化遷移 – 技術深潛

6.1 破解「全域變數」陷阱

COBOL 最危險的面向之一，是使用定義於 DATA DIVISION 並由程式各處多個 PERFORM 陳述式修改的全域變數。在 Java 中，最佳實務要求封裝；方法不應依賴隱藏狀態。

解方： Veriprajna 的代理在圖譜上執行資料流分析。我們追蹤每一個 變數的生命週期。

●​ 若段落 CALC-TAX 讀取 GROSS-INCOME，圖譜將 GROSS-INCOME 識別為 輸入相依 。

●​ 在產生 Java 方法 calcTax() 時，AI 明確把 BigDecimal grossIncome 加入方法簽章。

●​ 然後它更新該方法的 呼叫者，以傳入正確值。

此自動重構從「隱性全域狀態」到「顯性參數傳遞」 可防止困擾案例中那家銀行的副作用缺陷。 ⁴

6.2 拆解 GOTO 義大利麵

COBOL 遷移最棘手的障礙之一是 GOTO 陳述式。GOTO 允許 程式執行跳到任何地方，造成非線性控制流，這對 現代結構化程式設計極為忌諱。 ⁴⁰ Java 沒有 GOTO 陳述式。

翻譯 GOTO 邏輯需要的不只是語法翻譯；它需要 控制流 展平 。

1.​ 圖譜分析： 我們把 GOTO 目的地對應為控制流圖中的邊 （CFG）。

2.​ 模式識別： 圖譜識別模式。

○​ 跳回較早標籤的 GOTO 被識別為 迴圈 。

○​ 跳過一個區塊的 GOTO 被識別為 條件（if/else）。

○​ 跳到結束段落的 GOTO 是 返回 。

3.​ 重構： AI 在圖譜引導下，把這些跳躍重構為 while 迴圈、 do-while 迴圈，或 Java 中的 break/continue 陳述式。

若沒有圖譜來視覺化 GOTO 造成的「迴圈」，基於文本的 LLM 往往會 產生導致 StackOverflowError 的遞迴函式呼叫，或乾脆幻覺出 並不存在的邏輯流。 ⁴

6.3 處理「死碼」

遺留系統充滿不再使用的程式碼——舊促銷、已下架產品、 除錯常式。遷移這些程式碼是浪費金錢，並增加資安攻擊面。 基於文本的 AI 遷移它所得到的一切；它無法區分作用中與死亡 程式碼。

解方： 呼叫圖識別不可達節點——沒有傳入 邊（無呼叫者）的段落或檔案。Veriprajna 的系統把這些「死碼」標記為刪除，在 遷移開始之前。這通常使程式碼庫縮小 20-30%，帶來顯著的 成本節省與更潔淨的最終架構。31

第 7 章：代理式未來 – 深度 AI 對淺層包裝層

7.1 超越聊天機器人：代理式工作流

Veriprajna 不部署「聊天機器人」。我們部署 自主 AI 代理 。代理是一套 能夠規劃、執行，並依回饋修正其行動的系統。 ²

淺層包裝層工作流：

1.​ 使用者： 「轉換這段程式碼。」

2.​ 包裝層： 把文本送給 GPT-4。

3.​ 輸出： 回傳 Java 程式碼。

4.​ 結果： 程式碼無法編譯或執行。開發者手動除錯。

Veriprajna 深度代理工作流：

1.​ 規劃： 代理分析目標 COBOL 檔的 AST。它識別 相依並查詢知識圖譜。

2.​ 檢索： 它取得遷移所需的 GraphRAG 上下文。

3.​ 生成： 它使用「結構約束解碼器」產生 Java 程式碼，該解碼器 強制 Java 語法規則與型別安全。 ⁷

4.​ 驗證（迴圈）： 代理在沙盒中 編譯 所產生的 Java 程式碼。

5.​ 自我修正： 若編譯器拋出錯誤（例如「找不到變數」），代理 讀取錯誤、向圖譜查詢缺失相依，並重新產生程式碼。

6.​ 驗證： 它執行單元測試（由原始 COBOL 追蹤產生），以確保 輸出匹配輸入行為。

此 編譯—修復迴圈 把驗證負擔從人轉移到 AI，大幅 降低重構成本。 ⁴²

7.2 人在迴路的監督

雖然代理在執行上自主，但在策略上受監督。知識圖譜 提供 可解釋性 。不同於「黑箱」神經網路，圖譜讓開發者能 精確看見 AI 為何 做出決定。「AI 匯入了 com.bank.logic，因為它找到 對 COPYBOOK-X 的相依。」

此透明度對銀行這類受監管產業至關重要，每一行程式碼都必須 可稽核。我們從「相信我，我是 AI」走向「這是此邏輯的引用鏈」。 ⁴³

第 8 章：結論與策略 展望

8.1 儲存庫感知的投資報酬

McKinsey 資料顯示 GenAI 可將編碼任務減少 50%，但前提是部署 正確。 ¹⁴ Veriprajna 圖譜方法的投資報酬（ROI）來自 消除返工。

●​ 手動遷移： 高成本、高風險、上市時間慢。

●​ 包裝層 AI： 中等成本（因除錯「幻覺」）、高風險（隱藏缺陷）、 中等上市時間。

●​ 儲存庫圖譜 AI： 低成本（自動化）、低風險（確定性驗證）、快 上市時間。

透過消除「上下文切換」開銷——開發者花數小時尋找 變數定義於何處——Veriprajna 使開發者生產力提高 2x 至 3x，相較 於標準 AI 工具。 ²

8.2 以持續現代化面向未來

現代化不是一次性事件；它是生命週期。一旦程式碼庫被轉換為 知識圖譜，它就保持為活資產。隨著新 Java 程式碼演進，圖譜 即時更新。這使得：

●​ 自動文件： AI 能為 新系統產生最新文件，透過讀取圖譜。 ⁴⁴

●​ 架構漂移偵測： 系統可在新程式碼違反 圖譜中定義的模組化規則時警示架構師。 ⁴⁵

8.3 結構性轉向

「銀行失敗」的教訓很清楚： 程式碼不是文本。 它是複雜、相互連結的 邏輯系統。試圖用只懂文本的工具來現代化它，就如同 試圖用一串街名、卻沒有地圖來導航一座城市。你會「迷失在 中間」。

Veriprajna 提供這張地圖。透過建立 儲存庫感知知識圖譜，我們提供 AI 所需的結構智能，以導航遺留系統的複雜性。 我們對應相依、解開結點，並交付真正有效的現代化， 不只在語法上，更在現實中。

我們不只寫程式碼；我們工程化理解。這就是 聊天機器人與解決方案提供者之間的差異。這就是企業現代化的未來。

Veriprajna. 深度 AI，成就深度解方。

參考文獻

1. 2025 Legacy Code Stats: Costs, Risks & Modernization - Pragmatic Coders，2025年12月10日檢索， https://www.pragmaticcoders.com/resources/legacy-code-stats

2. Legacy App Modernization: AI Automation Slashes Costs & Time - SoftProdigy，2025年12月10日檢索， https://softprodigy.com/ai-driven-legacy-app-modernization/

3. Lost-in-the-Middle Effect | LLM Knowledge Base - Promptmetheus，2025年12月10日檢索， https://promptmetheus.com/resources/llm-knowledge-base/lost-in-the-middle-efectf

4. How We Use AI Agents for COBOL Migration and Mainframe Modernization | All things Azure - Microsoft Developer Blogs，2025年12月10日檢索， https://devblogs.microsoft.com/all-things-azure/how-we-use-ai-agents-for-cobol-migration-and-mainframe-modernization/

5. Bridging Code and Context: A Knowledge Graph-Based Repository-Level Code Generation，2025年12月10日檢索， https://quantiphi.com/blog/bridging-code-and-context-a-knowledge-graph-based-repository-level-code-generation/

6. Structural-Semantic Code Graph (SSCG) - Emergent Mind，2025年12月10日檢索， https://www.emergentmind.com/topics/structural-semantic-code-graph-sscg

7. SemanticForge: Repository-Level Code Generation through Semantic Knowledge Graphs and Constraint Satisfaction - ResearchGate，2025年12月10日檢索， https://www.researchgate.net/publication/397521461_SemanticForge_Repository-Level_Code_Generation_through_Semantic_Knowledge_Graphs_and_Constraint_Satisfaction

8. RANGER: Repository‑level Agent for Graph‑Enhanced Retrieval - arXiv，檢索 2025年12月10日，https://arxiv.org/html/2509.25257v1

9. 40 Legacy Software Migration Trends for Enterprises in 2025 | Adalo，2025年12月10日檢索， https://www.adalo.com/posts/cost-savings-from-replacing-legacy-tools-with-no-code-stats

10. The problems with migrating legacy code: Moving from COBOL to Java and how Metabob can help，2025年12月10日檢索， https://metabob.com/blog-articles/the-problems-with-migrating-legacy-code-moving-from-cobol-to-java-and-how-metabob-can-help.html

11. 7 Signs Legacy System Modernisation Can't Wait Any Longer - Dreamix，2025年12月10日檢索， https://dreamix.eu/insights/when-to-invest-in-legacy-system-modernisation/

12. How to plan a seamless COBOL to Java migration in 8 weeks? - OptiSol Business Solutions，2025年12月10日檢索， https://www.optisolbusiness.com/insight/how-to-plan-a-seamless-cobol-to-java-migration-in-8-weeks

13. Application Modernization Statistics: Future-Proof Insights - eSparkBiz，2025年12月10日檢索， https://www.esparkinfo.com/blog/application-modernization-statistics

14. Modernizing legacy architectures using GenAI-powered Knowledge Graphs | by Sigmoid，2025年12月10日檢索， https://sigmoidanalytics.medium.com/modernizing-legacy-architectures-using-genai-powered-knowledge-graphs-73d96169f6d7

15. How GPT Wrappers Can Accelerate Your AI Product Development - Synergy Labs，2025年12月10日檢索， https://www.synergylabs.co/fr/blog/how-gpt-wrappers-can-accelerate-your-ai-product-development

16. The Ephemeral Scaffolding or Enduring Infrastructure? LLMs, Their Wrappers, and the Specter of a Dotcom Déjà Vu - Torome，2025年12月10日檢索， https://torome.co.uk/Template/PDO3/the-ephemeral-scafolding-or-enduring-inffrastructure-llms-their-wrappers-and-the-specter-of-a-dotcom-deja-vu

17. GraphRAG vs. Vector RAG: Side-by-side comparison guide - Meilisearch，2025年12月10日檢索， https://www.meilisearch.com/blog/graph-rag-vs-vector-rag

18. Lost in the Middle in LLMS. Why large language models ignore the… | by Cengizhan Bayram | Nov, 2025 | Medium，2025年12月10日檢索， https://medium.com/@cenghanbayram35/lost-in-the-middle-in-llms-86e461dc7212

19. A practical guide to the Claude code context window size - eesel AI，檢索 2025年12月10日，https://www.eesel.ai/blog/claude-code-context-window-size

20. Lost in the Middle: How Language Models Use Long Contexts - MIT Press Direct，2025年12月10日檢索， https://direct.mit.edu/tacl/article/doi/10.1162/tacl_a_00638/119630/Lost-in-the-Middle-How-Language-Models-Use-Long

21. Why Language Models Are “Lost in the Middle” - Towards AI，2025年12月10日檢索， https://pub.towardsai.net/why-language-models-are-lost-in-the-middle-629b20d86152

22. LLM Hallucinations – Definition, Examples and Potential Remedies - Software Mind，2025年12月10日檢索， https://softwaremind.com/blog/llm-hallucinations-definition-examples-and-potential-remedies/

23. Repository GraphRAG MCP Server: A Deep Dive for AI Engineers，2025年12月10日檢索， https://skywork.ai/skypage/en/repository-graphrag-mcp-server-ai-engineers/1978326852212269056

24. AST-Based Source Code Migration Through Symbols Replacement，2025年12月10日檢索， https://www.computer.org/csdl/proceedings-article/csde/2022/10089298/1M7LebbRyEw

25. BMSD 2011，2025年12月10日檢索， https://is-bmsd.org/Documents/ProceedingsOfFirstBMSD.pdf

26. Abstract Syntax Tree Creation - Compiler Design - Meegle，2025年12月10日檢索， https://www.meegle.com/en_us/topics/compiler-design/abstract-syntax-tree-creation

27. AST (Abstract Syntax Tree) - by Dinis Cruz - Medium，2025年12月10日檢索， https://medium.com/@dinis.cruz/ast-abstract-syntax-tree-538aa146c53b

28. Daily Papers - Hugging Face，2025年12月10日檢索， https://huggingface.co/papers?q=outlier%20chunk%20handling

29. What is a Call Graph? And How to Generate them Automatically freeCodeCamp，2025年12月10日檢索， https://www.freecodecamp.org/news/how-to-automate-call-graph-creation/

30. Generation of Call Graph for Java Higher Order Functions - IEEE Xplore, 2025年12月10日檢索， https://ieeexplore.ieee.org/document/9138056/

31. Enhancing Neural Code Representation with Additional Context - arXiv，檢索 2025年12月10日，https://arxiv.org/html/2510.12082v1

32. Can We Translate Code Better with LLMs and Call Graph Analysis? - IJCAI, 2025年12月10日檢索， https://www.ijcai.org/proceedings/2025/0848.pdf

33. Code Graph: From Visualization to Integration - FalkorDB，檢索 2025年12月10日，https://www.falkordb.com/blog/code-graph/

34. Codebase to Knowledge Graph generator : r/LocalLLaMA - Reddit，2025年12月10日檢索， https://www.reddit.com/r/LocalLLaMA/comments/1mzvk44/codebase_to_knowledge_graph_generator/

35. SemanticForge: Repository-Level Code Generation through Semantic Knowledge Graphs and Constraint Satisfaction - arXiv，2025年12月10日檢索， https://arxiv.org/html/2511.07584

36. RAG vs GraphRAG: Shared Goal & Key Differences - Memgraph，檢索 2025年12月10日，https://memgraph.com/blog/rag-vs-graphrag

37. Do You Really Need GraphRAG? A Practitioner's Guide Beyond the Hype，2025年12月10日檢索， https://towardsdatascience.com/do-you-really-need-graphrag-a-practitioners-guide-beyond-the-hype/

38. Navigating the Nuances of GraphRAG vs. RAG - foojay，2025年12月10日檢索， https://foojay.io/today/navigating-the-nuances-of-graphrag-vs-rag/

39. GraphRAG vs RAG: Which is Better? | by Mehul Gupta | Data Science in Your Pocket，2025年12月10日檢索， https://medium.com/data-science-in-your-pocket/graphrag-vs-rag-which-is-beter-81a27780c4ff

40. Why not GOTO Statement? [closed] - Stack Overflow，2025年12月10日檢索， https://stackoverflow.com/questions/19766205/why-not-goto-statement

41. Alternative to a goto statement in Java - Stack Overflow，2025年12月10日檢索， https://stackoverflow.com/questions/2430782/alternative-to-a-goto-statement-in-java

42. Legacy Code Modernization with Claude Code: Breaking Through Context Window Barriers，2025年12月10日檢索， https://www.tribe.ai/applied-ai/legacy-code-modernization-with-claude-code-breaking-through-context-window-barriers

43. Legacy IT Modernization with AI | MITRE，2025年12月10日檢索， https://www.mitre.org/news-insights/publication/legacy-it-modernization-ai

44. Documenting and Modernizing Legacy Codebases with C3 Generative AI，2025年12月10日檢索， https://c3.ai/blog/documenting-and-modernizing-legacy-codebases-with-c3-generative-ai/

45. The AI revolution in application modernization: from manual burden to strategic advantage，2025年12月10日檢索， https://vfunction.com/blog/ai-app-modernization-strategy/