最近几天，刷到不少介绍 REA 的视频和文章。这个项目的名字就叫「逆向一切」，主打的是看到别人软件里一个好用的功能，就让 AI 去把它怎么做的拆出来。
看了这些介绍，我更想知道它拆一个真实的软件，到底能拆到哪一步，就让 Claude Code 把它装好，找了一个能合法拆的软件，真跑了一遍。
🔹 REA 到底是个什么东西
REA 全称 Reverse Engineer Anything，是 GitHub 上的一个开源项目，MIT 协议。
REA 官方仓库：
REA 官网与使用指南：
它今年 4 月 14 日才建仓，到 10 月 14 日，star 已经到了 21.1 万，README 上还挂着 Trendshift 发的 GitHub Trending 当日第一徽章。
它用 MCP 把 Claude Code、Codex 这类 agent 接到一套逆向分析能力上。拆原生程序时，它借用 Hopper、Ghidra、IDA 这些现成的反编译工具；拆 JavaScript、Electron 应用和 .NET 程序时，它用自带的静态分析。agent 拿到这些能力以后，就能在没有源码的情况下，去拆原生程序、桌面应用、网站和安卓 APK。
README 第一屏那句话，基本说明了它为什么会火：
💡
See a feature you like. Understand how it works, down to the binary level.
看到一个喜欢的功能，就把它怎么做的弄明白，一直弄到二进制那一层。README 里给的示例提问也很直接：弄懂某个应用的搜索功能是怎么做的，给出证据，然后在我的项目里做一个类似的。
🔹 我让它拆了一个企业 IM
拆什么要先想清楚。很多商业软件的用户协议限制逆向，REA 自己的免责声明也写得很重，明确不支持绕过许可证校验和 DRM，不支持复制专有软件、复现受保护的代码和资产。
所以我让 Claude Code 找一个能合法拆的目标，它选了 Mattermost 的桌面端。Mattermost 是一个开源的企业 IM，和 Slack 同类，相当于飞书、钉钉里聊天的那一块，协议是 Apache-2.0。选它还有一个好处，它的源码就在 GitHub 上。这次只把安装包交给 REA，让它像拆闭源软件一样，从打包好的成品往回推；源码留到最后，用来逐条对答案。
这次想弄明白的问题是：
💡
网页里来了一条新消息，Mattermost 桌面端是怎么把它变成系统通知和任务栏上的未读角标的？
REA 的命令行只接收要拆的文件，不接收问题。所以流程是 REA 先把整个应用拆一遍，Claude Code 再带着这个问题去翻它的结果。拆的对象是 Mattermost 桌面端 6.3.0 的 Linux 安装包里打包好的 app.asar：
npx -y rea-agents@6.4.0 analyze-javascript-application ./resources/app.asar --json
跑了 1 分 23 秒，吐出来一个 41MB 的 JSON。里面列了 105 个相关文件、376 个模块、171 处进程之间的消息调用，每条结论后面都挂着文件位置和证据等级。
🔹 它找到了什么，又卡在了哪
先说找到的部分。
REA 列出了 143 个写死名字的消息通道，每个都标了出自哪个文件。Claude Code 按「通知」「未读」这些关键词筛了一遍，筛出两条，都出自一个叫 externalAPI.js 的预加载脚本。这个脚本是网页和桌面程序之间的那道门，网页想弄出一个系统通知，或者想更新未读数，都得经过它。两条通道一条叫 notify_mention，负责「有人@你了，弹个通知」，另一条叫 unreads-and-mentions，负责上报「还有没有未读、被@了几次」。
Claude Code 顺着 REA 给的位置把这个文件打开，确实是这样。网页调用 sendNotification，脚本就往 notify_mention 发请求；调用 setUnreadsAndMentions，就往 unreads-and-mentions 发消息。
然后是卡住的部分。
消息发出去了，总得有人接。REA 的统计里，桌面程序主进程这一侧负责接收的处理函数是 0 个。它找到的 171 处消息调用全在网页那一侧，也就是说它只找到了发消息的一头，没找到收消息的一头。
可主进程明明在收。Claude Code 把安装包解开一查，主进程里注册接收的代码有 131 处，只是打包工具把写法改了个样子，REA 一处都没认出来。它在报告的局限里写得很清楚：
💡
Electron API identity follows proven lexical module aliases. … missing findings do not establish absence.
意思是，它只认能直接证明的写法；没找到，也不代表不存在。另外，主进程这个文件太大，也超出了它这次的分析预算。整份报告里，它自己标为「不确定」的地方有 7370 处。
剩下的半条链路，是 Claude Code 对照 Mattermost 的源码补上的。主进程在 initialize.ts 里接住 notify_mention，先校验 7 个参数的类型，再交给通知模块去弹通知。unreads-and-mentions 由 webContentsManager.ts 接住，交给应用状态记下来，应用状态把各个服务器的数字加总以后，通知 badge.ts 更新角标。角标按系统分别处理，Windows 在任务栏图标上叠一个小数字，macOS 改 Dock 上的角标，Linux 只在 Unity 这类支持角标的桌面环境里设置未读数。
图里实线那半段是 REA 直接给出来的，虚线那半段是对照源码补的。
跑完这一遍，REA 能做什么、做不到什么就具体了。它确实能在一分多钟里把一个陌生软件的骨架摊开，告诉你该从哪个文件、哪个通道下手。这次它没认出来的地方，没有硬编一个结果，而是在局限里说清楚了自己哪里看不见。不过 REA 自己的免责声明也说了，反编译和 AI 辅助分析的结果可能不完整，也可能出错。它给的是一张有证据的地图，地图上有空白。把空白补上、把整条链路走通，还得有人去核对。
🔹 拆得出功能，拆不走什么
跑完这个测试的前一天晚上，我刚好在抖音上刷到晓辉博士的一条视频。大意是，晓辉博士和一家知名制造业公司的负责人聊天，对方说他们之前订阅的 SaaS 服务现在基本都不续了，连飞书、钉钉这类 IM 也在逐渐不用。原因是他们更需要把企业自己的知识和规范沉淀下来，反复使用，不断优化。视频里还提到，对 ToB 来说，界面做得多精美没那么重要，关键功能做出来，整条流程能跑通，就已经够用了。
这是一家公司的说法，我没办法替所有企业下结论。但把它和 REA 放在一起看，我觉得能对上。
我这次让 REA 拆的，是一个 IM 客户端怎么把一条消息变成一个角标。这正是「功能」那一层，也是很多 SaaS 过去收钱的地方。这次实测能说明的事情有限：一个 agent 加一个开源工具，一分多钟就能把骨架摊开，告诉你该看哪里；可后半条链路，是靠源码补上的。换成闭源软件，没有源码可对，补这半条只会更费力。所以我不觉得功能已经能被随便拆走，但看懂一个功能的门槛确实在往下掉。单靠功能和界面收订阅费，这堵墙可能在变矮。
可 REA 拆开的那个安装包里，有一样东西是没有的。Mattermost 桌面端只是一个壳，一家公司真正的东西在壳的外面：谁负责什么，一个问题按什么流程走，哪些经验踩过坑以后写成了规范，这些都不在 app.asar 里，逆向工具也拆不出来。那位负责人想沉淀下来的知识和规范，就在这一层。
这也是我现在的判断，ToB 软件里最值钱的部分，正在从「功能做得全、界面做得好看」往「能不能装下这家公司自己的知识和流程，并且整条链路真的跑得通」那边挪。
当然，这件事有它的代价。自己沉淀知识、自己维护系统，需要有人懂业务又能把流程讲清楚，这对很多小公司来说并不便宜，IM 这种东西也不是说不用就能不用的。
如果你也想试试 REA，我的建议是先拿开源软件或者你自己写的程序练手，带着一个具体的问题去问，比如「这个按钮点下去以后发生了什么」。拆出来的结论，记得自己再核对一遍。想拆商业软件，先看它的用户协议和当地法律。REA 的免责声明也写了，拿到分析报告，不等于拿到了原程序的任何权利。
💡
/ 作者：kakarot / 投稿、合作或交流，欢迎在公众号后台留言
