理解的架构： 超越语法的企业遗留系统 现代化

执行摘要

企业遗留系统的现代化——具体而言是将大型机 架构迁移到云原生环境——已在 2020年代中期达到关键拐点。数十年来，金融与政府部门一直在一种 悖论式范式下运转：现代化的必要性关乎存亡，然而此类 举措的失败率仍灾难性地居高不下，徘徊在70%到80%之间。 ¹ 近期出现的 大语言模型（LLM）曾许诺一场革命，提供了诱人的 自动化代码翻译。然而，早期采用周期揭示了关键、系统性的 缺陷，当标准生成式AI方法应用于复杂、单体式 代码仓库时。

我们目前正在目睹一类新的工程失败形态的出现，其典型 情形是一个虽带传说色彩却高度写实的场景：某大型银行试图用商业编码助手将三十年 的COBOL改写为Java。该AI作为 精密的局部翻译器，完美地转换了语法。然而，由此产生的 应用程序在部署时使数据库崩溃。失败不在语法，而在 上下文。该AI受"中间迷失"综合征以及基于文本的 软件理解所限，错过了在执行块之前数千行处定义的 关键变量依赖。 ³

本白皮书由Veriprajna提出，论证现行的"LLM包装器" 方法——将代码视为文本标记的线性序列——从根本上不适合 企业现代化的非线性复杂性。软件不是文本；它是图。它 是一个由逻辑依赖、数据流和状态变化构成的高度结构化系统，存在于 多维拓扑空间之中。 ⁵

我们主张，唯一可行的前进路径是采用 仓库感知知识 图谱 。通过从随机文本预测转向基于图的确定性推理， 我们可以在数百万行代码中映射变量依赖，化解"中间 迷失"现象，并将现代化从一场高风险赌博转变为 可数学验证的工程过程。 ⁷ 本文档概述了从表面层语法翻译到深层语义结构转换的技术 过渡。

第1章：遗留的无声危机 基础设施

1.1 现代化悖论

在当前数字经济中，全球商业的基础设施岌岌可危地依赖于 冷战时期开发的技术。一个令人震惊、却常常不被承认的现实是， 到2025年，全球金融、医疗与政府系统中相当大的多数 仍由遗留代码库驱动——用COBOL、 PL/I和RPG等语言编写的单体应用，而这些语言早已淡出主流计算机科学课程。 这些系统不仅仅是"旧"；它们是全球经济的奠基基石， 却正在以惊人的速度侵蚀。

统计数据描绘了这种依赖的严峻图景。大约70%的软件 运行于《财富》500强公司的，是二十多年前开发的。 ⁹ 在银行业， 情况更为尖锐：43%的银行系统建立在COBOL之上，而这些 系统处理95%的ATM交易。 ¹ 我们实际上是在用早于互联网的数字根基运行现代、 即时支付经济。

维持这一现状的成本正在飙升。技术债务已累积至 仅美国就估计达$1.52 trillion。 ¹ 组织被困在"维持灯火 常明"的循环中，联邦IT预算的80%用于运维，仅留下 微薄的20%用于创新。 ⁹ 这种资源抽干又叠加严重的技能短缺； 随着编写这些系统的那一代开发人员退休，维护它们所需的机构知识 随之消失。 ¹⁰

表1：遗留系统的经济负担

指标	统计	来源
技术债务成本（美国）	$1.52 Trillion	1
联邦IT运维 预算	~80%的总支出	9
银行业依赖	95%的ATM交易 运行于COBOL	1

数据泄露概率	对>10的系统高出3倍 年	11
开发人员流失	58%考虑因 遗留技术栈而离职	1

这些数据表明一种系统性脆弱。现代化的必要性不仅仅关乎 降低成本；它关乎生存。超过十年的系统在统计上是三倍 更有可能遭遇安全漏洞，相较于现代应用。 ¹¹ 随着监管 对数据隐私与实时报告的要求收紧（例如GDPR、DORA），遗留系统无法适应 便成为最高级别的合规风险。

1.2 "银行失败"解剖

要理解新方法的必要性，我们必须剖析那个已成为 AI现代化失败"零号病人"的场景。该案例研究由 Veriprajna领导层引用，说明了标准AI在企业环境中失败的 具体机制。

一家大型金融机构启动项目，将核心交易处理系统 从IBM大型机（COBOL/DB2）迁移到云原生Java微服务架构。该 银行使用了一款流行的AI编码助手——本质上是基础模型外的一层 包装器——来翻译代码。

AI摄入了一个负责处理高额电汇的COBOL程序。该 程序包含一条涉及我们称为TRN-LIMIT的变量的复杂COMPUTE语句。 AI完美地翻译了语法。它将COMPUTE语句转换成Java BigDecimal运算。代码编译通过。由同一AI基于 局部代码块生成的单元测试——也通过了。

然而，一旦部署到用户验收测试（UAT）环境，第一笔 交易就使数据库一致性检查崩溃。

解剖： 变量TRN-LIMIT并非定义在AI所翻译的源文件中。它定义在 执行链更早数千行处被包含的COPYBOOK（共享头文件）中。 更重要的是，该COPYBOOK包含一条REDEFINES子句——一种COBOL构造， 允许同一内存地址根据完全不同模块中设置的标志被解释为两种不同的 数据类型。 AI在对一段文本"块"操作时，把TRN-LIMIT看成简单的数值字段。它没有看到 REDEFINES子句，因为该子句位于另一文件中，并不在即时 上下文窗口内。它为该变量"幻觉"出标准定义。在大型机 环境中，该内存地址保存压缩十进制；在Java环境中，AI 将其当作标准整数。这种不匹配导致Java应用将损坏的 二进制数据写入数据库列，触发参照完整性失败。 ⁴

失败不在语法；Java代码在句法上是完美的。失败在于 上下文盲视 。AI错过了存在于其"视野"之外的依赖， 导致灾难性的语义偏离。

1.3 "搬迁上云"与重构的两难

即使在生成式AI引入之前，行业在现代化方面的战绩也极为糟糕。 研究表明，70%到80%的数字化转型与 遗留现代化项目未能达成目标。 ²

传统上，组织面临二元选择：

1.​ 重新托管（搬迁上云）： 将已编译应用移到云中的仿真器。这 保留了"意大利面条代码"和债务，只是换了托管账单。它无法 释放云的敏捷性。 ¹⁴

2.​ 重写（重构）： 用现代语言手工重写代码。这 代价天文数字般高昂、缓慢且风险大，原因是缺少文档以及"大泥球" 架构，其中业务逻辑与数据访问纠缠得无法解开。 ¹⁰

生成式AI本应提供"第三条路"——自动化重构。然而， "银行失败"证明，若没有对软件拓扑的更深理解，AI只是 加速了有缺陷代码的产生。

第2章：随机性的失败 翻译

2.1 "包装器"经济及其限度

进入这一高风险环境的是"LLM包装器"。软件咨询市场对 GPT-4发布的即时反应，是大量工具涌现，它们充当 开发者与基础模型之间的薄软件层。 ¹⁵ 这些工具承诺 "与你的代码聊天"，让开发者粘贴一段COBOL段落并得到一段Java 方法作为回报。

虽然这些包装器降低了采用AI的门槛，但它们从根本上是有缺陷的 当应用于大规模系统再工程时。包装器通常依赖 朴素RAG （检索增强生成）。在此过程中，系统接受用户查询，搜索一个 向量数据库中与查询在_文本上相似_的代码片段，并将这些 片段作为上下文喂给LLM。 ¹⁷

该方法在企业场景中的局限极为严重：

1.​ 上下文近视： 包装器把代码看成文本片段。它不理解 在SECTION-A中被修改的变量ACCOUNT-BALANCE会驱动 五千行之外SECTION-Z中的决策逻辑。

2.​ 句法成功，语义失败： 如前所述，LLM可以生成 编译完美却无法复现原始COBOL精确运行时行为的Java代码， 因为它错过了一次全局状态变化。 ⁴

Veriprajna通过拒绝"薄包装器"哲学来自我区分。我们主张，深度 AI方案必须理解仓库的_结构_，而不仅仅是文件的_文本_。

2.2 "中间迷失"综合征

要理解标准AI为何在遗留现代化中失败，我们必须理解 大语言模型的认知架构。这些模型基于 Transformer架构，它使用"注意力机制"来权衡输入文本不同部分的 重要性。 ¹⁸

尽管现代LLM夸耀巨大的上下文窗口（高达100万个标记），它们 有效地_使用_该上下文的能力并不均匀。实证研究表明一种 被称为 "中间迷失"效应 的现象。当面对一段长 信息序列时，LLM呈现U形表现曲线：

●​ 首因偏差： 它们对回忆开头的信息高度准确 提示。

●​ 近因偏差： 它们对回忆提示末尾的信息高度准确。

●​ 低谷： 位于中间的信息，表现显著下降。 ³

在现代化项目中，单个COBOL程序可能长达数千行，并且它 可能引用本身也长达数千行的copybook（依赖）。如果 某个关键变量的定义——例如MAX-TRANSACTION-LIMIT——出现在这巨大上下文的 中间，AI在统计上很可能忽略它。 ²¹

当AI忽略变量定义时，它并不停止。它会"幻觉"。它基于概率而非事实为变量假定 默认类型或值。在银行系统中， 若假定某变量是Integer而它实际是压缩十进制，可能导致舍入 错误，从而损坏财务数据。 ²²

表2：标准LLM的认知局限

现象	描述	对现代化的影响
中间迷失	长提示中部的注意力 退化。3	错过埋在大型文件中的 变量定义。
幻觉	编造看似合理但 不正确的事实。22	发明依赖或 逻辑以填补上下文缺口。
首因/近因偏差	聚焦开头/结尾的 文本。20	忽略位于过程中部的 核心业务 逻辑。
随机生成	概率性文本 预测。	不一致的代码 生成；重新运行 提示会产生不同的 逻辑。

2.3 "词袋"对"逻辑树"

标准LLM与向量RAG系统主要将代码作为标记序列处理。 它们依赖语义相似性——检查查询中的词是否匹配文档 向量空间中的词。 ¹⁷

然而，代码不是自然语言。在自然语言中，"猫坐在垫子上"的 含义在很大程度上独立于五十页之前的句子。在软件中，x = y + 1毫无 意义，除非我们知道x和y的定义、类型和当前状态。这些 定义可能存在于不同文件、不同模块，或从父 类继承。 ⁵

当"包装器"AI为诸如"重构支付逻辑"的查询检索上下文时，它可能 取出包含单词"payment"的五个代码块。它很可能错过名为 GlobalVarDef.cbl的块，该块定义了支付逻辑使用的税率，因为该文件从未 提及单词"payment。"

这种脱节代表了_文本检索_与_结构_ _理解_之间的根本鸿沟。要弥合这一鸿沟，我们必须停止把代码当文学，开始把它 当作图。 ²³

第3章：软件的物理学 –

代码即图

3.1 软件作为关系系统

在Veriprajna，我们认识到软件仓库从根本上是一个 关系型数据库 之逻辑 。代码库中的每个实体——变量、函数、类、模块、数据库 模式——都存在于密集的关系网中。

●​ 包含： 文件包含类；类包含方法；方法包含 变量声明。

●​ 继承： 类B从类A继承属性和方法。

●​ 调用： 方法X调用方法Y。

●​ 数据流： 变量Z由函数Q修改并由函数R读取。

这些关系构成应用的"基本事实"。它们不是概率性的； 它们是确定性的。如果方法X调用方法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标记的 片段，常常把函数拦腰切断——AST解析尊重逻辑边界 即该代码。函数被当作离散的逻辑单元，而不是随机的文本跨度。 ²³

3.3 调用图与依赖矩阵

AST表示单个文件的结构，而 调用图 则表示整个应用的神经 系统。它可视化控制流，映射哪些段落或 子程序调用其他。 ²⁹

在遗留COBOL系统中，调用图常被动态调用或GOTO逻辑所遮蔽，这些逻辑 造成"意大利面条代码。"静态文本分析难以解析GOTO LABEL_X落在何处， 如果LABEL_X是动态或有条件定义的。

通过构建严谨的调用图，Veriprajna识别"死代码"（从未被 调用的代码）和"上帝类"（耦合过重的模块）。该分析对于 将单体拆成微服务至关重要。若我们不知道完整调用链，我们 就不能安全地抽取服务；我们冒着留下将导致 运行时失败的"悬空引用"的风险——这正是开篇案例中困扰该银行的确切场景。 ³¹

表3：结构分析对文本分析

特征	文本分析（标准 AI）	结构分析 （Veriprajna）
分析单元	标记 / 词	节点（AST元素）
上下文边界	任意标记上限	逻辑作用域 （函数/类）
依赖解析	关键词匹配	图遍历
GOTO处理	当作文本字符串	映射控制流边
准确性	概率性	确定性

3.4 依赖注入与反转

现代Java与云原生架构严重依赖依赖注入（DI）和 控制反转（IoC）。遗留COBOL则相反，依赖硬编码依赖 和全局状态。从一种转向另一种，需要识别图中的每一个依赖并 "反转"它。

我们必须把范式从"模块A硬编码到数据库B的连接"改为 "模块A将数据库连接作为参数接受。"这一架构转变 如果AI根本看不见该依赖，便是不可能的。知识图谱 使这些依赖显式化，让AI自动生成必要的DI样板 代码，确保新系统模块化且可测试。 ⁴

第4章：Veriprajna语义 熔炉

4.1 仓库感知知识的架构 图谱

对"中间迷失"综合征以及基于文本的迁移之脆弱性的解决方案是 仓库感知知识图谱 。这是一个统一的图数据库，它结合 代码的静态结构（AST、调用图）与 业务逻辑的语义含义（文档、注释、变量意图）。 ⁵

Veriprajna采用专有流水线，在前沿研究中常被称为 "语义熔炉"，以构建这种智能。这不是通用ETL过程；它是 专为遗留现代化打造的引擎。 ³³

4.2 第1阶段：用Tree-sitter进行智能解析

我们使用稳健的解析器，主要是 Tree-sitter，以摄入遗留代码库。该过程 支持超过13种语言，包括COBOL、JCL、PL/I和Java。解析器为仓库中的每个文件生成 AST。

关键的是，我们采用 语义分块 。标准RAG流水线使用"朴素切分"， 每隔_n_个标记切割文本。这经常把函数签名与其函数体切断，或把 变量定义与其使用切断，从而摧毁上下文。语义分块使用AST来 识别逻辑边界。我们按SECTION、PARAGRAPH或METHOD对代码分块， 确保图中每个节点都代表一个完整、可执行的逻辑单元。 ²³

4.3 第2阶段：实体与关系抽取

一旦AST生成，语义熔炉便抽取实体与关系以 填充图数据库（例如Neo4j、Memgraph）。

●​ 实体： 类、段落、变量、数据库表、API端点。

●​ 关系：

○​ CALLS：将段落连接到它调用的子程序。

○​ UPDATES_TABLE：将逻辑块连接到它修改的DB2表。

○​ IMPORTS_COPYBOOK：将源文件连接到其依赖。

○​ DEFINES_VARIABLE：将数据部连接到它创建的变量。

这一阶段把静态文本转变为动态拓扑。我们现在可以查询该图： "向我展示每一个更新CUSTOMER-ID字段的段落。"该查询立即返回精确 结果，这是grep或向量搜索无法做到的。 ¹⁴

4.4 第3阶段：实体解析与合并

这是关键的差异化点。标准解析器把文件A中的ACCT-NUM和 文件B中的ACCT-NUM看成两个不同字符串。我们的系统执行 符号解析 。它 判定两者指向共享Copybook中的同一条目。它将这些合并为图中的一个 单一变量节点。

此外，我们执行 跨模态合并 。如果代码库包含一份PDF 需求文档，描述"User API"，而代码中有一个名为 UserAPI的类，系统计算嵌入以识别它们是同一概念。它 将文档节点与代码节点合并。这将_意图_（文档）与 实现（代码）相连，向AI同时提供"为什么"与"如何"。 ⁸

4.5 第4阶段：传递闭包计算

"银行失败"由传递依赖引起：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，语义相似性 会下降，即使逻辑完全相同。

●​ 逻辑对关键词： 搜索"利息计算"可能错过实际数学，如果 函数名为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在图的引导下，将这些跳转重构为Java中的while循环、 do-while循环或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 仓库感知的投资回报

麦肯锡数据表明，生成式AI可将编码任务减少50%，但仅当正确 部署时。 ¹⁴ Veriprajna基于图的方法的投资回报（ROI）由 消除返工所驱动。

●​ 手工迁移： 高成本、高风险、上市慢。

●​ 包装器AI： 中等成本（因调试"幻觉"）、高风险（隐藏缺陷）、 中等上市时间。

●​ 仓库图谱AI： 低成本（自动化）、低风险（确定性验证）、快 上市时间。

通过消除"上下文切换"开销——开发者花费数小时寻找 变量定义在何处——Veriprajna将开发者生产力提高2倍到3倍，相较于 标准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，访问于12月 10日，2025年，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/