不是吧,这个skill能逆向任何一个软件?

用一个软件的时候，我经常会碰到这种情况：

某个功能很好用，想知道它是怎么实现的，或者想在自己的工具里做一个类似的功能。但软件已经打包好了，打开之后只能看到界面，看不到里面的代码。

这时如果直接问 AI ：“帮我做一个这样的功能”，它能根据界面猜出一套方案，却不一定知道原来的程序到底做了什么。

最近我找到一个 GitHub 开源项目：REA。

它的全名是 Reverse Engineer Anything ，可以和 Codex 等 AI 编程工具配合，分析软件文件、网页和应用的运行行为，再把找到的线索交给 AI 整理。

想弄清一个功能时， AI 可以从实际文件和运行记录中寻找依据。

REA 官方项目展示的分析界面，画面来自开发者。

先搞清楚： REA 到底做什么？

假设我以前做了一个桌面小工具，电脑里还留着安装包，但当时的项目代码找不到了。

现在我想知道：软件里有哪些主要功能？文件在哪一步被读取？点击按钮后，程序大概执行了什么？能不能参考现有行为，把功能重新做出来？

REA 可以协助 AI 调用不同的分析工具，从程序文件中寻找线索。它能处理的对象包括打包后的桌面程序、 JavaScript 和 Electron 应用、.NET 程序，以及网页和部分运行行为。

不同类型的文件，分析方式也不一样。分析 JavaScript 应用时，工具可以整理模块及其关系；分析一些原生程序时，结果可能是汇编和便于理解的伪代码，还需要 AI 根据这些线索继续编写、检查和测试。

我更愿意把它看成一套“帮 AI 找线索的工具”，而不是一个点一下就能把软件完整还原的按钮。

我最想用它解决的三个问题

① 老工具还在，代码找不到了

自己做过的小工具，最怕换电脑、换硬盘之后，程序还在，项目文件却不见了。

比如一个批量整理图片的小程序，我想在原有功能上增加“按日期分文件夹”，但手里只剩打包后的程序。

这时候，我会先让 Codex 弄清楚它是用什么技术制作的，再围绕文件读取、命名和输出流程寻找线索。

可以给 AI 一个明确任务：

这是我自己以前制作的桌面工具，现在只有打包后的程序。请先判断它的技术类型，再分析批量整理文件的主要流程。把能确认的内容和还不确定的地方分开列出来，先不要修改原文件。

把“先分析、不要修改原文件”写清楚，拿到的应该是一份待检查的线索，而不是直接覆盖旧程序。

如果后续准备重新开发，再把需要保留的行为交给 Codex 实现，并用相同的文件输入进行对照。

② 看懂一个功能，而不是照着界面猜

有时候我感兴趣的不是整个软件，而是其中一个细节。

例如一个笔记工具的剪贴板功能：复制一段带格式的内容，粘贴到不同位置时，为什么格式还能保留下来？

REA 的开发者公开展示过一个相关案例：分析 Notion 的 Electron 剪贴板桥接流程，从界面侧的剪贴板接口，追踪经过预加载层和进程通信后如何交给主进程处理。

开发者公开的 Notion 案例，研究的是复制文本与 HTML 的过程。

这个案例沿着调用关系继续往下找，找到了剪贴板操作经过的几个环节。

官方案例展示了给 AI 的任务，以及从哪里开始追踪。

如果我要分析自己有权检查的应用，可以这样描述：

请分析这个应用的复制和粘贴功能，找到相关入口、调用链和涉及的数据格式。每个结论尽量附上对应文件或代码位置；不能确认的部分单独列出。

最后再根据分析结果，在自己的项目中设计需要的功能。

③ 分析打包后的网页或桌面应用

不少桌面工具用 Electron 制作，界面部分仍然和网页技术有关。发布后，文件可能被打包在一起，直接打开不太容易看出模块之间的关系。

REA 提供了针对 JavaScript 和 Electron 应用的分析方式，可以从文件中寻找模块、导入关系，以及不同部分之间的边界。

对于一个自己开发并打包的应用，我会先问：

请分析这个应用的打包文件，列出与搜索功能有关的模块、它们之间的调用关系，以及你找到这些关系的依据。先生成分析报告，不要修改程序。

这个问题比“把整个软件都还原出来”更具体，也更容易检查结果是否回答了我的问题。

一个真实案例：老游戏的声音是怎么跟着位置移动的？

REA 官方还展示了一个更具体的案例：研究 1996 年的 Windows 游戏 DX-Ball 。

当游戏里的砖块被击中时，声音的位置会跟着砖块在画面中的位置变化。开发者想弄清楚：程序是怎么把砖块的位置，转换成左右声道的位置的？

REA 开发者公开的 DX-Ball 案例。

项目团队使用 REA 查看游戏程序里的相关函数，再沿着调用它的代码往前找，确认传入的是砖块的屏幕坐标；接着读取计算中用到的数值，把找到的线索整理成 C 语言函数。

找到代码只是第一步。开发者随后将重写函数的返回值与原程序对照，覆盖了 3,205 组位置和参数组合；还用指定编译工具进行比较，案例报告称该函数编译后的 63 个字节与原程序对应部分一致。

这里验证的是声音左右位置的一个计算函数，不是整款游戏已经复原。把问题缩到一个具体函数后，就能用原程序的结果逐项检查。

如果换成自己的软件，同样可以从一个按钮或一条处理流程入手：先找入口、追踪调用、记录证据，最后用相同输入比较原程序与新实现的结果。

它怎么和 Codex 配合？

REA 的核心作用，是把分析工具接进 AI 编程助手。项目提供了配置流程，支持 Codex 、 Claude Code 、 Cursor 等工具。

安装前需要有 Node.js 和 npm 。然后在终端运行项目提供的配置命令：

npxrea-agentssetup 

接下来按提示选择要连接的 AI 工具，查看它准备修改的配置，再完成设置。配置后需要重启对应的 AI 工具，让新接入的能力生效。

安装完成后，就可以在 Codex 中描述具体目标，例如：

使用 REA 分析我提供的桌面工具，先判断程序类型，再追踪“导出文件”功能。请给我一份包含调用过程、关键文件和不确定项的报告。

这里还有一个容易忽略的地方： Skill 和实际分析工具不是同一件事。

单独安装 Skill ，主要是给 AI 一份调查流程说明；要让 AI 真正调用 REA 的工具，还需要按照项目流程完成相应连接。分析不同类型的程序，也可能需要不同的工具支持。

用之前，先确认这几点

REA 的名称里有“Anything”，但不同文件能得到的结果并不一样。

原生程序的分析可能返回伪代码和汇编； JavaScript 应用则可能整理出模块及其关系。能不能还原出可运行的功能，还要看原始文件、分析工具和后续验证的情况。

另外，静态查看文件和实际运行程序也是两回事。静态分析主要读取提供的文件；如果要求观察运行行为，工具可能需要启动或操作目标程序。

我会优先拿自己制作、自己持有或已经获得授权的软件做分析。如果要重新开发功能，也应保留自己的代码和设计过程，不把别人的程序、素材或品牌直接当成自己的成果。

REA 项目说明其目标分析在本地进行，但分析结果会交给所使用的 AI 助手；这些数据如何处理，还要看对应模型服务的设置和政策。

如果让我给它安排一个任务

我会从一个范围小、结果容易核对的问题开始。

比如拿一个自己做过的桌面工具，让它回答：“点击导出按钮后，程序是怎么确定文件名和保存位置的？”

先看它找到了哪些文件、给出了什么调用线索，再用原工具实际导出一次，对照分析是否说得通。确认线索有价值后，再让 Codex 根据需求做一个新的导出功能。

关注我，获取更多 AI 资讯和实用工具分享。

本文由 AI 辅助创作，作者进行了实测验证和编辑修改。