两三年前我第一次尝试把页面迁到 Jetpack Compose 的时候心里其实挺没底的布局要改、状态要改、生命周期的处理方式也要改一个中等页面下来编码加调试往往就是一整天整个人被一堆琐碎细节磨得疲惫不堪。最近看了 Meta 工程师公开分享的用 AI 辅助迁移 Compose 项目的思路很多以前靠人肉硬顶的环节确实可以交出去了。这篇文章我会结合那套方法论再加上我自己实际踩出来的经验把整个迁移过程里最容易让人烦躁的环节拆开讲清楚给你一套可以直接抄作业的路线图。先说清楚适用对象如果你手上是一个已经在用传统 View 体系的 Android 项目计划整体或部分迁移到 Compose或者你已经在用 Compose但想引入 AI 来提升重构、翻新旧模块的效率那这篇文章基本就是为你准备的。我会尽量做到既讲清楚 AI 怎么用也讲清楚哪些地方绝对不能全信 AI保证你看完之后知道每一步该怎么落地。1. 为什么 AI 能让 Compose 迁移不再“烧心”1.1 迁移 Compose 从来不是“顺手改改”的事一个典型的 Android 界面栈通常长这样Fragment ViewBinding RecyclerView.Adapter ViewModel 各种自定义 View再加上一堆 XML 布局。一次全面迁移要动的东西远比“把 XML 换成 Kotlin 代码”多得多。拿一个中等规模的模块来说几十个 XML、十几个 Adapter、外加若干自定义控件是常规操作。你如果只是把这些文件手写翻译一遍等于用几个月时间重复一遍没有技术含量的苦力劳动。更难受的是这个过程中还容易引入隐藏故障比如 RelativeLayout 依赖关系在 Compose 里没有等价物、自定义 View 的 onMeasure 逻辑在 Compose 里需要重新建模这些问题会拖慢迁移节奏。这里我习惯把迁移拆成四个层次来看UI 描述层XML / View 体系换成 Compose UI。状态层普通可观察状态换成 StateFlow / Compose State。生命周期层Fragment 的 ViewLifecycleOwner 换成 Compose 容器相关的 LifecycleOwner。交互层回调用接口回调、事件总线等方式换成 Compose 事件传递和 Side Effect。一旦把这四层分开处理迁移就从“一次大手术”变成了“拆解成多个小操作”。Meta 分享的思路本质上也是这个方向但他们额外加了一个关键变量让 AI 参与每一层里的机械翻译工作。开发者的主要任务变成审查、校验和纠偏。这样确实能省下大量重复劳动让人把精力放在真正需要判断力的地方。1.2 Meta 的迁移困境与 AI 的切入点Meta 在 Android 这边最头疼的并不是“能不能用 Compose”而是“存量代码怎么低成本搬过去”。他们的几款核心应用都有海量历史页面这些页面可能承担着核心用户链路不能因为一次重构就直接下线。以前不少工程师宁愿在旧体系里多补一个功能也不想碰迁移这块硬骨头因为一个页面从 XML 搬到 Compose要反复确认视觉还原度、语义逻辑、埋点上报等一大堆细节。Meta 公布的 AI 辅助方案本质上是拿“代码翻译模型”去处理最基础的 XML 到 Compose 转换再用规则和编译检查把 AI 生成的结果约束在一个安全范围里。一个很关键的细节是他们不是让 AI 一次性生成整个页面而是把一个大页面切成若干个小块每次只翻译一块然后马上跑编译、跑测试、做视觉对比。这样就算 AI 出问题影响范围也被锁在一个很小的模块里不至于让整个项目处于不可用状态。另外一个值得借鉴的点是提示词约束。Meta 工程师在分享里提到他们的提示词会带上非常明确的输入输出格式比如“输入 XML 和对应 ViewModel输出可组合函数不要修改状态逻辑保持原有命名前缀”。这个约束听起来很普通但实际效果差异极大。如果没有这层约束AI 很容易把包结构、命名、依赖全部自作主张改掉最后你拿回一份“能编译但完全看不懂”的新代码代码评审阶段就能把团队拖垮。我自己试过之后最大的感受是AI 在 Compose 迁移里的价值不在于它有多聪明而在于它能不厌其烦地重复“翻译、格式化、匹配资源”这些机械化动作。真正决定迁移成败的反倒是人怎么给它设定边界、怎么验证它的输出。2. 动手迁移前先把地基打稳2.1 盘点工程现状与迁移范围很多迁移失败的项目死因不在后面而在最开始没定义清楚“迁什么、不迁什么”。我先说一个比较稳妥的盘点方法把页面按使用频率和复杂度分成三类然后再决定每一类的处理节奏。第一类是高频且简单的页面比如设置页的单个条目、用户信息展示块。这类页面结构简单、依赖少适合作为 AI 迁移的第一梯队即使出现偏差也容易发现。第二类是逻辑复杂但 UI 相对固定的页面比如订单详情、个人主页摘要。这类页面核心价值在状态和交互逻辑迁移时需要把更多精力放在状态对齐上AI 负责处理 UI 布局人负责核对状态流转。第三类是极度复杂的自定义页面比如地图轨迹展示、复杂图表、视频编辑面板。这类页面通常依赖大量自定义 View 和底层绘制能力不太适合初期就让 AI 直接生成最好先保留在旧体系里等前面两类跑顺了再逐步处理。我实操时还会用脚本统计模块之间的依赖关系。具体做法是扫描 Gradle 模块的依赖配置看看哪些模块的 UI 层和业务层耦合度最低就把它们排在迁移队列前面。耦合度极端的模块在 AI 时代也不建议硬迁因为 AI 对跨层业务的理解仍然有限强行让模型去生成复杂业务逻辑容易出偏差。2.2 建立可验证的迁移基线迁移不烧心的重要前提是你随时能回答“改完之后有没有变坏”。我推荐在动手之前先把三样基线做起来视觉基线、功能基线和性能基线。视觉基线的做法是把目标页面在不同分辨率、不同主题下的截图保存好之后 AI 生成的 Compose 页面在相同环境下重新截图做对比。这个环节麻烦归麻烦但绝对不能省。因为 Compose 默认的阴影、边距、字体渲染和传统 View 体系存在细微差异这些差异开发时肉眼不容易发现上线后却会变成用户嘴里“好像哪里不一样”。功能基线更直接把关键用户路径的 UI 测试和端到端测试跑通一遍保存测试结果。之后每一批迁移完成这些路径都要重新跑一遍。任何一条失败都要先做归因而不是盲目让 AI 去修。性能基线要记录页面首次加载耗时、滑动帧率、内存占用。Compose 的初始化开销和重组计算都是新风险点没有性能基线帮你兜底时间长了你根本说不出一次迁移到底是变好了还是变差了。2.3 选好 AI 工具并固化提示词关于 AI 工具选型我的建议是不要只依赖一个大模型。Meta 内部那套系统我们接触不到但现有的大模型和代码补全工具完全可以组成一条流水线。我常用的组合是这三种结构理解用支持代码库检索的模型先让 AI 通读整个模块的代码回答“这个页面的数据来源有哪些”这类问题。代码生成用专门的代码生成模型来写 Compose 代码把 XML 片段、ViewModel、资源文件一起作为输入丢给它。代码审查再用另一个侧重代码审查的模型对生成结果做一轮静态检查和风格检查。这种多模型组合会带来额外的好处不同模型的“偏见”会互相抵消。生成模型容易写出千篇一律的样板结构审查模型则会从规范层面挑出问题。两轮下来代码质量通常比我单靠一个模型来回调优高出不少。提示词模板是另一个关键点。我整理了一套基础模板核心要素包括输入文件的绝对路径与文件内容。目标框架版本与项目约束比如 Kotlin 版本、minSdk。明确禁止改动的东西比如数据层、网络层、业务状态。输出格式要求比如输出一个可组合函数、独立文件、导出给调用方。这套模板一旦固化下来就可以在项目里反复复用。每迁一批页面只需要把新页面的 XML 和 ViewModel 填进模板剩下的交给 AI。3. 用 AI 拆解和转换 UI 层3.1 XML 布局翻译成 Compose 的标准流程XML 布局里LinearLayout、FrameLayout、RelativeLayout 三类容器占了绝大多数。AI 翻译时最容易出的问题是它喜欢把布局层级原封不动搬到 Compose 里。比如一个可以合并成 Column 的多层嵌套 FrameLayoutAI 直接照搬导致重组范围无谓扩大性能反而比原来更差。所以我会在让 AI 干活之前明确要求它先做一步“结构简化”把没有业务含义的中间容器合并把只有装饰作用的层级去掉用 Modifier 代替布局嵌套。这是 AI 能做但需要明确指示的一项优化你不说它默认不做。实际操作中我建议让 AI 分两步输出第一步输出“翻译版”也就是和 XML 结构一一对应的 Compose 代码第二步输出“优化版”在翻译版基础上做层级合并和 Modifier 改造。你只需要人工审查优化版对比起来非常清爽。不要让 AI 直接输出最终版否则它很可能会跳步骤甚至连某些资源引用都漏掉。3.2 状态从 View 体系搬到 Compose 的关键点UI 层翻译完之后下一步是状态。传统 View 体系里我们习惯用 LiveData 或者直接把 Activity / Fragment 作为状态持有者Compose 里更推荐把状态提升到 ViewModel并用 StateFlow 暴露给界面。AI 在这里能帮的忙是读取整个页面的数据流自动生成一个基于 StateFlow 的 ViewModel 状态容器。这个环节有几个坑特别典型。第一AI 经常自作主张地把 val 变量改成 var然后把所有字段都包装成 MutableStateFlow。这在编译上没问题但会让状态管理变得不可控因为任何地方都能改状态违背了单向数据流原则。我会在提示词和人工审查里同时加两重约束。第二事件处理容易出错。传统 View 里可能有 interface Listener或者用 LiveData 传递一次性事件迁移到 Compose 之后一次性事件应该用 Channel 或者 StateFlow 加事件标志。AI 往往直接照搬接口回调把它转成一个普通函数调用这在组合函数里容易引发状态不一致。第三Compose 的重组模型要求“读什么状态就传什么状态”。如果你把一整个对象都传给了可组合函数那么任何字段变化都会触发不必要的大范围重组。AI 生成的代码经常忽略这一点所以我一般会让模型针对每个状态对象额外生成一组用于拆包的小函数确保各字段按需读取。3.3 可组合函数怎么拆分才不影响后续维护另一个容易被忽略的问题是函数粒度。旧体系里的一个页面类如果迁移时只是简单翻译成一个巨大的可组合函数虽然能跑但后续维护就是给自己埋雷。我习惯让 AI 按照“一个职责一块 UI”的标准把大函数拆开。比如一个订单详情页拆成订单信息区、物流卡片区、操作按钮区、底部推荐区每个区域对应一个独立的可组合函数。这样有几个明显的好处单块预览调试方便状态更新范围变小后续修改只动某个区域也不容易影响其他区域。可组合函数拆分之后还需要注意参数设计。我建议尽量使用“数据对象 回调函数”这种形式而不是“一堆零散参数 内部创建 ViewModel”。因为 Compose 函数要符合可复用原则如果每个函数都内部 new 一个 ViewModel测试时就没有解耦手段代码也会越来越难读。4. 阶段式迁移的实操细节4.1 按模块分批迁移批次怎么划Meta 的方法给了一个挺重要的启示永远不要让某一版迁移一次性合并进主干。他们的做法是按页面划分迁移批次每个批次单独提交、单独测试、单独发布。这种方式看似拖慢节奏实际上保证了任何时候仓库主干都是可发布的回归风险大大降低。我在团队里采用的批次划分更细一点第一批选取 5 到 8 个低复杂度、低耦合的页面跑通完整流程。这个阶段的目的是磨合 AI 提示词模板和测试流程不在于迁移数量。第二批选择中等复杂度的列表页和表单页加入状态容器迁移把 ViewModel 和 Compose 的配合模式确定下来。第三批处理需要自定义绘制、复杂动画的页面。此时前两批积累的模式已经比较成熟AI 提示词也更加稳定即使遇到难题也能靠已有经验快速排查。每一批完成的标准不是“能编译”而是“视觉对比通过、功能测试通过、性能不劣化”。少任何一项都别往下一批走否则问题会在后面被放大到很难收拾。4.2 生成“最小差异代码”而不是整文件重写这里说的差异代码指的是改造前后能够进行 diff 对比的代码而不是整个文件重写。AI 迁移过程中最怕的就是模型把和 UI 无关的代码也改了比如格式化变了、import 顺序换了、字符串资源被合并了。这些无谓改动会让代码 review 变成一场灾难因为你根本分不清哪些是核心变更。解决方案是约束 AI 生成“最小差异模块”。具体做法是让 AI 只输出目标可组合函数加上必要的 import 语句不要让它碰其它文件使用统一的格式化工具处理新代码确保 diff 范围可控。我还会把旧文件的 hash 值记下来迁移完成之后对比 hash一旦发现无关文件被动过先还原再退回重新生成。这里再补充一个细节迁移 Compose 代码时最好把“旧资源名到新资源名”的映射表交给 AI。比如某个颜色在旧体系叫 colorPrimary在 Compose 里可能已经被统一成 brandColor。AI 如果不知道这个映射就会保留旧名字造成不一致。映射表不长但能省掉大量后期清理工作。4.3 回归测试与性能对比的数据怎么抓回归测试方面我强烈推荐引入 Compose 自带的 UI 测试框架。Compose 的测试比传统 View 测试要自然得多可以直接通过节点查找、点击交互、断言状态不需要等待视图加载过程。AI 生成的代码在测试这块也可以“学”起来比如让它读取旧测试用例翻译成 Compose 测试版本再由人来增补边界场景。性能对比不能只看一次冷启动。Compose 的重组优化有热点效应真实用户操作路径会触发不同的重组。所以性能对比要覆盖几种典型场景快速滚动列表、表单输入触发状态变化、页面频繁进出。我会把这几个场景录制成基准脚本每次迁移一批页面后都重新跑一遍数据落后直接回滚。做性能对比时还有一个细节很多人会忽略要区分 debug 和 release。Compose 在 debug 模式下由于额外检查和实时布局工具性能会明显偏慢。如果拿 debug 包跑性能对比数据失真严重。至少要用 release 包来跑核心指标才能反映真实用户环境。5. 常见问题与避坑笔记5.1 AI 生成代码最容易犯的五个错误据我自己观察AI 生成 Compose 代码时以下五个错误出现得最频繁我按发生概率从高到低排一下第一是资源引用错误。XML 里的 dimen、drawable、color 引用AI 偶尔会用错名字或直接省掉。解决办法是让 AI 输出代码时保留所有资源引用的原始命名并通过 IDE 的 lint 做二次校验。第二是 Modifier 使用过度。AI 倾向把本来应该靠布局组合实现的效果全部堆进 Modifier.padding / Modifier.size导致样式和布局逻辑缠绕在一起后续改起来很费劲。第三是隐藏的无限重组。如果某个可组合函数把整个列表数据源作为 key 传入 LazyColumn很可能每次滑动都会触发全量重组。AI 自身很难发现这种问题需要靠性能测试才能暴露。第四是空安全处理不当。生成代码里容易出现大量 !!一旦数据缺失直接崩溃。我会在提示词里明确加一句“禁止使用非空断言所有可空字段必须提供默认值或显式处理”。第五是重复造轮子。AI 经常忽略项目里已经存在的通用组件比如项目里本身封装好了 AsyncImageAI 却会引入一个新的网络图片组件增加依赖和风险。在提示词里附上项目可复用组件列表能很大程度缓解这个问题。5.2 第三方库在 Compose 环境里的适配问题迁移过程中最容易被低估的是第三方库适配。Compose 对生态的要求更高很多旧库在 Compose 环境里不能直接使用或者需要额外的桥接层。常见的几类问题图片加载库如果带有自定义占位动画往往需要提供 Compose 版本的封装。地图、视频类 SDK 一般还是基于 View 设计需要 AndroidView 容器包一层再通过状态桥接。埋点库通常对 View 体系和 Compose 体系分别有接口需要确认当前版本是否支持 Compose 节点监听。我建议在迁移排期表上专门留出“依赖升级”的时间不要在业务迁移进行到一半时才突然发现某个库在 Compose 环境里不可用。在盘点阶段就应该把每个模块用到的依赖列出来逐个确认是否有对应的 Compose 支持或者桥接方案。如果某个第三方库在 Compose 环境下确实没有成熟方案还有一个变通思路用 AndroidView 把它包起来先用最少的代价保证页面功能可用后续再考虑替换。虽然这种方式不是最优雅的但它是迁移过程中的合法逃生通道能避免你被一个第三方库卡住整个项目。5.3 我踩过的坑和总结出的经验最后聊点实在的。我用 AI 做 Compose 迁移多次之后最大的体会是AI 再强也只能作为速度放大器不能作为判断器。它能把一个两天的工作量压到几小时但这些省出来的时间必须花在验证上而不是提前结束任务。有一个坑我印象特别深有一版迁移生成的代码所有页面看起来都正常测试也全绿结果上线后用户反馈一个表单页的输入法弹出位置不对。查了两天才发现是 AI 生成代码时把一个 ScrollState 的初始化位置搞错了导致滚动锚点异常。这类问题单靠代码审查很难发现必须结合设备实测才能暴露。所以我现在给自己定了一条规矩任何 AI 生成的迁移代码至少要在一个主流机型和一个小内存机型上跑一次完整闭环流程。因为你永远无法预判 AI 会在哪个细节里埋雷但一定能通过不断实测把风险包住。另外还有一个我自己比较受用的经验AI 迁移出来的代码一定要让人重新读一遍而且最好是让没参与这次迁移的同事来读。原因很简单参与迁移的人对代码太熟了很多问题看不出来而一个全新视角的同事往往能一眼发现命名混乱、职责不清的地方。如果你准备启动一个 Compose 迁移项目我的建议是先花一个星期搭建好提示词模板、验证流程和性能基线再让 AI 正式开始生成。这个准备工作看似慢实则是整个迁移过程中最值得的一笔投入。真正开始逐批迁移时你会发现自己只需要做审查和决策那些以前让人“烧心”的机械劳动已经不需要你亲自下场了。 
长河君 · 2026/10/25 21:09:30 · 阅读 1.2k AI辅助Jetpack Compose迁移：从XML到Compose的高效落地路线图
两三年前我第一次尝试把页面迁到 Jetpack Compose 的时候心里其实挺没底的布局要改、状态要改、生命周期的处理方式也要改一个中等页面下来编码加调试往往就是一整天整个人被一堆琐碎细节磨得疲惫不堪。最近看了 Meta 工程师公开分享的用 AI 辅助迁移 Compose 项目的思路很多以前靠人肉硬顶的环节确实可以交出去了。这篇文章我会结合那套方法论再加上我自己实际踩出来的经验把整个迁移过程里最容易让人烦躁的环节拆开讲清楚给你一套可以直接抄作业的路线图。先说清楚适用对象如果你手上是一个已经在用传统 View 体系的 Android 项目计划整体或部分迁移到 Compose或者你已经在用 Compose但想引入 AI 来提升重构、翻新旧模块的效率那这篇文章基本就是为你准备的。我会尽量做到既讲清楚 AI 怎么用也讲清楚哪些地方绝对不能全信 AI保证你看完之后知道每一步该怎么落地。1. 为什么 AI 能让 Compose 迁移不再“烧心”1.1 迁移 Compose 从来不是“顺手改改”的事一个典型的 Android 界面栈通常长这样Fragment ViewBinding RecyclerView.Adapter ViewModel 各种自定义 View再加上一堆 XML 布局。一次全面迁移要动的东西远比“把 XML 换成 Kotlin 代码”多得多。拿一个中等规模的模块来说几十个 XML、十几个 Adapter、外加若干自定义控件是常规操作。你如果只是把这些文件手写翻译一遍等于用几个月时间重复一遍没有技术含量的苦力劳动。更难受的是这个过程中还容易引入隐藏故障比如 RelativeLayout 依赖关系在 Compose 里没有等价物、自定义 View 的 onMeasure 逻辑在 Compose 里需要重新建模这些问题会拖慢迁移节奏。这里我习惯把迁移拆成四个层次来看UI 描述层XML / View 体系换成 Compose UI。状态层普通可观察状态换成 StateFlow / Compose State。生命周期层Fragment 的 ViewLifecycleOwner 换成 Compose 容器相关的 LifecycleOwner。交互层回调用接口回调、事件总线等方式换成 Compose 事件传递和 Side Effect。一旦把这四层分开处理迁移就从“一次大手术”变成了“拆解成多个小操作”。Meta 分享的思路本质上也是这个方向但他们额外加了一个关键变量让 AI 参与每一层里的机械翻译工作。开发者的主要任务变成审查、校验和纠偏。这样确实能省下大量重复劳动让人把精力放在真正需要判断力的地方。1.2 Meta 的迁移困境与 AI 的切入点Meta 在 Android 这边最头疼的并不是“能不能用 Compose”而是“存量代码怎么低成本搬过去”。他们的几款核心应用都有海量历史页面这些页面可能承担着核心用户链路不能因为一次重构就直接下线。以前不少工程师宁愿在旧体系里多补一个功能也不想碰迁移这块硬骨头因为一个页面从 XML 搬到 Compose要反复确认视觉还原度、语义逻辑、埋点上报等一大堆细节。Meta 公布的 AI 辅助方案本质上是拿“代码翻译模型”去处理最基础的 XML 到 Compose 转换再用规则和编译检查把 AI 生成的结果约束在一个安全范围里。一个很关键的细节是他们不是让 AI 一次性生成整个页面而是把一个大页面切成若干个小块每次只翻译一块然后马上跑编译、跑测试、做视觉对比。这样就算 AI 出问题影响范围也被锁在一个很小的模块里不至于让整个项目处于不可用状态。另外一个值得借鉴的点是提示词约束。Meta 工程师在分享里提到他们的提示词会带上非常明确的输入输出格式比如“输入 XML 和对应 ViewModel输出可组合函数不要修改状态逻辑保持原有命名前缀”。这个约束听起来很普通但实际效果差异极大。如果没有这层约束AI 很容易把包结构、命名、依赖全部自作主张改掉最后你拿回一份“能编译但完全看不懂”的新代码代码评审阶段就能把团队拖垮。我自己试过之后最大的感受是AI 在 Compose 迁移里的价值不在于它有多聪明而在于它能不厌其烦地重复“翻译、格式化、匹配资源”这些机械化动作。真正决定迁移成败的反倒是人怎么给它设定边界、怎么验证它的输出。2. 动手迁移前先把地基打稳2.1 盘点工程现状与迁移范围很多迁移失败的项目死因不在后面而在最开始没定义清楚“迁什么、不迁什么”。我先说一个比较稳妥的盘点方法把页面按使用频率和复杂度分成三类然后再决定每一类的处理节奏。第一类是高频且简单的页面比如设置页的单个条目、用户信息展示块。这类页面结构简单、依赖少适合作为 AI 迁移的第一梯队即使出现偏差也容易发现。第二类是逻辑复杂但 UI 相对固定的页面比如订单详情、个人主页摘要。这类页面核心价值在状态和交互逻辑迁移时需要把更多精力放在状态对齐上AI 负责处理 UI 布局人负责核对状态流转。第三类是极度复杂的自定义页面比如地图轨迹展示、复杂图表、视频编辑面板。这类页面通常依赖大量自定义 View 和底层绘制能力不太适合初期就让 AI 直接生成最好先保留在旧体系里等前面两类跑顺了再逐步处理。我实操时还会用脚本统计模块之间的依赖关系。具体做法是扫描 Gradle 模块的依赖配置看看哪些模块的 UI 层和业务层耦合度最低就把它们排在迁移队列前面。耦合度极端的模块在 AI 时代也不建议硬迁因为 AI 对跨层业务的理解仍然有限强行让模型去生成复杂业务逻辑容易出偏差。2.2 建立可验证的迁移基线迁移不烧心的重要前提是你随时能回答“改完之后有没有变坏”。我推荐在动手之前先把三样基线做起来视觉基线、功能基线和性能基线。视觉基线的做法是把目标页面在不同分辨率、不同主题下的截图保存好之后 AI 生成的 Compose 页面在相同环境下重新截图做对比。这个环节麻烦归麻烦但绝对不能省。因为 Compose 默认的阴影、边距、字体渲染和传统 View 体系存在细微差异这些差异开发时肉眼不容易发现上线后却会变成用户嘴里“好像哪里不一样”。功能基线更直接把关键用户路径的 UI 测试和端到端测试跑通一遍保存测试结果。之后每一批迁移完成这些路径都要重新跑一遍。任何一条失败都要先做归因而不是盲目让 AI 去修。性能基线要记录页面首次加载耗时、滑动帧率、内存占用。Compose 的初始化开销和重组计算都是新风险点没有性能基线帮你兜底时间长了你根本说不出一次迁移到底是变好了还是变差了。2.3 选好 AI 工具并固化提示词关于 AI 工具选型我的建议是不要只依赖一个大模型。Meta 内部那套系统我们接触不到但现有的大模型和代码补全工具完全可以组成一条流水线。我常用的组合是这三种结构理解用支持代码库检索的模型先让 AI 通读整个模块的代码回答“这个页面的数据来源有哪些”这类问题。代码生成用专门的代码生成模型来写 Compose 代码把 XML 片段、ViewModel、资源文件一起作为输入丢给它。代码审查再用另一个侧重代码审查的模型对生成结果做一轮静态检查和风格检查。这种多模型组合会带来额外的好处不同模型的“偏见”会互相抵消。生成模型容易写出千篇一律的样板结构审查模型则会从规范层面挑出问题。两轮下来代码质量通常比我单靠一个模型来回调优高出不少。提示词模板是另一个关键点。我整理了一套基础模板核心要素包括输入文件的绝对路径与文件内容。目标框架版本与项目约束比如 Kotlin 版本、minSdk。明确禁止改动的东西比如数据层、网络层、业务状态。输出格式要求比如输出一个可组合函数、独立文件、导出给调用方。这套模板一旦固化下来就可以在项目里反复复用。每迁一批页面只需要把新页面的 XML 和 ViewModel 填进模板剩下的交给 AI。3. 用 AI 拆解和转换 UI 层3.1 XML 布局翻译成 Compose 的标准流程XML 布局里LinearLayout、FrameLayout、RelativeLayout 三类容器占了绝大多数。AI 翻译时最容易出的问题是它喜欢把布局层级原封不动搬到 Compose 里。比如一个可以合并成 Column 的多层嵌套 FrameLayoutAI 直接照搬导致重组范围无谓扩大性能反而比原来更差。所以我会在让 AI 干活之前明确要求它先做一步“结构简化”把没有业务含义的中间容器合并把只有装饰作用的层级去掉用 Modifier 代替布局嵌套。这是 AI 能做但需要明确指示的一项优化你不说它默认不做。实际操作中我建议让 AI 分两步输出第一步输出“翻译版”也就是和 XML 结构一一对应的 Compose 代码第二步输出“优化版”在翻译版基础上做层级合并和 Modifier 改造。你只需要人工审查优化版对比起来非常清爽。不要让 AI 直接输出最终版否则它很可能会跳步骤甚至连某些资源引用都漏掉。3.2 状态从 View 体系搬到 Compose 的关键点UI 层翻译完之后下一步是状态。传统 View 体系里我们习惯用 LiveData 或者直接把 Activity / Fragment 作为状态持有者Compose 里更推荐把状态提升到 ViewModel并用 StateFlow 暴露给界面。AI 在这里能帮的忙是读取整个页面的数据流自动生成一个基于 StateFlow 的 ViewModel 状态容器。这个环节有几个坑特别典型。第一AI 经常自作主张地把 val 变量改成 var然后把所有字段都包装成 MutableStateFlow。这在编译上没问题但会让状态管理变得不可控因为任何地方都能改状态违背了单向数据流原则。我会在提示词和人工审查里同时加两重约束。第二事件处理容易出错。传统 View 里可能有 interface Listener或者用 LiveData 传递一次性事件迁移到 Compose 之后一次性事件应该用 Channel 或者 StateFlow 加事件标志。AI 往往直接照搬接口回调把它转成一个普通函数调用这在组合函数里容易引发状态不一致。第三Compose 的重组模型要求“读什么状态就传什么状态”。如果你把一整个对象都传给了可组合函数那么任何字段变化都会触发不必要的大范围重组。AI 生成的代码经常忽略这一点所以我一般会让模型针对每个状态对象额外生成一组用于拆包的小函数确保各字段按需读取。3.3 可组合函数怎么拆分才不影响后续维护另一个容易被忽略的问题是函数粒度。旧体系里的一个页面类如果迁移时只是简单翻译成一个巨大的可组合函数虽然能跑但后续维护就是给自己埋雷。我习惯让 AI 按照“一个职责一块 UI”的标准把大函数拆开。比如一个订单详情页拆成订单信息区、物流卡片区、操作按钮区、底部推荐区每个区域对应一个独立的可组合函数。这样有几个明显的好处单块预览调试方便状态更新范围变小后续修改只动某个区域也不容易影响其他区域。可组合函数拆分之后还需要注意参数设计。我建议尽量使用“数据对象 回调函数”这种形式而不是“一堆零散参数 内部创建 ViewModel”。因为 Compose 函数要符合可复用原则如果每个函数都内部 new 一个 ViewModel测试时就没有解耦手段代码也会越来越难读。4. 阶段式迁移的实操细节4.1 按模块分批迁移批次怎么划Meta 的方法给了一个挺重要的启示永远不要让某一版迁移一次性合并进主干。他们的做法是按页面划分迁移批次每个批次单独提交、单独测试、单独发布。这种方式看似拖慢节奏实际上保证了任何时候仓库主干都是可发布的回归风险大大降低。我在团队里采用的批次划分更细一点第一批选取 5 到 8 个低复杂度、低耦合的页面跑通完整流程。这个阶段的目的是磨合 AI 提示词模板和测试流程不在于迁移数量。第二批选择中等复杂度的列表页和表单页加入状态容器迁移把 ViewModel 和 Compose 的配合模式确定下来。第三批处理需要自定义绘制、复杂动画的页面。此时前两批积累的模式已经比较成熟AI 提示词也更加稳定即使遇到难题也能靠已有经验快速排查。每一批完成的标准不是“能编译”而是“视觉对比通过、功能测试通过、性能不劣化”。少任何一项都别往下一批走否则问题会在后面被放大到很难收拾。4.2 生成“最小差异代码”而不是整文件重写这里说的差异代码指的是改造前后能够进行 diff 对比的代码而不是整个文件重写。AI 迁移过程中最怕的就是模型把和 UI 无关的代码也改了比如格式化变了、import 顺序换了、字符串资源被合并了。这些无谓改动会让代码 review 变成一场灾难因为你根本分不清哪些是核心变更。解决方案是约束 AI 生成“最小差异模块”。具体做法是让 AI 只输出目标可组合函数加上必要的 import 语句不要让它碰其它文件使用统一的格式化工具处理新代码确保 diff 范围可控。我还会把旧文件的 hash 值记下来迁移完成之后对比 hash一旦发现无关文件被动过先还原再退回重新生成。这里再补充一个细节迁移 Compose 代码时最好把“旧资源名到新资源名”的映射表交给 AI。比如某个颜色在旧体系叫 colorPrimary在 Compose 里可能已经被统一成 brandColor。AI 如果不知道这个映射就会保留旧名字造成不一致。映射表不长但能省掉大量后期清理工作。4.3 回归测试与性能对比的数据怎么抓回归测试方面我强烈推荐引入 Compose 自带的 UI 测试框架。Compose 的测试比传统 View 测试要自然得多可以直接通过节点查找、点击交互、断言状态不需要等待视图加载过程。AI 生成的代码在测试这块也可以“学”起来比如让它读取旧测试用例翻译成 Compose 测试版本再由人来增补边界场景。性能对比不能只看一次冷启动。Compose 的重组优化有热点效应真实用户操作路径会触发不同的重组。所以性能对比要覆盖几种典型场景快速滚动列表、表单输入触发状态变化、页面频繁进出。我会把这几个场景录制成基准脚本每次迁移一批页面后都重新跑一遍数据落后直接回滚。做性能对比时还有一个细节很多人会忽略要区分 debug 和 release。Compose 在 debug 模式下由于额外检查和实时布局工具性能会明显偏慢。如果拿 debug 包跑性能对比数据失真严重。至少要用 release 包来跑核心指标才能反映真实用户环境。5. 常见问题与避坑笔记5.1 AI 生成代码最容易犯的五个错误据我自己观察AI 生成 Compose 代码时以下五个错误出现得最频繁我按发生概率从高到低排一下第一是资源引用错误。XML 里的 dimen、drawable、color 引用AI 偶尔会用错名字或直接省掉。解决办法是让 AI 输出代码时保留所有资源引用的原始命名并通过 IDE 的 lint 做二次校验。第二是 Modifier 使用过度。AI 倾向把本来应该靠布局组合实现的效果全部堆进 Modifier.padding / Modifier.size导致样式和布局逻辑缠绕在一起后续改起来很费劲。第三是隐藏的无限重组。如果某个可组合函数把整个列表数据源作为 key 传入 LazyColumn很可能每次滑动都会触发全量重组。AI 自身很难发现这种问题需要靠性能测试才能暴露。第四是空安全处理不当。生成代码里容易出现大量 !!一旦数据缺失直接崩溃。我会在提示词里明确加一句“禁止使用非空断言所有可空字段必须提供默认值或显式处理”。第五是重复造轮子。AI 经常忽略项目里已经存在的通用组件比如项目里本身封装好了 AsyncImageAI 却会引入一个新的网络图片组件增加依赖和风险。在提示词里附上项目可复用组件列表能很大程度缓解这个问题。5.2 第三方库在 Compose 环境里的适配问题迁移过程中最容易被低估的是第三方库适配。Compose 对生态的要求更高很多旧库在 Compose 环境里不能直接使用或者需要额外的桥接层。常见的几类问题图片加载库如果带有自定义占位动画往往需要提供 Compose 版本的封装。地图、视频类 SDK 一般还是基于 View 设计需要 AndroidView 容器包一层再通过状态桥接。埋点库通常对 View 体系和 Compose 体系分别有接口需要确认当前版本是否支持 Compose 节点监听。我建议在迁移排期表上专门留出“依赖升级”的时间不要在业务迁移进行到一半时才突然发现某个库在 Compose 环境里不可用。在盘点阶段就应该把每个模块用到的依赖列出来逐个确认是否有对应的 Compose 支持或者桥接方案。如果某个第三方库在 Compose 环境下确实没有成熟方案还有一个变通思路用 AndroidView 把它包起来先用最少的代价保证页面功能可用后续再考虑替换。虽然这种方式不是最优雅的但它是迁移过程中的合法逃生通道能避免你被一个第三方库卡住整个项目。5.3 我踩过的坑和总结出的经验最后聊点实在的。我用 AI 做 Compose 迁移多次之后最大的体会是AI 再强也只能作为速度放大器不能作为判断器。它能把一个两天的工作量压到几小时但这些省出来的时间必须花在验证上而不是提前结束任务。有一个坑我印象特别深有一版迁移生成的代码所有页面看起来都正常测试也全绿结果上线后用户反馈一个表单页的输入法弹出位置不对。查了两天才发现是 AI 生成代码时把一个 ScrollState 的初始化位置搞错了导致滚动锚点异常。这类问题单靠代码审查很难发现必须结合设备实测才能暴露。所以我现在给自己定了一条规矩任何 AI 生成的迁移代码至少要在一个主流机型和一个小内存机型上跑一次完整闭环流程。因为你永远无法预判 AI 会在哪个细节里埋雷但一定能通过不断实测把风险包住。另外还有一个我自己比较受用的经验AI 迁移出来的代码一定要让人重新读一遍而且最好是让没参与这次迁移的同事来读。原因很简单参与迁移的人对代码太熟了很多问题看不出来而一个全新视角的同事往往能一眼发现命名混乱、职责不清的地方。如果你准备启动一个 Compose 迁移项目我的建议是先花一个星期搭建好提示词模板、验证流程和性能基线再让 AI 正式开始生成。这个准备工作看似慢实则是整个迁移过程中最值得的一笔投入。真正开始逐批迁移时你会发现自己只需要做审查和决策那些以前让人“烧心”的机械劳动已经不需要你亲自下场了。