摘要
假如给你一个八音盒，没有图纸，让你弄清它为什么会唱歌，你会怎么做？
大概是拆开外壳，看齿轮怎么转、滚筒怎么碰到音梳，再试着做出相同的效果。
软件逆向也有点像这样：拿不到源码，就从已经做好的程序入手，研究它怎样工作。
最近受到关注的 REA，全名叫 Reverse Engineer Anything。它想做的，是让 AI 帮你完成这类研究。写作时该项目已有 283,326 个 Star，约 28.3 万，数据日期为 2026 年 10 月 16 日。
名字很有气势。但 AI 真能拆明白任何软件，还能照着做一套吗？
看完官方案例，我的判断是：它让研究软件更容易下手了，“任何软件”仍然需要打个问号。
一、REA 给 AI 配了一张工作台
以前把一个陌生程序交给 AI，如果它只能聊天，给出的通常是分析建议。要深入程序内部，还得有人操作工具、查文件，把结果再喂回来。
REA 把一部分操作接了起来：AI 可以调用分析工具，查看结果，再决定往哪里继续查。
用八音盒打比方：
- AI 像研究者：看到一个齿轮，会继续问它带动了什么。
- Ghidra、Hopper、IDA 等工具像检测设备：帮助观察程序内部。
- REA 把设备接到工作台上：让 AI 能调用工具、读回结果。
研究者需要工具，也需要根据观察决定下一步查什么。插画为生活比喻。
实际使用时，不同程序走的路径也不同。JavaScript / Electron 应用可以先读取文件、分析代码；对于已经编译成机器指令的程序，深度分析需要配合相应的底层工具。REA 项目说明
你可能见到的 MCP，可以简单理解成“AI 调工具的接口”。REA 也提供命令行入口。CLI 文档
沿箭头看一圈：提出问题、调用工具、拿回证据，再决定下一步。图中的底层工具按需选用。
对使用者来说，更值得关心的是：它的结论能不能指回具体代码或指令。 就像维修师傅说“这个齿轮有问题”，至少得让你看到是哪个齿轮。
二、打砖块游戏，能看出它到底帮了什么
官方 DX-Ball 案例研究了一个很小的问题：球打中左边的砖块，声音为什么会偏左？打中右边，又怎样偏右？
左右两幅情景演示横坐标与声音方向的关系，为原理插画，并非游戏截图。
研究过程也很具体：先找到相关函数，再追调用它的代码，读取里面的常量，逐步弄清“横坐标怎样换成声道偏移”。
有个细节很有意思：工具第一次把机器指令“翻译”成代码时，结果并不完整。继续看原始指令，才补齐输入和计算过程。
这说明，工具第一次给出的结果，也要继续核对。
官方随后对重建函数做了两类校验：
- 3,205 组行为用例：比较原程序与重建代码的返回值。
- 63 字节函数匹配：使用指定旧编译器，并处理经审核的地址调整后，重建代码编译出的这段机器指令与原程序匹配。
这些结果对应的是那段声音计算函数。DX-Ball 官方案例
这是常见的行为验证思路。当前用例通过后，还要扩大输入范围；字节匹配则需要另外比较编译产物。
就像弄清了八音盒里一个齿轮的尺寸和作用，接下来还得研究其他零件，才能谈整个八音盒的重建。
另一个 Notion 案例，追的是桌面应用的剪贴板调用链：复制请求如何从页面传到主进程，再写进系统剪贴板。它能帮助理解这项功能的内部路线；整套 Notion 的编辑、同步和协作能力，还远远超出这条路线。Notion 官方案例
以上是官方公开案例，本文未独立复测。
三、“逆向任何软件”，卡在哪里？
1. 看得到成品，未必看得到后厨
有些功能主要在服务器上运行，客户端只负责发请求、接结果。
这就像在餐馆吃到一碗面。你能尝味道、看配料，也能猜做法，但仅凭这一碗面，很难确定后厨完整的配方和流程。
客户端能提供部分线索，服务端内部实现可能仍然不可见。
AI 也受手头材料限制。客户端和几次请求响应，通常不足以确定服务端的完整算法。
2. 拆得开，也可能看不明白
有的软件会打乱代码，或给程序再包一层保护，也就是常说的“混淆”“加壳”。好比拆开机器后，发现零件标记被磨掉，有些部件还藏在另一层外壳里。
这会增加分析难度。REA 能帮忙调用工具，具体能走多远，仍然取决于目标、环境和工具能力。
而且，反编译得到的代码也不保证恢复原作者的写法。编译时丢掉的注释、命名和部分结构，不能指望原样找回来。
3. 做出相同效果，还要经得住反复试
正常输入时结果相同，只能说明这一种情况对上了。
空数据会怎样？连续操作会怎样？网络断了呢？版本升级后呢？这些都要另查。
就像照着做出一个会唱歌的八音盒，还得检查会不会卡齿、跑调，用久了能不能正常工作。完整软件还涉及部署、兼容和错误恢复，验证范围更大。
所以，看到“AI 已经逆向某软件”，我会先看两件事：还原了哪部分？拿什么证明？
四、普通开发者，怎么试才容易看出效果？
先选自己拥有或获授权分析的材料，从一个小功能开始。
比如：“点击导出后，文件写到了哪里，里面有哪些字段？”这个问题有明确终点，方便检查 AI 有没有找对。
环境和配置按官方入门指南准备。下面是连接 REA 的 setup 入口，运行前先确认 Node.js 版本符合文档要求：
npx rea-agents@latest setup
选择使用的客户端，查看配置变更，完成后重新启动客户端。然后可以这样提问：
用 REA 分析我提供的本地示例，追踪“导出”功能。
说明从哪里进入、经过哪些模块、最终写出什么文件。
每个关键结论附上文件位置或指令地址，并标明尚未确认的部分。
第一轮能把这条路线查清楚，就有收获。后面再根据缺少的证据，决定是否需要运行观察、补充测试或扩大范围。
还有两点要记住：分析内部软件前，确认工具结果会通过 agent 发送到哪里；使用目标软件和商业分析工具时，确认自己有相应授权。REA 的本地分析并不等于整条 AI 链路都离线。项目 FAQ、使用声明
五、这次值得期待的变化是什么？
很多开发者并不打算复制一个软件，只是想弄清一个老程序的行为、查明某项功能的实现，或者给手头的兼容工作找些线索。
REA 值得试的地方，就在这里：你提出一个具体问题，AI 可以带着工具往里查，并把发现交回来复核。
至于“任何软件”，先别急着下结论。让它把你关心的那一个功能查明白，比看一段热闹演示更有用。
评论区