接手前任留下的屎山代码，如何利用 AI 组合拳快速完成逆向工程
在这种场景下，如果还坚持用传统的“全局搜索 + 逐行阅读”来排查问题，效率低得惊人。因为这种代码的逻辑往往不是线性的，而是通过各种隐蔽的依赖关系交织在一起的。为了快速理清现状，我尝试用目前市面上主流的几个大模型来分析这段代码，实测结果给我的启发很大。
首先是 Claude 3.5 Sonnet。在分析旧代码逻辑方面，它目前表现出了极强的统治力。我尝试将几个相互关联、且包含大量冗余判断的复杂函数丢给它，它不仅能迅速梳理出隐藏的依赖关系，甚至能精准指出哪几行代码在制造内存泄漏。它的逻辑推理能力更像一个资深的架构师，能够读懂代码背后的“潜台词”，也就是开发者在写这段代码时试图解决什么问题，以及在哪个环节出现了偏差。
相比之下，GPT-4o 的表现则略有不同。它的响应速度极快，但在面对逻辑混乱的旧代码时，它倾向于给出一些泛泛的重构建议（比如建议你把函数拆分、增加注释），而不是直接定位具体的 Bug。不过在处理具体的报错信息时，它依然非常高效，能迅速给出可行的临时修复方案，但缺乏对全局上下文的深度洞察。
至于 DeepSeek V3，它在处理纯技术细节和语法优化上非常硬核，性价比极高。但由于这类旧项目带有强烈的“历史包袱”和特定的业务逻辑，DeepSeek 在理解这些非标准、非规范的业务逻辑时，稍微逊色于 Claude。
通过这次实操，我总结出了一套面对没人维护的烂项目时的 AI 工作流，建议大家参考：
第一步，利用 Claude 3.5 对关键模块进行逻辑反推。不要直接问它代码在做什么，而是要求它将复杂函数转化为伪代码文档。通过这种方式，你可以快速把一个 500 行的混乱函数变成一个清晰的逻辑流程图，从而搞清楚数据的流向。
第二步，将具体的报错日志（例如具体的 Stack Trace 堆栈信息）和相关的代码片段喂给 GPT-4o。利用它快速迭代修复方案的能力，在保证不破坏全局逻辑的前提下，先解决掉最紧急的 Bug。
第三步，在逻辑理顺且 Bug 修复后，使用 DeepSeek 进行最后的代码精简和性能优化。将修复后的代码交给它，让它在不改变功能的前提下，通过更现代的语法特性来精简冗余代码，提升运行效率。
这次踩坑让我意识到，在 AI Agent 时代，接手代码的核心能力已经发生了转移。过去我们追求的是阅读代码的速度，而现在核心能力变成了如何通过精准的提示词，驱动不同的模型帮你完成“逆向工程”。当你能把 AI 当作一个能够快速理解上下文的虚拟架构师时，所谓的“屎山”也不过是一堆待整理的数据而已。
