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

文 | 字母AI 各个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里讨论过是否要做一个一键安装版