REA 版本对比：这次更新改了什么？

01. 把回归问题描述具体

“更新把导出弄坏了”留给猜测的空间太大。写清输入、操作和差异，例如：包含引号的标题，在更新前能正确导出，更新后却生成格式错误的 CSV 行。

将两个应用版本放在不同文件夹，记录版本标签和文件哈希。比较同类对象：开发源码树与生产环境的压缩代码包，不是同一种证据。

npx -y [email protected] analyze-javascript-application "/absolute/path/old/app.asar" --json > before.json
npx -y [email protected] analyze-javascript-application "/absolute/path/new/app.asar" --json > after.json

02. 对比保留的分析证据

保留完整原始 JSON 输出。版本对比流程需要带验证信息的应用分析证据；手动编辑的摘要或文件名列表不能替代它。

让已连接的智能体查看可用的 compare_application_versions schema，再按要求提供两份结果，避免猜测可能随版本变化的嵌套输入字段。CLI 也能显示相同的接口定义。

npx -y [email protected] compare-application-versions --schema

使用 REA compare_application_versions，对比 before.json 和 after.json 中的完整应用证据。先检查已安装工具的 schema。报告聚焦 CSV 导出：变化的模块、相关调用路径和未解决的匹配。不要把部分覆盖中缺失的节点解释为已删除的证明。

03. 比较功能，而非压缩后的名称

从已知的按钮、IPC 通道或格式化函数开始，在两个版本中追踪该功能并查看变更代码。压缩后的变量名常在重新构建时改变，行为却未必变化。

模块摘要可以确认内容完全相同。函数改名或代码块编号变化，本身不能证明语义变化。报告应保留未匹配或仅部分解析的区域。

• 两个版本都包含相关功能入口吗？
• 实际发生变化的是哪段源码？
• 变化的分支是否影响失败输入？
• 打包、配置或覆盖缺失能否解释差异？

04. 在两个版本中重放相同输入

使用各自独立、可丢弃的数据文件夹，避免新版应用迁移旧版的测试状态。针对相同测试内容执行完全相同的操作，保存每次运行的输出文件或聚焦的行为记录。

对于 CSV 回归，解析输出行并比较字段。换行符等字节差异可能有影响，但时间戳变化不应掩盖真正的引号错误。记录对比中采用的每一项规范化处理。

为实际观察到的精确输入创建回归测试。对比新旧输出解析后的导出字段，同时展示原始差异和任何规范化对比。区分怀疑的源码变化与实际复现的行为。

05. 写一份有用的错误报告

包含两个版本的身份、一个失败输入、精确复现步骤、实际新旧输出，以及最小相关源码差异。说明行为已经复现，还是仅根据静态代码预测。

好的对比能给出下一步行动：回归测试、兼容性绕行方案，或范围明确的替代实现。本教程介绍流程，不声称某个具名商业版本存在回归问题。