ARTICLE · 1177052
REA 让 AI 开始拆解软件:从 63 字节代码到一场更大的变化
奇点档案 / ARCHIVE
最近看 REA（Reverse Engineer Anything），我一直在想一个挺实际的问题：AI 已经能够迅速写出一个功能，但如果我想弄懂别人十年前写下的那个功能，它能帮上多大忙？
一套程序的源码可能早就找不到了，开发人员换了几拨，文档和实际行为也未必一致。大家仍然依赖它，只是谁都不太愿意碰。
REA 让我感兴趣的，是它把调查的起点从“给 AI 一份需求”换成了“给 AI 一个真实运行过的程序”。它会借助专业工具追踪程序内部线索，再尝试解释功能为什么这样工作。
Replit 联合创始人兼 CEO Amjad Masad 在 X 上谈到，AI 逆向与反编译的发展可能让软件变得“事实上开源”。我觉得这个判断值得研究，但它把几件事放在了一起：看得见程序、弄得懂行为、做得出类似实现，以及造得出可靠产品，其实是四种不同的能力。
01 / REA 的新意，不在于发明逆向工程
IDA、Ghidra、Hopper 早就能帮开发者分析二进制。反编译、交叉引用、查看指令、读取内存数据，这些都不是新技术。
困难在于把它们组织成一次完整调查。比如研究某个 Electron 应用的导出功能，线索可能散在界面事件、preload、IPC、主进程与文件系统操作里。单独找到某一段代码不难，难的是确认它和问题究竟有什么关系，以及有没有遗漏另一条处理路径。
REA 通过 MCP 把分析工具交给 Agent。你给出的是一个问题，它可以根据上一步结果继续追函数、找调用方、读数据，并把发现对应到具体位置。官方 Notion 案例就是从剪贴板 API 追到 Electron 主进程的处理链。
项目提供了不少实际调查案例，最值得注意的不是界面演示，而是每一步发现是否能追到相应的指令、函数或调用关系。
这里有个容易被忽略的区别：让 AI 操作逆向工具，和让 AI 真正完成调查，并不是一回事。
前者只是把命令换成自然语言。后者需要发现信息之间的矛盾，知道什么时候应该继续追问，并且允许证据推翻先前的判断。REA 有价值的部分，就在于它试图把这种“带着问题不断取证”的过程变成 Agent 可以参与的工作流。
它当然不能代替所有逆向经验。工具提供了指令和结构，模型负责连接线索；但线索解释错了，后面也可能顺着错误走得越来越远。因此，能追溯到哪里，比回答得有多完整更重要。
02 / DX-Ball 的 63 字节，真正证明了什么？
REA 官方展示了一个老游戏 DX-Ball 的案例：重建用于计算声音左右偏移的函数。
第一次反编译得到的伪代码，几乎只剩一个 __ftol() 调用。若照着这段伪代码猜，连函数实际接收什么输入都看不出来。
Agent 接着查汇编，发现栈参数；沿调用方找到砖块的水平位置；再读取二进制中的浮点常量 1.5625 与 500.0。几个原本不相干的线索终于拼成一段可以解释的计算：
// 根据 REA 官方公开的运算关系整理int screen_pan(int x, double scale) { double pan = (double)x; pan = pan * 1.5625; pan = pan - 500.0; pan = pan * scale; return (int)pan;}
scale = 1 时，x = 320 的计算结果是零；位置往左、往右移动时，声道偏移分别朝负值和正值变化。
更值得关注的是验证方式。项目方把恢复的函数和原始 x86 函数做对照，在 0—640 的整数位置、五种缩放系数下形成 3,205 组测试，返回值均一致；再使用指定的旧版编译工具链核对，函数的 63 字节机器码匹配。
这个实验说明的事情很具体：在这个固定目标、固定函数和明确对照条件下，Agent 找到的证据支持了一个高度可信的重建结果。它不等于整个 DX-Ball 已经复原，也不意味着复杂软件都能照着这个速度拆开。
但它确实让我意识到 REA 可能带来的变化：以前逆向工程师亲手建立“猜测—取证—验证”的循环，现在 Agent 开始能够承担其中一部分高重复度的调查。
还有一个更深的前提：DX-Ball 的这个函数之所以能验证得这么漂亮，是因为原程序就在那里，输入可以控制，输出可以直接比较。不是所有软件都具备这样的条件。一个图像编辑器的“看起来差不多”，或一个企业系统的“业务上可用”，很难压缩成 3,205 个自动化断言。
03 / 从“读懂旧程序”，到“决定应该保留什么”
对我来说，比复刻一整款商业软件更值得尝试的，是把一段原本摸不清的旧逻辑重新变成可以讨论的东西。
例如，一个设备配置工具保留了十年前的工程文件格式，现在只有原程序能打开。拿到文件格式的部分规则后，新系统就可能逐步实现读取、转换和校验，而不必永远依赖那台旧机器。
但这里有一个比反编译更难的问题：程序当前的行为，未必等于它最初的设计意图。
假设一个旧软件读取异常文件时会自动截断末尾数据。REA 可以帮助调查它究竟怎样截断，却无法仅凭机器指令告诉我们：这是开发者故意保留的兼容规则，还是十几年没人修复的 bug？
如果新实现“修好了”这个问题，历史文件也许反而打不开；如果原样照搬，新的隐患又被带进来。究竟复现、修复还是提供兼容开关，需要理解使用者和业务后果。
我越来越觉得，这恰好说明 AI 逆向最值得做的不是把旧代码机械翻译成新代码，而是把观察到的行为整理成一份可以追问、可以核验、也允许人重新作决定的功能依据。
这条路线对老软件迁移、设备固件研究、协议兼容、丢失文档的内部系统，都可能比“做一个长得一样的软件”更有价值。前提是目标本身允许被研究，且有足够证据验证关键行为。
04 / ArtCraft 很有意思，但它证明了另一种难度
再看 ArtCraft / Crafting Apps。开发者借助 AI 和 Rust，做了一组面向图像、视频、PDF、矢量设计等场景的开源创意工具。
ArtCraft 当前的产品页面与应用界面见文末资料来源。
图文提示｜产品阵容更新很快，这里以项目方当前官网为准，不沿用之前只有七款应用的旧截图。
我第一次看到这些界面时，也很容易联想到 Photoshop 和 Premiere。以往开发这种工具，要先准备编辑框架、图层、时间线、文件读写、交互细节……现在 AI 至少能帮开发者把大量基础工程往前推。
但 TechRadar 的 Steve Paris 实际体验 PhotoCraft、FilmCraft 后，遇到了图片格式导入、选区与对象操作、片段修剪和音频播放等问题。对于早期项目，这些问题并不令人意外，却很能说明一个事实：功能可以做出来，工作却未必因此能够交付。
DX-Ball 里的声道函数有明确的“标准答案”；专业编辑软件却有几百种文件格式、无数历史兼容情况，以及用户多年养成的操作习惯。即便每个基础功能都能展示，组合起来也可能出现大量没被测试过的边界。
这正是我认为 AI 软件创造会出现的一种不均匀进步：有明确输入输出、能自动验证的部分，会先大幅提速；需要长时间磨合、兼容和信任的部分，仍然慢得多。
REA 和 ArtCraft 是两个独立项目，没有证据表明后者依赖前者。我把它们放在一起，是因为它们刚好从不同方向提醒我：AI 正在降低“知道怎么做”的成本，但离“做成可依赖的产品”还有距离。
05 / Replit CEO 很乐观，我更关心成本降在哪里
Replit 联合创始人兼 CEO Amjad Masad 在 X 上谈到，软件可能变得“事实上开源”。如果放到经济层面，我能理解他的兴奋：当研究已有实现的成本下降，一些过去根本不值得逆向的功能，可能终于有了重新实现的价值。
Forward Future 创办人、AI 技术创作者 Matthew Berman 在 X 上公开讨论 REA，也体现了这种探索冲动。不过，一句激动的感叹和完成可用的软件重建，中间仍有很长的距离。
我更在意其中的落差：想研究一个功能，和已经能够可靠重建它，并不是一回事。
我倒觉得，这件事对不同软件的冲击会非常不一样。
一个大量逻辑留在客户端、实现相对稳定、行为容易测量的工具，确实可能更容易被研究和重建。但一家持续运营的在线服务，真正的价值还包含服务端逻辑、长期积累的数据、业务流程、客户关系与故障处置。客户端能够被研究，并不意味着这些东西也跟着公开。
所以，“闭源还值不值钱”并没有统一答案。更可能先失去优势的，是那些仅靠实现细节不易被看懂、又缺少其他积累的功能。 反过来，稳定性、兼容性、服务质量和用户信任可能越来越重要。
另一个争议也不能跳过。Simon Willison 是 Django 联合创建者、Datasette 作者。他在 2026 年 3 月的原文中分析过 Python 库 chardet 的 AI 辅助重写争议：新实现采用不同的开源许可，原作者和维护者对其独立性提出异议。
Simon 讨论的不是 REA，而是一个更普遍的问题：当 AI 能轻易提供某种既有功能的替代实现，代码写得出来，与代码有权这样使用，是两回事。 具体是否侵犯权利要看事实和适用法律，不能靠“AI 重写了一遍”就自动得到答案。
我同样在意那些不容易出现在演示里的风险。REA 的本地工具在本机分析，但分析结果会进入所连接的 Agent；若使用云模型，敏感代码、配置和商业信息是否被送出，仍取决于具体工具配置与服务商政策。
能力扩张得很快，使用边界却未必会自动跟上。
06 / 我期待 AI 拆开更多问题，也担心它让人太快满足于答案
前特斯拉 AI 总监、Eureka Labs 创办人 Andrej Karpathy 在 2026 年的红杉资本 AI Ascent 访谈中谈到，Agentic Engineering 和随手生成原型不是同一种工作。专业工程仍需要可验证的结果、安全边界和维护能力。
他还提出过一个我觉得很适合放在 REA 这里的观察：AI 更容易在可以获得明确反馈的任务上迅速进步。 写代码可以运行测试；研究 DX-Ball 可以执行原始函数做对照。但复杂业务需求、法律边界和产品体验，并不总有一个自动裁判告诉模型“你对了”。
以前我担心的是 AI 生成的代码太多，开发者来不及看；REA 又让我想到下一层问题：当 AI 连研究、解释现有代码也越来越熟练，我们会不会连对原始证据的耐心都慢慢失去？
这不是说人必须亲自读完每一条汇编指令。恰恰相反，我很愿意把重复的查找、比对和整理交给 Agent。但当它给出一个看似完整的结论时，至少应该能回答：证据来自哪里，哪些情况没有覆盖，遇到不同结果该如何修正。
AI 让人更容易开始，也让人更容易产生“已经完成”的错觉。技术进步带来的这两种感受，我现在都有。
所以，REA 留下的并不是“闭源软件即将消失”的预言。我更期待的是：过去因为难以理解而被搁置的问题，开始有人愿意重新动手解决。
至于什么值得复现、什么应该改掉、什么不该碰，最后仍得由人作决定。
资料来源：
https://github.com/morluto/rea/blob/main/README_zh.md https://getartcraft.com/apps https://simonwillison.net/2026/Mar/5/chardet/
奇点零号｜XIYUE.00以零号之名，观测未来。
