平時用一些應用時，碰到一個順手的功能，總會想給自己來一個。截張圖發給 AI，做出來的東西只是界面像，但是具體功能還是沒辦法復刻的完美。
最近在 GitHub 上看到的 REA，就能幫開發者完成這一步。
REA 全稱 Reverse Engineer Anything。Codex、Claude Code 等 Agent 可以藉助 REA 分析現成程序，追蹤某個功能的實現過程，給出有依據的解釋，再嘗試爲自己的項目寫一個類似版本。
多的不說，直接給大家演示如何逆向一個項目。
01. 項目實測
美化圖片時，總想找個能加個背景、留一點空白，最好再能調圓角和陰影的。
找了一圈發現 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 中作爲項目打開。後面的分析記錄、代碼和導出圖片，都放在這個文件夾裏，方便後續修改。
安裝 REA環境
準備好後，可以把安裝工作交給 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 –client claude_code
REA 的 Setup 會註冊 MCP 服務，並安裝匹配的工作流指令。
REA 連上 Pika
REA 的網頁分析需要連接瀏覽器的本地調試接口，用一個獨立的 Chrome 配置目錄啓動瀏覽器。
打開 PowerShell，完整複製下面這一行並回車。命令會使用獨立的瀏覽器配置打開 Pika 編輯器，供 REA 連接。
& ‘C:\Program Files\Google\Chrome\Application\chrome.exe”–remote-debugging-port=9222′”-
如果提示找不到 Chrome，讓 Codex 查出本機安裝路徑，再替換命令中的程序路徑。
打開瀏覽器之後，回到 Agent，發送：
提示詞：
使用 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：
第五輪調整陰影到 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 支持哪些分析對象，以及各自需要準備什麼。
02. 項目簡介
REA（Reverse Engineer Anything）是一套供 AI 編程助手調用的逆向分析工具。給出一個現成軟件和想研究的功能，Codex、Claude Code 等 Agent 就可以藉助 REA 查找線索，研究功能怎樣實現，再根據分析結果復刻一個出來。
REA 可以幫助 Agent 檢查相關程序、觀察操作過程，逐步找出答案。
分工上，REA 提供分析工具和依據，Agent 負責確定調查方向、解釋結果，以及編寫和測試新代碼。
除了網頁，REA 還支持多種桌面程序和 Android 安裝包。例如，分析 Electron 桌面應用時，可以檢查程序內部各部分怎樣聯繫；分析 Android 安裝包時，可以查看應用包含哪些功能組件，以及相關代碼之間的關係。不同類型的軟件需要準備不同的文件，部分還要安裝專門的分析工具。
REA 最值得關注的能力是會記錄分析對象、結果以及限制。
分析記錄可以保留在當前 MCP 會話中，繼續用於功能追蹤、版本比較，也可以導出供後續檢查。這樣，Agent 解釋某個功能時，開發者有機會回到相關代碼、地址或觀察結果，而不必只接受一段自然語言回答。
03. 挖一挖
AI 編程讓個人開發者和小團隊有了更多自己做工具的機會，REA 又把分析現成軟件的能力接進了開發流程。
如果這樣的開發方式越來越普遍，功能單一、主要依靠實現難度收費的軟件，可能會面臨更大的價格壓力。
開發者需要提供更多讓用戶留下來的理由，比如穩定的交付、與已有流程的配合，以及出了問題後持續解決問題的服務。
對用戶來說，選擇會更靈活：成熟產品合適，就繼續使用；某個具體需求遲遲得不到滿足，也可以嘗試自己做。REA 的應用價值，就體現在這些原本嫌麻煩、嫌成本高而被擱置的小需求上。
軟件開發的門檻降低之後，值得投入的工作仍然很多，尤其是理解需求、驗證結果，以及把工具長期維護好。
原文鏈接：GitHub 18 萬 Stars ，REA 要毀了應用開發行業嗎
