企业官网建设流程全解析

1. 项目缘起：为什么大厂也怕 Compose 迁移

Android 圈子里有个心照不宣的共识：Jetpack Compose 写新页面很爽，但把存量 View 体系迁移过去，往往是一场噩梦。Meta 的 Android 团队最近分享了一套用 AI 辅助 Compose 迁移的实践，我看完之后最大的感受是——他们踩过的坑，和我们中小团队踩的坑本质上是一模一样的，只是规模不同。

先说清楚这个项目到底在解决什么问题。Meta 旗下有 Facebook、Instagram、Messenger 等多款 App，Android 端代码量以百万行计，大量界面还是传统的 XML + View 体系。全面重写成 Compose 不现实，成本高、风险大、回归测试量爆炸。所以他们走的是渐进式迁移路线：新功能用 Compose 写，老页面按优先级逐步替换。问题就出在"逐步替换"这四个字上——一个中等复杂度的页面，从 View 迁到 Compose，熟练工程师也要花好几天，而且迁移过程中极易引入 UI 细节偏差、状态管理 bug、性能回退。

AI 在这里扮演的角色，不是"一键转换器"，而是迁移过程中的副驾驶。它承担的是那些重复度高、模式化强、但又必须逐行确认的脏活累活。这篇文章我会把 Meta 这套思路拆开，结合我自己在几个中型项目里做 Compose 迁移的经验，讲清楚哪些环节适合交给 AI、哪些环节必须人来把关、具体怎么落地、以及最容易翻车的地方在哪。

适合读这篇的人：正在做或准备做 Compose 迁移的 Android 工程师、技术负责人，以及想了解 AI 辅助大型代码重构真实边界的人。不需要你是 Compose 专家，但至少要写过几个 Compose 页面，否则后面的一些细节会缺少体感。

2. 迁移这件事，难在哪

2.1 不是语法翻译，是范式转换

很多人对 Compose 迁移有个误解，觉得就是把TextView换成Text、LinearLayout换成Column。如果真是这样，那写个正则脚本就完事了。实际上 View 体系和 Compose 是两套完全不同的心智模型。

View 体系是命令式的：你拿到一个 View 对象，调用它的方法去改变它的状态。textView.text = "hello"、progressBar.visibility = View.GONE，这些都是命令。而 Compose 是声明式的：你描述 UI 在某个状态下应该长什么样，状态变了，UI 自动重组。这个差异导致迁移时最难的往往不是控件替换，而是状态该放在哪、怎么流动、副作用怎么处理。

举个最常见的例子。View 体系里，一个列表项点击后改变背景色，你可能是这样写的：

itemView.setOnClickListener { itemView.setBackgroundColor(Color.RED) selectedId = item.id }

迁到 Compose，如果你直接翻译成：

Box(modifier = Modifier.clickable { // 这里想改背景色，但怎么改？ })

就会发现无从下手——因为 Compose 里没有"改背景色"这个动作，你只能让背景色依赖于某个状态，状态变了背景色自然就变了。这个思维转换，AI 如果只是做字面翻译，产出的代码大概率是错的，或者能跑但不符合 Compose 的最佳实践。

2.2 迁移的四个真实痛点

我把实际迁移中遇到的痛点归了归类，基本逃不出这四个：

• 状态管理重构：View 里的mutable字段、LiveData、Observable，要重新映射到remember、mutableStateOf、StateFlow，还要考虑状态提升（state hoisting）到哪一层。
• 生命周期与副作用：onResume里做的事、Handler.postDelayed、RxJava订阅，在 Compose 里对应LaunchedEffect、DisposableEffect、rememberCoroutineScope，选错了就是内存泄漏或重复执行。
• 自定义 View 的等价实现：项目里那些继承View手写onDraw的组件，Compose 里要用Canvas、drawBehind重写，这部分几乎无法自动转换。
• UI 细节偏差：间距、圆角、阴影、字体行高，View 和 Compose 的默认行为不完全一致，迁移后视觉走样是家常便饭。

Meta 的分享里特别强调了一点：AI 最擅长的是第二类和第四类，第一类和第三类必须人来主导。这个判断我完全认同，后面会展开讲为什么。

2.3 为什么不能全自动

有人会问，既然有 AI，为什么不干脆让它把整个页面一次性转完？答案很简单：迁移的验收标准是"行为完全一致"，而 AI 无法验证这一点。它不知道你这个页面的业务逻辑，不知道某个按钮点击后应该跳到哪里，不知道某个状态在特定条件下应该是什么值。它能做的是基于代码上下文做合理推断，但推断就有出错概率，而 UI 迁移的错误往往很隐蔽——编译能过、跑起来不崩，但某个边界条件下就是不对。

所以 Meta 的思路是人机协作的分工模式：AI 负责生成候选代码和批量处理，人负责定义迁移规则、审查关键逻辑、验证行为一致性。这个定位想清楚了，后面的所有操作才有意义。

3. AI 在迁移流水线里的四个落点

3.1 落点一：迁移前的代码理解与依赖梳理

在动手改任何一行代码之前，先得搞清楚这个页面到底依赖了什么。一个 View 页面可能引用了十几个自定义 View、若干工具类、一堆资源文件。人工梳理费时费力，这一步交给 AI 做效率很高。

具体做法是把目标页面的 XML 布局文件、对应的 Fragment/Activity 代码、以及它引用到的自定义 View 源码一起喂给 AI，让它输出一份依赖清单和迁移影响面分析。提示词可以这样设计：

以下是一个 Android View 页面的布局文件和对应代码。 请分析： 1. 页面用到了哪些标准控件，分别对应 Compose 的什么组件 2. 用到了哪些自定义 View，迁移难度评估（高/中/低） 3. 状态相关的字段有哪些，分别是什么类型 4. 有哪些生命周期回调和异步操作 5. 列出迁移时需要特别注意的风险点

这个提示词的关键在于要求它输出结构化的分析而不是直接给代码。直接给代码你会被淹没，先要一份"地图"，你才知道哪里是雷区。

注意：喂给 AI 的代码要脱敏。业务逻辑里的敏感字符串、接口地址、用户数据字段，该删的删。这不是不信任工具，是基本的工程纪律。

3.2 落点二：模式化控件的批量转换

标准控件的转换是 AI 的舒适区。TextView、ImageView、Button、LinearLayout、ConstraintLayout这些，转换规则明确，AI 的准确率相当高。Meta 的做法是先建立一套内部的转换规则库，把团队约定的映射关系固化下来，再让 AI 按规则转换，而不是让它自由发挥。

为什么要有规则库？因为同一个控件在不同团队有不同的迁移偏好。比如ConstraintLayout迁到 Compose，你可以用ConstraintLayout的 Compose 版本，也可以用嵌套的Row/Column/Box，还可以用Modifier链。如果不定规则，AI 每次给你的方案可能都不一样，代码风格就乱了。

一个简化的规则表示例：

有了这张表，AI 转换时就有了约束，产出的一致性会好很多。

3.3 落点三：状态逻辑的辅助重构

这是最有价值也最容易出错的一环。AI 可以帮你把LiveData转成StateFlow、把Observable字段转成mutableStateOf，但它无法判断状态应该提升到哪一层。这个判断必须人来做。

我的经验是分两步走：先让 AI 做机械转换（类型替换、API 替换），再由人做结构决策（状态放哪、怎么传递）。比如：

// 迁移前：View 体系 class ProfileFragment : Fragment() { private val userNameLiveData = MutableLiveData<String>() override fun onViewCreated(...) { userNameLiveData.observe(viewLifecycleOwner) { name -> binding.userNameText.text = name } } }

AI 机械转换后可能给你：

// AI 转换后（能跑，但结构不一定对） @Composable fun ProfileScreen() { val userName = remember { mutableStateOf("") } // ... 但 userName 从哪来？谁更新它？ }

这时候人要做的是决定：userName是页面内部状态，还是应该从 ViewModel 传进来？如果是后者，就要改成viewModel.userName.collectAsState()。这个决策 AI 做不了，因为它不知道你的架构约定。

3.4 落点四：迁移后的自查与测试用例生成

迁移完成后，AI 还能帮你做两件事：一是生成 UI 测试用例，二是对比迁移前后的行为差异。Meta 提到他们会用 AI 生成 Compose 的 UI 测试，覆盖迁移页面的关键交互路径，作为回归保障。

比如让 AI 基于迁移前的页面行为描述，生成对应的 Compose 测试：

@Test fun profileScreen_showsUserName_whenLoaded() { composeTestRule.setContent { ProfileScreen(userName = "测试用户") } composeTestRule.onNodeWithText("测试用户").assertIsDisplayed() }

这些测试用例不能完全替代人工验证，但能覆盖掉大量重复的回归场景，尤其是那些"改完这里忘了那里"的低级错误。

4. 一套可复现的迁移流程

4.1 第一步：选定试点页面并建立基线

不要一上来就挑最复杂的页面。选一个中等复杂度、依赖清晰、有现成测试的页面做试点。Meta 的经验是先在小范围验证流程，跑通了再推广。

建立基线要做三件事：

1. 截图基线：把迁移前页面在各个状态下的截图存下来，作为视觉对比的基准。
2. 行为基线：列出页面的所有交互路径，每条路径的预期结果写清楚。
3. 性能基线：记录页面的首帧时间、滚动帧率、内存占用，迁移后要对比。

这三条基线是后面验收的依据，缺一不可。我见过太多团队迁移完只看"能不能跑"，结果上线后用户反馈卡顿、错位，回头查才发现没有基线可对比。

4.2 第二步：用 AI 生成迁移方案草案

把页面代码、依赖清单、团队的转换规则库一起给 AI，让它输出一份迁移方案草案。这份草案应该包含：

• 组件映射表（哪个 View 对应哪个 Composable）
• 状态管理方案（状态放哪、怎么流动）
• 副作用处理方案（哪些用 LaunchedEffect、哪些用 rememberCoroutineScope）
• 风险点清单

这一步的产出不是最终代码，是方案。你要审查这份方案，把不合理的地方改掉，再进入下一步。跳过这一步直接让 AI 写代码，返工率会高得离谱。

4.3 第三步：分模块生成与人工审查

方案确认后，按模块让 AI 生成代码。我的习惯是一个 Composable 一个 Composable 地生成，而不是整个页面一次性生成。原因很简单：一次性生成的代码量太大，审查时容易漏看，而且一旦某个基础组件错了，整个页面都要返工。

每个 Composable 生成后，人工审查的重点：

• 状态是否正确提升，有没有该传参的地方用了内部状态
• 副作用有没有用对 API，会不会重复执行
• Modifier 链的顺序对不对（这个特别容易错，顺序不同效果完全不同）
• 有没有硬编码的尺寸、颜色，该用主题的地方有没有用

4.4 第四步：视觉与行为双重验证

代码写完只是开始，验证才是重头戏。视觉验证用截图对比工具，把迁移后的页面在相同状态下截图，和基线逐像素对比。行为验证按之前列出的交互路径逐条走。

这里有个技巧：用 Compose 的 Preview 功能批量生成不同状态的截图，比手动点来点去高效得多。把页面可能出现的各种状态（加载中、空数据、错误、正常）都做成 Preview，一次性对比。

4.5 第五步：性能回归与灰度发布

性能对比用基线数据。如果发现帧率下降或内存上涨，优先排查这几个地方：LazyColumn有没有加key、有没有在 Composable 里做重计算、remember有没有用对。这些是 Compose 性能问题的高发区。

灰度发布是最后一道保险。Meta 的做法是先在内部员工版本上线，观察一段时间再逐步放量。中小团队可以借助应用商店的分阶段发布功能做类似的事。

5. 踩坑实录与排查速查

5.1 那些 AI 最容易搞错的地方

坑一：Modifier 顺序。这是最高频的错误。Modifier.padding(16.dp).background(Color.Red)和Modifier.background(Color.Red).padding(16.dp)效果完全不同——前者是背景包含 padding，后者是背景不包含。AI 经常搞反，审查时务必逐个确认。

坑二：状态提升过度或不足。AI 有时会把本该提升的状态留在组件内部，导致外部无法控制；有时又把纯 UI 状态提升到 ViewModel，造成不必要的耦合。判断标准很简单：这个状态是否影响业务逻辑？是就提升，否就留在内部。

坑三：LaunchedEffect 的 key 用错。LaunchedEffect(Unit)只执行一次，LaunchedEffect(someState)在 state 变化时重新执行。AI 经常在该用 key 的地方用了Unit，导致数据更新后副作用不重新触发。

坑四：忘记处理重组。View 体系里你手动更新 UI，Compose 里 UI 自动重组。AI 转换时有时会保留一些"手动更新"的残留逻辑，这些在 Compose 里是多余甚至有害的。

5.2 常见问题速查表

5.3 几条血泪经验

经验一：不要相信 AI 的"看起来对"。它生成的代码往往语法正确、逻辑自洽，但就是不符合你的业务。审查时带着"这段代码在边界条件下会怎样"的问题去看，能发现很多隐藏问题。

经验二：迁移和重构分开做。迁移时只做迁移，不要顺手改业务逻辑。两件事混在一起，出了问题根本分不清是迁移引入的还是重构引入的。Meta 的实践里也强调了这一点。

经验三：保留迁移前的代码分支。迁移不是一锤子买卖，上线后发现问题要能快速回滚。保留旧代码分支，用功能开关控制走哪套实现，是稳妥的做法。

经验四：AI 生成的测试用例要人工补充边界。AI 擅长生成正常路径的测试，边界条件（空数据、超长文本、网络异常）往往覆盖不到，这些要人工补。

6. 关于工具选型的一点个人看法

Meta 用的是他们内部的 AI 工具链，我们普通团队用不了。但思路是通用的，市面上能用的工具无非几类：代码补全类（如各类 IDE 的 AI 插件）、对话类（把代码贴进去让它分析）、以及专门的代码转换工具。

我的建议是不要迷信某一个工具。迁移这种任务，不同环节适合不同工具：理解代码用对话类，批量转换用补全类，验证用测试生成类。关键是把你自己的转换规则和验收标准建立起来，工具只是执行者。

另外，本地跑得动的模型优先考虑。迁移涉及大量业务代码，能不上传就不上传，这是数据安全的基本要求。现在一些开源模型在代码任务上的表现已经够用，配合好的提示词，效果不比在线服务差多少。

最后说个我自己的体会：AI 辅助迁移真正省下的时间，不在于它写代码有多快，而在于它帮你把那些你懒得做的梳理、对比、测试生成工作自动化了。迁移的瓶颈从来不是打字速度，是理解和验证的成本。把这两块的成本降下来，迁移效率自然就上去了。至于那些需要判断力的决策——状态放哪、架构怎么定、边界怎么处理——还是得你自己来，这恰恰是工程师价值所在的地方。