REA：逆向工程任何事物

很多人知道REA是最近GitHub上破12万星的Reverse Engineer Anything项目，少有人知道REA的思想根源可以追溯到1982年密歇根州立大学William E. McCarthy教授提出的Resources-Events-Agents模型。前者是工具，后者是本体论。把这两层打通，你才能真正理解为什么REA可以"逆向一切"，而不只是拆个软件。这篇文章会从最底层的本体论讲起，到工具链实现，再到四个不同领域的实战案例，最后聊清楚边界和局限。

一、被误解的REA：不只是AI逆向工具

先澄清一个最常见的误区：现在网上刷屏的REA（Reverse Engineer Anything）是一个具体的开源MCP项目，但REA作为一种建模思想已经存在了44年。两者不是一回事，但内核高度一致。

1.1 经典REA：从会计革命到企业本体

1982年，McCarthy在《The Accounting Review》上发表了那篇著名的论文《The REA Accounting Model: A Generalized Framework for Accounting Systems in a Shared Data Environment》。核心观点一句话就能说清：传统复式记账法是为纸质账本设计的，它记录结果却丢失了过程。

一笔销售业务，传统会计只记"借：应收账款 1000，贷：主营业务收入 1000"。谁卖的？卖给谁了？卖的什么商品？从哪个仓库出的？几点几分成交的？这些信息要么散落在各个业务单据里，要么根本没记录。会计分录是高度抽象后的结果，它把经济现实压平成了两个数字。

REA模型反其道而行之：直接记录经济现实本身，而不是记录它的会计投影。所有经济活动都可以拆解为三类最基本的实体：

• 资源（Resource）：企业拥有且可控的、有价值的事物。比如现金、库存、设备、厂房。注意：应收账款不是资源，它只是销售事件和收款事件时间差产生的派生概念，数据足够的话随时可以计算出来。
• 事件（Event）：引起资源数量或状态发生变化的经济活动。比如采购、销售、付款、收款、生产入库。事件是REA模型的核心，所有变化都由事件驱动。
• 参与者（Agent）：参与事件的人或组织。可以是内部的（销售员、仓库管理员），也可以是外部的（客户、供应商、税务局）。

这三类实体通过四种关系构成完整的业务语义网络：

1. 存量-流量关系（Stock-Flow）：事件与资源之间的关系。事件是流量，资源是存量；事件导致资源增加或减少。比如"采购入库"事件增加"库存"资源，"付款"事件减少"现金"资源。
2. 二元关系（Duality）：事件与事件之间的对偶关系。有得必有失，一个资源增加的事件必然对应另一个资源减少的事件。比如销售事件减少库存，对应的收款事件增加现金，两者构成二元关系。
3. 控制关系（Control）：事件与参与者之间的关系。每个事件都有参与者，参与者分为内部和外部。比如一笔销售，内部参与者是销售员，外部参与者是客户。
4. 责任关系（Responsibility）：参与者之间的层级关系。比如销售经理对销售员的行为负责，部门对员工的行为负责。

这套体系最厉害的地方在于：它是一套通用的业务原子模型，不依赖任何特定行业、特定系统、特定软件。制造业、零售业、银行业、互联网，表面看业务千差万别，底层都是资源在事件驱动下的流转，都有参与者在其中起作用。

1.2 现代REA：AI时代的逆向工程方法论

2026年10月爆火的REA开源项目，全称Reverse Engineer Anything，本质上是把经典REA的建模思想用AI工具链落地了。它不自己做逆向，而是通过MCP（Model Context Protocol）把Ghidra、Hopper、IDA等专业逆向工具的能力开放给AI编程Agent，让Agent按照"证据-推理-验证"的闭环去拆解目标系统。

它的工作逻辑和经典REA一脉相承：

• 逆向目标系统 = 逆向一个"经济系统"
• 系统中的数据结构 = 资源
• 系统中的函数调用/状态变化 = 事件
• 系统中的模块/进程/角色 = 参与者

传统逆向工程是工程师拿着工具手动找线索，靠经验猜逻辑。REA的思路是让Agent按照本体论框架系统地收集证据，每一步推理都有对应的代码、内存、网络包作为支撑，最后输出的不是零散的反编译代码，而是完整的语义模型。

这两者的关系可以用一句话总结：经典REA提供了"应该拆成什么"的本体论框架，现代REA提供了"怎么拆"的工具链和方法论。

二、REA逆向工程的核心原理

很多人觉得逆向工程靠的是技术，其实不是。逆向工程的本质是语义还原——把机器能理解的二进制、字节码、网络包，还原成人能理解的业务逻辑、算法逻辑、协议逻辑。

REA之所以能成为通用方法论，核心在于它抓住了所有系统的共性：任何系统，无论硬件还是软件，无论业务还是技术，本质上都是一个状态机，有资源（状态）、有事件（状态转移）、有参与者（状态转移的触发者）。

2.1 逆向工程的三层语义模型

任何逆向目标都可以拆解为三层，从下往上依次是：

绝大多数新手逆向停留在物理层，反编译出一堆代码就觉得完事了。中级逆向能到逻辑层，看懂函数调用关系和数据结构。真正的高手能到语义层，还原出设计者的意图。

REA的作用就是给你一套从物理层提取语义层的标准范式。你不用靠灵感和经验去猜，按照资源-事件-参与者的框架去套，总能找到线索。

2.2 证据驱动原则

这是REA方法论里最重要的一条原则，没有之一。所有结论必须有可追溯的证据支撑，没有证据的推理就是猜测，猜测不能写进最终报告。

证据分为三个等级：

• 一级证据：直接来自目标系统的原始数据。比如反编译出的汇编指令、抓包得到的原始网络报文、固件里提取的字符串。
• 二级证据：基于一级证据的推导结果。比如反编译工具生成的伪代码、根据报文格式推测的字段含义。
• 三级证据：基于二级证据的逻辑推理。比如根据函数名和调用关系推测的功能。

逆向过程中可以用三级证据提出假设，但最终结论必须落到一级或二级证据上。DX-Ball那个经典案例里，第一次反编译出的伪代码漏掉了输入参数，Agent没有直接采信伪代码，而是回去对比原始汇编指令，发现了栈上的参数传递，这就是证据驱动的典型体现。

2.3 REA逆向的五步法

结合经典REA的本体论框架和现代REA的工程实践，我把逆向工程的标准流程总结为五步。这套方法我在多个项目里验证过，适用于软件、固件、协议、业务流程等几乎所有逆向场景。

第一步：锁定目标

逆向最容易犯的错误就是范围失控。一开始只想拆一个功能，拆着拆着就陷进整个系统里去了。动手之前必须明确：

• 逆向的具体目标是什么？（复刻某个功能？理解某个算法？还原某个协议？）
• acceptable的粒度是多细？（到函数级？到算法级？到指令级？）
• 哪些东西不用管？（无关的库函数、调试信息、资源文件）

边界画清楚，效率才能高。REA项目的最佳实践是"单功能逆向"，每次只针对一个具体功能展开，完成就收手。

第二步：收集证据

根据目标类型选择对应的工具，全面采集原始证据。这一步的原则是多维度交叉验证，单一来源的证据可信度有限。

不同目标类型的证据采集工具：

很多人逆向只看代码，这是很大的误区。字符串、常量、内存布局、调用时序、网络报文，这些都是比代码本身更可靠的证据。尤其是字符串，几乎不会撒谎。

第三步：语义建模

这是REA方法论的核心。把收集到的证据按照资源、事件、参与者三个维度进行归类，建立语义模型。

具体操作的时候可以问自己三个问题：

1. 这个系统里有什么东西？ —— 找出资源。比如电商系统里的商品、订单、库存、资金；游戏里的血量、分数、道具；通信协议里的会话、状态、数据包。
2. 什么事会导致这些东西变化？ —— 找出事件。比如下单、付款、发货；打怪、升级、捡装备；握手、传输、断开。
3. 谁/什么触发了这些事件？ —— 找出参与者。比如用户、系统模块、第三方服务、硬件外设。

刚开始练的时候可以画表格，三列分别写资源、事件、参与者，把找到的证据往里面填。填着填着你就会发现，很多之前看不懂的东西自动串起来了。

第四步：逻辑还原

实体找出来之后，下一步是还原它们之间的关系。对应经典REA的四种关系：

• 存量-流量关系：每个事件影响哪些资源？是增加还是减少？数量怎么算？
• 二元关系：事件之间有没有配对关系？比如请求和响应，发送和接收，扣减和增加。
• 控制关系：每个事件由谁触发？需要什么权限？有什么前置条件？
• 责任关系：模块之间的调用链是什么？谁依赖谁？谁对谁负责？

这一步做完，你得到的就不再是零散的代码片段，而是一张完整的语义网络图。这张图就是你理解目标系统的地图。

第五步：验证闭环

逆向最容易翻车的地方就是自以为搞懂了，其实理解错了。验证是必不可少的环节。

验证的方法有三种，优先级从高到低：

1. 输入输出对比验证：给原版和重制版输入完全相同的参数，对比输出结果是否一致。DX-Ball案例用3205组测试数据做对比，就是这种方法。
2. 行为一致性验证：观察原版和重制版在相同场景下的行为是否一致。比如状态转移顺序、异常处理、边界表现。
3. 代码级验证：对于编译型语言，可以对比生成的机器指令序列。这是最严格的验证，DX-Ball案例最后做到了编译后63个字节完全匹配。

验证不通过就回到第二步，重新收集证据，修正模型。直到所有测试用例全部通过，逆向才算完成。

三、REA工具链架构与实现

现代REA之所以能把逆向工程的门槛拉下来，核心是构建了一套"AI Agent + 专业工具 + 标准协议"的三层架构。人不用再在工具之间反复横跳，Agent会替你完成大部分机械性工作。

3.1 整体架构

3.2 MCP：工具能力的标准接口

MCP（Model Context Protocol）是整个架构的关键。它的作用相当于一个通用适配器，把各种专业逆向工具的能力封装成标准接口，让AI Agent可以用统一的方式调用。

在REA出现之前，AI想调用逆向工具非常困难。每个工具都有自己的API、自己的数据格式、自己的交互方式。你得给每个工具单独写插件，还得处理各种异常。

MCP解决了这个问题。它定义了一套标准的工具调用协议，工具方只要实现MCP服务端，Agent端只要支持MCP客户端，双方就能直接对话。REA本质上就是一个把各种逆向工具包装成MCP服务的集合。

目前REA集成的核心工具能力包括：

• 二进制分析：Ghidra反汇编、函数识别、交叉引用、字符串提取
• 动态调试：内存读写、断点设置、寄存器查看、单步执行
• 网络分析：HTTP请求解析、WebSocket抓包、协议流量分析
• 代码搜索：全局字符串搜索、模式匹配、调用链追踪
• 文件解析：APK/IPA解包、资源提取、格式识别

这些能力组合起来，Agent就拥有了和人类逆向工程师差不多的"观察手段"。

3.3 Agent的工作模式

很多人以为Agent就是把反编译代码扔给大模型让它解释，其实远不止这么简单。REA模式下的Agent是主动探索者，不是被动解释者。

它的工作模式是假设-验证循环：

1. 收到逆向需求后，先做初步分析，提出假设
2. 调用工具收集证据，验证假设是否成立
3. 如果发现矛盾，提出新的假设
4. 重复这个过程，直到所有线索闭环
5. 最终输出完整的分析报告和可运行的重现代码

还是以DX-Ball的声音定位算法为例，Agent的推理过程大致是这样的：

• 假设1：声音位置由砖块X坐标直接决定 → 调用工具查看函数，发现伪代码里没有参数 → 假设不成立
• 假设2：参数通过栈传递 → 查看原始汇编指令，确认EBP+8位置有参数传入 → 假设成立
• 假设3：计算逻辑是线性映射 → 追踪指令里的常量和运算，还原出计算公式 → 假设成立
• 验证：代入3205组X坐标值，对比原版输出 → 全部匹配 → 结论可靠

整个过程中，Agent不是一次性得到答案，而是像侦探一样一步步收集线索，修正判断，最后形成完整的证据链。

3.4 为什么不是直接让大模型反编译

很多人会问：现在大模型这么强，直接把二进制扔给它不行吗？

不行，原因有三个：

1. 上下文窗口限制：稍微大一点的程序反编译出来就有几十万行代码，远远超出任何现有模型的上下文窗口。你不能把整个程序都塞进去。
2. 幻觉问题：大模型看到不完整的代码会自行脑补，编出来的逻辑看起来很合理，其实完全不对。逆向工程对准确性的要求是零容忍。
3. 工具能力缺失：大模型本身不能调试、不能抓包、不能动态运行程序。这些能力必须通过外部工具获得。

REA的思路是对的：大模型负责推理和决策，专业工具负责观察和取证。两者结合，才能既保证效率又保证准确性。

四、实战案例

讲了这么多理论，现在看具体怎么用。

4.1 案例一：Electron应用功能逆向

这是最入门的场景。很多桌面应用都是用Electron做的，本质上就是个Chrome浏览器包了层壳。逆向难度不高，适合练手。

目标

逆向Electron笔记应用的搜索功能，理解它的跨进程调用机制，然后用自己的技术栈重写。

证据收集

1. 安装包解包，找到app.asar文件，解压出前端代码
2. 主进程代码和preload脚本一般是混淆的，需要反混淆
3. 打开开发者工具，抓IPC通信的消息
4. 搜索关键词"search"、"find"、"ipcRenderer"，定位相关代码

语义建模

• 资源：笔记数据数组、搜索关键词、搜索结果集
• 事件：用户输入关键词、前端发起搜索请求、主进程处理搜索、返回结果
• 参与者：渲染进程（前端UI）、preload脚本（桥接层）、主进程（业务逻辑）

逻辑还原

整个调用链是：

1. 用户在输入框打字 → 渲染进程触发onChange事件
2. 渲染进程通过ipcRenderer.send('notes:search', keyword)发请求
3. preload脚本暴露安全的API接口，做参数校验
4. 主进程通过ipcMain.handle监听'notes:search'消息
5. 主进程过滤notes数组，返回匹配结果
6. 渲染进程收到结果，更新UI

验证

• 输入相同的关键词，对比原版和重制版的返回结果
• 测试空字符串、特殊字符、大小写等边界情况
• 验证并发请求的处理逻辑

这个案例虽然简单，但完整体现了REA逆向的思路。你不是在抄代码，而是在还原"搜索"这个业务事件在三个参与者之间的流转过程。

4.2 案例二：二进制算法逆向

这是最能体现REA威力的场景。没有源码，只有二进制可执行文件，要还原里面的核心算法。

目标

逆向经典游戏DX-Ball（1996）中的声音定位算法：砖块被击中时，声音的左右声道偏移是怎么计算的。

证据收集

1. 用Ghidra加载EXE文件，分析字符串找到声音相关的函数
2. 定位到声音播放函数，查看调用方
3. 反编译出伪代码，同时保留原始汇编指令
4. 动态调试，在关键函数处下断点，查看输入参数和返回值
5. 提取游戏中的常量数据，比如屏幕宽度、声音范围等

语义建模

• 资源：砖块X坐标、声音声道偏移值、屏幕宽度常量
• 事件：砖块被击中、计算声道偏移、播放声音
• 参与者：碰撞检测模块、声音计算函数、音频播放系统

逻辑还原

这是整个案例最精彩的部分。第一次反编译出的伪代码是错的，函数没有参数，里面只有一个float转int的调用。Agent没有轻信伪代码，而是回去看原始汇编：

fild    dword ptr [ebp+8]
fmul    dword ptr [004XXXXX]
fistp   dword ptr [ebp-4]
mov     eax, [ebp-4]
sub     eax, 64


从汇编里能清楚看到：

1. 函数有一个参数，从[ebp+8]取，是个整数
2. 乘以一个浮点常量
3. 结果转成整数
4. 减去100（0x64）

然后去数据段找那个浮点常量的值，再结合屏幕宽度640像素，就能还原出完整的计算公式：

int calculate_pan(int brick_x) {
   float ratio = brick_x / 640.0f;
   int pan = (int)(ratio * 200.0f) - 100;
   return pan;
}


计算结果范围是-100到+100，对应左声道到右声道。

验证

• 提取原版游戏中3205个不同砖块位置的实际声音偏移值
• 用还原的公式计算对应的值
• 逐一对比，全部匹配
• 编译C代码，对比生成的机器指令，63个字节完全一致

这个案例完美诠释了证据驱动原则。伪代码会骗人，汇编指令不会。逆向的时候永远要保留回到原始证据的能力。

4.3 案例三：业务流程逆向

很多人以为REA只能用来逆向软件，其实它最擅长的是逆向业务系统。尤其是接手遗留系统的时候，用REA模型梳理业务，比看文档快得多。

目标

逆向一个老ERP系统的采购付款流程，理解完整的业务逻辑，为后续重构做准备。

证据收集

1. 数据库表结构分析：找出采购相关的表（采购单、入库单、付款单、供应商）
2. 数据分析：拉取一段时间的真实业务数据，看数据之间的关联
3. 日志分析：看操作日志，了解每个节点是谁在什么时候操作的
4. 界面截图：系统各个操作页面的字段和按钮
5. 访谈业务人员：确认实际业务流程和系统是否一致

语义建模

• 资源：原材料库存、现金、采购订单、入库单、付款单
• 事件：创建采购订单、入库验收、收到发票、付款申请、财务付款
• 参与者：采购员、仓库管理员、财务会计、财务经理、供应商

逻辑还原

用REA的四种关系梳理：

存量-流量关系：

• 创建采购订单 → 增加"在途物资"（承诺资源）
• 入库验收 → 减少"在途物资"，增加"原材料库存"
• 财务付款 → 减少"现金"

二元关系：

• 入库事件 和 付款事件 构成二元关系（拿货和给钱）
• 采购订单 和 入库单 是一对多关系
• 入库单 和 付款单 是多对多关系（可以合并付款）

控制关系：

• 创建采购订单：采购员创建，部门经理审批
• 入库验收：仓库管理员操作，质检员复核
• 付款：财务会计制单，财务经理审批

责任关系：

• 采购部对采购订单负责
• 仓库对入库数量负责
• 财务部对付款金额负责

梳理完你会发现，很多老系统虽然代码写得乱七八糟，但底层业务逻辑还是符合REA模型的。因为业务本身就是这么运转的，跟用什么技术实现没关系。

验证

• 用真实数据走通整个流程：从采购订单到入库到付款
• 验证数据一致性：订单数量 = 入库数量之和，入库金额 = 付款金额之和
• 验证异常场景：部分入库、分批付款、退货退款

业务流程逆向的好处是，你得到的模型是技术无关的。将来不管用Java重写还是用低代码平台搭，业务模型都不用变。

4.4 案例四：硬件通信协议逆向

这是目前REA延伸最前沿的领域。很多智能硬件只有厂商自己的APP能控制，协议不公开。用REA的思路可以把协议逆向出来，自己做控制端。

目标

逆向某品牌智能空调的WiFi控制协议，实现用自己的程序控制空调开关和温度。

证据收集

1. 手机APP抓包：用Charles或mitmproxy抓取APP和空调之间的通信
2. 本地网络抓包：用Wireshark抓手机和空调之间的局域网报文
3. 固件分析：如果能拿到固件，解包出里面的协议处理代码
4. 控制变量测试：APP发不同指令，对比对应的报文变化

语义建模

• 资源：空调状态（开关、温度、模式、风速）、指令报文、状态报文
• 事件：发送控制指令、设备状态变更、状态查询、心跳保活
• 参与者：手机APP、空调WiFi模块、云服务器（如果有）

逻辑还原

协议逆向的核心是找出字段含义。方法就是控制变量法：

1. 只改温度，其他不变，对比报文字节的变化 → 找到温度字段
2. 只切换开关，对比变化 → 找到开关字段
3. 切换不同模式 → 找到模式字段
4. 看报文的固定开头和结尾 → 找到帧头帧尾
5. 计算不同长度报文的校验和 → 找到校验算法

一般智能家居的局域网协议都不复杂，大多是JSON格式或者简单的二进制帧。难的是加密，如果报文是加密的，就得去固件里找密钥和加密算法。

验证

• 构造自己的指令报文，发给空调，看是否正确执行
• 遍历所有功能点，逐一验证
• 测试边界值：温度上下限、风速档位
• 长时间运行测试稳定性

这个方向现在玩的人还不多，但潜力巨大。家里的智能设备越来越多，各自为战，把协议都逆向出来，就能自己做统一控制。

五、边界、合法性与行业影响

技术从来都不是中立的。逆向工程这个话题绕不开法律和伦理。有些话必须说在前面。

5.1 合法边界在哪里

先说结论：逆向工程本身不违法，但有明确的边界。

各国法律普遍认可的合法场景包括：

• 兼容性研究：为了让自己的软件和目标软件兼容而进行逆向
• 安全研究：为了发现和报告漏洞而进行逆向
• 教育研究：为了学习和研究技术而进行逆向
• 合理使用：个人学习、非商业用途的逆向

有明确法律风险的场景：

• 破解软件的版权保护、序列号验证，然后传播
• 逆向后抄袭代码，直接用在自己的商业产品里
• 逆向商业机密用于不正当竞争
• 绕过DRM保护并分发内容

具体到REA这种工具，它本身只是个分析工具，就像螺丝刀。螺丝刀本身不违法，但你用它去撬别人家的门就违法了。

我个人的建议是：

1. 只逆向你合法拥有的软件和设备
2. 逆向结果仅供自己学习研究，不要传播
3. 商用场景一定要咨询律师，不要心存侥幸
4. 复刻功能可以，不要抄代码。思想和逻辑不受版权保护，代码受

5.2 对软件行业的影响

REA爆火之后，很多人说"软件完了"、"再也没有护城河了"。这话太夸张了，但影响确实存在。

首先，功能复刻的门槛大幅降低。以前要抄一个功能，得有经验丰富的逆向工程师花几天甚至几周。现在AI Agent几个小时就能给你还原出来，还带重写的代码。中小团队追赶大厂的速度会越来越快。

其次，软件的护城河正在从"功能实现"转向"生态和数据" 。功能容易抄，但用户数据、社交关系、内容生态、服务体系这些东西抄不走。以后产品竞争会更多地在这些维度展开。

第三，对知识产权保护提出了新的挑战。以前代码混淆、加壳还能挡一挡，现在AI辅助逆向的效率越来越高。未来可能会出现更多针对AI逆向的保护技术，比如代码混淆专门针对大模型优化，加入各种误导性的逻辑。

但我觉得总体是好事。技术本来就是在攻防交替中进步的。逆向能力的普及，会倒逼整个行业提升代码质量和安全水平。

5.3 从代码逆向到业务逆向

大多数人关注REA都是因为软件逆向，但我认为它更大的价值在业务领域。

想想看：既然任何软件系统都能用REA模型逆向，那任何企业的业务是不是也可以？

你去研究任何一家公司的商业模式，本质上就是在做业务逆向。找出它的核心资源是什么，关键事件是什么，参与者有哪些，利益怎么分配。然后你就能理解它的商业模式，甚至找到它的薄弱环节。

这才是"逆向工程任何事物"真正的含义。它不只是一个技术工具，更是一种思维方式。把任何复杂系统都拆解成资源、事件、参与者三个基本要素，然后还原它们之间的关系。这套方法可以用在软件上，可以用在业务上，可以用在组织上，甚至可以用在理解一个城市、一个国家的运转上。

六、实践建议与避坑指南

最后分享一些我自己做逆向工程积累的经验，都是踩过坑总结出来的。

6.1 给初学者的建议

1. 先练眼神再练手。刚开始不要上来就反编译大程序，先从小例子入手。找个自己写的小程序，编译成二进制，然后自己逆向自己。先能看懂自己写的代码编译出来是什么样，再去看别人的。
2. 打好基础再谈工具。Ghidra、IDA这些工具只是放大镜。看不懂汇编，工具再强也没用。x86汇编不用精通，但常用指令要认识，栈帧结构要理解，函数调用约定要熟悉。
3. 学会用搜索的思路逆向。不要一行行读代码，那是大海捞针。先找字符串、找常量、找特征码，定位到关键函数，再往里深挖。逆向工程大部分时间是在搜索，不是在读代码。
4. 建立自己的证据笔记。每发现一个结论，就把证据位置记下来。哪个地址的指令证明了什么，哪个报文对应哪个操作。不然过两天你自己都忘了结论是怎么来的。

6.2 常见的坑

1. 过度依赖反编译伪代码。伪代码是工具猜的，经常会错。尤其是参数传递、结构体访问、数组下标，错的概率很高。重要的地方一定要回去看汇编。
2. 命名陷阱。很多人逆向的时候喜欢给函数起名字，起着起着就当真了。名字只是你的假设，随时可能被推翻。建议用编号或者功能描述，不要过早下结论。
3. 范围蔓延。逆向很容易上瘾，拆着拆着就想把整个系统都搞明白。记住你的目标是什么，完成就停。剩下的以后有需要再说。
4. 不做验证。这是最致命的。觉得自己看懂了就开始写代码，写完发现不对，回头查半天，最后发现是理解错了。逆向完成的标志不是"我觉得懂了"，而是"所有测试用例都通过了"。

6.3 AI时代的逆向工程师

很多人担心AI会取代逆向工程师。我觉得不会。AI取代的是机械性的劳动，比如找字符串、追调用链、写重复代码。真正考验功力的地方——判断哪些信息重要、提出合理的假设、设计验证方案、理解业务语义——这些AI暂时还做不好。

但只会用工具的逆向工程师确实会被淘汰。未来的逆向工程师，应该是懂业务的技术专家。你不仅能看懂代码，还能理解代码背后的业务逻辑和设计意图。你输出的不是反编译代码，而是业务模型和设计思路。

REA给我们的最大启示就在这里：逆向的终极目标不是复制代码，而是理解思想。

结尾

从1982年McCarthy提出REA模型，到2026年REA工具爆火，44年过去了。变的是技术，不变的是本体论。

这个世界上很多东西看起来复杂，拆解到底层其实都很简单。软件也好，业务也好，组织也好，本质上都是资源在事件驱动下的流转，都有参与者在其中扮演角色。理解了这个框架，你就拥有了拆解任何复杂系统的能力。

技术工具会过时，方法论不会。希望这篇文章能让你看到REA之外的东西。

❝

参考资料： 厦门大学信息与网络中心. 论REA模式与SAP数据模式之间的关系.