号称能“逆向一切”的AI工具爆火，狂揽近30万颗Star，软件开发的护城河守得住吗？

从办公软件 Notion 的剪贴板机制，到经典游戏 DX-Ball 的声音算法，再到《东方幻想乡》的弹幕计算方式，一系列演示引发了广泛关注。 截至 10 月 17 日，GitHub 页面显示，其 Star 数已超过 29 万 。 科技博主 Matthew Berman 甚至在社交平台上感叹：“Software is done”（软件完了）。

热潮之下，各种 AI 逆向软件的案例也开始传播。有人尝试重建 Claude 的幻灯片编辑器，有人用它给家里的智能马桶开发新的控制工具，还有开发者借助 AI 推出了对标 Adobe、微软多款核心软件的开源应用。

但随着越来越多开发者亲自尝试 REA，一些问题也逐渐浮现。在 GitHub 的公开测试中，有人发现 AI 会遗漏实际存在的函数调用，却仍将分析结果标记为“完整”；有时甚至根本没有调用 REA，而是直接给出未经验证的答案。REA 的作者也参与了讨论，回应了工具调用方式和项目设计上的问题。

与此同时，另一个疑问也开始被提起： 那些号称被 AI“逆向”出来的 Adobe 软件，真的经过了反编译吗？

逆向工程早就存在，REA 为什么突然爆火？

要理解 REA 的作用，首先需要弄清楚它与传统逆向工具有什么区别。

软件逆向工程并不是新技术。长期以来，工程师一直在使用 Ghidra、IDA、Hopper 等专业工具分析程序。即使拿不到源代码，他们仍然可以通过反汇编、反编译等方式，研究程序内部的指令、函数及调用关系，再推测某项功能是如何实现的。

不过，这项工作通常需要较强的专业经验。软件经过编译后，原始代码中的变量名称、注释和部分结构信息会消失，工程师需要在大量难以直接阅读的指令中寻找线索，并不断验证自己的判断。

REA 并没有发明一种全新的反编译技术。 它主要通过 MCP（模型上下文协议），将已有的逆向分析工具连接到 Claude Code、Codex 等 AI 编程智能体，让 AI 能够根据开发者提出的问题调用工具、分析结果，并尝试编写相应代码。

以分析某款软件的搜索功能为例。过去，工程师需要自己打开 Ghidra，查找函数、梳理调用关系，再逐步整理分析结果。现在，开发者可以直接向 AI 提问，由 AI 借助 REA 调用专业工具，寻找相关代码和线索。

这并不意味着专业工具可以被替代。REA 官方文档明确说明，使用 Ghidra 等工具时，开发者仍需要准备相应的运行环境。REA 本身也不能保证恢复一款软件原来的源代码。

但这种让 AI 自动调用专业工具的工作方式，恰好遇上了 AI 编程智能体快速发展的阶段。

Reddit 社区出现的一篇 REA 推荐帖，获得约 1.47 万次赞同。随着相关演示不断传播，甚至有人专门发帖询问，最近突然出现的大量 AI 逆向视频究竟是怎么回事。

不过，很快有开发者指出  REA 的实际能力可能被外界高估了： 真正承担反编译工作的仍然是 Ghidra 等专业工具，REA 主要让 AI 智能体能够使用它们。而且，IDA、Binary Ninja 等工具此前也已经出现过类似的接口。

与此同时， 开发者陆续展示的实际成果，还是让更多人看到了这种工作方式的吸引力。

一位开发者尝试重建 Claude Slides 幻灯片编辑器。他先下载了编辑器的部分程序文件，再让 Codex 借助 REA 分析其中经过混淆的代码。由于第一轮处理后的代码仍然比较混乱，他又使用 Claude Code 继续整理和重写，最终展示了一个能够实现部分编辑功能的版本。

另一位开发者则把 REA 用在了家里的智能马桶上。他利用 Codex 和 REA 分析厂商微信小程序的蓝牙通信协议，再根据分析结果，开发了一个电脑菜单栏遥控器。在公开演示中，他直接通过电脑让马桶盖打开。据其介绍，从分析协议到完成工具，整个过程只用了约半小时。

图｜开发者利用 REA 分析蓝牙通信协议后，制作的智能马桶控制工具（来源：开发者演示）

类似的尝试还有 GitHub 上的 open-claude-ui 项目。开发者利用 REA 研究 Claude 桌面应用的界面和交互方式，整理出 30 个界面组件、8 项交互功能及 3,000 多行设计说明，并公开了相关代码。

这些案例让 REA 的用途变得更加具体：它既能辅助研究网页应用，也能帮助分析智能设备的通信方式。不过，公开成果主要集中在特定功能和界面模块，尚不是对完整商业软件的还原。

而当一些开发者开始用更严格的方式测试 REA 时，也发现了演示视频中不容易看到的问题。

开发者亲测后，发现了什么？

一位开发者在 REA 官方 GitHub Discussions 中发布了一份使用指南。与社交平台上直接展示重建结果的视频不同，他选择了一个更容易检验的办法：找来有公开源代码的程序，让 REA 分析，再将结果与原程序进行比较。

他首先选择了 Linux 上的压缩工具 bzip2。为了增加难度，他使用了一个删除调试符号的版本，程序中原本便于识别函数的信息已被移除。随后，他要求 REA 找出负责输出某条提示信息的函数，并分析其调用关系。

结果比较顺利。REA 找到了目标函数，以及一个调用它的函数和 24 个被它调用的函数。开发者再与原始源代码核对，发现结果一致。

但换成另一个程序，情况就不一样了。

这次，他选择了开源游戏引擎 OpenMW 项目中的 esmtool 程序，让 REA 分析其中 50 个函数的调用关系，再使用传统工具 objdump 进行核对。

结果显示，其中 22 个函数的分析遗漏了实际存在的调用关系。更值得注意的是，REA 当时仍将这些结果标记为“完整”，并没有提示存在遗漏。

测试中，他还遇到了另一个有些出人意料的问题： AI 有时候根本不会使用 REA。

他尝试让本地 AI 模型调用 REA 分析程序，但在最初四次测试中，模型始终没有主动使用这个工具，而是不断尝试其他办法，甚至把二进制程序当成普通文本文件读取。

调整工作流程后，模型虽然开始给出答案，却仍然出现猜测性回答。直到他改为先通过脚本运行 REA，再让 AI 阅读已经取得的分析结果，三次测试才都得到了符合预期的答案。

这组测试也引起了 REA 作者 Morluto 的注意。他在 GitHub 讨论中回应称， REA 最初采用的是一种原型式的 MCP 工具调用设计，但随着 AI 客户端逐渐支持按需加载工具，这种方式已经不一定适合多数智能体。 他认为，让 AI 通过程序化方式使用专业工具，仍是值得探索的方向。

如果说这些测试主要关注 AI 能否正确分析代码，那么另一些用户已经开始尝试更加复杂的任务，比如将一款经典游戏重新移植到新平台。

一名 Reddit 用户就想借助 Claude Opus，将经典游戏《神偷 3：致命阴影》移植到 MacBook Pro 上。

主题：开发者