GitHub 18 万 Stars ，REA 要毁了应用开发行业吗？
|
admin
2026年10月14日 21:16
本文热度 36
|
平时用一些应用时，碰到一个顺手的功能，总会想给自己来一个。截张图发给 AI，做出来的东西只是界面像，但是具体功能还是没办法复刻的完美。
最近在 GitHub 上看到的 REA，就能帮开发者完成这一步。
REA 全称 Reverse Engineer Anything。Codex、Claude Code 等 Agent 可以借助 REA 分析现成程序，追踪某个功能的实现过程，给出有依据的解释，再尝试为自己的项目写一个类似版本。
多的不说，直接给大家演示如何逆向一个项目。
美化图片时，总想找个能加个背景、留一点空白，最好再能调圆角和阴影的。
找了一圈发现 Pika 这个软件挺合适的，能把普通截图处理成适合展示的配图。不过，4K 导出和无水印都得花钱。
如果只是做一张图就开个会员，多少有点肉疼。
我们正好用这个应用来试试 REA 能不能把我想要的功能复刻出来。
我用的是 Windows＋Codex ，还需要准备 Node.js、Chrome。
Node.js 建议选择 24 LTS，版本至少为 24.11。REA 也支持部分 Node.js 22 版本和 Node.js 26+，但不支持 Node.js 23、25。
准备一个空文件夹，在 Codex 中作为项目打开。后面的分析记录、代码和导出图片，都放在这个文件夹里，方便后续修改。
环境准备好后，可以把安装工作交给 Agent。直接将下面这段话发给 Codex：
提示词：
请在当前 Windows 环境中实际安装并配置 REA，接入当前 Codex，供后续分析 Pika 网页使用。
本条消息已授权：
安装 REA、执行 Codex 范围的官方 setup、安装匹配的工作流 Skill，
以及修复 REA 自身的启动配置。
请持续执行到完成安装和验证，不要只提交安装计划或 dry-run 结果。
执行要求：
1. 重新检查当前 Node.js、npm 和 REA 配置。
如果现有 Node.js 已受支持，直接使用。
已有可用的 REA 配置时验证并复用。
2. 使用官方命令实际应用配置：
npx.cmd -y rea-agents@latest setup --client codex --yes --json
应用前备份相关配置，保留其他 MCP、模型及 Codex 设置。
本次只使用网页分析，无需安装原生反编译引擎。
3. 检查实际写入的 REA MCP 配置、安装版本和 Skill。
确认启动命令与路径在新进程中能够使用。
若启动失败，依据实际错误修复 REA 配置并重新验证，
不要仅凭推测修改启动方式。
4. 执行 Codex 注册和 Skill 的针对性检查。
按照最终注册的启动方式启动 MCP，
完成 initialize、tools/list，
并调用至少一次无需目标文件的 REA 状态或能力查询。
进程启动或配置文件写入成功，不能单独视为验证通过。
5. 最后分别报告：
- 实际安装的版本和配置路径。
- MCP 启动及工具调用的验证结果。
- 当前 Codex 会话是否已能调用 REA。
- 是否需要我重启或重新连接 Codex。
如果当前会话无法动态加载新 MCP，
先完成能够执行的安装和独立启动验证，再说明重连步骤。
遇到系统强制审批或必须由我完成的操作时，
明确说明具体阻碍，不要报告安装成功。
如果使用 Claude Code，把上面提示词的客户端参数换成：
npx.cmd rea-agents@latest setup
REA 的 Setup 会注册 MCP 服务，并安装匹配的工作流指令。
REA 的网页分析需要连接浏览器的本地调试接口，用一个独立的 Chrome 配置目录启动浏览器。
打开 PowerShell，完整复制下面这一行并回车。命令会使用独立的浏览器配置打开 Pika 编辑器，供 REA 连接。：
& 'C:\Program Files\Google\Chrome\Application\chrome.exe''--remote-debugging-port=9222'"--user-data-dir=$env:LOCALAPPDATA\REA\PikaBrowser"'https://pika.style/templates/screenshot-editor'
如果提示找不到 Chrome，让 Codex 查出本机安装路径，再替换命令中的程序路径。
提示词：
使用 REA 连接下面的浏览器调试接口：
http://127.0.0.1:9222
列出当前页面，找到：
https://pika.style/templates/screenshot-editor
返回实际找到的页面标题、URL 和目标标识，
确认可以读取目标页面。
Codex 会找到 Pika 编辑器，检查返回的 URL，确认分析的是正确页面。
我这里需要的是 Pika 的截图美化和图片导出功能功能，所以我第一版的研究范围就定为：导入截图、修改背景、调整留白和圆角、添加阴影、导出 PNG。
我将下面的提示词发给了 Codex：
提示词：
使用 REA 研究 Pika 截图编辑器的正常可用功能。
浏览器调试地址：
http://127.0.0.1:9222
目标页面：
https://pika.style/templates/screenshot-editor
本次分析：
导入图片、切换背景、调整留白、圆角和阴影，
以及正常可用的 PNG 导出。
请分轮观察，每轮只研究一个操作。
开始观察前告诉我操作时机，我会在浏览器里完成操作。
需要查清：
1. 导入图片后，图片怎样进入预览区域。
2. 编辑参数怎样影响画面。
3. 预览采用什么渲染方式，判断依据是什么。
4. 导出时发生了什么请求或下载行为。
5. 哪些结论已经确认，哪些仍是推断。
可以检查公开页面和正常加载的资源来定位机制，
不要把原版代码、模板或图片素材复制到新项目中。
在当前工作目录新建 pika-local 文件夹，保存：
analysis.md：分析依据、观察记录和未确认部分。
behavior-spec.md：用自己的语言描述功能和交互规则。
captures：用于对照的页面截图。
本轮先完成分析和功能说明。
如果大家需要分析其他网页的功能，提示词模板是这个，提示词里面要填写好需要分析的网页地址，需要分析的功能：
提示词：
使用 REA 分析下面的网页。
浏览器调试地址：
http://127.0.0.1:9222
目标网页：
填写实际网页 URL
需要研究的功能：
填写具体功能，例如图片导出、拖动排序或本地搜索。
先列出浏览器页面，找到与目标 URL 对应的页面，
确认连接成功后再开始分析。
需要观察操作时，提前告诉我操作时机，
我会在浏览器中完成操作。
分析结果需要给出依据，
区分已观察到的事实、推断和未确认部分。
如果大家需要分析其他本机应用的功能，提示词模板换成这个，提示词里面要填写好需要分析的本机应用的实际路径（在文件资源管理器中右键文件，选择复制文件地址），需要分析的功能：
提示词：
使用 REA 分析下面的软件。
软件名称：
填写名称
目标程序的绝对路径：
填写实际路径
需要研究的功能：
填写一个具体功能。
先识别程序类型，并选择当前 REA 支持的分析方式。
检查该目标所需的依赖，说明实际使用的分析工具。
围绕指定功能查找相关实现，给出依据，
区分静态分析结论、运行时观察和未确认部分。
如果入口文件只是启动器，
继续定位与该功能相关的程序组件。
如果大家需要逆向整个应用，提示词模板换成这个，需要填入目标应用的位置、运行环境和输出目录，再交给 Agent 执行。：
提示词：
使用 REA 研究并重建下面的应用。
目标应用：
填写名称
目标位置：
填写网页 URL、浏览器调试地址，
或本机程序／应用目录的绝对路径。
目标版本：
记录实际分析的版本或网页状态。
目标是完整重建已确认范围内的功能与交互。
请持续完成分析、开发和验证，
不要把安装计划、功能介绍或静态页面当作最终交付。
第一阶段：建立应用清单
- 识别目标类型，选择适用的 REA 分析工具。
- 整理页面、模块、操作入口、输入输出和依赖。
- 建立功能矩阵，记录每项功能的分析、实现和验证状态。
- 标明当前无法访问、无法观察或资料不足的部分。
第二阶段：逐模块调查
- 追踪每个功能从入口到输出的处理过程。
- 必要时观察正常可用的运行行为。
- 保存分析依据，区分观察事实、推断和未知部分。
- 根据结果写出行为规格和对照用例。
第三阶段：开发新版本
- 先完成核心操作流程，再逐项补齐功能矩阵。
- 根据已经确认的行为独立编写代码。
- 未确认的机制可以自行设计，但必须注明。
- 云端功能使用自己的服务和数据。
- 品牌、素材和代码复用遵循对应授权与许可。
第四阶段：对照验证
- 使用相同输入、参数和操作比较两边结果。
- 在相同视口下比较界面和交互。
- 检查导出文件、保存恢复、异常输入和边界情况。
- 发现差异后修复，再执行相关回归检查。
持续维护：
功能矩阵、分析依据、行为规格、差异记录、验证结果。
最终交付可运行项目、启动说明和完成情况。
明确列出已通过的用例、尚未验证的功能和剩余差异。
只有实际完成并验证的项目，才能标为完成。
输完提示词之后，按 Agent 提示操作一遍你需要逆向的功能。
对于这次我需要逆向的功能，Codex 首先让我导入一张图片：
第二轮切换背景：
第三轮调整图片的大小，从 100 调整到 70：
第四轮调整圆角，从 16 到 0：
第五轮调整阴影到 8：
第六轮测试导出：
大家可以看到输出时是有水印的：
这整个测试过程其实就是 REA 在一步一步的学习，每个操作是如何实现的。整套操作完成后，会生成一个 REA 观察记录：
报告记录了各轮操作的参数变化、页面截图和观察期间的网络请求，还结合页面加载的脚本，梳理了图片进入预览、参数影响画面和生成 PNG 的过程。
提示词：
根据上一阶段 REA 生成的 Pika 观察记录，
在当前工作区的 pika-local 文件夹中制作一个原创截图美化工具，
名称为「配图台」。
先定位并读取上一阶段实际保存的报告。
本次报告名为 pika-research-report.md，
具体位置以当前会话中的实际输出路径为准。
同时查看报告引用的必要截图、导出样本和分析依据。
使用 Vite、TypeScript 和浏览器 Canvas。
界面自行设计，代码独立编写，
背景使用自己生成的纯色和渐变。
第一版实现：
- 选择文件、拖入图片、粘贴剪贴板图片。
- 纯色和自定义渐变背景。
- 留白、圆角、阴影、图片缩放。
- 自定义画布尺寸，保持图片比例。
- PNG 导出。
实现时：
- 根据报告中已确认的行为，编写对应功能。
- 报告没有研究到的功能，按照本工具的需求自行设计。
- 区分图片缩放、外部留白和画布尺寸，明确各控件的作用。
- 修改一项参数时，保留其他编辑参数。
- 图片处理和导出在浏览器本地完成。
- 预览与导出共用绘制逻辑，并实际检查两者的效果。
- 导出图不包含编辑控件，输出尺寸与设置的画布尺寸一致。
先完成单张图片的编辑和导出，
再补齐文件拖入、剪贴板粘贴等输入方式。
实际安装依赖、运行项目并打开页面检查。
验证图片导入、参数调整、连续编辑和 PNG 下载，
检查导出文件能否正常打开、尺寸是否正确。
修复发现的问题，再检查受影响的功能。
在实现说明中区分：
- 依据 REA 分析实现的行为。
- 自行设计的功能、参数和实现方式。
- 尚未验证的部分，以及与原版存在的差异。
在 pika-local 中保存：
- README.md：安装、启动和构建方法。
- verification.md：实际验证结果与剩余问题。
- screenshots/：实际运行的页面截图。
- samples/：实际生成的 PNG 导出样本。
完成前检查上述交付文件是否实际存在。
最终返回项目路径、启动命令和验证情况。
只有实际执行并通过的检查，才能标为通过；
无法执行的检查注明原因。
最终所有我想要的功能都有：导入图片后，调整背景、留白、圆角和阴影，再导出 PNG。从实际导出样本看，渐变背景和图片搭配自然，圆角、阴影也有了预期效果，输出也没有水印。
大家的通用开发提示词我也准备好了，只需要填上 REA 观察报告的完整路径、新版本名称、想实现的功能和代码保存目录，再发给 Agent。
提示词：
根据上一阶段生成的 REA 观察报告，
开发一个满足指定功能需求的新版本。
REA 观察报告路径：
填写实际报告文件的完整路径
新版本名称：
填写名称
需要实现的功能：
填写具体功能；如果希望实现全部已分析功能，填写「报告中已确认的全部功能」
代码保存目录：
填写项目目录
请实际完成开发、运行和验证，交付可运行项目。
一、读取分析材料
- 读取指定报告，以及报告引用的必要截图、输出样本和分析依据。
- 根据实际文件读取材料，不假设报告必须叫某个固定名称。
- 提取需要实现的功能、输入输出、操作顺序、状态变化和关键参数。
- 区分运行观察、静态分析、推断和未确认部分。
- 将上述内容整理为开发要求和验收清单，保存到项目目录。
二、开发新版本
- 根据目标应用类型、功能需求和当前环境选择合适的技术方案，
简要说明选择后继续实施。
- 界面自行设计，代码独立编写，使用新版本名称。
- 依据报告中已确认的行为实现对应功能。
- 未确认的细节按新版本需求自行设计，并记录设计选择。
- 涉及服务端能力时，明确所需服务与数据来源；
当前材料不足以还原的部分注明。
- 先完成一条从输入到输出的核心流程，
再逐项补齐指定范围内的功能。
- 保留目录中与本任务无关的文件。
三、实际运行与验证
- 安装必要依赖，构建并运行项目。
- 按验收清单检查核心功能、连续操作、异常输入和实际输出。
- 有原版素材和结果时，使用相同输入、参数和操作进行对照。
- 缺少原始素材时，可以使用新的共同测试输入，并记录差异。
- 检查实际生成的文件、保存结果或接口响应，
不能只根据页面显示或构建成功判断功能完成。
- 修复发现的问题，再检查受影响的功能。
四、保存交付材料
在项目目录中保存：
- README.md：环境要求、安装与启动方法、功能说明。
- verification.md：实际验证结果、剩余问题和与原版的差异。
- 适用的运行截图、日志和实际输出样本。
实现说明中分别列出：
- 依据 REA 分析实现的行为。
- 自行设计的功能和实现方式。
- 尚未确认或尚未验证的部分。
完成前检查代码和交付文件是否实际存在。
最终返回项目路径、启动命令、已完成的功能和验证情况。
遇到确实需要我补充的信息时，说明具体缺口，
继续完成不依赖该信息的部分。
只有实际执行并通过的检查，才能标为通过。
看了整个流程，大家对一 REA 在开发过程中的作用应该也清楚了：帮助 Agent 查清原版功能的运行方式，然后复刻一个一模一样的出来。
但是想把这整个流程用到自己需要的应用上，还要先了解 REA 支持哪些分析对象，以及各自需要准备什么。
REA（Reverse Engineer Anything）是一套供 AI 编程助手调用的逆向分析工具。给出一个现成软件和想研究的功能，Codex、Claude Code 等 Agent 就可以借助 REA 查找线索，研究功能怎样实现，再根据分析结果复刻一个出来。
REA 可以帮助 Agent 检查相关程序、观察操作过程，逐步找出答案。
分工上，REA 提供分析工具和依据，Agent 负责确定调查方向、解释结果，以及编写和测试新代码。
除了网页，REA 还支持多种桌面程序和 Android 安装包。例如，分析 Electron 桌面应用时，可以检查程序内部各部分怎样联系；分析 Android 安装包时，可以查看应用包含哪些功能组件，以及相关代码之间的关系。不同类型的软件需要准备不同的文件，部分还要安装专门的分析工具。
REA 最值得关注的能力是会记录分析对象、结果以及限制。
分析记录可以保留在当前 MCP 会话中，继续用于功能追踪、版本比较，也可以导出供后续检查。这样，Agent 解释某个功能时，开发者有机会回到相关代码、地址或观察结果，而不必只接受一段自然语言回答。
AI 编程让个人开发者和小团队有了更多自己做工具的机会，REA 又把分析现成软件的能力接进了开发流程。
如果这样的开发方式越来越普遍，功能单一、主要依靠实现难度收费的软件，可能会面临更大的价格压力。
开发者需要提供更多让用户留下来的理由，比如稳定的交付、与已有流程的配合，以及出了问题后持续解决问题的服务。
对用户来说，选择会更灵活：成熟产品合适，就继续使用；某个具体需求迟迟得不到满足，也可以尝试自己做。REA 的应用价值，就体现在这些原本嫌麻烦、嫌成本高而被搁置的小需求上。
软件开发的门槛降低之后，值得投入的工作仍然很多，尤其是理解需求、验证结果，以及把工具长期维护好。
阅读原文：原文链接
该文章在 2026/10/16 13:06:32 编辑过
400 186 1886
