REA 拆成 4 步:让 AI 看懂旧软件,再决定怎么改

一套旧工具还能用，却没人说得清：导出的表格为什么多一列，某个数字为什么这样算，换新系统时哪些规则必须保留。

最耗人的，常常是动手之前这段“先弄明白”。

GitHub项目REA值得关注的地方就在这里。它把软件分析工具接到Claude、Codex等AI助手上，让AI沿着一个功能找线索、讲依据，再帮助你决定怎样实现或替换。我按项目方公开案例，把这件事归纳成四步看；这不是本人实测。

从一个功能开始：明确问题、找依据、用样例核对，再决定怎样改。

第一步，只问清一个功能

先别把问题写成“分析整个软件”。

换成一句具体的话：“点下导出后，文件存在哪里？包含哪些内容？什么情况下会出错？”

问题越清楚，调查越容易落到可以检查的结果。对项目负责人来说，这已经能减少一类沟通：大家讨论的是同一个功能，而不是各自想象中的“旧系统逻辑”。

第二步，让结论带上依据

官方有个Notion桌面端案例：追踪一次复制，怎样从页面里的操作传到本地程序，再写入系统剪贴板。

值得借鉴的是追问方式：别只听“它大概这样做”，还要问“这个判断来自哪里”。

REA提供线索和位置，AI再把它们解释成人能读懂的话。看到的是哪些本地代码，就说明哪些本地行为，不能顺手推断自己已经看见云端的全部逻辑。

第三步，换个输入，看看说法对不对

官方入门教程用了一个带源码的小笔记应用：先找到导出按钮的处理路径，再检查导出文件。

接着，把笔记标题换成带逗号、引号的内容，核对结果有没有串列。这个小动作，比一大段听起来合理的解释更有说服力。

项目方公开教学示例的中文示意，不是本文实测结果。

它展示的是一种调查习惯：先作判断，再用允许的样例核对。这个教学例子也不是“找回了一个没有源码的完整工程”。

第四步，决定怎么改，再开始写

摸清局部规则后，才适合讨论：保留什么，替换什么，哪些还需要补证据。

例如，迁移一个旧工具时，先确认导出字段和异常处理；做一个自己的小应用时，先理解参考功能的行为，再按自己的需求实现。

真正值得留下的成果，可以很短：入口在哪、规则是什么、依据在哪、还有什么不确定。下一位接手的人能继续查，调查才没有白做。

对我们来说，什么时候值得用

有权研究，但只有安装包、资料又不全的旧工具，值得挑一个功能试试。

如果完整源码就在手边，直接读代码、看日志、做测试通常更直接。只是写文章、做表格、画页面，也不用为了热度专门装它。

它更像工具箱里的一件专用工具。用对场景，能帮你把“没人讲得清”变成“有依据可以讨论”。

第一次交代任务，可以用这段：

只调查这个我有权研究的软件的导出功能，先不要修改它。说明输入、输出和关键规则；每个判断给出依据，分开标注不确定项。最后给一组可以验证结果的样例。

从官方公开示例或获授权的软件开始。涉及私有材料时，还要留意：分析在本机完成，分析结果仍会交给你使用的AI模型处理。

REA原始仓库的真实页面截图：morluto/rea。

REA的名字叫Reverse Engineer Anything，但我们真正需要的，往往只是先把一个功能弄明白。

如果这篇文章对你有用，可以点一下「喜欢作者」，或转发给正在使用这些工具的朋友。