加载失败
Hypercubic（YC F25）的产品 HyperDocs 宣称能摄取 COBOL、JCL、PL/I 等大型机代码库，自动生成文档、架构图与依赖图，并尝试构建反映工程师实践的“数字孪生”。讨论围绕两个事实展开：一是传统迁移（如源码翻译到 Java 或完全重写）经常因测试覆盖不足、超支或缺乏运维经验而失败；二是企业面对 SME 退休、向 IBM 支付高额维护费以及高层推动 AI 项目的现实动力，促使自动化知识提取成为商业机会。评论中既有人肯定用多模态（代码、文档、访谈、工作流捕获）抽取隐性知识的价值，也有人质疑 AI 能否可靠还原潜规则、是否会引入新漏洞，以及“70% Fortune 500 使用 COBOL”类统计的含义。补充背景还包括其他遗留生态（如医院/政府常见的 MUMPS）和厂商（如 IBM）的既有研究，表明该领域既有市场与资金，也存在合规、数据访问和可证明正确性的挑战。
评论指出传统遗留系统现代化经常失败且代价高昂。一个项目把 COBOL 源码翻译成 Java 因缺乏生产级 Java 运营经验被中止，另一个重写工程则因超支被取消。保守的迁移流程通常要求先构建大量输入/输出对的测试套件，再逐行重写并在达到 100% 覆盖后进行 shadow run（将同一流量同时发给旧系统与新系统对比），但很多项目缺少这种全面测试步骤。由此得出结论：迁移既昂贵又复杂，风险控制与测试准备是核心难题。
多条回复认为本方案的核心价值在于把长期维护者（SME）的“部落知识”结构化，而非直接改写大型机。支撑理由包括 SME 退休导致知识流失、许多公司每年向 IBM 支付 7–9 位数维持大型机运行，以及企业高层对 AI 项目的强力推动，这些都构成进入企业的尾风。实现手段强调多模态信息三角化：现有代码、文档、AI 驱动访谈与工作流捕获结合用于抽取隐性规则；评论方同时承认 COBOL 在通用 LLM 训练语料中样本较少，但其高度结构化可让推理模型达到可用水平。为达到接近 95% 以上的精度，创始人和评论者提出需要构建面向遗留系统的专用 frontier models。
许多评论对 AI 生成的文档或“数字孪生”是否能可靠还原隐含业务逻辑持怀疑态度。实际重要逻辑常埋在命名约定、隐含规则和未成文做法中，AI 可能只输出稀疏的 wiki 而无法复制专家在边界情形下的判断，从而引入生产级错误风险。还有人担忧治理、访问控制与数据保密问题，以及企业是否愿意承担由自动化带来的改动和潜在故障。总体语气谨慎甚至讽刺：把 AI 加到“恐龙级”大型机上听起来有趣，但不等于解决了核心风险与责任归属问题。
评论同时指出除了 COBOL/大型机外，像 MUMPS（医院与政府系统常见）这类遗留生态也是有价值的目标市场，因为政府与医疗系统背后有较大预算。有人质疑“70% 的 Fortune 500 仍在用大型机/COBOL”这一统计的来源与含义：是企业自身大规模维护百万行 COBOL，还是依赖少数金融或服务商的下游供应？另有提醒指出厂商（如 IBM）在大型机上已有相关研究与产品，说明市场上存在既有竞争与技术投入。评论因此强调须厘清目标客户的实际代码规模、数据访问与决策链条，才能评估商业可行性。
COBOL: COBOL：一种为商业数据处理设计的老牌编程语言，历史悠久且在银行、账单和批处理系统中遗留大量代码，训练数据在通用 LLM 中相对有限但语言结构化。
Mainframe（大型机）: Mainframe（大型机）：指企业级高可靠服务器（如 IBM z 系列），用于核心事务处理与高并发金融交易，维护成本高且常作为遗留平台存在。
JCL: JCL（Job Control Language）：IBM 大型机上的作业控制语言，用于定义批处理作业、运行参数和输入/输出配置。
PL/I: PL/I（Programming Language One）：1960s 出现的系统/业务混合编程语言，历史上在大型机环境中使用，在部分遗留代码库仍可见。
MUMPS: MUMPS（也写作 M 或 MUMPS）：一种集成了数据库与语言的老旧技术，历史上在医院与政府系统（例如美国 VA）广泛使用，维护群体有限。
数字孪生 / digital twin: 数字孪生（digital twin）：将专家知识或系统行为建模为可查询的虚拟实体，用于解释、仿真、调试或自动回答“代码在做什么”的问题。
SME: SME（Subject Matter Expert）：领域专家或长期维护者，掌握代码中未文档化的“部落知识”，是许多现代化项目的关键风险点。
shadow run（影子运行）: shadow run（影子运行）：迁移或替换后将相同线上流量同时发送到旧系统与新实现进行比对验证的做法，常用于金融级系统以最小化风险。