REA 版本比較：這次更新改了什麼？

01. 把迴歸問題描述具體

「更新把匯出弄壞了」留給猜測的空間太大。寫清輸入、操作和差異，例如：包含引號的標題，在更新前能正確匯出，更新後卻生成格式錯誤的 CSV 行。

將兩個應用程式版本放在不同資料夾，紀錄版本標籤和檔案雜湊。比較同類物件：開發原始碼樹與正式環境的壓縮程式碼包，不是同一種證據。

npx -y rea-agents@6.4.0 analyze-javascript-application "/absolute/path/old/app.asar" --json > before.json
npx -y rea-agents@6.4.0 analyze-javascript-application "/absolute/path/new/app.asar" --json > after.json

02. 比較保留的分析證據

保留完整原始 JSON 輸出。版本比較流程需要帶驗證資訊的應用程式分析證據；手動編輯的摘要或檔名列表不能替代它。

讓已連線的 AI 代理檢視可用的 compare_application_versions schema，再按要求提供兩份結果，避免猜測可能隨版本變化的巢狀輸入欄位。CLI 也能顯示相同的介面定義。

npx -y rea-agents@6.4.0 compare-application-versions --schema

使用 REA compare_application_versions，比較 before.json 和 after.json 中的完整應用程式證據。先檢查已安裝工具的 schema。報告聚焦 CSV 匯出：變化的模組、相關呼叫路徑和未解決的匹配。不要把部分覆蓋中缺失的節點解釋為已刪除的證明。

03. 比較功能，而非壓縮後的名稱

從已知的按鈕、IPC 通道或格式化函式開始，在兩個版本中追蹤該功能並檢視變更程式碼。壓縮後的變數名常在重新構建時改變，行為卻未必變化。

模組摘要可以確認內容完全相同。函式改名或程式碼塊編號變化，本身不能證明語義變化。報告應保留未匹配或僅部分解析的區域。

• 兩個版本都包含相關功能入口嗎？
• 實際發生變化的是哪段原始碼？
• 變化的分支是否影響失敗輸入？
• 打包、設定或覆蓋缺失能否解釋差異？

04. 在兩個版本中重放相同輸入

使用各自獨立、可丟棄的資料夾，避免新版應用程式遷移舊版的測試狀態。針對相同測試內容執行完全相同的操作，儲存每次執行的輸出檔案或聚焦的行為紀錄。

對於 CSV 迴歸，解析輸出行並比較欄位。換行符等位元組差異可能有影響，但時間戳變化不應掩蓋真正的引號錯誤。紀錄比較中採用的每一項正規化處理。

為實際觀察到的精確輸入建立迴歸測試。比較新舊輸出解析後的匯出欄位，同時展示原始差異和任何正規化比較。區分懷疑的原始碼變化與實際重現的行為。

05. 寫一份有用的錯誤報告

包含兩個版本的身份、一個失敗輸入、精確重現步驟、實際新舊輸出，以及最小相關原始碼差異。說明行為已經重現，還是僅根據靜態程式碼預測。

好的比較能給出下一步行動：迴歸測試、相容性因應方案，或範圍明確的替代實作。本教學介紹流程，不聲稱某個具名商業版本存在迴歸問題。