昨天还在互撕的产品经理，今天全被REA逼成了战友

2026-10-21 科技阅读

　　各个 App 的产品经理们总是水火不容，“你的 UI 是垃圾”、“这交互是给人用的？”、“你是伪用户视角，拿少数用户个案代表全量”。
　　可当 REA 爆火之后，这群产品经理们一瞬间就完成了战线统一，一致对抗 REA。
　　产品是这群产品经理们的命脉，有了 REA，这些产品的护城河几乎荡然无存。
　　法国技术博主 K...

　　各个 App 的产品经理们总是水火不容，“你的 UI 是垃圾”、“这交互是给人用的？”、“你是伪用户视角，拿少数用户个案代表全量”。

　　可当 REA 爆火之后，这群产品经理们一瞬间就完成了战线统一，一致对抗 REA。

　　产品是这群产品经理们的命脉，有了 REA，这些产品的护城河几乎荡然无存。

　　法国技术博主 Korben 用 Opus 5.5 对 REA 进行实测。

　　他让 Agent 读取自己写的一个 crackme 程序的伪代码，大约 2 分钟，Agent 就写出了能通过验证的 Python keygen，API 成本仅为大约 0.5 美元。他随后用 479 个随机用户名做了验证，全部通过。

　　一个功能从提需求、排期、开发、测试到上线，动辄几个礼拜甚至几个月。可 REA 只要几分钟就给反编译了，这搁谁谁也受不了。

　　具体是怎么反 REA 的？

　　由于 REA 包含了市面上所有的逆向软件，再加上 AI，因此怎么设计产品都不能保证 100% 不会被反编译。

　　既然挡不住，产品经理们就开始了抱团想对策。

　　最朴素也最有效的做法，是不在客户端放密钥和隐藏接口。

　　过去很多产品会把一些“反正用户看不到”的东西塞进安装包。这其中就包括写死的密钥、内部接口、只在客户端做的权限校验、靠前端判断的会员状态。而这些东西在 REA 面前，就等于是“裸奔”。

　　逆向教材《Practical Reverse Engineering》作者之一的埃利亚斯·巴沙拉尼（Elias Bachaalany）就表示，唯一稳妥的办法，是把关键逻辑放到服务器上。

　　所以这群产品经理按照埃利亚斯的方法，把值钱的东西搬出客户端。

　　尤其是把信任决策放回服务端。用户有没有付费、能不能访问某个功能、这次请求合不合法，都不再由客户端说了算，而是每次都去问服务器。

　　随后，产品经理们将核心逻辑上云。推荐算法、定价策略、风控规则、关键的数据处理，只让客户端拿到结果，拿不到过程。

　　这三步合在一起，客户端慢慢变成了一个“只有界面的外壳”。外壳可以被拆，被复刻，但里面没有东西。

　　但是有些场景是没法搬到云端的，比如嵌入式设备和游戏，这些都只能在本地运行。

　　于是产品经理们开始商量第二套办法，他们对代码加壳、混淆、虚拟化保护和反调试，让 REA 最先逆向出来的玩意是“假的”。

　　虽然到最后 REA 还是能逆向完整的产品，但是这会让整个逆向过程变得费劲。

　　一些厂商也盯上了这门生意。REA 爆火后，Thales 发布 Sentinel Envelope Plus，官方称之为专门针对 AI 逆向的保护方案，可以在不改源码的情况下，对应用的指定部分做多层的反反编译、防篡改和防运行时检查。

　　Thales 还公布了一组受控测试：对于未保护的应用，AI Agent 找出了 10 个漏洞中的 8 个；加上保护之后 Agent 一个都没找到，token 消耗是之前的 970 倍，最后 Agent 自己建议放弃分析。

　　对产品加强防护之余，产品经理们还互相分享方法，在 Discord 上创建了反 REA 频道，专门给那些不知道怎么对付 REA 的产品经理传授方法。

　　其中最常被引用的，是安全公司 Quarkslab 在 8 月发表的文章《Defeating AI-Assisted Reverse Engineering (or at Least Trying To)》。

　　这篇文章的核心发现是：现代混淆可以让反编译结果在结构上看起来合理，实际上却不反映程序的真实行为，从而把 AI 带离“容易的路径”，让它得出看似合理但并不正确的判断。

　　这个思路最有意思的地方在于，过去混淆是为了让人“看不懂”，现在更重要的是让 AI“看错”。

　　面对一个完全看不懂的程序，Agent 会老实承认他看不懂。可一个看起来逻辑通顺的错误答案，才是对付 AI 的最好办法，因为 Agent 不会停下来质疑它。

　　产品经理们“统一战线”，其实更像一种无奈。归根结底，谁也没法让自己的客户端变得不可逆向，只能减缓逆向它的过程，增加逆向它的成本。

　　质疑与谩骂接踵而至

　　REA 狂欢过后，留下的是一地鸡毛。

　　埃利亚斯在 REA 刷屏后对其评价为：hype（炒作）。社区给出的证据是，REA 的星标增速远超过它的下载量，也就是所谓的“drive-by stars”，点了星标但没真正用。

　　随后埃利亚斯列出了一串早就存在的同类工具。埃利亚斯表示，诸如 GhidraMCP、IDA Pro MCP 这类工具，在 2025 年就已经实现了用 AI 进行逆向分析。

　　IDA Pro MCP 插件的作者、x64dbg 调试器的开发者邓昆·奥格尔维（Duncan Ogilvie），在只使用 IDA Pro MCP 的前提下，大约一小时就解完了今年 Flare-On 逆向挑战赛的题目。也就是说，此前市面上就有比 REA 更好的逆向插件。

　　但 REA 的优势在于，它自己不做反编译，它做的是调度。让 Agent 去调用 Ghidra、IDA 和 Hopper 这些逆向工具，REA 自己拿到结果，再去写代码、做测试。在这之中，真正对目标进行逆向分析的，仍然是那些老牌工具加上大模型。

　　实测方面，评价也不一致。Korben 的测试里，REA 与不使用 REA、直接让 Claude 配合 Ghidra 的方案，都完成了四项测试，REA 在一些项目上更快，但在 patch 测试上反而更慢。

　　还有一个容易被忽略的细节。10 月 19 日的一篇 DEV Community 实测文章表示，通过记录 REA 逆向分析所需的环境后发现，Ghidra、JDK 等依赖需要用户自己准备。

　　和上面这些冷静的质疑相比，在独立开发者社区更多的是纯粹的谩骂。独立开发者的研发效率远低于企业团队：企业端产品的开发周期通常在2-3 个月，而不少独立开发者的项目往往要打磨数年。

　　这要是让 REA 几分钟复制走，那他们心态确实容易崩溃。

　　10 月 10 日，外网论坛的独立开发者版块就出现了一个爆火的帖子，标题是《Fxxking Hate the whole new trends of “Reverse Engineer Anything”》，大意是“我 XXX 讨厌这股‘REA’新潮流”。

　　帖子里没有论述，只有纯粹的谩骂。帖子下面的回复里也充斥着谩骂，独立开发者们把这里当成了情绪的宣泄口。

　　随后，由于这篇帖子几乎变成了英语脏话宝典，最终导致帖子被整个删除。

　　愤怒的独立开发者们没有大公司的法务和安全团队，没有预算买 Thales 那样的保护方案，作品一旦被逆向分析，几个月甚至几年心血就都没了。

　　专家说它没什么新东西，是炒作，而普通人却觉得它让一切都变了。

　　就在矛盾之中，更可怕的事情发生了。

　　已经有木马冒充 REA

　　任何一个爆火的开源项目，几乎都会引来仿冒者。比如 OpenClaw 爆火之后，GitHub 上面至少有几百个人冒充 OpenClaw 仓库，骗人点进来，然后给下载这个假 OpenClaw 仓库的人植入病毒。

　　REA 也不例外。

　　10 月 10 日，一个名为 rea-tools 的 GitHub 组织出现。这个名字，刻意模仿了 REA 的官方网站 rea.tools，让人看一眼就以为这是官方的另一个入口。

　　仿冒者整份复制官方 README，只在里面加了一段“Windows 独立版 .exe/GUI”的下载说明，指向一个名为“rea-agents: v6.3.0”的 Release。

　　而 REA 官方的 README 里根本没有任何安装包，虽然官方仓库的 Issue 2136 里讨论过是否要做一个一键安装版，然而那只是 REA 作者的计划，并没有真正发布出来。

　　REA 仿冒者的 Release 里是一个 82.6 MB 的压缩包，名为 rea-x64.7z。Microsoft Defender 把压缩包判为 Trojan:Script/Wacatac.B!ml，解压出的 rea-x64.exe 判为 Trojan:Win32/Wacatac.B!ml。VirusTotal 上，45 个引擎中有 8 个报毒。

　　被举报时，这个文件已经被下载了 172 次。不要忘了，这个病毒是可以二次传播的，所以仿冒者造成的破坏要远远超过已经被曝光的 172 次。