ARTICLE · 1174101
REA把逆向工具接给AI,软件会变得更透明吗?
REA把逆向工具接给AI,软件会变得更透明吗?GitHub上，一个叫REA的项目，已经拿到了超过18万颗Star。 它的名字也够直接：Reverse Engineer Anything，逆向一切。 看到这里，你可能会觉得，又是一个把名字起得很大的AI工具。 但往下看，它想解决的事情确实很有吸引力：你喜欢一款软件的某个功能，即使拿不到源码，也可以让AI去调查它到底怎么实现，再为自己的项目写一个版本。 过去，我们让AI看一张截图，说“照着这个做”。 现在，有人开始给AI接上专业工具，让它沿着一个按钮、一条通信链、一段计算，往软件内部追。 这也是REA值得聊的地方。18万颗Star说明它吸引了大量关注；至于它到底有多好用，还得看它能找到什么、解释到哪一步。 读完它的官方案例，再看本地测试的结果，我最感兴趣的是一个变化： AI写软件的过程，开始多了一步——研究已经存在的软件。 先想一个你可能遇到过的场景。 在一款笔记软件里复制一段内容，粘贴以后，标题、列表、块结构都还在。换个软件，同样的内容却变成了一团普通文字。 你觉得前者很好用，也想给自己的产品做一个。 问题是，只看界面，你知道的是“复制以后效果很好”，看不到数据怎样保存、格式怎样传递，更不知道粘贴时怎么找回原来的结构。 过去，要弄清这些问题，往往得请懂逆向的人来研究。 他们可能会拆开软件包，检查JavaScript，追进程之间的通信；遇到编译后的原生程序，还得用Ghidra、Hopper、IDA这类工具看机器指令和调用关系。 逆向工程，就是从一个已经做好的东西出发，反过来调查它怎样工作。 REA做的，是把这些调查能力接给AI Agent。Agent可以调用工具取得观察结果，再决定下一步往哪里查。 于是，“帮我做一个类似的复制功能”，有机会变成更具体的调查： 复制从哪里触发？内容发给了哪个进程？谁写入剪贴板？粘贴时，靠什么找到原来的块数据？ 问题越具体，答案就越有机会落到一个能核对的位置上。 这比对着界面猜实现，多了很重要的一层。 不过，不同软件藏起来的东西不一样，能读到的东西也不同。 
原生程序编译后，原来的变量名、注释和不少代码结构可能已经消失。工具能提供汇编，以及推导出来的伪代码，帮助理解运算。 .NET程序通常还保留类型、方法签名和中间语言指令，可以从这些信息继续往下查。 JavaScript包则往往还有文本代码，只是打包、压缩后，模块关系变得难读。 所以，“把软件拆开”也有层次。列出文件、读到指令、理解一个功能、重建整个应用，难度差得很远。 REA能帮忙调查，能调查多深，要看目标和工具条件。 REA背后的结构，可以用三句话理解： Agent提出问题。REA组织调查。分析工具提供观察。 Agent可以是Codex、Claude Code等编程助手。它负责理解你要研究什么，判断下一步查哪里，并解释结果、编写实现。 REA提供调用入口和调查工作流。它根据目标选择分析路线，管理会话、文件身份和调查记录，再把结果交回Agent。 底层才是具体干活的读取器与分析引擎。 原生程序的深度分析需要配置Ghidra、Hopper或IDA等外部工具；JavaScript和.NET有对应的内置静态读取路线。 
图里的MCP，可以理解为Agent调用工具的一套接口约定；CLI则是在终端里输入命令。两种入口共享主要调查能力。 REA本身没有取代大模型。它让模型有东西可查、有结果可读，也有依据继续问。 其中很重要的一部分，是证据记录。 比如，AI判断“复制动作最后由主进程处理”，我们自然会追问：你怎么知道？ 一个有用的回答，应当能指回具体文件、方法、调用位置，而不只有一段听起来很顺的解释。 REA会保留观察的来源、范围和限制。哪些是直接读到的，哪些需要进一步推导，哪些还不知道，可以继续分开看。 这也让产品经理更容易判断进度。 “分析完成”四个字太宽泛了。到底是找到入口，还是确认了通信链？是静态代码里存在这个调用，还是运行时真的走过它？ 把这些问题展开，才知道下一步该做什么。 官方的Notion案例，是一个很直观的例子。 它从页面能够调用的剪贴板接口入手，继续追到preload代码。这是Electron应用里连接网页页面和桌面能力的一层桥。 随后，请求通过IPC交给主进程。IPC就是不同进程之间的通信。主进程收到请求，再执行系统剪贴板写入。 一条“复制”的路径，就这样从页面一路接到了系统能力。 
但有意思的还在后面。 按照官方案例记录，复制的HTML里带着一个标记，本地保存与它对应的块数据。粘贴时，再通过匹配标记找回结构。 这就解释了一个读者能感受到的现象：为什么有些复制粘贴，能保留普通文字之外的内容关系。 如果只说“它用了富文本”，你还是不知道怎么做。找到标记、本地数据和匹配动作以后，实现思路才真正开始清楚。 这些是官方对特定版本的调查结果。软件继续更新，具体路径也可能改变。 另一个官方展示来自老游戏DX-Ball：研究屏幕横坐标怎样变成声音的左右定位，再重写一个局部计算函数。作者报告了3205组原始x86样例的验证，以及63字节编译结果的匹配。 这些数字对应的是那个局部函数，没有覆盖整个游戏。 两个案例放在一起，有一个共同点：都从很小的具体问题切入。 一个复制动作，一段声音计算。先把这一小块弄明白，再验证。 “逆向一切”听起来很大，实际调查却需要这样一处一处地往下走。 看完案例，再看本地测试，我对REA的判断反而更具体了。 它确实已经安装并注册到Codex，使用的是6.4.0版。但最值得写的，并不是安装了多少依赖，而是拿到软件文件以后，究竟发生了什么。 先试的是公开版求职工作台打包后的前端文件。 这里没有把可读源码直接拿来分析。源码本来就在手里，能解释它，不能证明工具面对打包产物也一样顺利。 21个JavaScript构建文件，语法解析可以完成，也有关系图输出；但部分语义分析碰到了内存和结果预算限制，覆盖并不完整。 再把范围缩到一个较小的构建块，文件能解析，却没有得到有效的功能发现。 这个结果很有参考价值：读到代码，不等于已经弄懂功能。 再换一个受控样本，结果就不同了。 这是一个自行编译的.NET计费程序。输入停留分钟数、是否会员，输出费用，里面包含分段计费、会员折扣和价格上限。 REA做静态检查时，拿到的是编译后的可执行文件。它读出了计费方法的参数、常数和分支，以及32条中间语言指令。 根据这些观察和已知样本上下文，重新写出计算逻辑。接着，把同一组输入分别送进原程序和重写程序，比较两边的输出。 1448组，结果全部一致。 
我觉得，这个实验真正有意思的，是把“理解”变成了能验证的动作。 看参数，知道它接收什么；看常数和分支，补出计算规则；最后用原程序的输出检查重写版本。 它仍然只是已知源码的受控小样本，验证了有限输入，不能推成复杂商业软件也能一键重建。 本轮也没有完成SketchUp测试：本机没有发现它的安装文件，Ghidra等原生分析后端还没有准备好。 所以，这次体验更接近一张能力地图。局部规则可以走通，较复杂的构建产物仍会卡住。想查原生软件，还要把相应引擎接好。 这样的结果，比一句“太好用了”更能帮助我们判断它该用在哪里。 对开发者来说，REA带来的吸引力很直接。 以前看到一个好功能，可能只能查文档、找开源替代品，再试着搭出来。 现在多了一条路：研究已有软件中的具体实现，带着观察结果回到自己的项目。 维护老程序时，也可能更容易理解缺少文档的模块，为局部功能补一个经过验证的替代实现。 但我更在意普通用户能感受到的变化。 比如换笔记软件、换项目管理工具，最麻烦的往往不是学新界面，而是把旧数据搬过去。 格式怎样保存？关联怎样表达？复制时哪些信息丢了？这些问题被理解得更清楚，兼容和迁移工具才更容易做好。 以后，我们或许可以少花一点时间手工整理，少因为数据搬不走而继续留在一个不合适的产品里。 这是可能出现的影响，还需要有人把调查结果做成真正好用的工具。 
软件内部也不是所有东西都在客户端。服务端的业务规则、账户权限、云端数据，不能靠读一个本地文件就全部取得。 理解实现，也不等于取得原产品的完整源码与开源许可。 但即使把这些边界算进去，REA仍然值得关注。 它让Agent有机会接触到以前需要专业工具和经验才能研究的问题。写代码之外，AI开始参与调查、整理证据、检查自己的解释。 站在AI产品经理的角度，这意味着我们以后评价一个Agent，可能需要多问一句： 它给我的答案，能不能带着依据，被重新验证？ REA的18万颗Star，让很多人注意到了“逆向一切”这个名字。 往后真正决定它价值的，是它能帮我们把多少陌生的软件行为，变成清楚、可检验、能继续利用的知识。
一、喜欢一个功能，终于有机会问清它怎么做
二、它到底怎么工作？把一次调查拆成三层
三、Notion的复制功能，被追到了哪一步？
四、实际跑起来，有成功，也有卡住的时候
五、以后换软件，我们能少被困住一点吗？
既然看到这里了，如果觉得有收获，随手点个赞或者转发，是对建步走最大的支持。有想聊的，评论区见。
