REA 逆向工程教學：讓 Claude Code 追查軟體功能，從證據到自己的實作
REA 把逆向工程工具接進 Claude Code、Codex 等 AI 代理。本文解析分析流程、官方支援範圍、安裝準備與證據判讀，說明如何研究軟體功能，再寫出能驗證、能維護的實作。
REA 讓 AI 代理有機會追查一項軟體功能如何運作，而不只是看著畫面猜程式怎麼寫。
你可能喜歡某個應用程式的搜尋體驗，卻不知道它如何整理資料、處理輸入，或決定哪些結果排在前面。
直接請 AI 做出相似介面，通常只能回答外觀問題，無法證明背後採用了哪種機制。
逆向工程則從可取得的程式、檔案或執行行為回推設計，再把推論與證據連起來。
REA 的價值，是讓代理更容易使用這些調查工具，並沿著找到的線索繼續追問。
適合的起點是你有權分析、範圍明確的功能，最後交付一份可核對的解釋與自己的實作。
要判斷它是否適合你的專案，先看它究竟替代理增加了什麼能力。
REA 是什麼？它把調查工具接進 AI 代理
REA 的全名是 Reverse Engineer Anything，官方將它定位為連接代理與逆向工程工具的介面。它利用 MCP，讓 Claude Code 等代理呼叫分析能力。MCP 可以理解成 AI 使用外部工具時的共同接線方式，詳見官方專案。
這個分工很重要。代理負責理解你的問題、安排調查與整理答案，分析工具則提供程式結構、呼叫關係或觀察結果，兩者不能混成同一個來源。
例如工具找到一段搜尋函式，不代表它已經證明使用者畫面會執行這段程式。代理仍須追查入口、相關資料與呼叫順序，才能把函式和功能接起來。
相同道理也適用於反編譯。反編譯是把編譯後的程式轉成較容易閱讀的表示，通常無法還原原作者的命名、註解或完整開發歷史。
所以看到一段像原始碼的輸出，應先把它當成分析材料。它能協助理解行為，卻不能直接被稱為取回了原始專案。
官方 README 也提供終端機工作方式。你可以讓代理調查，也可以由工程師自己操作工具。挑選哪一條路，應由可重現性與團隊習慣決定。
社群星數能說明什麼？
REA 的官方儲存庫有 107,706 顆星，這是 2026 年 10 月 12 日查核 GitHub 資料介面時的數字。這是當時的關注度快照，後續仍會變動，詳見GitHub 官方資料。
社群貼文提到的9萬6千顆星，可能反映更早的時間點。單看目前總數，不能證明它在某半個月增加多少，也不能推算有多少團隊已經投入正式工作。
對使用者來說，更有用的問題是你的目標格式是否支援、工具能否產生可靠證據，以及分析結果能不能被另一個人重跑。這些問題才會影響採用成本。
先選分析對象，再準備需要的工具
選對第一個目標，往往比安裝全部工具更有效率。建議從一項可描述、可觀察、輸入輸出清楚的功能開始，避免一開始就要求理解整套大型產品。
官方文件區分 JavaScript、Electron、原生程式與網站等分析路徑。不同目標需要不同工具，不能因為專案名稱有 Anything，就推定所有格式與作業系統都能完成同樣深度的調查。
JavaScript 靜態分析可以讀取提供的檔案，檢查模組、匯入與相關結構。靜態分析的意思是先看檔案本身，這一步不等於已經執行程式並觀察真實行為。
Electron 是用網頁技術製作桌面應用程式的方式。分析這類專案時，除了介面程式，還要留意前後兩側如何傳遞訊息，否則容易把畫面上的變化誤認為完整邏輯。
原生二進位分析則依賴 Hopper、Ghidra 或 IDA 等工具。這些工具的安裝、支援格式與授權各有條件，REA 不能把這些差異消除。
網站調查還可能涉及瀏覽器與網路觀察。瀏覽器能看到的請求，只揭露客戶端取得的資料，不會自動揭露企業後端的所有程式與資料庫結構。
官方安裝文件列出設定方式。開始前應確認目前版本的執行環境需求，並逐一核對你要用的分析路徑，而不是照著社群截圖假設已經準備完成。
官方設定入口怎麼使用？
目前官方文件要求 Node.js 22.19以上的22系列、24.11以上的24系列，或26以上版本，並搭配 npm。Node.js 是執行 JavaScript 工具的環境，npm 負責取得與啟動套件。先核對版本，再選擇你要串接的代理。
設定入口是以下指令。它會啟動 REA 設定流程，不是本文已替你執行的操作：
npx rea-agents@latest setup
流程會讓你檢視代理設定與相關變更，確認後才套用。完成後重新啟動或連接代理，再確認實際出現的工具，而不是只看指令是否結束。
原生分析還需要對應引擎。若只做 JavaScript 靜態分析，可以先從這條較小的路徑開始，不必為了第一個任務安裝全部引擎。
第一個目標可以怎麼縮小？
假設你要研究自己維護的筆記程式，可以把題目縮成「輸入兩個關鍵字時，結果排序如何改變」。這比「分析整個搜尋系統」更容易形成有答案的問題。
接著列出可取得的材料，例如安裝包、測試資料與可操作的畫面。缺少哪一項，就把對應結論的範圍縮小，避免讓模型用推測補上空白。
這個步驟也能避免無效分析。若功能主要由遠端服務決定，而你只有本機介面，第一輪應回答可見的請求與結果關係，不宜直接聲稱已找到伺服器的排序演算法。
範圍縮小以後，下一個問題就變得具體：代理應留下哪些材料，讓你相信它的解釋？
一份有用的分析，必須讓結論能回到證據
調查報告最重要的是讓別人查得到。每一個影響實作的結論，都應指出對應的檔案、位置或可重現的觀察，並說明哪些地方仍只是推論。
以搜尋案例來說，「它會先做文字正規化」是一個結論。支持它的材料可能是相關函式與測試輸出，兩者共同出現時，解釋才比較完整。
若只有名稱叫 normalize 的函式，還要看它處理的是文字、路徑還是其他資料。名稱有提示作用，卻不足以決定它在整個搜尋流程中的角色。
若報告說搜尋忽略大小寫，則應提供相同內容使用不同大小寫的輸入，以及對應結果。這種最小對照能讓工程師快速確認結論是否成立。
把觀察、推論與缺口分開
觀察是工具或測試直接得到的材料，例如某個輸入產生某組結果。推論則是依據多個觀察，解釋背後可能採用的規則。
兩者分開後，報告不必假裝所有問題都已解決。例如可以說排序結果與某種評分方式一致，但目前沒有足夠材料辨認權重，而不是把猜到的數字寫成確定規格。
資料缺口也應有用途。它告訴下一位工程師該補哪個檔案、設計哪個測試，或在哪個階段停止追查，避免重複花時間。
這種報告比一大段肯定的答案更能支援工作。因為讀者可以按證據強弱安排實作，也能知道哪些行為需要自行設計，哪些必須先補查。
不要把本機分析理解成資料完全不外流
官方說明分析在本機進行，指的是分析工具的執行位置。代理使用的模型如何取得工具輸出，仍要看你採用的模型服務與設定，兩件事應分別確認。
如果材料含有內部字串、檔案路徑或服務資訊，先決定哪些內容能交給代理。把工具放在自己的電腦上，不會自動替所有後續模型呼叫建立保密條件。
對團隊而言，這也會影響報告格式。需要共享的證據可以留下必要片段與識別資訊，敏感原始材料則依既有儲存規則管理，讓同事仍能回到原件查核。
從分析到實作：先寫行為規格，再讓 AI 寫程式
分析完成後，最值得交給開發代理的是一份行為規格。它描述哪些輸入應得到什麼結果，比直接要求複製整段反編譯輸出更容易維護。
假設調查確認搜尋支援前綴比對，你可以把「輸入部分名稱仍找到項目」寫成需求。至於資料索引與介面佈局，則依自己的產品規模選擇。
這樣能保留已經驗證的使用體驗，同時避免把原產品的偶然限制一併帶進來。例如舊程式一次只能處理少量資料，未必代表你的新系統也必須採用相同架構。
先做最小版本，讓差異看得見
第一版只實作一條完整路徑，例如讀入測試資料、輸入關鍵字、回傳排序結果。資料量與畫面可以簡單，但輸入到輸出的關係應可重現。
接著拿分析階段保留的案例做比較。如果結果不同，先判斷差異來自需求理解、資料內容，還是新實作本身，不要一律要求模型「更像一點」。
「更像」缺少可操作的標準。改成「在這組資料中，完全符合的項目應排在前綴符合之前」，工程師與模型才知道應修改哪個行為。
只有這條路徑站穩後，才增加模糊比對、效能優化或介面效果。每次增加一種能力，就保留原本測試，避免新功能把已確認的行為改掉。
允許自己的實作有不同設計
研究既有功能的目的，可以是理解設計取捨，而不是追求程式逐行一致。你可能只需要相同輸入輸出，卻更適合使用現有資料庫或成熟函式庫。
如果採用不同做法，應在規格中寫清楚。例如保留搜尋結果的優先順序，但改善空白處理，讓使用者知道這是刻意的產品決策。
這個界線也有助於處理權利問題。你有權取得某個程式，不必然代表能任意散布其中的內容。自己的需求與程式實作，仍應依實際授權安排。
能夠解釋差異，比宣稱一比一還原更有交付價值。因為後續維護者需要知道設計理由，才能判斷未來改動是否合理。
團隊要怎麼評估 REA 是否真的省時間？
評估應從完整工作量開始。調查花多久、人工核對花多久、實作與修正花多久，都應納入，不能只看代理第一次產生報告的速度。
如果報告很快，但工程師需要重新查完全部證據，省下的時間就可能有限。相反地，一份較短但每項結論都有定位的報告，可能更快讓人進入實作。
建議用一個團隊原本熟悉的小功能作為試點。由工程師先保留已知答案，再觀察代理能否找到關鍵路徑、提出合理缺口，並產生可用的測試規格。
這種方式不是要證明代理知道一切，而是量出它適合承擔哪些部分。若它擅長找模組，卻容易誤解排序，就把人工注意力放在排序證據上。
第一輪可以記錄哪些結果？
可以記錄查到的有效結論數、無法定位的結論數，以及需要人工推翻的結論。數量應搭配重要性解讀，漏掉核心行為比漏掉一個畫面細節更值得處理。
還可以請另一位同事只讀報告，嘗試重跑其中一個案例。若他無法找到相同材料，先改善報告與材料管理，再考慮擴大分析範圍。
版本也要留下。REA、分析工具與目標程式都可能更新，同一問題在不同版本有不同結果，記錄版本才能讓後續比較有意義。
當試點顯示報告可靠、接手容易，才適合把工具加入例行流程。若主要收穫仍是漂亮解釋，卻沒有可驗證的需求，應先補強調查方式。
REA 常見問題
REA 只能搭配 Claude Code 嗎？
官方列出 Claude Code、Codex、Cursor 等代理設定入口。能否使用還要看你目前的版本與目標工具。選擇熟悉的代理通常比為了名稱更換整套開發環境更合理。
它會把程式的原始碼全部找回來嗎？
不能把逆向分析等同完整取回原始碼。工具取得的程式表示與行為證據，仍可能缺少命名、註解與後端資訊，應用可驗證的規格承接分析結果。
新手可以直接分析大型產品嗎？
比較合理的第一步，是選一個自己有權分析的小功能，先學會看輸入輸出與證據。範圍太大時，模型產生大量細節，也未必能回答最初的問題。
分析結果可以直接拿來上線嗎？
應先完成自己的實作與測試，再依產品流程審查。分析報告回答的是原功能可能如何運作，正式上線還需要處理你的資料、效能、錯誤情況與維護需求。
把熱門專案變成可用的工作方法
REA 值得關注的地方，是把專業調查工具帶進代理的工作流程。它降低找線索與整理材料的門檻，但可靠的結果仍來自清楚的問題、可定位的證據與實作驗證。
對工程師來說，最好的起點是一項明確功能與一份能交給同事重跑的報告。當分析能轉成行為規格，熱門工具才開始變成可以累積的開發能力。
想持續追蹤 AI 科技新聞與開發工具解析，歡迎免費註冊 AI 郵報會員，訂閱後續文章。
延伸閱讀：前 Adobe 總監打造！全新 pen.dev 震撼登場：網頁一鍵逆向成畫布、AI 雙向生成前端代碼全攻略
延伸閱讀：Codex Cloud、CLI、Code Review 完整指南：OpenAI 如何重做 AI 軟體開發流程
資料來源
資料查核日期：2026年10月12日。本文的筆記搜尋流程為說明用情境，並非作者實測報告。
