ARTICLE · 1208645
REA火了:让AI照着软件做一个,普通人真能用起来吗?
REA火了:让AI照着软件做一个,普通人真能用起来吗?
一个文件预览器很好用，但缺了你常用的格式。一个记账工具很顺手，可你只想要其中的导出功能。 以前通常有两个选择：等作者更新，或者换一个软件。 现在多了一种念头：能不能让AI研究一下，再给我做一个？ 马佳彬最近在X上分享了用REA配合WorkBuddy制作文件浏览器的过程。案例很直观，也让“照着现成软件做一个”听起来离普通人更近了。 但先别把故事理解成：输入软件名字，等一个小时，就能省下所有订阅费。 研究清楚一个功能，和交付一个长期能用的软件，中间还有不少工作。 REA全称Reverse Engineer Anything。你可以把它理解成编程助手与软件分析工具之间的一套连接和工作流程。 你提出问题；它帮助助手取得代码、引用关系和运行观察等材料；助手再解释这些材料，尝试写出实现，并继续测试。 这与给AI一张截图说“做得一样”，有一个重要区别：截图看得到按钮，未必看得到按钮背后的规则。 同一个“导出”，可能导出当前筛选结果，也可能导出全部数据；同一个“删除”，可能进回收站，也可能直接消失。界面画对了，这些地方仍然可能全错。 REA的价值，是让助手有机会带着证据回答“它到底怎么做”。连接不同工具、保留分析依据，本身就能省事；但不能因此把它当成一个什么都懂、什么都能复原的新模型。 目标类型也有区别。静态JavaScript分析与原生程序分析需要的工具不同，不是装一个包，就把所有分析引擎和商业授权一起买齐了。 项目官网用计算器做了一个很小的演示： 为什么同样是10%，前一题不是200.1？ 因为这个示例在加法路径下，先取前一个数的10%，得到20；乘法路径则把10%换成0.1。 本篇实际在官网交互示例中分别选择两种计算，再点击百分号与等号，核对页面结果。下面是该网页的操作截图，不是本机逆向Windows计算器的记录。 
这件小事，恰好解释了为什么不能只比外观。 一个计算器可以长得很像，百分号却算成另一套规则。文件工具可以把窗口、侧栏都做出来，却在中文路径或大文件上崩掉。 所以，评价这类项目时，先找一个能明确验证的行为。按钮点下去，输入是什么，输出应该是什么，有没有反例。 当然，两道算式正确，也不能推出整个计算器已经复刻成功。它只验证了这两条路径。 REA不是一个打开网页就能替你访问整台电脑的软件。你需要能调用工具的编程助手，以及符合要求的Node.js和npm。 在终端分别检查： 官方安装页列出的运行时范围是Node.js 22.19及以上的22.x、24.11及以上的24.x，或26及以上，不要简单理解成“任何高于22的版本”。 再核对发布版： 本篇在10月17日查询npm官方源，返回6.5.0。这只证明发布版本，不证明你的助手已经接通了它。 官方入口命令是： 选择自己要用的一个助手，查看计划修改的配置路径和安装内容，再决定是否批准。完成后按提示重启或重新连接。 
安装文档特别区分了配置检查和实际连接。诊断通过后，还要在新会话里让助手列出它当前真正能调用的REA工具。不要把“包下载好了”当成“已经能分析”。 原帖用了WorkBuddy。当前文档也列出相应接入项，但本文没有完成WorkBuddy的实时连接测试，不照搬作者的耗时和积分作为你的预算。 另外，选中一个工作文件夹，不代表整个安装自动变成文件夹级隔离。看清配置作用范围；不需要的助手，不顺手一起配置。 更适合新手的起点，是自己写的程序、明确获准分析的项目，或者项目提供的练习材料。 REA的入门练习提供了一个小型Notes示例，围绕“导出笔记”追踪文件写到哪里、包含哪些字段，再检查带逗号和引号的标题会怎样输出。 这比第一天就说“给我做个Photoshop”踏实。范围小，失败在哪一步也比较容易说清。 换到自己的需求，可以这样开始： 最后一句不是装饰。要让助手知道你在研究什么，也知道不该顺手研究什么。 如果一个导出功能靠界面操作和公开说明就能看懂，也不必为了用REA，硬把所有分析工具都装一遍。 回到文件预览器这个例子。普通人真正想解决的，往往不是“拥有另一款同名软件”，而是少点几次鼠标。 可以先做一个只读版本：选定测试文件夹，查看文件名和大小，预览常见文本、图片；暂不支持的格式明确提示，不伪装成支持。 暂时去掉删除、移动、批量覆盖。也别第一版就承诺几十种格式、插件和全盘搜索。 给编程助手的下一轮要求，可以独立写成： 这是本篇设计的练习方案，不是已经完成的预览器实测。它的意义，是把“复刻一个软件”变成能逐项检查的工作。 研究结果与独立实现之间，也要核对目标软件的许可和素材权利。换个名字、重新生成代码，不会自动解决这些问题。 测试别只用一个正常文件。给它一份中文文件名、一份空文件、一个超出限制的大文件，再放一种不支持的类型。 检查能否正确提示，而不是卡住；预览后原件有没有变化；换一个文件夹、重新启动后，还能不能工作。 发现问题，保留输入、错误和修复后的结果。只有截图，没有复现步骤，很容易把“这次碰巧能打开”当成“已经完成”。 还要问：如果AI明天不在这个会话里，你能不能按启动说明把工具重新打开？依赖更新后出了问题，谁来修？ 如果维护一晚，比原软件一年的费用还贵，继续用成熟产品，并不丢人。 第一，能读到，不代表可以任意使用。 项目自己的声明明确不支持绕过许可、DRM和未授权访问，也不支持复制专有软件中受保护的代码和素材。别把“不卖、只自用”当成通行证；具体仍要核对适用规则和许可。 第二，本地分析，不等于分析结果绝不出电脑。 REA的说明提到，工具在本地分析，但结果会交给调用它的Agent，模型服务商有自己的数据政策。涉及公司代码、客户数据或带登录状态的材料，先确认是否允许进入这条处理链路。 本次只核对官方文档、发布版本和官网计算器交互，没有安装REA、更改助手配置，或分析任何商业应用。不会拿这些工作冒充“一小时复刻成功”。 我更看好这类工具带来的一个变化：想做小工具的人，可以从一句模糊的“我觉得它很好用”，走到一份有证据、能验证的功能说明。 先让AI说清一个按钮做了什么，再让它交一个你明天还用得上的工具。
REA补上的，不是另一个聊天框
一个百分号，比十张相似截图更能说明问题
200 + 10% = 220200 × 10% = 20真想试，先把入口装明白
node -vnpm -vnpm view rea-agents dist-tags.latestnpx rea-agents@latest setup第一件作品，别从复刻整款软件开始
目标是我有权分析的测试项目：……只研究“导出当前列表”这一个功能。先不要修改或运行目标程序。列出输入、输出、排序、错误处理，每项给出对应文件、位置或观察依据。把确认的事实与推测分开，未知就写未知。先交功能说明和待验证清单，等我确认。不要处理许可校验、登录绕过或保护措施。把想要的功能，改写成自己的需求
根据确认后的需求，独立实现一个只读文件预览工具。使用自己的名称、布局和素材，不搬用原程序代码。第一版只处理明确列出的文件类型。大文件设上限，超限说明原因；不支持的类型不执行、不联网解析。不修改原文件，不扫描用户主目录。交付源代码、启动说明、已支持范围、未完成项和实际测试报告。报告不能把计划中的功能写成已通过。
