没有源码,AI 怎么看懂软件?一篇讲清 REA 从原理到实战

维护旧软件时，最麻烦的情况之一，是程序还在用，源码和文档却找不到了。一个按钮怎样处理数据，一个文件按什么规则生成，都得重新查。

AI 很会写代码，但要解释某个现成软件的内部实现，光有编程知识不够。它需要接触这个软件，读到相关代码或机器指令，才能回答“这里实际上做了什么”。

REA（Reverse Engineer Anything）提供的就是这套检查工具。编程助手可以调用它，寻找实现一项功能的代码，再根据结果继续追查。对开发者来说，变化在于：原本需要自己反复翻找的线索，现在可以交给助手协助整理。不过，工具取得材料与助手理解材料，是两件需要配合完成的事。

下面本文先说明这套配合怎样工作，再用官方笔记应用的导出功能做一次实战分享。

正常开发时，我们把源码编译或打包成应用。逆向工程从相反方向出发：检查已经发布的应用，弄清其中某项功能怎样实现。它可以服务于旧系统维护、行为排查，以及已有功能的兼容实现。

不同应用留下的材料不一样。许多 JavaScript 桌面应用的安装包里，仍保留可阅读的脚本；另一些程序主要留下机器指令，需要用分析工具把这些指令整理成便于阅读的形式。

REA 把这些检查能力提供给编程助手。分析 JavaScript 应用时，它可以寻找文件之间的引用和调用；分析原生程序时，则需要连接 Ghidra、Hopper 或 IDA 等工具，取得指令、函数和相关数据。

这些材料能帮助理解程序，但未必能恢复原作者的完整源码。分析工具整理出的“伪代码”，可能缺少原来的名字、注释，甚至遗漏部分逻辑。因此，调查通常从一项具体功能开始：先找到有关的代码，再解释这段代码做了什么。

截至 2026 年 10 月 12 日核查，官方最新发布是10 月 11 日的 v6.4.0。它增加了 Android 设备检查和 JEB 工具接入，也让大型分析可以先看证据概要、再读取细节。这些改进扩大了调查范围，基本方法仍是围绕问题逐步找依据。

假设我们想知道一个应用把导出文件保存在哪里。助手可以先让 REA 检查应用目录，找到与“导出”有关的入口，再读取入口调用的代码。若其中又调用了别的方法，助手就继续查看那一处。

这是一个反复缩小范围的过程。助手决定下一步查什么；REA 执行相应检查，并返回代码位置、调用关系等结果；助手根据新结果继续提问，直到找到能够解释保存位置的依据。

连接助手与 REA 的通常是 MCP。它是一套工具通信约定，让助手知道有哪些工具、应该传入什么参数、怎样接收结果。MCP 文档介绍了这种连接方式；对使用者来说，先理解它负责传递请求与结果就足够了。

资料图：REA 项目｜REA investigation flow。

图中阅读重点

REA 负责检查与追踪，分析工具提供底层能力；编程 Agent 读取代码、引用位置和未解决问题，再解释、实现与测试。回到前面的箭头表示继续追问，不代表程序已经全部还原。

最后，助手应把分析写成能够核对的说明。例如：“这个文件里的写入操作使用了下载目录，文件名来自这段代码。”我们能顺着位置打开原始材料，检查它是否真能支持这个解释。

这样的结果也便于继续调查。如果保存位置已经找到，但文件名是在运行时拼出来的，助手可以明确说还需要检查哪一段，而不必为追求一个完整回答补上猜测。官方调查工作流也要求区分直接观察到的内容、据此作出的推断，以及尚未查明的部分。

为了让这套过程更具体，官方提供了 Notes 笔记应用的练习。它只有六个文件，用 Electron 搭建。Electron 可以用网页技术制作桌面应用，因此这个示例里既有页面代码，也有负责文件操作的代码。

调查的问题是：“点击导出以后，笔记保存到哪里？文件里有哪些列？”示例保留了可读脚本，我们可以跟着官方分析记录逐文件核对，不需要一开始就接触机器指令。

按钮点击后，页面调用 notes.exportCsv()。这个方法通过桥接脚本发送一条名为 notes:export 的消息。接收消息的是应用主进程，也就是负责文件读写等工作的部分。

这种安排来自 Electron 的结构：显示界面的进程与管理应用工作的主进程，通过消息联系。技术上称为 IPC，即进程间通信。这里的消息名称把“页面请求导出”和“主进程执行导出”连接起来，Electron 官方文档有对应机制说明。

主进程接到请求后，调用 csv.js 整理笔记内容，再把内容写入用户下载目录下的 notes.csv。CSV 是一种用逗号区分各列的文本格式，这个示例输出的是笔记编号和标题两列。

保存位置和文件名，都能在示例 main.js 第 8—12 行找到。这样，助手就有依据回答最初的问题；负责整理内容的 csv.js 也被定位出来，后面可以继续检查特殊字符怎样处理。

围绕 Notes 导出，说明每个结论应该留下哪些依据

图中阅读重点

保存位置要回到 main.js 的写入代码，特殊字符处理要回到 csv.js 的格式化代码；代码中的可能路径与实际执行仍需区分。

大家可以从同一个示例开始。

先按安装指南准备 Node.js 和 npm：前者运行 REA，后者获取软件包。当前支持的 Node.js 版本为 22.19+、24.11+ 或 26+。本篇固定 REA 为 6.4.0，便于说明复现条件。

如果只想在终端检查目录，官方命令行入口是 analyze-javascript-application，后面接目录路径和 --json。这一步读取已有文件，不要求运行完整应用，也就是静态分析。

现在可以检查一个具体细节：CSV 用逗号分列，标题里也有逗号时，会不会被拆成两列？找到 csv.js 后，我们看到它把标题放进双引号里，并把标题内部的双引号写成两个。

根据这段规则，笔记编号为 1、标题为 Hello, "REA" 时，应该得到下面这一行。本文实际调用负责整理内容的 toCsv 函数，输出与这个预测一致：

最外面的双引号把标题包成一个字段，成对出现的内部引号则保留了标题中的引号。本次还检查了包含中文和换行的标题，函数把内容保留在同一个带引号的字段中。官方练习也用特殊字符说明怎样核对代码解释。

明确格式化函数检查与完整导出验证的区别。

这个检查覆盖的是格式化函数。完整导出还包括按钮触发、目录写入和失败提示，尚未在本次环境中验证。要继续检查完整功能，就把应用运行起来，用同样的输入观察最终文件和页面反馈。

一次实战的结果可以很小：查清一个保存位置，确认一条处理规则，留下对应代码和输出。这比一开始就要求助手理解整个应用更容易复查，也更方便决定下一步查哪里。

Notes 展示了入门方法。下面前三类有官方公开案例，第四类是本文的使用建议。它们的共同点，是先选一个具体行为，再准备能够检查结果的输入；这些案例还不能代表企业已经大规模部署 REA。

1. 桌面应用的复制与导出。
    官方 Notion 案例追踪内容怎样从页面到达系统剪贴板。实战可以选一个复制或导出按钮，要求助手列出请求发出的位置、接收它的代码和最终写入操作，再用中文、换行和特殊字符检查输出。
2. 原生程序或旧游戏的小计算。
    官方 DX-Ball 案例调查砖块位置怎样影响声音偏左或偏右。开始前需要配置合适的程序分析工具。实战先选输入输出明确的计算，找到运算与常量的来源，再比较原实现和恢复后的结果，避免一次承担整款游戏的还原。
3. Android 应用中的变化规则。
    官方 Aegis 案例检查 APK，也就是 Android 安装包，追踪验证码生成方法，并用公开测试数据核对规则。实战先准备官方指南要求的依赖，再围绕一个问题调查，例如时间变化怎样影响显示结果，最后测试时间边界等输入。
4. 旧系统迁移与版本差异排查。
    这是使用建议。保留新旧版本，用相同输入比较输出；发现差异后，只追踪产生差异的功能。留下版本、输入、输出和代码位置，便于同事判断变化是预期调整，还是迁移遗漏。

选第一个任务时，不必追求范围大。找一个你能描述预期行为、又能准备样本的软件功能即可。实战是否有用，可以看助手有没有缩短寻找相关代码的过程，以及它的解释能不能被另一个人复查。

实际调查中，分析工具可能没看全代码，助手也可能把结果读错。遇到没有解析出来的调用，或者只能确定部分输入的情况，应把结论限定在已经找到的材料上，再决定是否补做运行检查。

使用环境也需要事先考虑。REA 安全说明明确说它不是沙箱，不能自动把陌生文件的分析过程与电脑里的其他内容隔离。处理这类文件，需要独立测试环境；内部软件的分析结果是否可以发送给模型服务，也要按所用助手的配置核对。

回到笔记导出，代码告诉我们文件准备写到哪里，格式化检查告诉我们特殊标题会得到什么内容，完整运行才能确认文件是否真正写成。这几种依据各自回答了不同问题，合在一起才是一项功能的完整调查。

REA 的价值就在这里：让编程助手有工具接触实际软件，也让开发者能沿着代码和实验复查解释。先把一项行为查清，再把这套方法用到下一个问题上，才是更务实的上手方式。