REA 不是软件的末日,拿到源代码也不等于拿到生意

最近 REA（Reverse Engineer Anything）引发了不少关于软件行业的讨论。它把逆向分析工具接给 AI Agent，让 AI 可以研究一个现成的软件，分析某个功能怎样实现，再辅助开发类似的功能。

顺着这个能力往下想，很容易产生一个疑问：如果别人花了很多年做出来的软件，现在可以被 AI 分析、重做，软件公司以后还靠什么赚钱？

我觉得 REA 确实会进一步影响软件行业的生意模式，但要说这是软件的末日，我不认同。从能做出类似功能，到客户愿意付钱，再到能够长期服务好客户，中间有很多事情，拿到代码并不能替你完成。

这件事让我想起自己在 BEA 和 Oracle 工作时的一段经历。

我能看到 WebLogic 的全部源码，但做不了这门生意

当时，作为BEA国内的Backline Support Engineer，我能访问 WebLogic 的全部源代码。也就是说，今天很多人设想用 AI 逆向才能获得的那些实现信息，我已经有条件直接去看原始代码了。

但我并没有因此具备把这些源码独立商业化的能力。哪怕只从商业能力上考虑，我也做不了 BEA、Oracle 那样的生意，因为企业不会仅仅因为我能访问源码，就信任我能提供完整的服务。

可以换到客户的位置想一想：你说自己有代码，也能把程序跑起来，那我的系统出了问题，你有没有能力持续跟进？碰到你暂时解决不了的问题，背后有没有研发团队可以调动？几年之后，我需要升级、迁移，或者接入新的系统，你还在不在，能不能继续提供支持？

这些问题靠我展示几段代码，是回答不了的。

企业选择供应商，会看产品本身，也会看产品背后的组织。研发、测试、技术支持、实施服务，以及合作伙伴共同形成的能力，才让客户有理由相信，这个东西交到自己手里以后，有人能够持续把它维护下去。

我能接触到源代码，不代表这套组织能力也同时属于我。这里面的差距，我在那个时候就有很直接的感受。

拿到一套软件的代码，距离做成这套软件的生意，还差着一整套让客户放心使用它的能力。 今天讨论 AI 逆向，我觉得首先应该把这件事想清楚。

企业要解决的，是怎样把软件用好

我们平时看到的软件演示，往往是输入一些东西，点几个按钮，出来一个结果。只看这一段，确实很容易觉得，只要把功能做得差不多，就可以替代原来的产品。

但软件行业里，有很大一块生意是面向企业的。企业的软件要进入真实业务环境，和已有系统、数据、流程以及使用它的人一起工作。交付一个能演示的功能，只覆盖了其中一部分。

比如一套软件在测试环境里运行正常，到了客户那里，需要连接已有的数据库、身份系统和其他业务系统。历史数据怎么迁移，原来的权限怎么对应，哪些流程要调整，都得有人一起解决。即使这些事情做完了，员工不会用、不愿意用，或者各个部门对流程的理解不一样，软件也未必能产生预期的价值。

上线以后，事情还会继续发生。业务量变了，性能要调整；依赖的系统升级了，兼容性要验证；发现了漏洞，要评估影响、安排修复。客户需要的，是这些问题出现时，供应商有能力响应，并且持续把事情推进下去。

因此，我说企业软件的核心包括服务体系，并不只是说有人接电话、回工单。它还包括产品选型、方案设计、实施集成、培训、运行维护，以及后续的升级和持续改进。有些由原厂承担，有些由合作伙伴完成，但总得有人把它们组织起来。

信任也落在这些具体事情上。客户看的是你有没有做成过类似的项目，有没有稳定的团队，出了问题能不能找到明确的负责人，以及过去承诺的事情有没有兑现。公司名气可以帮助建立最初的信任，后面的合作还是得靠交付。

当然，服务不能替代产品质量。一套不稳定的软件，不会因为配了很多服务人员就变成好产品。好的工程能力，反而可以减少实施和维护中的麻烦。只是从客户的角度，产品和服务需要共同支撑业务，单独证明一个功能可以运行，还远远不够。

开源软件早就把这个问题摆在面前了

如果源码一旦可以获得，软件生意就无法继续，那开源软件的商业模式早就应该不存在了。

很多开源项目的代码，大家本来就可以获取、研究，也可以在许可证允许的范围内使用和修改。但企业仍然愿意购买相关的商业订阅、托管和技术服务，这个现象已经存在很多年。

以 Red Hat 为例，它在官方订阅说明里列出的价值，包括面向生产环境的软件、生命周期管理、兼容性、补丁和更新，以及技术支持和专家资源。客户付费买到的内容，明显超出了下载一份代码。

企业当然可以选择自己组建团队，把这些事情做起来。但自己做也有成本，需要招聘、培训、积累经验，还得让这支团队长期存在。对一些企业来说，向专业供应商付费，是比全部自己承担更合适的选择。

一个版本发布以后，谁来维护？依赖的组件出了问题，谁来判断是否影响业务？多个产品放在一起使用时，谁来验证兼容性？这些工作不会因为代码公开了就自动完成。

企业愿意付的钱里，有相当一部分，是为了减少自己把软件用好、长期维护好的成本和不确定性。 这也解释了为什么同样围绕一个开源项目，不同公司能够做出的生意差别很大。代码的可获得性相近，服务能力、客户关系和履约记录却可以相差很远。

开源商业模式也不只有技术支持，还可以包括托管服务、企业功能和其他产品能力。但无论采取什么形式，都需要说明自己持续提供了什么价值。仅仅拥有一份别人也能拿到的代码，显然不足以回答这个问题。

所以，用开源软件作参照，反而能帮助我们看清 AI 逆向的影响。即使以后理解和重做某些功能变得更容易，帮助企业把软件用好这件事，仍然有人需要做，也仍然需要有人为此付出成本。

REA 会改变软件公司凭什么收费

我不认同软件末日论，但这也不意味着原来的软件公司可以高枕无忧。

如果一家公司的优势，主要来自某个功能难以实现、别人不知道内部怎么做，那么 AI 辅助逆向和 AI 编程能力的进步，确实可能削弱这部分优势。类似功能更容易出现以后，客户会有更多选择，也会重新判断原来的价格是否合理。

尤其是那些功能相对独立、容易验证、替换成本不高的工具，受到的影响可能更直接。对深度进入企业业务的系统，替代还需要解决迁移、集成、稳定性和后续维护。功能复现得快，不代表整套替换过程也能同样快。

这里还有一点容易被忽略：服务体系本身也会被 AI 改变。

过去需要很多人完成的排查、文档整理、配置检查和部分实施工作，以后可能由更小的团队借助 AI 完成。如果新公司既能做出合适的产品，又能以更低的成本提供可靠服务，它就有机会逐步建立客户信任。原来的大厂不能因为自己过去拥有完整服务体系，就认为这种优势会永远保持下去。

因此，对软件公司来说，真正需要重新回答的是：客户为什么还要向你付这笔钱？你帮助他节省了多少工作，降低了哪些风险，解决了什么他自己不愿意或者不擅长解决的问题？如果这些价值依然存在，收费就有基础；如果过去的价格主要依靠实现难度或者信息不透明来支撑，压力就会越来越大。

这个变化可能让一些功能更便宜，让一些原来的收入受到挤压，也可能让新的服务商有机会进入市场。它对生意模式的影响会很实际，但企业对可靠软件、专业服务和持续支持的需求，并没有因此消失。

回到我在 BEA 和 Oracle 的经历：当时我能看到 WebLogic 的全部源码，也不能因此独立做成那门生意。今天即使 AI 能帮助我更快理解代码、实现功能，我仍然需要回答客户后面那些关于交付、维护和持续支持的问题。

在今天 AI 能力越来越强的时候，就算没有 REA，软件的生产成本因为 AI 的存在也越来越低。所以软件服务行业更重要的就是要回到服务本身，需要在企业服务中真正证明自己给企业带来企业愿意付费的价值。无论是 FDE，还是交付结果，都是在这方面的一种新的形式探索，我自己也正在这方面进行实践。