如何用 REA 复刻任意 App 的功能

REA 的主张用一句话就能说清：看到一个你喜欢的 App 功能，把它弄懂到二进制层面，再为自己的项目做一个同款。morluto/rea 仓库就凭这个承诺，它在 2026 年 10 月拿下了 115,000 个 GitHub star。演示视频里，Agent 能重建整个桌面 App。但真正有用的工作流要小得多、也可重复得多：从一个 App 里挑一个功能，把它的行为提取成证据，基于证据写出属于你自己的规格，在自己的技术栈里实现它，再证明你的版本行为一致。

本教程用 Claude Code、Codex 或任何支持 MCP 的 Agent，分六步走完这个循环。调查部分用的是 REA 自带的 Notes 示例，同时也会说明当你要做的功能背后有 API 时流程会有什么变化——而这正是 Apifox 接手的地方。如果你想先了解 REA 是什么、怎么走到今天，可以先看我们的 REA 解读。

AI Coding 交流群

如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。

开始之前：三条规则

重建行为，而不是代码。 REA 返回的是伪代码、模块图和调用链。把它们当成对这个功能行为的描述，然后根据这份描述自己写实现。不要把还原出来的代码、字符串、资源或 UI 直接粘进你的产品。REA 的 README 把工具限定在合法研究与重建的范围内，授权问题由你负责。动手之前先确认目标软件的许可与条款，并记录你都看过哪些内容。

一次只做一个功能。 REA 的 FAQ 建议：只给 Agent 一个本地目标和一个待调查的行为。那些真正跑通的展示（声像平移计算、剪贴板桥接、导出按钮）都是单一数据路径，而且答案可以验证。“把这个 App 重建一遍”是演示，不是方案。

从 JavaScript 或 Electron 目标开始。 静态 JavaScript 分析不需要本地引擎。原生二进制则要动用 Hopper、Ghidra 或 IDA，也更耗时。第一次尝试，挑容易的那一类。

第 1 步：安装 REA 并确认可用

你需要 Node.js 22.19 或更高版本，以及 npm。先把 MCP server 注册到你的 Agent：

npx rea-agents@latest setup

setup 会先展示它打算改动的配置、备份原始文件，只有在你确认之后才写入。重启 Agent，然后确认注册结果以及它能看到的工具：

npm install --global rea-agents
rea doctor --json
rea doctor --client claude_code --json

安装指南列出了 Codex、Cursor、Gemini CLI、Windsurf 等客户端的 ID。如果 setup 之后 Agent 看不到 REA 的工具，FAQ 给出的办法是重启或重新连接，然后为那个客户端重新运行一次 setup。

第 2 步：问一个精确的问题

REA 内置了六个引导式 MCP prompt。这件事你要用的是 investigate_feature，它接收一个功能和一个目标，把 Agent 指向正确的分析工具。如果目标是 JavaScript 或 Electron 目录，那就是 analyze_javascript_application；如果是二进制文件，则是 open_binary 以及它背后的一整套 provider 工具。你也可以不按名字来调用 prompt：只要请求中点明了一个目标和一个行为，用普通的自然语言就能生效：

Use REA on /absolute/path/to/notes-app. Find what happens when the user clicks
"Export notes": which message is sent, which process handles it, where the file
is written, and what fields it contains. Cite the files and lines.

REA 自己的首次调查指南就是用这个一模一样的问题跑的 Notes 示例。预期答案是：renderer 调用 notes.exportCsv()，preload 脚本发出一个 notes:export 消息，主进程处理它、把笔记格式化成 CSV，并把 notes.csv 写入下载目录，其中包含 id 和 title 两列。每一步都会附上文件名和行号。

你的提问也照这个方式来：点名触发点，要求给出从触发到效果的完整路径，并要求给出出处。问题含糊，得到的总结也含糊。

第 3 步：读证据，而不是读总结

REA 的结果会把观察、推断和未知项分开列出，引导式 prompt 也会要求 Agent 保持这种区分。你也该这样要求自己的 Agent：让它在写下第一行代码之前，先讲清楚它看到了什么、推断出了什么、以及有哪些无法确定。

DX-Ball 那个展示说明了为什么。反编译器给 sound-pan 函数出的第一版伪代码声称它不接收任何输入。只有指令视图才暴露出那个整型参数，也只有调用方函数才说明这个参数的含义。Agent 是靠读了三份证据、而不是一份，才拿到正确答案的。如果只看一份跳过未知项的总结，得到的函数签名就是错的。

当证据仍有缺口时，就让 Agent 使用 audit_residual_unknowns prompt。它会列出 REA 在本次会话中记录的未决问题，以及每个问题需要什么才能解决。有些对你的重建确实重要，很多则不重要，你可以明确说不要。

第 4 步：先写规格，再写代码

现在把行为翻译成一份属于你自己的规格。以 Notes 导出为例，它很短：

触发点：UI 中的一个导出操作。
效果：用户下载目录中生成一个 CSV 文件。
列：id、title。
引号规则：标题中如果包含逗号或引号，整个标题要用引号包起来，内部的每个引号都要写成两个。

最后那条就是能让重建成或败的细节。REA 的指南让你用一次预测检查来确认它：先预测一个含逗号和引号的标题会输出什么，再运行原始格式化函数做对比。凡是这类规则，都写进规格里。

如果你要做的功能背后有 API，那这份规格其实就是一份接口设计，流程也在这里发生变化。先抓一次流量（用测试账号在 DevTools 里导出一份 HAR），让 REA 用 inspect_web_network_capture 检查它，并要求给出 api-surface 视图。你会看到所有请求按 method、origin 和推断出的路径模板分组，其中会变化的 ID 位置用 {numeric} 和 {uuid} 占位符表示。这就得到了一份清单，说明原 App 的客户端需要服务端提供什么。

接下来在 Apifox 里设计你自己的 API，而不是照抄对方的。打开一个项目并进入文档模式，用你自己的资源命名和响应结构，定义功能所需的接口；抓到的流量只用来核对有没有漏掉某个字段或错误场景。我们的 HAR 导入指南介绍了如何把抓包数据作为参考导入。这里强调接口定义先行的意义在于：契约先于代码存在，Agent 和测试都照着它来做。

第 5 步：在你自己的技术栈里实现

把规格交给 Agent，而不是把 REA 的输出交给它，并要求它用你项目的语言和结构来实现：

Build the export feature described in SPEC.md in our Electron app. Use our
existing IPC naming, put the CSV formatter in src/export/csv.ts, and write unit
tests for the quoting rules in the spec. Do not reuse names or code from the
investigation.

尽量别让调查证据进入这次提问的上下文。Agent 应该是在解你的规格，而一个能看到原始代码的模型，会不自觉地向它靠拢。对于 API 驱动的功能，Agent 是照 Apifox 里的契约实现的：从接口定义生成请求代码，把客户端指向 Apifox 的 mock 服务端，这样后端还没写完，UI 就能先跑起来。

第 6 步：证明你的版本行为一致

当重建版本能通过原版同样会通过的测试时，重建才算完成。REA 对这件事有一套正式的表述：verify_reconstruction prompt 会针对保留的对比证据，评估一份有限的重建规格；而 build_reconstruction_obligation_ledger 工具会把你的证据包变成一张断言清单，每条断言都需要有负责人、测试数据和通过的校验者，账本才会显示 ready。账本文档明确说明：仅凭一条推断，任何断言都不会关闭。

落到实践中，就是三类检查：

按规格做行为测试。 DX-Ball 的重建把 3,205 组输入分别灌进原始 x86 函数和新的 C 函数，再比对结果。你的规模会小一些，但形状是一样的：把规格关心的输入枚举出来，两边都跑，再 diff。
边界场景的预测检查。 含逗号和引号的标题、空列表、写不出去的文件——Notes 指南就把最后这个当作追问。
针对 API 的契约测试。 在 Apifox 里写一个测试场景，依次调用你实现中的每个接口，并对状态码、数据模型和 UI 依赖的字段做断言。每次提交都用 Apifox CLI 跑一遍：

apidog run --access-token "$APIDOG_TOKEN" -t <scenario-id> -e <dev-env-id> -r cli,junit

这样重建就变成了一套回归测试，而这正是演示和能上线的功能之间的差距。已经在循环里跑 Agent 的团队早就在这么做；CI 该怎么搭，可以看我们的用 Codex 和 Apifox 测试搭建软件工厂一文。

这套方法在哪些地方会失效

只在运行时才出现的行为。 静态分析只能看到代码路径，看不到真实数据下的表现。REA 为此提供了浏览器和进程捕获工具，它们会以你的用户权限运行目标程序。请务必在隔离环境里操作。REA 自己的安全政策也说得很清楚：它的 provider bridge 不是沙箱。

原生目标。 Ghidra 和 Hopper 生成的伪代码在细节上经常出错，DX-Ball 的输入 bug 就是例子。要为好几轮证据阅读留出预算，并做好需要看汇编视图的准备。

UI 与素材。 你可以弄清一个功能是怎么工作的，但不能照搬它的界面、图标、文案或数据文件。像素级重建竞品界面是法律问题，REA 改变不了这一点。

版本迭代很快。 在 10 月那波爆发期，REA 九天里发了七个小版本，而小版本同样可能破坏它的输出契约。在一个项目周期内，请锁定版本。

常见问题

REA 能给我原始源代码吗？ 不能。原生二进制得到的是伪代码和汇编；JavaScript 得到的是模块、模块之间的关系和源码位置。实现要你自己写，而这也正是重建版本属于你的原因。

如果功能完全是本地的，还需要 API 工具吗？ 不需要。Notes 导出全程不碰网络。只有当功能依赖服务端时，Apifox 才派上用场——而大多数 Web 和移动端功能都属于这一类。

怎么判断重建已经完成？ 当规格中的每条断言都有通过的测试，并且你选择忽略的未知项都已记录在案。

这个循环，一句话说完

装好 REA，问一个精确的问题，读证据和其中的未知项，写一份属于你的规格，在自己的技术栈里照着规格实现，再用对比行为的测试来证明。对于有 API 支撑的功能，规格活在 Apifox 里，证明则是 CI 里的一个测试场景。这个循环比那些爆款视频慢得多，但也更可能让你最终拿到一个自己说得清、守得住的功能。