技术深度解析
AI驱动代码考古的核心机制在于Transformer架构对代码中长程依赖关系的建模能力。与依赖模式匹配或抽象语法树的传统静态分析工具不同，GPT-4o、Claude 3.5等LLM以及DeepSeek-Coder、CodeLlama等开源模型，利用注意力机制理解代码背后的语义意图，而不仅仅是其语法。
当开发者输入遗留代码库时，LLM将其作为一系列Token处理，但其在数十亿行来自不同语言和时代的代码上的训练，使其能够推断出约定俗成的惯例、常见模式甚至已弃用的API。例如，一段用COBOL编写的执行文件读取的函数，可以被理解为现代I/O操作的上下文，因为模型已在不同语言中见过类似模式。关键的技术突破在于上下文学习：通过提供几个如何记录或解释代码片段的示例，模型可以泛化到整个代码库。
一个备受关注的开源工具是sweep-ai/sweep，这是一个GitHub仓库（超过7000星），利用LLM自动生成代码库改进的拉取请求。虽然它并非专门针对遗留代码，但其架构——包括解析仓库、识别相关文件并生成修复——直接适用。另一个值得注意的项目是gpt-code-clippy，它使用LLM以自然语言解释代码，并已被用于记录未文档化的内部库。
性能基准测试揭示了其能力与局限：
| 模型 | HumanEval Pass@1 | 代码理解 (CodeXGLUE) | 上下文窗口 | 每百万Token成本（输入） |
|---|---|---|---|---|
| GPT-4o | 90.2% | 87.5% | 128K | $5.00 |
| Claude 3.5 Sonnet | 84.0% | 85.1% | 200K | $3.00 |
| DeepSeek-Coder-V2 | 86.5% | 84.3% | 128K | $0.14 |
| CodeLlama-34B | 48.8% | 71.2% | 16K | 免费（自托管） |
数据要点： 虽然GPT-4o等闭源模型在代码生成基准测试中领先，但DeepSeek-Coder-V2等开源模型以极低的成本提供了有竞争力的理解能力，使小型团队也能进行遗留代码分析。上下文窗口至关重要：遗留系统通常具有深度嵌套的依赖关系，需要一次性处理整个文件甚至模块。
然而，存在工程陷阱。LLM可能会幻觉出不存在的依赖关系，或误解混淆的代码。为缓解这一问题，开发者将LLM输出与SonarQube或CodeQL等静态分析工具结合，以验证生成的文档是否与实际代码结构一致。最有效的工作流是迭代式的：LLM生成初步解释，开发者纠正错误，模型再优化其理解。
关键参与者与案例研究
多家公司正围绕这一能力积极构建产品。GitHub Copilot已从代码补全扩展到代码解释与重构，但其重点仍在活跃开发上。Tabnine提供类似功能，但采用隐私优先的方法，吸引拥有敏感遗留代码的企业。一个更专业化的参与者是Swimm，它通过分析代码变更，利用AI生成并维护文档。
一个引人注目的案例来自一家大型欧洲银行，该银行使用LLM记录了一个有20年历史、基于大型机的交易处理系统。该系统用一种专有的COBOL变体编写，没有文档，仅由一名即将退休的工程师维护。通过将源代码及样本输入/输出提供给LLM，该银行生成了一份功能规格文档，使新团队能够开始现代化改造。该项目原估计需要18个月，实际在3个月内完成。
| 解决方案 | 主要用例 | 定价模式 | 关键局限 |
|---|---|---|---|
| GitHub Copilot | 代码补全与解释 | $10-39/用户/月 | 大文件的上下文窗口有限 |
| Tabnine | 代码补全与文档 | $12-39/用户/月 | 对冷门语言效果较差 |
| Swimm | 文档生成 | 企业定制 | 需与CI/CD集成 |
| 自定义LLM流水线 | 遗留代码考古 | 可变（计算+API成本） | 需要提示工程专业知识 |
数据要点： 没有单一工具主导遗留代码考古领域。最有效的方法仍是结合LLM、静态分析和人工监督的自定义流水线。安全要求高的企业正倾向于自托管的开源模型。
行业影响与市场动态
软件维护市场巨大。据行业估计，全球在遗留系统维护上的支出每年超过1万亿美元，IT预算的70-80%用于维持现有系统运行。AI驱动的代码考古学的引入可能从根本上改变这一平衡。