让 AI 把航班行程搬到新 App，怎样确认一条没漏、一次没重复？
一条采集到的 X 摘录讨论了让 AI 操作手机迁移航班行程。实际尝试应先保留原记录，再用行程字段、完成清单和失败记录核对迁移结果。
怎么判断？
先列出原有行程，再逐条核对新 App 中的记录，不能只看 Agent 报告完成。采集到的 X 摘录提到作者在 Codex 中让 DeepSeek 操作手机，尝试把航旅纵横的行程迁到 Flighty；摘录在过程处截断，无法据此判断最终结果。准备尝试类似任务的人，可以先选一段自己的历史行程，保存关键字段与原记录，在目标 App 中确认信息完整且没有重复后，再决定是否继续迁移。
迁移前先明确哪些记录需要搬过去
先区分需要保留的历史行程、未来行程和已经取消的记录，并写清各自怎么处理。为选中的记录保存可核对的信息，例如航班号、日期、出发与到达地点。若原记录有时间标注或行程变更，也把这些差异列入清单。
采用自己已经获得使用权限的导出或操作方式，保留原 App 中的记录。试用阶段先确认新增内容在目标 App 中如何显示，不把清空来源数据作为迁移的一部分。这样遇到遗漏或显示差异时，仍能回到原记录逐项比较。
把已完成和需要处理的行程分开记录
每处理一条，就记录原行程、目标记录和当前结果。结果可以分为已经核对、等待确认和本次未完成，方便在手机操作被打断后接着处理。再次运行前先查看已经存在的目标记录，避免把同一条行程重复新增。
验收时从目标 App 重新打开记录，核对字段是否对应，而不是只依赖 Agent 的过程描述。如果界面没有明确显示某个字段，就将它保留为待确认；没有依据时不让模型猜测航班日期、时间或其他缺失信息。
先确认一段迁移流程再扩大处理范围
完成试用后，分别数清计划迁移、已核对和未完成的记录，并保留无法匹配的原因。需要继续处理时，以这份清单为起点；遇到目标 App 的新增要求或来源信息不完整，就先暂停相关条目，让使用者决定如何补齐。
采集摘录没有提供最终迁移数量、成功率或完整步骤，也不能证明两个 App 提供了某种正式互通接口。本文给出的是个人数据迁移的核对方法，适用于使用者能够查看原记录和目标结果的情况，不将这次讨论扩写为已经验证的产品教程。
资料链接
以下为采集记录附带的资料链接；本文依据摘要做独立分析，未逐条核验原文，也不代表本站实测。