逆向工程不再慢吞吞，Thoughtworks 仅 3 周还原功能蓝图

Thoughtworks 的咨询顾问近期分享了一项实验：他们尝试将生成式 AI 应用于一个完全没有源码可用的遗留系统。

这篇文章最初发布在 Martin Fowler 的博客上，介绍了一个试点项目：一个五人团队同时从数据库、用户界面和二进制文件三个角度对该系统展开分析。

InfoQ 与文章作者 Thiyagu Palanisamy 和 Chandirasekar Thiagarajan 进行了交流。据介绍，在为期两周的试点中，团队使用 Gemini 2.5 Pro 对这一庞大遗留系统的一小部分进行分析。最终产出是一份功能规格说明书——即“黑箱”系统的功能蓝图，能够由领域专家进行验证。

AI 在代码分析、二进制文件归纳和数据库变更追踪上展现了优势，也让原本复杂的数据库结构梳理变得简单得多。

在解析汇编代码的逆向工程中，AI 的作用尤为明显。传统方法可能需要耗费数月，才能逐步解读汇编代码中复杂的逻辑，并区分哪些属于系统函数、哪些属于业务功能，而 AI 显著缩短了这一过程。

实验结果显示，AI 能显著提速逆向工程，让企业不必再完全依赖缓慢、繁琐的人工分析来理解遗留系统。

许多企业的核心系统，由于使用多年，逐渐变得晦涩难懂：文档不完整，源码缺失，经验性知识也随着人员流失而消散。

文章将这种情况称为“黑箱”问题：系统继续运行，但内部逻辑已难以掌握。解决思路不是重新生成代码，而是重建一份功能意图的“蓝图”，以便在现代化过程中降低风险。

试点采用了多种技术路径。一方面，团队通过对比 UI、数据库模式和运行时行为，尝试将不同来源的数据“串联”起来。另一方面，他们利用变更数据捕获（Change Data Capture, CDC），追踪用户操作如何触发数据库中的变更。

之后，团队开始把数据库的变化与二进制调用关联起来，逐步还原服务器逻辑。他们称这种方法为“AI 辅助的二进制考古学”：通过反编译工具和大语言模型来概括函数作用，并猜测它们各自的职责。

整个过程是迭代进行的，包括寻找相关函数、构建子树、验证入口点，再将零散的片段拼接成连贯的功能说明。

在每个阶段，AI 都能提供加速：生成摘要、突出关联关系或草拟候选规则，而最终的结果则由人工进行验证。

领域专家在审阅输出结果后表示，这些规格说明准确度足够高，可作为可信的参考依据。作者告诉 InfoQ，只要核心团队保持稳定，并积累足够的系统上下文，他们相信这种方法可以顺利扩展到整个系统。

作者还补充说，这些技术已被应用到其他客户项目中，无论是否能获取源码，都能显著加快对遗留系统的理解。

当然，实验也揭示了一些挑战。虽然 AI 加快了许多环节，但其输出并非总是可靠，存在幻觉、误报或覆盖不足等风险。每条假设都需要通过其他证据加以验证。

因此，验证环节显得至关重要。团队通过交叉比对不同数据源，并请领域专家复核，确保初稿规格说明的准确性，从而在提高效率的同时保持可靠性。

这次试点让架构师看到，AI 能在逆向工程中提供帮助：它可以关联 UI、数据库和二进制文件数据，生成初步功能说明，而最终的准确性仍需专家验证。

基于试点取得的积极结果，InfoQ 对作者 Thiyagu 和 Chandirasekar 进行了更深入的访谈，了解试点的具体设置及他们对这一技术前景的思考。

InfoQ 访谈节选

InfoQ：试点持续了多久？团队规模多大？

大约 2 周，团队由 5 人组成，同时从数据库、应用 UI 和二进制文件三个方向展开工作。我们分析了 24 个业务领域中的一个，其中包括 650 张表、1200 个存储过程、350 个用户界面以及 45 个编译后的 DLL。

InfoQ：除了这次小范围试点，团队是否有信心该方法能扩展到整个系统？

信心很高，只要能保持核心团队的连续性与上下文积累。通过小范围实验，我们掌握了方法和技术，也加深了对问题和业务领域的理解。

InfoQ：这种方法后来是否已应用到其他客户项目中？

是的，已经用于其他类似的项目，无论是否能获取源码，这种方法都能显著加快对遗留系统的理解。

InfoQ：AI 生成的规格说明给客户带来了怎样的实际价值？

我们向客户展示了小范围试点的详细规格说明，这让他们对推进项目充满信心。同时，借助相同的方法，我们还识别出了整个系统的关键能力，让客户对整体系统有了比以往更深入的理解。

InfoQ：在哪些场景下，AI 的表现与传统逆向工程方法差异最明显？

在 ASM 代码的逆向工程上差异最大。传统方法需要数月才能完成逻辑解析和系统功能识别，而 AI 显著缩短了时间。

InfoQ：最大的挑战或潜在风险是什么？

一个主要问题是 AI 在处理细粒度任务时表现最佳，但在面对大规模上下文时容易出现幻觉。我们还发现模型存在“正向偏差”，有时会生成看似正确但实际上不准确的结果。结论是：AI 最适合用于细节分析，而对整体上下文的理解和判断，仍然需要人工验证和整合。

InfoQ：团队是如何进行验证的？有哪些管理或审核机制确保 AI 生成的结果可信？

我们将工作拆分为若干小步骤，并在每一步详细标注数据来源，便于核查和验证。通过逐步验证，确保整体结果的可信与一致性。

InfoQ：你们认为这一方法未来几年会如何发展？期待出现哪些工具链或实践？

我们预期会出现新一代工具链，使上下文的采集和整合几乎无缝完成，例如借助 MCP server 风格的封装来编排现有的逆向工程工具。未来 AI 也可能原生集成这些工具，在工程师探索复杂系统时实时提供洞察。更具变革性的是协作式的上下文构建，让多方利益相关者能够实时共同创建、验证和进化系统蓝图，大幅缩短从发现到决策的周期。

InfoQ：你们对其他想尝试这一方法的团队有什么建议？

先从可控的小范围试点入手，从中积累经验和启发，再逐步推进遗留系统的现代化改造。

原文链接：

https://www.infoq.com/news/2025/09/tw-blackbox/