没有源码也能重写软件?“逆向一切”REA项目把AI带到了哪一步

REA 官方资料、开发者项目与社区讨论

你喜欢一款软件，可它偏偏没有你正在用的系统版本。过去，你可以等官方移植，或者找个勉强够用的替代品。现在，有开发者开始试另一条路：让 AI 调查原来的软件，再做一个适合自己电脑的版本。

10 月 19 日，开发者 @typecraft_dev 在 X 上分享，他用 REA 做出了一个给 Linux 桌面 Omarchy 使用的、类似 Raycast 的启动器，并称花了几个小时。帖子公开存档保留了他的描述，对应的 oma-cast 仓库也已公开。我们能检查项目做了什么；“几个小时”仍是作者自述，不能当作人人都能达到的开发耗时。

一个更具体的问题随之出现：软件已经运行在自己的电脑里，AI 能不能查清其中一个功能怎样工作，再按自己的需要重做？REA 让 AI 能够检查程序中的代码与调用关系；重写得对不对，还要把新代码与原程序放在一起检验。

REA给AI添了一套调查工具

平时让 AI 复刻一个应用，我们最容易提供的是截图和功能描述。AI 可以据此写出看起来相近的界面，却很难仅凭截图知道，一个复制动作经过了哪些模块，或者某段动画怎样更新速度。REA 增加了一条调查路径：把已经发布的软件作为材料，让 AI 调用分析工具，读取代码片段、函数之间的关系和程序运行时留下的记录，再决定下一步查什么。官方仓库把它定位为连接编程助手与逆向工具的命令行程序和 MCP 服务；这里的 MCP 可以理解为 AI 调用这些工具的一套接口。

不同材料的读法不同。桌面程序的机器指令，需要 Ghidra、Hopper 或 IDA 这类工具来分析；JavaScript 应用可以从打包文件里整理模块与调用关系。REA 负责让调查工具的结果进入 AI 的工作过程，AI 再根据结果追问、解释和编写代码。底层分析工具、REA 和语言模型各自承担一部分工作。因此，评价 REA 时，既要看它接入了哪些工具，也要看返回的材料能否支持后续判断。

这条路径最吸引人的地方，是 AI 的调查范围可能从“我正在写的项目”扩大到“我手里已有的软件”。在维护旧系统、研究文件格式、学习交互实现时，已经交付的程序本身也可以成为技术资料。能查到多深，取决于拿到的文件、分析工具和问题本身；一句“帮我理解整个应用”仍然过于宽泛。

一个旧游戏的声音，怎样证明重写对了

官方的 DX-Ball 案例研究了一个很小的函数：把砖块的横向位置换算成左右声道的位置。第一份反编译结果几乎只显示了一个数值转换调用，连输入都没说清楚。调查继续读取机器指令、调用这个函数的位置和文件中的常数，才补出了计算过程。这个细节有用：工具第一次给出的伪代码也会漏掉重要信息，AI 需要拿其他记录交叉检查。

案例中的重写函数接受了两种检查。开发者在 3,205 组输入上对照原始机器代码的返回值，还使用指定的旧编译工具链，核对重写函数编译后对应的全部 63 个字节。第一种检查比较原函数和新函数是否返回相同结果。第二种检查先按说明调整代码中引用的地址，再比较编译出的字节。这些是官方公布的验证结果，本文没有独立重跑。证据范围是这个函数，整款可玩的游戏当时仍在继续重建。

这给“AI 看懂了”加上了一个可检查的标准。AI 解释声音为什么左右移动，只完成了解释；重写函数在事先选定的输入上给出同样结果，才多了一层行为证据。更复杂的功能可以沿用这种做法：先圈定一小段行为，再选择能暴露差异的输入。若直接要求 AI 重写整款应用，即使界面顺利运行，内部错误也可能藏在很少有人触发的分支里。

Notion复制一段文字，背后经过了多少层

第二个 Notion 案例更接近日常软件。用户只是复制文字，实际调用却从页面里的接口，经过预加载层和进程间消息，最终抵达负责写入系统剪贴板的进程。接收端还会检查消息来自哪个页面。调查要沿着同一条消息找到两端，并把几层包装函数展开，才能说明这个复制动作怎样完成。

这个案例使用了 Notion Desktop 7.6.1 的部分文件，以及另行保存的网页资源。官方给出的证据包括打包代码和小型模块测试，不能把这些测试当成一次完整的桌面操作录像。案例也没有声称复原了 Notion 的全部功能。对想做编辑器的人来说，这种小范围调查已经有价值：一个看起来简单的复制功能，可能同时涉及页面数据、桌面进程和系统接口。只抄最外层的按钮和函数名，很容易漏掉决定功能能否工作的那一段。

往产品设计上再想一步，AI 辅助学习成熟软件，可能越来越像带着问题读工程实现。读者可以追问“这条消息从哪里来，谁接收，接收后检查什么”，而不是让 AI 凭经验编一套架构说明。已有程序提供线索，模型提出解释，实际调用关系再约束解释。这个循环能否节省时间，仍需在自己的任务上测量。

安装包拿到了，哪些东西仍然看不见

一个网站的页面可以告诉你浏览器收到了什么脚本、发出了什么请求，但服务器内部怎么处理请求，需要额外的材料。浏览器分析文档描述了页面结构、脚本和有限观察窗口中的记录，也明确保留覆盖范围。根据前端看到的接口，推断出一套可能的后端实现很容易；证明线上服务器确实如此工作，需要另一组证据。

回到开头的启动器。oma-cast 的项目说明列出了应用搜索、排序和桌面整合，也把窗口管理、扩展支持等内容留在后续计划里。重建规格还明确把 Raycast 的内置 AI 功能排除在范围之外。因此，这个案例支持的是“做出一个满足特定需要的类似工具”，距离完整替代原产品还有明确的差距。

图：来自 oma-cast 项目 README 的公开截图，展示启动器界面。界面图说明功能形态，不代表本文已经验证它与 Raycast 的全部行为一致。

《塞尔达》跑到Mac上，走的又是哪条路

MacNativeGames把问题推到了更大的软件上。按作者的技术说明，这个项目让《塞尔达传说：王国之泪》的原有 ARM64 代码在苹果芯片上运行。Switch 与苹果芯片都使用 ARM64 指令，项目针对需要适配的指令做预先改写，再提供游戏需要的系统服务，把原来的图形指令适配到 Metal。它保留了游戏本身的大量机器代码；这与让 AI 根据观察重新写一款游戏，是两种工程路线。工作原理

这里也需要把功劳说准确。项目的致谢与来源明确列出了 d2r-mobile、nxnative 和 Ryujinx；目前查阅的作者资料没有明确说明使用了 REA，因此本文把它放在迁移路线的对照里。让一个游戏在新设备上运行，可能依靠保留原代码、复用已有兼容层，再逐项适配。看到成品以后，先问哪些部分沿用、哪些部分重新实现，会比直接归结为某一个 AI 工具更接近实际工作。

MacNativeGames 还要求用户提供自己的游戏文件，公开仓库并不是一份可以直接游玩的《塞尔达》下载。项目给出的适配与测试记录也限定了设备、版本和场景；能够启动、进入若干场景，与全游戏长期稳定运行之间仍有差距。这个例子让人看到跨平台适配的可能，也提醒我们，把一个大型程序迁移到新环境，后面还有持续的图形、声音和稳定性工作。

即使文件拿得到，大型应用仍可能包含很多没有看懂的关系。JavaScript 分析文档会保留未解析部分和覆盖限制。只选择几个文件分析时，其他文件之间的关系仍可能未知。读分析报告时，值得多停留在“尚未确定”的地方：没找到某个调用，有时只是相关代码未进入本次分析范围。

另外，官方 FAQ区分了本地分析与模型服务接收工具结果。程序在自己的电脑上被分析，工具返回的片段仍可能进入编程助手的对话。公司内部的程序包含业务规则和数据结构，使用这类工具时，也需要核对哪些内容会传给模型服务。

如果功能更容易重做，软件生意会怎样变

最先让人心动的，可能是只为自己重做一小部分。你喜欢某款软件的搜索，却不需要它的团队协作；你想保留一个老工具的文件转换，却不愿继续使用旧系统。下面这些是从现有案例延伸的用途设想，仍需实测：如果 AI 能帮助查清你真正依赖的那几条规则，开发目标就可以从“做一个同类大全套”，缩小成“让我的这一件事好用”。

旧软件维护也值得看。假设一家企业已经获准检查自己的历史程序，工程师可以先追查一个导出格式、一种数值舍入或一条异常处理路径，再用原程序的输出测试替代实现。关键不是重写了多少行代码，而是多年业务依赖的那些细节有没有留下来。DX-Ball 的小函数恢复与验证，展示了这种工作可以怎样起步。

学习软件设计的方式也可能改变。过去我们读开源项目、看公开技术博客，去理解一个功能怎样实现。未来，手头的软件包、保留下来的运行记录，也可能帮助解释某个具体功能。AI 有机会承担繁琐的定位和阅读工作，人来决定问题是否重要、证据是否足够，以及哪些行为值得保留。把一个功能解释清楚以后，再改成适合自己的实现，或许比要求模型凭空写出“某某应用替代品”更容易验收。

对创业者而言，压力可能先落在“主要靠一个本地功能收费”的产品上。假如用户最需要的那部分越来越容易被研究并重做，团队就要回答：用户为什么继续选择我们？这是一种商业推测，现有案例尚未测量收入或竞争格局的变化。持续维护、数据同步、团队工作流和出了问题有人负责，仍然需要长期投入。功能可以被模仿，可靠地交付同样的服务还要继续做工程。

还有一个容易被热度盖住的机会：帮人检查 AI 的调查报告。如果越来越多的代码解释由模型生成，人就更需要知道，每个结论对应哪个文件版本、哪段代码和哪次验证。REA 的证据与命令行文档把材料身份、来源位置、观察、推断和未知项放进结果里。围绕这些记录做复核、版本对比和回归测试，可能比再做一个能生成漂亮说明的聊天框更有用。这同样是待验证的产品方向。

X上在喊颠覆，实际用过的人在争论什么

REA 的传播很会触动这种愿望。X 上，@0xCodila 在介绍它的长文公开存档里，把它称为“当下互联网上最危险的东西”，并从用户每月付费的软件切入。这是作者的评价和宣传角度。安装在本地的程序确实提供了可检查的材料，但“能研究一个功能”与“免费获得一整套服务”之间，还隔着使用范围、服务器和维护工作。

@typecraft_dev 的分享给了另一种更具体的方向：把喜欢的交互带到自己正在使用的平台。读者可以查看公开仓库，确认自己的桌面是否支持、需要的功能是否已经实现。即使只做出了搜索和启动应用的部分，对有相同需求的人也可能已经有用。完整替代 Raycast，则需要继续补齐项目尚未实现的功能。

也有很实际的质疑。在 Reddit 的同题实测讨论中，用户 Unusual_Shake5041 说，自己尝试后发现，AI 在一些任务里根本没有调用 REA。另一些参与者则追问，直接使用 Ghidra 等工具的接口是否已经足够。这些都是参与者的个人反馈，不能汇总成成功率，却提醒了一个容易忽略的问题：最后做出了东西，究竟是 REA 帮上了忙，还是模型和其他工具本来就能做到？

要回答它，可以在自己的同一项任务上比较：加上 REA 后，是否更快定位到相关函数，是否少了错误推断，是否留下了更容易复核的材料。熟悉逆向工具的人，可以比较 REA 和原有工具是否存在重复工作。刚开始接触的人，则可以看它能否帮自己选对工具、找到该读的文件。采用 REA 的理由，最终要落在实际节省了哪些工作上。

下一步最值得关注的，是 REA 能否在更多独立使用者的真实问题上稳定复现，以及调查结果是否足以让另一个人接着工作。如果换一台电脑、换一个软件版本，就得重新猜测输入或寻找丢失记录，维护成本仍然很高。反过来，若一次调查能留下可追溯的材料和可重复的测试，即使只解决了一个小功能，也可能给后来的开发者省下很多时间。

这篇最值得学的点：让AI用原程序检验自己的解释

下次看到“AI 已经复刻某款软件”的演示，可以连续问三个问题：AI 实际读到了什么？它从这些材料推断出了什么？它怎样把新实现与原程序对照？这三个问题能帮助我们区分看起来相似的界面、合理的工程解释，以及经过检查的行为。如果目的是保留旧程序的关键计算规则，就需要用更多输入比较原程序和新实现。只检查界面是否相似，还不能判断这些规则有没有保留下来。

如果想自己尝试，可以先选一个有权分析的小程序，再只问一个能观察结果的问题，例如某个数值为什么这样舍入。要求 AI 标出来源，写清不确定的地方，并设计一组可能推翻当前解释的输入。让原程序和新代码都处理这些输入，分歧会告诉你下一步该查哪里。对复杂软件，每完成一个这样的小闭环，才更接近可以维护的实现。

没有源码，AI 确实多了一条理解软件的路。REA 已公开的案例让我们看到，这条路要经过定位、追查和验证。最让人期待的进展，是越来越多曾经只有少数人能调查的程序行为，可以被更多开发者解释、检查，再用于自己的工程工作。