一个旧系统要迁移，负责它的人已经离职；一个桌面软件的复制功能很好用，团队却不知道数据怎样流到系统剪贴板。界面可以反复操作，内部路径依然说不清。

企业真正需要的第一步，是把一个具体功能调查清楚：谁处理请求，数据经过哪里，结论有什么依据，还有什么没有查到。调查有了结果，再决定是否值得投入实现和迁移。

REA 提供了一条这样的工作路径。它让 AI Agent 连接分析工具，检查已有软件，把发现、证据和限制带回任务中。这篇文章用三个官方案例说明这条路径，再把它转成企业可以讨论的试点方法。

图 01让 AI 看懂软件怎么做

先把问题问到一个功能上

逆向工程可以先理解为：从一个已经存在的成品出发，追问它为什么这样工作。REA 的全名是 Reverse Engineer Anything。对于负责人，更实用的理解是“给 AI 一套调查软件的工具”。

Agent 负责理解问题、提出追问和解释结果。REA 通过 MCP 这个工具连接接口，把任务接到相应的分析能力上。工具返回模块、调用关系、指令或运行观察后，Agent 再据此推进调查，也可以继续编写和测试自己的实现。

图 02给 AI 一套调查软件的工具

例如，“复制后能保留格式”描述了一个可见效果。若要理解实现，还要追问：按钮调用了哪个入口，文本和 HTML 由谁组织，消息经过哪些模块，最后是谁写入系统剪贴板。

这样问，任务才有了可追踪的路径。每个判断都应该连着具体位置和目标版本；一段看起来合理的解释，需要能回到证据上核对。

图 03从看见效果到追到实现

工具分工决定交付质量

可以把工作分成三层。Agent 拆解任务、提出下一步问题；REA 连接并组织调查能力；底层分析工具读取文件结构、代码或运行行为。人则提供有权分析的目标，确定业务问题，并核对结论是否足以支持决策。

这个分工影响采购和验收。看懂一份工具输出，还需要解释它与业务行为的关系；写出代码之后，还要检验它在约定样本上是否一致。

图 04三个角色各有分工

一条可执行的工作流是：提出一个可观察的问题，锁定目标和版本，沿调用与数据路径追查，形成带证据和未知项的说明，再按需实现与测试。

这里有两个容易省掉的动作。开始时记录目标身份，避免把不同版本的行为混在一起；结束时写出未知项，避免把局部发现放大成对整个系统的理解。

图 05从一个问题走到证据

REA 官方资料覆盖桌面应用、JavaScript 与 Electron、原生程序、网页、Android，以及 .NET、固件、模型和网络等方向。目标类型只是选路入口，能分析到什么程度，还取决于平台、格式和分析引擎。

例如，原生程序的深入分析通常需要 Hopper、Ghidra 或 IDA 等工具；静态 JavaScript 和 .NET 分析不必套用同一套原生引擎要求。团队应按目标确认依赖和许可，不能只凭一张支持清单估算项目。

图 06先看目标再选分析路径

三个案例看清证据怎样形成

下面三个例子来自 REA 官方展示页。它们分别涉及桌面应用的消息链、原生程序的计算逻辑和 DOS 游戏的弹幕行为。本文整理其方法和公开验证记录；本项目没有安装 REA，也没有在本机复现这些案例。

图 07三个官方案例

官方展示中的 Hopper 分析界面提醒我们，调查要落到实际目标上。工具中的函数、指令和引用位置，提供了继续追查的入口。截图的价值在于呈现证据所在的环境，结论仍须说明对应哪个文件、版本和范围。

对负责人而言，可以要求团队把“发现了什么、依据在哪里、还有什么不知道”放在同一份交付里。这样后续开发人员能够复查，决策也更容易交接。

图 08把调查落到实际目标

Notion 的复制请求怎样到达系统

Notion Desktop 7.6.1 的案例追踪剪贴板路径：页面侧 API 发起请求，经 preload 桥接，再通过 IPC 到主进程处理器；处理器检查消息发送方，最后由 Electron 的系统剪贴板接口写入文本或 HTML。

这条链把一个用户动作拆成了可定位的环节。若团队研究互操作或定位复制差异，就能继续判断问题发生在内容组织、桥接、消息处理还是最终写入阶段。

阅读这个案例时，还要区分静态安装包里的代码线索与缓存网页模块的测试。不同来源支持不同判断，不能合并成“整个 Notion 已完整还原”的结论。

图 09Notion 剪贴板路径

DX-Ball 的声音为什么左右变化

DX-Ball 案例追问的是一段很小的行为：砖块在画面中的横向位置，怎样转换为声音的左右声像。分析沿相关指令、调用者和常量展开，重建项目再用 C 代码和测试核对逻辑。

官方记录给出了两个具体结果：与原始 x86 行为对照的 3,205 个测试用例，以及该函数编译后匹配的 63 字节。这些数字指向特定函数的验证范围，不能外推到整款游戏。

它对企业试点的启发是，把“是否一致”写成能执行的对照：输入是什么，预期输出是什么，哪些样本通过，哪些尚未测试。这样才能判断实现是否足以进入下一阶段。

图 10DX-Ball 声像计算

TH04 的一圈子弹怎样生成

TH04 DOS 案例研究一组 16 发等间距子弹，并继续追查玩家方向与模板旋转如何参与生成。屏幕上的环形效果，由此变成了可以解释和检查的计算过程。

官方案例中，2026 年 10 月 3 日的编译检查记录显示，包含辅助函数的子弹生成代码段有 2,139 字节匹配。这个范围需要保留；完整游戏行为和实际硬件表现仍是另外的验证对象。

这三个案例共同展示了一种方法：先缩小问题，再找到路径，最后把解释与特定证据和测试连接起来。负责人可以借鉴这套交付方式，实际价值仍要用自己的目标验证。

图 11TH04 弹幕生成

企业从哪里开始值得试

基于上述能力，可以优先讨论四类小范围调查：理解旧系统中的关键规则，研究不同系统的互操作路径，在迁移前确认行为与依赖，以及定位版本或环境之间的差异。

这些是试点建议。例如，在替换一个旧模块之前，先弄清一个关键计算规则，再用代表性输入输出判断新实现是否一致。能否减少成本、缩短时间或提高复用率，需要记录本企业的样本、投入和结果后再判断。

图 12企业可以先试的四类问题

立项前应同时确认目标与工具、数据去向、授权与验证条件。分析在本机进行，分析结果会交给 Agent；所用模型提供商的数据处理政策要单独确认。涉及第三方商业分析工具时，也要具备相应许可。

工具返回的汇编、伪代码或恢复出的模块关系，需要进一步解释和核对。负责人应把所需结果写清楚：这一轮要回答哪些问题，接受什么证据，哪些内容需要另外开发和测试。

图 13立项前看清三个条件

用一个小样决定下一步投入

一次试点可以从一句话开始：“我们要弄清某个版本中，一个具体功能在这些样本下怎样工作。”同时指定业务负责人，记录目标文件、版本、样本、分析范围和数据处理方式。

接着完成调查，提交证据、解释和未知项。若结论已足以支持决策，可以在这里结束；若业务确实需要实现，再做隔离的最小小样。最后用预先约定的输入输出对照验收，通过后再讨论扩围。

图 14从一个小问题开始试点

验收应分成两组。调查成果回答“为什么这样工作”，包括目标身份、证据位置、追踪路径、解释和未知清单。实现成果回答“做出来是否一致”，包括可运行小样、代表性输入输出，以及通过、失败和未测项。

两组成果分别验收，范围和费用才容易说清。一次有价值的调查，可能只完成了第一组；一份可运行小样，也需要第二组对照记录。成本、速度和复用价值，都应在本企业的试点中留痕。

图 15用两组成果判断试点

REA 带来的机会，是让“理解已有软件”成为可以组织、追查和交接的工作。对于企业，行动可以很具体：选一个获授权的小功能，写下想知道什么，再写下怎样才算查清楚。

问清一个功能，沿证据追查，小样通过再扩围。下一步是否值得投入，让自己的样本和验收结果回答。

图 16让理解软件成为可执行的工作