“软件完了。”Matthew Berman 分享开源项目 REA 时，写下了这句话。这条帖子在 X 上获得了超过 300 万次阅读。截至 10 月 12 日，REA 在 GitHub 上的标星也已超过 10 万。

REA 的全名是 Reverse Engineer Anything——逆向一切。它把分析工具与 AI Agent 接在一起，让模型研究已经写好的软件，理解内部逻辑，再尝试重建其中的功能。人们开始讨论：安装在电脑里的程序，能否成为 AI 重写它的线索？

在此前的公开讨论中，开源软件倡导者 Eric S. Raymond（ESR）已经预测，软件依赖代码保密维持的壁垒正在松动。商业竞争也未必需要逐行恢复原厂源码：覆盖用户最常用的功能，就可能做出一个够用的替代品。

如果竞争者不用拿到原厂源码，就能以可接受的成本重做你常用的功能，你电脑里那些付费软件，究竟还能靠什么让你继续掏钱？

以前也能逆向，为什么现在更值得担心？

逆向工程本身并非新兴技术。长期以来，安全研究员与工程师一直使用 IDA Pro、Ghidra、Hopper 等工具，将编译后的机器指令转换为汇编或伪代码。在传统流程中，分析工作高度依赖人工经验：

• 面对剥离了符号名的二进制文件，需要人工逐一排查函数跳转与数据结构；
• 编译器优化与控制流变换常导致反编译出的伪代码丢失类型和传参；
• 理解算法后，仍需工程师手动编写高层语言代码，并逐一设计用例比对输入输出。

目前的变化不在于逆向原理本身被颠覆，而在于大语言模型开始与分析工具协同，使原本需要人工在反编译器、编辑器与测试环境之间反复跳转的调查流程实现了部分自动化。既有逆向工具负责提取底层指令、符号与数据，Agent 则在此基础上提出后续查询、尝试推断代码意图、生成重写实现并协助验证。这种衔接使部分调查与重写工作可以交给 Agent，但这些案例还不足以量化整个行业的成本降幅。

开源工具 REA (Reverse Engineer Anything) 展示的就是这种工具连接方式：它通过模型上下文协议（MCP），把底层分析引擎（如 Hopper、Ghidra 或 JavaScript 解析器）与 Agent 直连。REA 负责根据指令检索函数、调用关系与内存数据并返回证据，由 Agent 负责理解上下文并推进实现与测试。

在 DX-Ball 游戏重构案例 中，反编译器最初给出的声像计算函数伪代码丢失了输入参数，仅显示调用了类型转换。借助 REA 检查底层指令和调用方传参，并读取对应地址的常量数据，Agent 推导出了完整的声像计算逻辑并重写为 C 语言函数。该函数通过了原版 x86 的 3,205 组行为用例对比，并重现了全部 63 个编译字节。验证覆盖的是这一个声像计算函数；完整游戏仍在重建中。

面对现代打包应用时，这种流程同样能梳理本地逻辑。在针对 Notion 桌面客户端的分析 中，Agent 利用 REA 定位到页面预加载脚本暴露的剪贴板接口，顺着进程间通信（IPC）通道追踪到主进程处理函数，理清了将文本与 HTML 写入系统剪贴板的完整路径。这一案例表明，桌面客户端中打包的本地脚本即使经过压缩，其调用关系与本地实现也更容易被梳理；但这仅限于客户端本地逻辑，并不等同于能够直接获取后端的云端服务。

在社区独立探索方面，开发者 P.E. Cooper 发帖称，他借助模型将经典游戏《使命召唤：战争世界》（WaW）的初代僵尸地图移植到了网页端，随后又展示了融入建造机制的玩法演示。这些演示展示了社区借助 AI 尝试跨平台移植与定制改造的空间。

在更长期的系统重构中，《任天堂明星大乱斗 DX》的开源匹配反编译项目提供了一个典型样本。开发者 banteg 指出，这一历时六年的工程在后期借助大模型显著加速了反编译推进。重建成可增删修改的高层代码工程之后，社区便有了继续维护、研究机制与开发模组的基础。

这种本地逻辑的可分析性，体现了 OWASP 客户端安全指南 中的基本原则：不要把核心业务秘密与安全凭据托付给客户端逻辑；只要程序被分发并运行在用户的本地设备上，其包含的本地代码和运行过程在技术上就是可以被观测和分析的。

用户得到什么，哪些软件更容易承压？

技术门槛的变化对不同角色的影响并不相同：

用户：停更、迁移和修复多了一种选择

对终端用户而言，逆向与分析门槛的降低带来了一些切实的用途：

• 数据互操作与格式解析：当专有软件的本地存储格式能被更清晰地解析时，如果外部工具能读取到足够的格式规范并完成兼容性验证，用户跨软件导出和迁移数据的阻力会相对减轻。

• 老旧与停更软件维护：在原开发商停止维护或停业后，若有社区维护者或商业支持团队愿意投入工程力量，借助逆向分析补充缺失的接口与逻辑，老软件更有可能通过打补丁或重新适配在现代操作系统上继续运行。

• 跨平台适配与针对性修复：当软件缺乏特定平台版本或存在未修复问题时，具备技术能力或愿意购买第三方支持的团队能够更直接地定位底层行为，协助完成移植或错误修复。

但这些用途能否成立，取决于是否有维护者愿意持续承担兼容测试与更新维护的工作。即便转向开源或独立替代方案，用户也需要评估后续的技术支持途径——是依赖自建维护，还是采购包含服务承诺与 SLA 的商业化支持。

本地软件：常用功能可能先遭到替代

如果一款软件的核心功能完全运行在本地、业务范围明确且容易建立测试用例，那么当外部开发者更容易理清其算法与实现细节时，它就更直接地面对功能被重写或替代的竞争风险。这类产品面临的商品化压力更为直接。

开源创意套件 ArtCraft 提供了一个更具体的现实参照。据 Futurism 采访，其联合创始人 Michael Caffrey 称团队借助 Claude 5.5 逆向重构了七款 Adobe 核心工具：由图像编辑 PhotoCraft 对应 Photoshop，矢量绘图 VectorCraft 对应 Illustrator，视频剪辑 FilmCraft 对应 Premiere Pro，照片调色 LightCraft 对应 Lightroom；另外还有处理 PDF 的 PdfCraft、制作动态特效的 EffectCraft，以及排版工具 DesignCraft。

项目官方在文档中将其定义为依据公开规范与可观察行为重新编写的“净室重实现”（Clean-room），并非获取或交出 Adobe 的原版源码；目前各工具均处于早期开发阶段，尚未证明能够在专业日常工作中完全替代原版。

熟悉的图层、时间线、工具菜单与快捷键，可能减少创作者更换软件时重新学习的负担。即使没有还原原厂源码，只要替代品能以更低成本覆盖用户的日常需求，就可能对原软件的订阅价值形成挑战。 ArtCraft 把这种竞争呈现成了具体的界面和工作流程。

面对这种压力，将关键逻辑迁移至云端是部分厂商可能会考虑的防御路径。但转向云端并非毫无代价：

• 一旦将计算转入云端，原本由用户本地承担的算力与存储成本将转嫁给厂商自己；
• 用户需要常时联网，并可能面临数据上传带来的隐私顾虑，失去对纯本地运行的掌控；
• 如果软件本身定价较低或依赖离线使用，强行云端化在成本和用户体验上都可能难以维持。

云服务：看不到源码，也能做出竞争者

云端服务同样不能高枕无忧。虽然安装包通常不包含完整的后端逻辑，但这并不意味着云端功能无法被复制。竞争对手可以通过观察客户端与服务端的输入输出交互、调用流程和前端形态，用自己的技术栈重新实现一套类似业务流程。对于业务逻辑相对简单的 SaaS，常用功能同样面临被仿制的压力。

但云端产品真正的防线在于无法直接带走的运行支撑：

• 未公开的后端实现与专有数据：复杂系统内部的调度机制、风控策略、数据管道以及长期积累的私有数据，无法直接从客户端安装包中提取；

• 真实的基础设施与运营成本：替代者即便模仿了前端与接口，依然需要建设与目标服务规模相适应的运行环境，承担服务器与运维账单；

• 用户信任与工作流惯性：企业和团队日常运转所依赖的历史数据积累、操作习惯与协同网络，无法通过单纯复制代码直接迁移。

拿到安装包之后，还缺什么？

软件本身的交付形态与架构差异，决定了它面对逆向与功能重构时的暴露程度。以下定性条件比较梳理了在不同软件形态下，外部能够获取的实现内容、需要补足的工程环节，以及无法直接从客户端带走的服务支撑：

功能能复制，用户为什么还会付钱？

在 Reddit 的讨论中，针对功能可能被 AI 快速复刻的担忧，数位开发者指出价值的重心其实不在于代码本身：

一位为实体小店开发软件的从业者评论道：客户买的不是界面和逻辑，而是“省心”。一个免费的克隆版本如果在周二出了故障，依然需要有人排查修复；克隆版可以复制功能，却不会自动完成多年历史记录的迁移、员工的重新培训，也不会自动接手工资导出失败后的求助电话。

另一位开发者也补充道：如果一个 Agent 在短时间内就能仿制出界面，说明界面本身从来不是核心壁垒。买方真正付费的是出故障时有人承担责任的确定性结果；克隆可以复制交互，但无法直接接管全天候的值班与故障响应（On-call）。

事实上，持续维护、品牌信任、业务集成与服务支持一直都是商业软件价值的关键组成部分。随着 AI 降低了编写与理解代码的成本，这些原本就存在的工程与运营要素的相对重要性变得更加明显：

1. 真实工作流与系统集成：许多企业软件的开发难点在于深入复杂的业务场景，例如与各类旧系统、异构数据库及多方接口进行联调对接。即使外部重写了核心算法，这部分具体的集成工作依然需要逐一落地。
2. 数据沉淀与迁移成本：用户的长期业务记录、配置习惯和协作网络通常沉淀在既有系统中。替换一套软件意味着承受重新清洗数据、验证业务流程与重新培训员工的实际成本与中断风险。
3. 持续交付与责任归属：任何线上系统都需要持续应对运行环境变更、安全更新与故障恢复。即使代码能够在短时间内被仿写，后续的持续迭代、可用性保障以及当系统出现异常时的排查责任，依然需要确定的组织或团队来承担。这些工作同样需要成本，替代品若想长期立足，也必须解决这些问题。

演示能跑，离可靠替代品还有多远？

快速逆向演示容易让人产生“商业软件很快都会出现免费平替”的印象。但未经长期验证的演示，与在真实生产环境中稳定运行的替代品之间，仍存在显著的工程差距。

要理解从“初步复现”到“精确可靠”的验证成本，开发者 Maurice Heumann 对一款经典第一人称射击游戏的反编译实验提供了一个参考样本。该项目独立于 REA，展现了多 Agent 协同反编译大型程序时的实际过程：

• 能运行不等于逻辑正确：在项目最初的一个月里，Agent 虽反编译了约 80% 的代码且游戏能启动并加载地图，但深入检查发现存在大量类型错误与虚构逻辑，看似连贯的代码并不符合原版语义；

• 给 AI 一个可靠的判卷老师：团队切换到原版编译器编写脚本逐函数比对字节，并通过 CI 校验验证脚本的哈希防范绕过。这套机制就像一个可靠的判卷老师：AI 每重写一个函数，检查程序就拿原版作为参照比对，不通过就继续改，通过了再接收。有了明确的通过与失败信号，较便宜的模型也能在反复修正中修到合格。据作者自述，后期多数时间采用 14 个 Luna 与 2 个 Opus 5.5 并行，表明复制门槛不只取决于最强模型，能否建立自动验收同样关键；

• 规模化推进与成果边界：引入机器码比对后经两个月排查，重构代码已覆盖原游戏 99% 的函数；以全部原函数为分母，83% 实现了编译字节匹配。这个 83% 统计的是编译结果精确匹配的函数，不能理解成“只有 83% 的功能能用”；其余函数可能指令排列等不同，但结果相同。据作者评价，这些函数语义均已正确，重构游戏具备原版全部功能且无明显故障。字节一致也会保留原版缺陷，修复与跨平台适配仍属独立工作。因部分日志丢失，作者估计消耗了约 6000 亿至 7000 亿 Tokens。团队认为工程已达到完成状态，但代码出于版权考量保持私有，并未公开源码。

这个项目提示，可靠的自动验收能帮助调用成本较低的模型承担更多重构工作。不过，该案例耗费的数月时间与巨量算力，对应的是严苛的字节级还原，普通商业替代品若仅复现核心常用功能，并不必然需要付出同等成本。因此，从特定游戏的重建推导出“软件保密壁垒正在瓦解”仍属推测，具体软件是否容易被替代，既取决于能否构建自动验收，也取决于替代者是否愿意承担长期的维护与适配成本。

“被迫开源”，到底交出了什么？

“被迫开源”是一个很有冲击力的说法，但在版权与商业逻辑上不能等同。

根据开放源代码促进会（OSI）的开源定义（OSD），“开源”并不是指外部能够看懂或重构某段代码，而是指软件的分发条款必须符合一系列明确条件，包括允许自由再分发、必须提供源码、允许修改与衍生作品，且不对任何人或应用领域施加歧视。

商业软件被逆向或功能被重写后：

1. 原软件并未自动获得开源许可：逆向本身没有带来原作者的新授权，也没有使原版二进制、专有代码和美术素材自动变成可自由传播的内容。
2. 功能相近不等于有权复制专有资产：实现类似的功能，与直接提取和复制受保护的原版代码或素材并非同一回事；即便重构出的程序能够顺利运行，也并不自动说明它享有公开发布和传播的合法权利。
3. 技术保密性的削弱改变的是竞争难度：软件并没有变成开源项目，但过去依靠机器码难以阅读所维持的实现壁垒有所松动。在商业竞争中，替代者并不需要完整恢复原软件 100% 的全部源码，只要能以可接受的成本复现用户最常用、最愿意付费的核心功能，原产品依靠单一功能实现的独占优势就会受到直接挑战。

原作者不开源，还能守住什么？

电脑里的商业软件不会因为 AI 逆向技术的进展而在一夜之间变成开源软件，原作者也不会自动交出代码的法律授权。

但在实际技术层面上，单纯依靠编译后二进制的不可读性来维持长期的实现独占，正变得越来越困难。这一变化带来的影响是多维度的：

• 对于用户：在面对老旧软件维护和私有数据导出时拥有了更多的潜在选择，但如果厂商为了保护逻辑而加速向云端收拢，用户也可能面临更多的网络依赖与本地控制权让渡；

• 对于开发者：与其焦虑代码本身是否能被推导，不如回到两个更具体的问题——用户当初究竟是因为什么选择了你的产品？而一个潜在的替代者如果要达到同等可用性，除了复现逻辑之外，还必须承担哪些无法省去的维护、集成与运营成本？