用AI复刻安卓APP到鸿蒙？我的全自动搬砖惨痛经验复盘

最近接了个有点让人头秃的任务：把一个现有的安卓APP移植到鸿蒙系统。

乍一听好像不难，毕竟现在的AI代码工具都已经进化到GPT-5.5这种级别了，我手里还有安卓项目的完整源码。唯一的问题是，当年的需求文档早就找不到了，只能硬着头皮通过代码和APP的实际运行表现去反推逻辑。

起初，我想着只要把资料喂给AI，坐等它“搬砖”就行。结果现实狠狠地给我上了一课，今天就把这段踩坑经历分享给想搞AI辅助开发的朋友们。

我最开始的思路非常直接。我在项目配置里专门写了一个AGENTS.md文件，把安卓项目的路径贴进去，同时写好了自动编译、安装到鸿蒙模拟器的脚本。我的指令非常明确：“Codex，参考这个安卓项目的XX路径，每次写完代码必须自动编译、测试一遍。”

我的工作流很简单：直接对着AI喊，“实现原APP的登录页”、“实现列表页下滑刷新”。然后看着它哐哐输出代码，我自己再进行验收。

结果问题非常多：

AI生成的糟糕UI界面

AI尝试还原UI时的惨状：Emoji代替图标，排版错乱

显然，单纯的“看代码写代码”，它抓不住精髓。

后来在ChatGPT的建议下，我决定升级战术，搞了一个复杂的编排技能，试图模拟正规军的开发流程。我设计了三个专门的子Agent，像流水线一样工作：

考古Agent：负责探索安卓APP代码仓库，并在模拟器上实际操作原APP。要求它每一步必须截图，Dump出布局XML，生成一份详细的“考古报告”给后面的兄弟。
实现Agent：只看考古Agent的报告，负责在鸿蒙端还原功能。写完后打成安装包交给下一环。
验收Agent：拿着考古Agent的报告，写Appium自动化测试脚本。它会对比每一步的截图、布局结构，如果有问题就打回给实现Agent修改。

听着是不是很专业？逻辑闭环了。

多Agent协作流程图

设计的三阶段流水线：考古、实现、验收

试了几轮后，我陷入了绝望。

虽然流程上看似严谨，但效果提升并不明显。我觉得问题出在“考古”挖得不够细，而验收标准又太宽松。于是我不断微调提示词，要求它们进行组件级的细致检查。

这下可好，副作用立竿见影：

看着那一堆生成出来的报告文件，我陷入了沉思：这不就是用高科技在搞人海战术吗？效率还不如我自己手写来得快。

这次经历让我明白，现在的AI在处理这种大规模、高精度的“黑盒移植”任务时，还是有明显的局限。

如果你也在做类似的AI辅助开发项目，我有几个避坑建议：

不要完全依赖“考古”：让AI去反推需求极其消耗Token，且容易产生理解偏差。最好还是人工先梳理出核心流程图和关键UI规范，作为“强上下文”喂给它，而不是让它自己去猜。
资产要剥离：不要让AI去“画”图标或者猜资源。提前把安卓项目里的图片资源、字符串资源提取出来，放到鸿蒙项目的对应目录，明确告诉AI：“只调取资源，不要生成Emoji”。
单元测试比端到端测试管用：用Appium做UI层面的自动化验收，Token开销太大且不稳定。不如将重点放在核心业务逻辑的单元测试上，UI部分还是由人工把把关更划算。
控制Agent的颗粒度：不要搞太长的多Agent链路。每增加一环，信息损耗就增加一分。现在的模型语境窗口虽然大了，但不是无限大，链路越长，离题越远。

虽然GPT-5.6马上要出了，大家都期待模型能力更进一步，但在等待“救世主”降临之前，还是得把AI当成“副驾驶”，而不是“代驾”。复刻这种脏活累活，还得人类把控方向盘，AI只负责踩油门。

不知道大家有没有遇到过类似的槽点？欢迎在评论区交流你的AI搞代码心得。