ARTICLE · 1178529
REA 火了:当 AI 开始读懂软件,SaaS 会消亡吗?
REA 火了:当 AI 开始读懂软件,SaaS 会消亡吗?杨同学 发自 灵境胡同 最近，开源项目 REA 把一个问题推到了很多人面前：如果 AI 不仅会写软件，还能研究别人已经做好的软件，软件公司以后靠什么收费？ 这个问题值得讨论。但在谈 SaaS 的命运之前，我们得先拆掉一个误解：看懂一个功能、重写一个功能、替代一家软件公司，是三件不同的事。 REA 的价值，恰好藏在这三件事之间。 
01｜REA 是什么？先把“逆向工程”说清楚 01 做软件时，我们通常从需求开始，写代码，再得到能运行的程序。这是正向开发。 逆向工程则从成品出发：观察它怎么运行，检查它留下的文件，研究内部结构，逐步回答“它为什么会这样工作”。 想象你手里有一只钟，却没有设计图。你可以看指针如何走，也可以拆开外壳，研究齿轮怎样咬合。你最终可能画出结构图，甚至做出另一只能走时的钟。但这不意味着你找回了原设计师的全部图纸。 软件也是如此。逆向工程可以研究程序行为、文件格式、通信方式和机器指令。反编译只是其中一种手段。 编译后的程序可能已经丢掉变量名、注释和部分结构信息；反编译得到的“像源码的东西”，通常是工具推导出的伪代码，不能直接当成原始源码。不同的源码写法还可能生成相近的机器指令，因此通常无法唯一反推出原来的写法。 REA 的全称是 Reverse Engineer Anything。它是一个开源工具项目，把 AI 智能体接到软件分析能力上，让智能体依据证据调查目标。它不是新的大模型；名字里的 Anything 也不代表对任何软件都能无条件、完整还原。[1] 
02｜为什么是现在？变化发生在“调查成本”上 02 逆向工程并不新。过去的难点，是人要反复在工具之间切换：找字符串，定位函数，跟踪调用，读指令，做实验，再把零散线索串起来。 为什么 REA 这类项目现在更容易被关注？下面是基于其架构的分析 第一，AI 的能力可以用在调查里。代码理解、解释和生成，除了帮助“从零写程序”，也能帮助阅读陌生程序、整理假设和编写验证用例。具体效果仍取决于模型与任务。 第二，智能体把一问一答变成了连续工作。第一次结果不够，就查调用者；变量的含义不清楚，就检查输入；发现矛盾，就回到原始证据。调查天然适合这种反复追问的方式。 第三，统一的工具接口让连接更容易。MCP 可以理解为 AI 应用与工具之间的一套通信约定：应用发现工具、请求执行，再接收结果。它本身不负责反编译，却让模型能够调用外部分析能力。[2] 这几个条件结合起来，带来的变化是：专家反复寻找和整理线索的部分工作，可以由智能体协助组织。 需求则一直在那里：旧软件缺少文档，业务系统需要迁移，文件格式需要兼容，故障需要定位。只要理解一个陌生系统的成本下降，就有更多以前“不值得研究”的问题变得值得尝试。 因此，REA 可以被看作一个信号：AI 编程正从“根据描述写出东西”，延伸到“根据真实系统留下的证据理解东西”。 
03｜它怎样工作？把一次导出操作追到底 03 假设你要研究一个桌面笔记软件：点击“导出”之后，文件究竟在哪里生成？ 最容易犯的错，是让 AI 看一张截图，然后猜后台实现。REA 的路线是让智能体拿到可以核对的线索。 先找地图。 分析应用文件，识别模块与入口，判断这部分属于网页脚本、Electron 应用，还是原生二进制。不同目标需要不同工具。 再找入口。 从导出按钮相关的 API 或字符串入手，缩小范围，避免把整个软件都当成一道题。 然后追踪链路。 REA 的官方 Electron 教程展示了这样的路径：页面调用导出 API，经预加载层发送进程间消息，主进程接收消息，再调用 CSV 格式化和写文件逻辑。工具提供代码位置与关联，智能体据此继续阅读。[3] 这里的“进程间消息”，可以理解为软件内部几个工作部门之间传递的一张任务单。找到发单人还不够，还要找到接单人和最终执行者。 接着区分“代码可能怎样走”与“这一次实际上怎样走”。 静态分析查看文件而不运行目标；运行观察记录特定操作发生时的现象。官方浏览器教程把导出点击、一次 JSON 请求和生成 CSV 的脚本对应起来。它说明了这次操作的数据来源，却没有揭示任意服务器的内部代码。[4] 最后才是实现和测试。 根据证据解释机制，必要时写一个独立实现，再拿相同输入比较输出。一次比较通过，只能支持相应范围的结论；异常输入、错误处理和其他版本仍需另查。 
这条工作链中，原生二进制分析可以借助 Hopper、Ghidra 或 IDA 等工具；JavaScript 分析走的是不同路径。REA 的作用是连接和组织这些能力。[1] 还有一个关键细节：“没查到”不等于“不存在”。 REA 的工具契约保留分析限制与未知项，例如调用图覆盖不完整时，空结果不能证明没有调用关系。这个区别比一份流畅的 AI 总结更重要。[5] 
04｜一个真实案例：AI 为什么不能只相信伪代码 04 REA 官方的 DX-Ball 案例，研究的是一个很小的问题：打砖块时，如何根据屏幕横坐标计算声音偏左还是偏右？ 第一次反编译得到的伪代码，几乎只剩一个数值转换调用。倘若直接相信它，就会漏掉真正的运算。 调查继续查看机器指令、调用这个函数的位置，以及程序里的数值常量，才还原出主要计算关系： 声道偏移 =（横坐标 × 1.5625 − 500）× 缩放值 当缩放值为 1 时，屏幕中间的横坐标 320 对应偏移 0；左右位置则分别落到负值和正值。公式解释了现象，也能拿来做输入输出对照。 官方案例报告，这个函数通过了 3,205 个原始 x86 输入比较，并在特定历史编译条件下复现了完整函数的 63 个编译字节。[6] 这些数字证明的是该局部函数的验证结果，不能推广成“所有程序都能自动还原”。本文是对公开案例的解读，并未独立运行 REA 复测。 案例最有启发性的地方，是证据纠正了工具的不完整输出。AI 的解释可以很好听，但结论要经得起原始程序的检查。 
05｜它能解决什么实际问题？ 05 与其问“能不能逆向一切”，不如问“我现在有什么具体问题，哪些证据能回答它”。 下面是可能的应用方向，属于场景推演，并非已完成的实测：
其中最接地气的一类任务，是把“这个软件一直这样，但没人知道为什么”，变成“这里有可定位的规则、可复现的输入和可检查的输出”。 另一个官方例子是 Notion 桌面端剪贴板桥接：调查沿着页面 API、预加载包装、进程间消息和主进程，追到 Electron 的剪贴板写入。它研究的是一个具体机制，并非重建了 Notion 的全部系统。[7] 能力之外，也要认清使用边界。REA 项目将合法研究、教育、互操作和软件保存等列为用途，并明确不支持复制受保护的代码与素材、绕过许可或未经授权的访问。公开可下载，不等于可以随意复制和操作。[8] 对企业还有一个容易误读的点：分析在本地进行，不等于所有数据都留在本地。 智能体会收到工具结果；若使用云端模型，结果如何传输和处理，要看客户端配置与模型供应商政策。[1] 
06｜SaaS 会消亡吗？先算清“替代”的账 06 SaaS，就是由厂商通过网络持续提供的软件服务。REA 这类能力会增加部分软件的竞争压力，但不足以推出“SaaS 将消亡”。下面讨论的是可能的商业变化，不是确定的行业预言。 要判断影响，先问三个问题： 功能重写成本下降了吗？ 对规则简单、客户端可观察、测试容易的功能，理解和重新实现可能变得更便宜。主要靠一组常见功能维持溢价的产品，会面对更强的替代压力。 客户替换系统的总成本下降了吗？ 这包含迁移数据、重新配置权限、打通其他系统、培训用户，以及处理迁移失败。代码写出来，只是其中一项。 长期交付的成本下降了吗？ 软件上线后仍要应对故障、版本变化、性能问题和客户需求。AI 可以帮助其中的工作，但演示成功不能替代持续运行。接口变更和原软件升级还可能带来适配工作，自行维护的成本可能抵消初次重建的节省。 省掉订阅费，不等于省掉软件的总成本。 设想一家企业要换掉审批系统。新的页面可以很快搭起来，困难却在于：历史审批记录是否完整？权限能否对上？与财务系统的连接是否可靠？出错时谁负责恢复？这些问题不会因为“看懂了导出按钮”就自动消失。 
还有一条技术边界：浏览器和本地客户端能暴露部分行为与实现，但隐藏的服务端算法、数据库和运营系统，并不会因此自动落到你的电脑上。可以观察接口表现，再尝试重建类似行为；这与拿到服务端源码仍有距离。 未来可能同时出现三种变化：简单功能更难卖高价；软件厂商更强调数据、集成和可靠服务；智能体承接一部分交互入口，背后的云端服务继续工作。 也会有反方向的力量：软件连接越多，维护这些连接的价值越高；可迁移性越好，客户也越容易选择真正适合自己的服务。 所以，SaaS 公司值得追问的不是“代码能不能保密”，而是：即使客户理解了我的功能，我持续提供的哪些结果，仍值得付费？ 
07｜给 AI 从业者和技术爱好者的启示 07 第一，把“回答质量”推进到“证据质量”。一个好智能体应当能交代结论来自哪里、哪些关系还没确认、怎样验证。解释越流畅，越要能追溯依据。 第二，小问题比大口号更容易带来进步。第一次实践，可以选自己写的程序或得到授权的教学样例，研究“这个文件怎么生成”“这个参数怎样影响结果”。不要一开始就要求复刻整套产品。 第三，学会设计能区分假设的实验。若怀疑一个导出操作在本地完成，就寻找相关代码和文件写入证据；若涉及网络，就研究请求与响应。拿到线索后，用边界输入去检查解释是否成立。 第四，工具返回的内容也需要辨别。被分析软件中的字符串、网页或日志可能夹带伪装成指令的文字。它们是调查对象的数据，不能因此变成让智能体执行命令的授权。REA 的契约也明确强调这一点。[5] 第五，产品设计要重视接入与持续维护。把软件做成清晰可调用的服务，提供可核对的结果和稳定接口，可能比单纯增加页面更有价值。这是从上述趋势得到的产品判断。 对技术爱好者而言，一个可行的练习闭环是：选一个有权分析的小目标 → 提一个具体问题 → 找到原始证据 → 写下解释 → 用测试检查。 你学到的将不只是使用一件工具，还有面对陌生系统时怎样建立可靠认识。 
结尾｜真正变化的，是软件被理解的方式 08 软件不必永远是一个只能使用、无法追问的黑箱。REA 展示了一条道路：让智能体借助工具，从行为出发，把规则、证据与验证连起来。 理解成本下降，会压缩某些功能的稀缺性，也会释放维护、迁移和重新设计的机会。 未来，写出一个功能的能力仍然重要；但能解释它为什么正确，并长期让它可靠地服务真实用户，会更值得珍惜。 
参考资料 09 [1] REA 项目 README：https://github.com/morluto/rea [2] MCP 官方架构说明：https://modelcontextprotocol.io/docs/learn/architecture [3] REA Electron 导出教程：https://rea.tools/guides/javascript/ [4] REA 浏览器观察教程：https://rea.tools/guides/browser/ [5] REA 工具契约与证据限制：https://github.com/morluto/rea/blob/main/docs/mcp-contracts.md [6] DX-Ball 声道计算案例：https://rea.tools/showcase/dx-ball/ [7] Notion 剪贴板桥接案例：https://rea.tools/showcase/notion/ [8] REA 项目用途声明：https://github.com/morluto/rea/blob/main/DISCLAIMER.md 
AI学习的杨同学 | 公众号 AILearnerYang
- End -
