让Codex做一个复刻已有安卓APP到鸿蒙的项目，感觉走到歪路上了

背景

随着鸿蒙操作系统（HarmonyOS）的逐步推广，许多企业面临将现有安卓应用迁移至鸿蒙平台的需求。迁移过程中，由于原始需求文档缺失，开发者往往只能依赖现有代码和APP行为反推功能逻辑。本文作者正是这样一位开发者，尝试借助AI编程助手（GPT-5.5，推理强度设为xhigh）完成这一移植任务，但多次尝试后效果不佳，陷入“歪路”。

核心内容

作者手头有安卓项目的完整源码，但需求文档已丢失，只能通过代码和现有APP行为反推。最初的工作方式是在AGENTS.md文件中指定安卓项目路径供Codex参考，同时写好编译、安装到模拟器的脚本，要求Codex每次写完代码后必须编译、测试一遍。每次对话开始时，作者直接要求Codex“实现原APP的XX功能/XX页面”，然后观察Codex执行并自行测试。然而，作者发现Codex的实现经常丢三落四，UI样式和排版与原APP差距很大，并且喜欢用Emoji代替原APP中的图标素材。

在ChatGPT的建议下，作者设计了一个编排技能，依次启动几个子Agent：

1. 考古Agent：探索安卓APP的代码仓库，在模拟器上实际操作APP，每一步必须截图，dump出布局XML，并出一份报告给作者确认，然后交给实现Agent。
2. 实现Agent：根据考古Agent的报告开始工作，完成后build安装包交给验收Agent。
3. 验收Agent：根据考古Agent的报告，写Appium脚本进行自动测试，对比每一步的截图和布局。如有问题，再写报告反馈给实现Agent。

经过几次尝试，作者仍不满意，认为考古Agent的报告不够细致，验收Agent的检查过于宽松。于是多次修改编排技能和子Agent的提示词，要求进行组件级检查。但修改后，一次任务消耗的token和时间明显变大，几个Agent来回运转，一天能用掉30%以上的额度（作者是5x pro订阅）。最终效果提升却不明显。如今随便一次任务至少一小时起步，各种md、json文件多到让人不想看。

关键要点

• 原始需求文档缺失，作者只能通过代码和APP行为反推功能，增加了迁移难度。
• 最初的简单交互方式（直接在AGENTS.md中指定路径，要求Codex实现功能）导致UI样式、排版严重偏离原APP，且Codex习惯用Emoji替代图标素材。
• 在ChatGPT建议下，作者设计了多Agent编排流程：考古Agent（探索、截图、dump布局）→ 实现Agent（编码）→ 验收Agent（Appium自动测试对比）。
• 即使引入多Agent流程，效果仍不理想，作者认为考古Agent报告不够细、验收Agent检查过于宽松。
• 作者将检查粒度提升到组件级后，任务耗时和token消耗急剧增加，一天用掉30%以上订阅额度（5x pro），但效果提升不明显。
• 最终每次任务至少一小时，产生大量md和json文件，团队难以管理。

意义与影响

这一案例揭示了当前AI编程助手在复杂、跨平台迁移任务中的局限性。即使采用多Agent编排、自动测试验证等精良设计，AI仍难以准确还原缺少文档的既有APP的全部细节，尤其在UI样式、图标素材等视觉层面。同时，过度细化检查粒度会导致成本（token消耗、时间）急剧上升，但收益递减。对于开发者而言，该案例提示：在依赖AI进行移植时，仍需保留人工审核与关键决策，并合理设定检查粒度，避免陷入“过度优化”的陷阱。此外，它也反映出当前AI模型在理解“已有UI风格”和“精确复现”方面仍有明显短板，未来需要更强大的多模态理解和上下文记忆能力。