claude code对Android Jetpack Compose状态管理的生成模式分析

上周，我在一个电商项目里遇到了一个棘手的问题。项目已经用Jetpack Compose重构了大半，购物车模块的状态管理复杂到让我头疼，跨页面库存同步、多选优惠计算、优惠券叠加时的价格联动，每个逻辑都牵一发动全身。我突发奇想：让Claude Code来写这部分状态管理，会发生什么？

它不到40秒就生成了完整的代码。可运行，功能也大致对。但当我仔细审视那段代码的状态组织方式时，发现了一些让我这个做了六年安卓开发的“老兵”都感到意外的“模式”，有些很精妙，有些则藏着让人后背发凉的隐患。

这篇文章不打算给你复述“什么是mutableStateOf”或“remember怎么用”，那些基础教程搜索引擎一抓一大把。我要做的是：把Claude Code生成的Compose状态管理代码“解剖”给你看，分析它的生成模式、判断它的设计偏好、揭示它反复出现的“习惯性错误”，并给出一套你可以直接用起来的AI协作策略。

读完你会发现：AI写状态管理的能力远比你想象的强，但如果你不了解它的“生成模式”，你接过来的可能不是宝藏，而是定时炸弹。

一、核心结论：Claude Code在Compose状态管理上的六种生成模式

在正式展开分析之前，我先把核心发现摆出来。过去三个月，我在六个真实的业务场景中测试了Claude Code生成Compose状态管理代码的表现，反复观察到了以下六种“生成模式”：

模式一：局部状态优先原则。 Claude Code极度偏好使用var x by remember { mutableStateOf(...) }来处理一切状态，即使在跨多组件共享状态的场景下，它仍然倾向于先定义局部状态，再通过参数层层传递，而不是第一时间考虑ViewModel。

模式二：副作用API的“过度保险”行为。 它在处理LaunchedEffect和DisposableEffect时，会习惯性地添加比实际需求更多的key参数或清理逻辑。这种“防御性编程”看似健壮，实则容易造成不必要的重组和逻辑复杂度。

模式三：单向数据流的“表面遵循”。 Claude Code生成的代码在结构上看起来遵循了UDF（Unidirectional Data Flow）模式，状态向下流动，事件向上传递。但当你仔细检查数据路径时，会发现它的“事件”往往没有真正封装业务意图，而是变成了简单的属性修改回调，丢失了领域语义。

模式四：ViewModel引入的门槛异常稳定。 我做过量化统计：当一个Composable函数内的状态变量超过3个，或者状态需要在3个以上组件间共享时，Claude Code有89%的概率会主动创建ViewModel。这个阈值表现出了惊人的一致性。

模式五：对remember和rememberSaveable的边界模糊。 Claude Code在生成代码时，很少主动使用rememberSaveable，而是默认使用remember。即便在需要进程重建后恢复数据的场景（如表单输入），它也经常忽略这一差异。

模式六：状态提升的“过度执行”。 当要求重构代码时，Claude Code容易把状态提升到一个过高的层级，比如把本应属于单个页面的ViewModel状态定义到全局Application级，导致不必要的全局依赖。

下面我会逐一展开这些模式，用具体的代码案例、数据对比和实践建议来拆解。

二、从一次真实的购物车重构实验说起

我先把场景交代清楚。

实验对象：一个中等复杂度的电商购物车模块。功能包括：商品勾选/取消、单品数量增减、全选/反选、删除选中、优惠券选择与折扣计算、不同店铺商品分组展示。

实验方式：我给Claude Code（通过API调用，模型为claude-sonnet-4-20250514）提供了完整的业务需求描述，包含7条具体的功能点和3条边界条件（比如“商品库存为0时不可勾选”“跨店铺商品优惠券独立计算”）。没给任何架构提示或状态管理偏好的引导。

结果代码：它生成了一个包含3个Composable函数、1个ViewModel、2个数据类的完整购物车界面。代码总计217行，可以直接编译运行。

这个结果粗看没什么问题。但当我开始逐行审查时，发现了第一个让我警觉的信号。

2.1 第一次审看：状态定义位置的“异常”

Claude Code把购物车的商品列表状态定义在了ViewModel中，这没问题。但优惠券的选中状态和折扣计算结果，却被写在了Composable函数内部：

// Claude Code生成的代码（简化）
@Composable

fun ShoppingCartScreen(viewModel: ShoppingCartViewModel = viewModel()) {

val cartItems by viewModel.cartItems.collectAsState()

var selectedCoupon by remember { mutableStateOf<Coupon?>(null) }

var discountAmount by remember { mutableStateOf(0.0) }

// 当selectedCoupon变化时计算折扣

LaunchedEffect(selectedCoupon) {

discountAmount = viewModel.calculateDiscount(selectedCoupon, cartItems)

}

// ...

}

这段代码的问题在哪？优惠券选择作为影响订单金额的核心业务逻辑，却被隔离在ViewModel之外。这意味着：如果我需要在订单确认页面复用这个优惠券计算逻辑，就必须重新写一遍，或者把这部分状态“再提一次”。

这是Claude Code生成模式的典型特征：它把“暂时只有一个地方使用”等同于“应该定义为局部状态”。 在AI的“思维”里，局部状态简单、直接、不需要跳转到另一个文件查看依赖，但这种便利性是以架构的可扩展性为代价的。

我把这种模式称为“视觉亲近性优先”：AI倾向于让代码在当前文件中“自洽”，尽量避免跨文件依赖。这对写Demo来说很高效，对生产级项目则意味着技术债务。

2.2 第二次审看：重组触发器的隐患

再看LaunchedEffect那行代码。Claude Code用selectedCoupon作为key来触发折扣重算。这在当前逻辑下是对的，只在优惠券变化时重新计算。但购物车商品的价格变化、数量变化、勾选变化，实际上也应该触发折扣重算。

真实业务场景中，折扣依赖的变量远不止一个selectedCoupon。Claude Code的生成模式再次暴露了一个特征：它倾向于用单一变量作为副作用触发器，而不是构建一个完整的派生状态推导链。

正确的做法应该是把折扣金额定义为派生状态：

val discountAmount = remember(cartItems, selectedCoupon) {
viewModel.calculateDiscount(selectedCoupon, cartItems)

}

或者更好，把整个计算逻辑下沉到ViewModel中，让Composable层仅作为展示。

三、模式一深入辨析：局部状态优先的边界在哪里？

前面已经点出了这个模式的核心表现，这里我要给出量化的数据和你可以在自己项目中使用的判断标准。

3.1 我是如何量化这个模式的

我在五个不同类型的Compose项目中，记录了Claude Code生成的状态管理代码的“状态位置”选择。统计结果如下：

可以看到一个明显的规律：当场景被AI识别为“单页面”时，即便有多个组件，状态仍然大量留在Composable中。只有当明确的“跨页面”需求出现在prompt中，ViewModel的使用比例才会显著上升。

而“全局设置”这类明确需要跨Application使用的状态，Claude Code几乎无例外地选择了Application级定义（通常通过CompositionLocal实现）。这说明它对“全局vs局部”的二元判断是清晰的，但对“页面内跨组件”这种灰色地带，它倾向于“能不建ViewModel就不建”。

3.2 这个模式什么时候是优势，什么时候是坑？

你需要保留AI这个习惯的场景：

• 原型验证阶段。 当你只是想快速验证一个交互逻辑，所有状态都定义在Composable中能让你在单一文件中完成修改，效率极高。这时候不要跟AI较劲让它加ViewModel。
• 极简工具类页面。 比如一个设置页面的开关状态、一个搜索框的输入文本。这些状态天然就是这个Composable的私有状态，局部定义恰恰是最佳实践。

你必须纠正AI这个习惯的场景：

• 跨路由复用的业务状态。 购物车商品、用户登录态、订单支付信息，这些数据后续页面必然要用，一开始就应该放进ViewModel。
• 需要参与单元测试的逻辑。 定义在Composable中的状态很难被独立测试，你得启动整个Compose框架才能验证逻辑。把业务逻辑抽到ViewModel，测试成本下降90%。
• 需要在配置变更（屏幕旋转）后恢复的状态。 纯remember无法处理配置变更，而ViewModel天然支持。

判断标准我总结为一句话：问自己一个问题，“如果这个页面的UI全改掉，这些状态还有意义吗？”如果答案是“有意义”，那它应该进ViewModel。

四、模式二三联动：副作用API的“过度保险”与UDF的表面化

我把模式二和模式三放在一起讲，因为它们在实践中高度联动，副作用API的误用往往是“表面UDF”的产物。

4.1 一个“过度保险”的真实案例

还是从代码看起。下面是Claude Code生成的商品列表页中的一段筛选逻辑：

@Composable
fun ProductListScreen(viewModel: ProductListViewModel = viewModel()) {

val products by viewModel.products.collectAsState()

var filterCategory by remember { mutableStateOf("全部") }

var sortOrder by remember { mutableStateOf(SortOrder.DEFAULT) }

var searchQuery by remember { mutableStateOf("") }

LaunchedEffect(filterCategory, sortOrder, searchQuery, products.size) {

viewModel.applyFilter(filterCategory, sortOrder, searchQuery)

}

LaunchedEffect(Unit) {

viewModel.loadProducts()

}

DisposableEffect(Unit) {

onDispose {

viewModel.clearCache()

}

}

// ...

}

第一个问题：LaunchedEffect(filterCategory, sortOrder, searchQuery, products.size)这四个key的组合。每当products.size变化（比如加载完成或删除了一个商品），筛选逻辑都会重新执行，但筛选条件其实没变。这是一种不必要的性能支出。

第二个问题隐藏在更深的地方。让我们跳到ViewModel内部：

// Claude Code生成的ViewModel
class ProductListViewModel : ViewModel() {

private val _products = MutableStateFlow<List<Product>>(emptyList())

val products: StateFlow<List<Product>> = _products.asStateFlow()

fun applyFilter(category: String, sortOrder: SortOrder, query: String) {

// 直接修改_products，触发UI重组

_products.value = _products.value

.filter { ... }

.sortedBy { ... }

}

}

表面上看，UI层触发事件（用户选择筛选条件），ViewModel处理逻辑，状态向下流动，UDF的外壳有了。但问题出现在“数据源”上：_products既作为原始数据存储，又作为筛选后的结果返回，这意味着原始数据在筛选后被丢失了。 如果用户清空筛选条件想回到原始列表，已经回不去了。

这就是“表面UDF”的致命缺陷：它模仿了UDF的形式（事件上、状态下），却没有贯彻UDF的核心精神，状态应该是单一的数据源，派生状态应该可回溯。

4.2 Claude Code为什么会写出“表面UDF”？

我发现这跟它的“信息检索模式”高度相关。当你跟它说“实现商品筛选功能”时，它会检索到的“UDF模式”是一种结构模板，它知道要有事件回调、要有状态流、ViewModel要负责逻辑。但它不理解为什么UDF要这样设计。

具体表现就是：

• 它有事件，但事件是UI操作的直译（onFilterChange、onSortChange）而不是业务意图的表达（applyCategoryFilter、togglePriceSort）。
• 它有ViewModel，但ViewModel只是一个“状态暂存器”而不是业务逻辑的真正封装者。原始数据和派生数据的边界被模糊。
• 它有副作用处理，但key的选择倾向于“把所有可能影响结果的变量都放进去”而不是精确识别真正触发逻辑变化的最小依赖集合。

4.3 你该怎么修正这种模式？

修正步骤我总结为四步：

1. 识别原始数据源。 问自己：“如果所有筛选条件全部重置，我需要什么数据？”把这些数据定义为独立的状态。
2. 派生状态独立声明。 筛选后的结果、排序后的列表、计算出的总价，这些都是派生状态，使用StateFlow.map{}或combine{}推导，而不是在原始数据上覆盖。
3. 事件重命名。 把onClickFilter改成applyCategoryFilter(category)，让事件表达“用户想完成什么业务目标”而非“用户点击了什么按钮”。
4. 副作用key最小化。 在LaunchedEffect中只放入真正需要触发逻辑变化的key。如果一个变量变化不应该重新执行逻辑，就不要放进key列表。

五、模式四的量化解剖：ViewModel引入的“3个状态变量”阈值

这是我最有信心的一个发现。

5.1 实验设计

我设计了20个不同的需求描述，每个描述中，我只改变状态变量的数量和跨组件共享的范围。然后观察Claude Code是否主动创建ViewModel。每个描述测试3次，取多数结果。

控制变量： 功能复杂度保持一致（都是带CRUD的列表管理），prompt风格保持一致，不暗示任何架构选择。

分组设计：

• 对照组A：1-2个状态变量，单一Composable
• 对照组B：3-5个状态变量，单一Composable
• 对照组C：3-5个状态变量，2-3个兄弟Composable
• 对照组D：6个以上状态变量，多Composable且有父子嵌套

5.2 实验结果

门槛非常明显：当状态变量超过3个，尤其当这些状态需要在2个以上组件间共享时，Claude Code几乎必定引入ViewModel。 我把3个状态变量称为Claude Code的“ViewModel激活阈值”。

5.3 这个阈值的价值在哪？

知道这个阈值，你就获得了一个精准的“预期管理工具”。

当你给Claude Code写prompt时，如果你想让它生成轻量级的纯Composable代码（比如做一个快速Demo），就刻意把需求拆解到3个状态变量以内：“实现一个只有标题和内容的笔记输入框，点击保存后清空。”，这种描述只会产生2个状态变量，VM创建概率接近0%。

反之，如果你想让它直接生成架构完整的生产级代码，就在prompt中明确提及超过3个需要被跟踪和修改的数据实体：“实现用户资料编辑页，包含昵称、头像、邮箱、手机号、收货地址列表、通知偏好设置。”，这种描述天然超过3个状态，它会主动建ViewModel并定义事件回调。

这个技巧在你需要控制AI产出物粒度的时候非常实用。我现在的做法是：在需求描述的“数据结构”段落中，有意识地控制提及的数据实体数量。

六、模式五的残酷真相：Claude Code为何从不主动使用rememberSaveable？

这是六个模式中我最晚发现，但后果可能最严重的一个。

6.1 发现过程

我在审查Claude Code生成的注册表单时，注意到所有输入框的状态都是用remember定义的。这看起来没什么问题，页面运行正常。但当我旋转屏幕测试时，输入的所有内容都消失了。

这很反直觉，因为我们在日常开发中，大部分表单都会在配置变更后丢失数据，这是大家都知道的坑。我们也会自然地使用rememberSaveable或配合ViewModel来处理。

但Claude Code从来不会主动写rememberSaveable。我专门做了试验：在50次不同的表单类需求中，Claude Code使用rememberSaveable的次数是多少？0次。 50次全都是remember。

6.2 原因分析

这不是bug，是训练数据分布的反映。公开的Compose教程、博客、Stack Overflow回答中，remember的使用频率是rememberSaveable的7-10倍。rememberSaveable通常只在专门讲解配置恢复的进阶教程中出现。AI模型是对训练数据的概率分布建模，它“学会”的是最常见的写法，而非最安全的写法。

更隐蔽的是，当我在ViewModel中定义了状态并用collectAsState()在Composable中收集时，Claude Code依然会在某些边缘场景（比如过渡动画状态、UI交互中间态）使用remember。这些状态在屏幕旋转后同样会丢失，可能导致UI闪烁或交互中断。

6.3 你应该制定的检查清单

针对这个模式，你需要建立一套审查纪律，每次接到AI生成的Compose代码后强制检查：

• [ ] 是否有用户输入的表单字段？→ remember 必须换成 rememberSaveable
• [ ] 是否有列表滚动位置？→ 需要手动保存到 rememberSaveable
• [ ] 是否有临时UI状态（如展开/折叠状态、选中的tab索引）？→ 评估是否需要在旋转后恢复，大多数情况需要
• [ ] 是否有过渡动画的播放状态？→ 考虑rememberSaveable或在ViewModel中维护

特别提醒：rememberSaveable需要数据可序列化（放入Bundle），自定义数据类不要忘记添加@Parcelize或实现Saver。

七、模式六：状态提升为什么会“过度”？

模式六与模式一是镜像问题：如果说模式一是“该提的状态不提”，模式六就是“不该提的状态过度提升”。

7.1 典型的过度提升案例

我特意测试了一种场景：我先把Claude Code生成的“局部状态过多”的代码批评了一遍，“要求重构以支持更好的可测试性和跨页面复用”。然后它会“过度反应”：

// 过度反应后的结果，购物车页面的展开/折叠UI状态被提到了Application级
object ShoppingCartGlobalState {

var isDiscountDetailExpanded by mutableStateOf(false)

var selectedItemId by mutableStateOf<String?>(null)

var currentEditingQuantity by mutableStateOf(1)

}

展开/折叠状态、临时选中的item、正在编辑的数量，这些是纯UI交互状态，跟业务逻辑无关，跟其他页面无关。设置为全局状态后，不仅增加了不必要的全局耦合，还在多实例场景（比如分屏模式、多个Navigtion入口）中引入冲突风险。

7.2 它与模式六的关系揭示了一个深层规律

Claude Code对于状态的“层级定位”能力是相对静态和机械的。当你给出“这个状态需要更高层级的共享”这样的反馈时，它缺乏判断“多高算高”的语义理解能力。它倾向于把“提一个层级”执行成“提到最高层级”以避免再次被批评“提得不够高”。

这就是为什么你会发现，当你要求它“优化架构”而不是“修正具体问题”时，Claude Code的自我修正往往从“太局部”跳到“太全局”，中间最合适的ViewModel层反而被跳过。

7.3 修正策略：用层级边界引导词

经过大量测试，我发现下面的prompt引导词可以有效帮助Claude Code把状态放在正确的层级：

错误引导：“把这个状态提升以便跨组件共享。” → 它会提到全局

正确引导：“把这个状态移到XXXViewModel中，保持它在ShoppingCart模块内的私有性。” → 它能精准放置

关键差异在于：明确指出目标容器的名称和它所属的模块边界。 不要给AI一个“提升”的模糊指令，而是给它一个具名的目标位置。

八、综合诊断：Claude Code的“生成模式”背后是什么？

剖析完六个模式，我想退一步，试着抽象出这些模式背后的几条“AI思维习惯”。理解这些习惯，你才能在所有场景下预测和管控它的行为，而不是每次碰到新情况都要重新踩坑。

8.1 信息近端性偏好

Claude Code对状态作用域的选择，高度依赖它在分析需求时“先看到什么信息”。如果它先看到某个Composable需要这个状态，它会把状态定义在那个Composable中，除非后续有明确证据表明其他Composable也需要。这种自底向上的决策有时产生合理的封装，但也经常忽略“后面马上会用到”的架构整体性。

8.2 正确性优于优雅性的权衡

LaunchedEffect的key过度添加是这个特征的最佳体现。AI推理：多放一个key可能导致一次多余的无害重组 → 但如果少放一个key可能导致逻辑错误 → 那还是多放吧。这种“宁可多做也不错漏”的倾向在安全领域是美德，在性能敏感的移动开发领域则可能变为问题。

8.3 高频模式压倒低频模式的统计倾向

remember的例子完美说明：AI模型是“统计驱动的开发习惯聚合器”。在训练语料中高频出现的模式（简单remember）会压制低频但更安全的模式（rememberSaveable）。这意味着AI生成代码的“默认安全性”永远是一个需要人工介入的偏差项，它偏爱的是“最常见的”而非“最正确的”。

九、给你的实战手册：如何与Claude Code高效协作Compose状态管理？

前面的分析都是为了让你在实际工作中有判断依据。这一节，我把所有发现转化为一套可操作的工作流。

9.1 Prompt工程：怎样“指挥”Claude Code生成更合理的状态管理代码？

经过反复测试，我整理了一套prompt模板。这不是写死的咒语，而是需要你理解其设计逻辑后灵活调整的框架。

标准prompt结构：

我要用Jetpack Compose实现[具体功能描述，包含数据实体清单]。
功能需求：

[列出具体功能，明确哪些数据需要在不同操作间保持]
[声明跨页面的数据依赖]
架构要求（重要）：

所有跨页面的业务状态必须放在ViewModel中管理

纯UI交互状态（如展开/折叠、动画状态）放在Composable中

用户输入的表单数据使用rememberSaveable，不要用remember

筛选/排序等派生状态不要覆盖原始数据，用独立的StateFlow

请生成代码，并解释你选择每种状态管理方式的理由。

Prompt中的关键设计逻辑：

• “数据实体清单”：引导AI识别状态变量数量，触发ViewModel阈值。
• “跨页面 / UI交互”：主动为AI画出状态层级边界，避免它的近端性偏好。
• “rememberSaveable”：直接覆盖高频模式偏差，把低频模式提升为显性要求。
• “解释理由”：强制AI进行架构思考而非模式匹配。

9.2 代码审查：一份检查清单

无论AI生成的代码看起来多完美，我建议你按以下清单执行一次结构化的审查。我在项目中发现，这个流程大约需要15-20分钟，但它能抓住80%以上的生成模式问题。

第一轮：状态位置审查

• [ ] 有多少个remember状态？逐一判断：这个状态在其他页面需要吗？
• [ ] 如果有ViewModel，其中的状态是否包含纯UI状态（如展开/折叠）？如有，移回Composable。
• [ ] 是否有本该进ViewModel的业务状态留在Composable中？对照数据实体清单。
• [ ] 有没有被提到Application级的状态？除非是主题/语言等全局配置，否则降级。

第二轮：数据流审查

• [ ] 是否有原始数据和派生数据混淆的情况？（筛选是否覆盖了源数据）
• [ ] LaunchedEffect的key列表是否包含不必要的触发项？
• [ ] 事件回调的命名是否表达业务意图，而非UI操作直译？

第三轮：生命周期与配置恢复审查

• [ ] 所有存储用户输入的状态是否使用了rememberSaveable或ViewModel？
• [ ] 是否有应该在旋转后恢复的UI状态丢失？
• [ ] DisposableEffect的清理逻辑是否必要且不会过于激进？

9.3 协作流程：我的“生成-审查-重构”三阶段法

我用一个真实项目的时间数据来说明这个方法。

时间对比： 手写购物车模块的状态管理逻辑，我花了大约6小时（包括调试重组问题）。而用“三阶段法”配合Claude Code，总时长为2.5小时。

审查阶段的时间比手写的审查时间更长，这是因为AI代码的结构性审查是需要成本的，但对于复杂模块来说，审查总比从零开始快。而且审查过程中我学到了很多我自己容易忽略的架构细节，这点是意外的收获，AI代码的“奇怪之处”有时候会提示你反思自己的编码习惯。

十、边界情况与取舍：什么时候你应该“将错就错”？

如果你把前面的清单和规则奉为圭臬，对所有AI生成的代码都照此修正，那你就陷入了另一种教条。这一节讨论几种你应该主动“放过”AI生成模式的情况。

10.1 什么时候“局部状态优先”其实是更好的选择？

情况一：独立工具组件。 比如你写了一个自定义的下拉刷新动画组件，它的动画播放状态、触摸偏移量、阻尼系数，这些状态定义在Composable内部是最干净的。如果你硬要提到ViewModel，反而把纯UI逻辑泄露进了业务层。

判断标准：这个组件能不能被提取为一个独立的三方库？ 如果可以，它的状态就应该在内部。

情况二：一次性迁移项目。 如果你是在把老代码中的某个页面迁移到Compose，而且这个页面的功能和依赖已经冻结，那么过度架构设计是浪费。此时Claude Code生成的“局部状态优先”代码其实是合适的，别花时间往ViewModel上改。

情况三：团队学习阶段。 如果你的团队成员还在Compose状态管理的学习期，过于复杂的ViewModel+UDF架构反而会拖慢理解和交付速度。先让AI生成简单的remember版本，等团队适应了再重构，这个策略虽然临时欠了技术债，但能保持项目节奏。

10.2 什么时候“过度保险”的LaunchedEffect反而救了你？

一个我亲身经历的例子：在一个复杂的数据看板页面中，Claude Code的LaunchedEffect多放了一个key，导致筛选逻辑在每次数据刷新时多执行了一次。我最初觉得这是需要修复的无谓重组。

但后来产品要求加一个“数据的实时更新时间戳”显示，这个需求需要在数据变化时更新UI上的一个时间文本。Claude Code“多放的那个key”恰好包含了数据变化的信号，让我加时间戳功能时完全不用改动副作用逻辑。

反思：如果你预判某个页面未来可能会频繁迭代、增加新的联动逻辑，保持AI生成的略微冗余的LaunchedEffect key可能是更务实的做法，它会让后续修改更安全。

当然这只适用于性能消耗很小的场景。如果页面数据量大、重组成本高，还是得精确化。

10.3 取舍框架：一个决策矩阵

十一、前沿展望：新一代AI编码工具是否会改变这些模式？

最后，我想谈谈这个领域正在发生的变化，以及它们对我们开发者意味着什么。

11.1 Claude Code的迭代方向

从2025年上半年的版本更新来看，Claude Code正在强化“项目级上下文感知”。新版本已经开始理解整个项目的目录结构、读取gradle依赖和部分项目配置，这意味着它可能从“看一个文件写一个文件”进化到“理解项目架构约束后生成代码”。

如果这个能力继续提升，前面分析的“信息近端性偏好”和“高频模式偏差”有望被部分缓解。因为当AI能看到你项目中已有的ViewModel定义方式、命名规范和架构分层，它生成的代码更有可能保持一致性。

但目前（截至2025年6月），这种上下文感知仍然偏弱，不能完全依赖。我测试的项目中有大量ViewModel和Usecase层，但Claude Code依然在20%的情况下生成纯Composable的状态管理，而非复用已有的架构模式。

11.2 竞争对手的表现对比

我对比过Google的Gemini CLI和MiniMax的M2.1在相同Compose状态管理任务上的表现。一个简短的发现速报：

• Gemini CLI：在Kotlin/Compose的生成能力上略弱于Claude Code，但它更倾向于使用官方推荐的架构组件（ViewModel + StateFlow）。它的“过度保险”倾向比Claude Code低。
• MiniMax M2.1：宣传中强调了Kotlin能力的增强，实际测试中它的代码结构更接近Android官方的Now in Android架构示范。在ViewModel的引入时机上比Claude Code更准确，但rememberSaveable的使用率同样为0。

结论是：所有主流AI编码工具在Compose状态管理上都存在类似的生成模式偏差，只是在偏差的具体分布上略有不同。 这意味着作为开发者，你需要建立的不是针对某一个AI工具的应对策略，而是一套通用的“AI生成Compose代码质量评估体系”。

11.3 未来的开发者工作流

我的判断是：未来两年内，AI编码工具会进化为能够直接理解并遵循项目级架构约束的程度。届时，“prompt告诉AI架构规则”会被“AI自动检测项目架构并适配”取代，状态管理模式的偏差将大幅缩小。

但在那一天到来之前，能够识别AI生成模式、快速定位架构偏差、并有策略地修正的开发者，会获得远超同行的开发效率。

这不仅是一个技术能力，更是一种新的“AI协作素养”，知道该给AI什么信息、知道AI会产生什么偏差、知道如何用最少的时间修正偏差。本文整理的六个生成模式、四个审查清单和三个决策矩阵，都是这种素养的具体构成。

十二、最后的话

回到文章开头那个购物车项目。在我按本文的方法审查和重构了Claude Code生成的代码后，那个模块最终平稳上线，0崩溃，用户操作流畅度评分提升了12%。当产品经理两周后说“购物车要加一个拼团功能”时，因为状态管理架构合理，我花了不到原估算时间的一半就完成了。

Claude Code确实不是银弹，它生成的Compose状态管理代码有可对话的系统性偏差。但了解这些偏差之后，它就是一个极其高效的协同者：用它的速度生成骨架、用你的判断塑造架构、用结构化的审查保证质量。

下次你再让Claude Code写Compose代码时，回想一下这篇文章里的六个模式。当你发现它又在不必要的地方用了LaunchedEffect的四个key、又在ViewModel外面放了个selectedCoupon、又忘了rememberSaveable，不要沮丧，因为这不是它故意“犯错”，而是一种可以预测、可以被管理、可以被利用的生成模式。

把这种预测能力用起来，你的效率会进入另一个层级。