NTT用可追溯关系整理存量软件：AI编程如何读懂老系统

NTT于2026年10月23日公布一套面向存量软件的AI辅助分析技术，目标不是让模型凭空重写老系统，而是先把分散在需求、设计文档、源代码和测试用例里的关系梳理出来。大型系统经过多年增补，文档可能落后于实现，测试也可能只覆盖常规路径；开发者若无法确认某个函数对应哪条规格、哪些测试能验证修改影响，通用代码助手就容易在不完整上下文上做推断。

两步把上下文整理成可检查的关系

NTT将方案拆成追溯分析与综合测试生成两部分。第一部分按功能单元整理规格、设计、代码之间的上下游联系，再检测遗漏、矛盾和粒度不一致。公告称，它会调整段落切分粒度、提取各阶段信息要点并映射依赖，而不是只把相似文档片段检索给模型。第二部分依据相互一致的规格、设计与代码建立测试视角空间，把已有测试映射进去，暴露边界值、异常条件、多条件组合及跨功能影响等薄弱处，再用决策表等方法补出可执行用例。

这与直接问模型“请为这个模块生成测试”有不同的工程路径：先说明功能从何而来、如何实现、目前被哪些测试覆盖，再从覆盖空白派生测试。规格工程标准ISO/IEC/IEEE 29148讨论需求工程过程与信息，ISO/IEC 25010提供产品质量特性模型；它们能帮助团队设计检查视角，但标准本身并不证明NTT工具的检测效果。

80%是样例实验结果，不是普遍准确率

NTT在Macchinetta Framework的ATRS示例应用上做了初步实验。追溯分析测试在设计文档中人工植入41项错误，包括与规格或代码矛盾、信息缺失等情况。传统RAG方法检出11项，即27%；新方法检出33项，即80%。测试生成实验则在目标代码中植入6个错误，方案检出4个，并另找出3个此前未知的问题；公告指出，直接由生成式AI依据规格造测试的对照方式没有发现这3个潜在缺陷。

这些数字来自有限样例与NTT自己的测试，不等于真实企业系统会达到相同召回率。41项植入错误的种类、项目规模、语种、系统年代和标注质量都会影响结果；公告也明确说，正在把技术放到不同规模与特征的实际系统验证，并继续扩展支持的制品和编程语言。因此，当前准确说法是“公布了初步实验”，而不是“已经能自动修好企业遗留代码”。

团队可以怎样评估

较稳妥的试点方式是选一个业务边界清楚、资料可脱敏的模块，先抽样核对规格与代码链路，再检查生成结果是否能被工程师追溯到来源。随后把现有测试按功能与质量视角分类，评估工具提出的缺口是否真实，再在隔离分支生成少量用例，交给代码所有者审核、执行并比较误报和漏报。评估指标应包含关系映射的人工确认率、错误类型覆盖、测试可执行比例、误报处理时间，以及修改后回归风险，而不只是生成了多少条文档或用例。

还要提前检查项目权限、源码和缺陷记录是否会送出团队边界，文档模板与旧语言是否受支持，以及结果能否接入现有代码审查和测试流水线。NTT公告没有公布产品名称、价格、可下载实现、公开基准数据或独立复现，也没有给出对所有语言的兼容清单；它描述的是研发技术和后续项目验证计划。

结论：这条动态值得关注，是因为它把AI编程从补全新代码推进到“先理解旧系统关系、再验证变更影响”的工程问题。现阶段的价值是提示团队如何组织需求、设计、实现和测试证据；是否能节省维护成本，要等真实代码库试点、误报复核和长期质量数据。将它视为需要验证的研发方案，比把一次预实验当成生产保证更可靠。

来源资料

• NTT 2026-10-23 官方公告与实验方法
• NTT提及的ATRS示例应用
• ISO/IEC/IEEE 29148:2018 需求工程标准
• ISO/IEC 25010:2023 软件与系统质量模型
• Lewis等人的Retrieval-Augmented Generation研究