AI随便逆向重做软件功能,我们还在为什么付费

你喜欢一款软件中的某个功能，却未必需要它的全部服务。现在，REA这样的工具把一个新问题推到了眼前：当AI更容易理解功能、帮助开发者做出自己的版本，我们购买软件时，究竟还在为什么付钱？

10月13日，仙人甲介绍了REA。它的全名是Reverse Engineer Anything，是把软件分析工具连接到AI编程助手的开源项目。我对照了官方说明和案例，没有运行第三方软件，也没有测试所谓一键复刻。

值得关注的变化确实存在：开发者获得功能线索和可检查解释的入口变得更方便。但理解一项功能、做出相似实现，以及把它长期交付给用户，需要不同的证据。软件竞争可能因此加快，却不会只剩谁先生成代码。

01 REA增加了观察能力，没有交付万能复制机

普通的AI编程助手主要依据你提供的材料回答问题。REA则让它接触专业软件分析工具，返回有依据的线索。官方把自己的角色描述为连接二进制、应用和运行行为的统一接口。

这里的二进制，可以理解为软件编译后供电脑执行的程序文件。MCP则是一种让AI助手连接工具的接口约定。它们不意味着模型突然无所不知，只意味着助手有了更多可用来核对问题的材料。

官方列出的对象包括原生程序、JavaScript与Electron应用、.NET程序集和网站。不同对象的分析条件并不相同，部分能力需要外部专业工具。支持一种文件类型，也不等于能正确解释其中每项业务功能。

官方FAQ对交付物说得更具体：原生分析返回便于阅读的伪代码和机器指令表示，JavaScript分析恢复模块及其关系；AI助手再依据这些发现编写和测试实现。分析结果与可交付产品之间，仍有一段工作。

案例范围也能帮助校正预期。官方展示里，有游戏声音的位置计算，也有笔记应用的复制功能。这些都是范围明确的问题，不能因为一个局部功能获得了解释，就宣布整款应用的全部能力已经被复制。

REA还强调结论应带证据和限制。对普通读者，这比“什么都能做”更值得看：它依据什么作出判断，哪些部分尚未确认？一份能交代未知项的说明，比没有失败边界的演示更有用。

原文提到不到一周获得14万星标。我在10月14日读取GitHub官方接口时，看到当前累计已超过21万。但这次读取不能反推上周每天的增长，更不能把星标当成准确率；本文不采用那个增长速度结论。

02 看起来像专业软件，离替代它还有多远

另一个传播很广的例子，是ArtCraft团队推出的PhotoCraft。它的README把项目称为对Photoshop的独立重写，并声明依据公开规格与可观察行为实现。这是项目方说明，不是我们对开发过程的独立审计。

这类重写与REA不能混成同一件事。一个项目提供分析能力，另一个项目尝试交付应用；后者的存在，不能直接证明前者做到了完整复制。所谓“Adobe整套已经一比一复刻”，也需要逐项产品证据。

PhotoCraft官方的状态说明尤其重要：项目仍处于早期Alpha，也就是较早的试验版本；许多功能已有某种形式，但还不能替代Photoshop用于日常专业工作。原文的完整等效说法，与这个限定并不一致。

文档还提醒，每个菜单项接上了命令，衡量的是入口连接，而非实际行为。你能点到滤镜，不代表所有参数、图层组合和输出结果都符合预期。菜单完整，是一项进度，不是专业可用性的最终验收。

以一个明确的示意场景来说：给个人照片做一次简单调整，与接手一份复杂设计文件，是两种需求。前者能接受少量功能，后者还要保留编辑结构、字体表现和交付格式。一次成功演示无法同时回答两者。

PhotoCraft文档确实给出特定文件集合的测试结果，也列出格式处理和兼容限制。测试值得关注，但通过某批文件，不能扩大为所有客户文件都可靠。判断替代品时，应先找与自己任务相同的证据。

例如，文档说明应用重新保存PSD设计文件，不保证与原文件逐字节一致。这并不直接证明画面会出错，却提醒我们：文件能打开、画面相近、内部数据完整保留，是不同的验收问题。

这里并不是否定新工具。一个功能有限、边界清楚的早期产品，也能服务特定用户。问题在于，能满足一项轻量任务的替代方案，不该被包装成已经接住了整个专业工作流。

03 功能更容易重做，用户仍要为省心买单

如果AI确实让理解和实现某些功能的成本下降，独立开发者就更容易尝试细分需求。这是基于工具能力的方向判断，不是已经完成的市场统计，也不能据此断言所有单功能软件都会迅速退出。

举一个产品选择的示意：你只想偶尔给几张图片调整尺寸，本地小工具可能足够。若要和同事反复修改设计稿，能否继续编辑旧文件、对齐结果并可靠保存，就会成为更重要的购买理由。

用户付费的对象往往不只是一项算法，还包括少返工、少中断，以及出错后有人解决。自建工具的代码也许很快生成，但你仍要理解它、验证它，并在环境改变后维护它。这些时间应算进比较。

兼容性尤其容易在演示中被省略。界面相似，会减少学习负担；文件往返可靠，才能减少迁移风险。前者可以通过一次展示感受到，后者则要靠真实任务的反复核对，两种优势不能互相替代。

生态也不是一句空泛的“护城河”。对用户来说，它是现成模板、可用插件、同事习惯和交付对象接受的文件格式。一个新产品即使实现了核心功能，也可能仍要补齐这些连接，才适合原来的任务。

反过来，如果你的任务简单、不需要多人协作，也没有复杂历史文件，那些连接未必重要。此时，少而准确的功能、清楚的数据边界和可预期的维护，可能比一长串菜单更值得选。

这会改变产品竞争的重心，但不是让功能失去价值。开发者仍要找出具体不便，决定哪些功能该做、哪些不该做。AI能扩大候选方案，用户却只会为真正减少麻烦的结果留下来。

04 先问四个问题，再决定换不换工具

面对下一段令人惊讶的演示，先问它交付了哪一层：解释、局部实现，还是可以完成你整项任务的应用？把范围问清楚，才能避免拿一段漂亮的演示替代自己的使用判断。

再问证据对应什么任务：只是菜单存在，还是结果经过对照？测试对象是否接近你的文件和工作方式，失败情况有没有公开？没有这些信息，可以继续观察，但不必急着迁移重要工作。

第三问谁来维护，以及退出是否方便。出现问题有没有明确反馈渠道，旧文件能否保留可用副本，替代方案失效后能否回到原来的流程？这些问题，比生成第一版用了多久更接近你的实际成本。

最后问授权与数据去向。REA官方限定合法研究、教育、互操作和获授权的软件分析；工具可用，不代表任何对象都可以分析，更不代表可以忽略原产品和外部工具的许可。

隐私也不能只看“本地”二字。官方FAQ说明分析在本地进行，同时指出AI助手会接收工具结果，模型服务商有自己的数据政策。因此，本地分析并不是所有信息永不离开设备的保证。

REA带来的信号，是功能理解有了更方便的工具入口。选软件时，你可以更重视适合自己的替代方案；但只有当它在真实任务里减少返工、保住文件、有人维护，生成出来的功能才成为值得依赖的产品。