当前位置：首页 > news >正文

AI编程助手如何精通Jetpack Compose？compose-skill技能包实战解析

news 2026/5/5 9:34:30

1. 项目概述

如果你和我一样，每天都在和 Jetpack Compose 打交道，那你肯定也遇到过这个让人头疼的场景：你向 AI 编程助手提问一个 Compose 问题，它自信满满地生成了一段代码，编译通过了，但运行时要么性能拉胯，要么行为诡异，甚至直接崩溃。问题出在哪？这些 AI 模型对 Compose 的理解，往往停留在“语法正确”的层面，它们能拼凑出看起来像那么回事的代码，却不懂背后的“心法”——比如remember和derivedStateOf到底该用哪个？Modifier的顺序为什么不能乱？LazyColumn的key不设置会有什么后果？

这就是aldefy/compose-skill要解决的问题。它不是一个新框架，也不是一个库，而是一个“技能包”。你可以把它理解为一套专门为 AI 编程助手（如 Claude Code、GitHub Copilot、Cursor 等）编写的、极其详尽的 Compose 开发手册和源码速查表。它的核心价值在于，将我们开发者多年踩坑积累的经验、官方最佳实践，乃至 Compose 运行时和 UI 库的真实源码，都“喂”给了 AI。安装了这个技能包之后，你的 AI 助手就不再是那个只会“猜”和“编”的新手，而是一个真正理解 Compose 设计哲学、熟悉其内部机制、能写出生产级代码的“专家级结对编程伙伴”。

这个技能包覆盖了从 Android、Desktop 到 iOS 和 Web 的 Compose 全平台，内容基于androidx/androidx和compose-multiplatform-core的真实源码，确保了指导的准确性。接下来，我将带你深入拆解它的设计思路、核心内容，并分享如何将它集成到你的工作流中，真正提升你的开发效率与代码质量。

1.1 核心需求解析：为什么我们需要一个“AI 技能包”？

在深入技能包细节之前，我们得先搞清楚，为什么通用的 AI 编码工具在 Compose 领域会“失灵”？这背后是几个根本性的鸿沟：

第一，概念理解与实现细节的鸿沟。AI 模型通过海量代码训练，能学会@Composable注解、remember等关键字的使用模式。但它很难理解这些模式背后的“为什么”。例如，它知道mutableStateOf用于创建可变状态，但它可能不知道，在计算依赖于其他状态的派生状态时，使用derivedStateOf可以避免不必要的重组。它生成的代码在语法上是正确的，但在语义和性能上可能是错误的。

第二，API 幻觉与时效性的鸿沟。Compose 是一个快速迭代的框架。AI 模型的训练数据有滞后性，它可能会“幻想”出一些已经废弃的 API（比如旧的字符串路由导航），或者不知道最新版本引入的新特性（如实验性的 Styles API）。这会导致生成的代码无法编译，或者使用了不推荐的模式。

第三，平台差异与最佳实践的鸿沟。Compose 现已支持多平台。在 Android 上能用的 API，在 iOS 或 Web 上可能根本不存在。AI 助手如果不清楚平台间的expect/actual机制，很容易生成无法跨平台编译的代码。同样，针对 TV 的大屏交互、焦点系统，也有其独特的最佳实践，通用模型很难掌握。

第四，设计到代码的转换鸿沟。将 Figma 设计稿转化为 Compose 代码，不仅关乎像素还原，更关乎组件语义、布局结构和主题令牌（Token）的应用。AI 如果只是机械地翻译图层和属性，会生成结构混乱、难以维护的代码。

compose-skill的设计目标，就是填平这些鸿沟。它通过提供结构化的知识（20份参考指南）和权威的“事实核查”依据（6份源码文件），将 AI 助手从一个“模式匹配器”升级为一个“基于知识的推理者”。当 AI 被问到 Compose 问题时，它会先查阅技能包中的工作流程和检查清单，然后定位到具体的参考文件，必要时甚至去核对源码，最终给出一个不仅正确、而且高效、符合最佳实践的答案。

2. 技能包架构与内容深度解析

这个技能包的成功，很大程度上归功于其清晰、分层的架构设计。它不是简单的一堆文档堆砌，而是一个有引导、有深度、可验证的知识体系。

2.1 双层知识体系：从指南到源码

技能包的核心是一个双层结构，我称之为“指南+源码”的黄金组合。

第一层：20 份实践参考指南。这是 AI 助手主要消费的内容。每一份指南都针对一个特定的 Compose 主题，采用“模式、陷阱、该做/不该做”的实用主义写法。例如，在state-management.md中，你不会看到冗长的概念定义，而是会看到清晰的决策树：

场景：需要一个在重组中保持的状态 -> 用remember。
场景：状态变化由其他状态计算而来，且计算开销大 -> 用derivedStateOf。
场景：状态需要在配置更改（如屏幕旋转）后存活 -> 用rememberSaveable。
场景：需要将状态提升到调用方，以实现可测试和可复用 -> 使用状态提升模式。

每一份指南都充满了这种可直接操作的“干货”。以modifiers.md为例，它不会只说“修饰符顺序重要”，而是会给出一个具体的、基于渲染管线的顺序规则清单：

clickable、selectable等交互修饰符应尽可能靠近布局开始处。
padding应在size或fillMaxSize之前，否则内边距会被计算在尺寸约束之外。
background和border的绘制顺序取决于它们出现的先后。
semantics修饰符通常放在最后，因为它不改变布局或绘制。

这种清单式的知识，正是 AI 模型最容易理解和应用的形式。

第二层：6 份核心源码文件。这是技能包的“杀手锏”。当指南中的规则无法覆盖一个极端情况，或者 AI 需要确认某个 API 的确切行为时，它可以去查阅这些从官方仓库提取的源码。例如，当用户问及LaunchedEffect的key参数如何影响副作用重启时，AI 可以引用runtime-source.md中的相关代码片段来解释其生命周期绑定机制。这从根本上杜绝了“幻觉”，因为答案直接来自于实现本身。

注意：源码文件并非完整的库代码，而是经过精心挑选的、最能体现核心机制的部分。例如runtime-source.md可能包含Composer的start/end逻辑、remember的实现、mutableStateOf的订阅机制等关键片段。这确保了查询效率，也避免了让 AI 陷入无关代码的海洋。

2.2 核心主题覆盖：从基础到前沿

技能包涵盖的主题之广，令人印象深刻。它不仅覆盖了 Compose 的基础，还深入了当前最前沿和最容易出问题的领域。我们可以将其分为几个大类：

1. 核心机制与性能：

状态管理 (state-management.md)：深入讲解各种状态原语的选择策略，这是 Compose 心智模型的核心。
副作用管理 (side-effects.md)：厘清LaunchedEffect、DisposableEffect、SideEffect的区别与适用场景，以及key参数的正确用法。
性能优化 (performance.md)：重组跳过机制、@Stable和@Immutable注解的实战意义、延迟读取、基准测试等。
修饰符系统 (modifiers.md)：顺序规则、自定义修饰符，以及面向未来的Modifier.Node迁移指南。

2. UI 构建与导航：

视图组合 (view-composition.md)：如何结构化可组合项、使用槽位 API、编写有效的@Preview。
列表与滚动 (lists-scrolling.md)：LazyColumn等惰性列表的深度优化，包括key、contentType的重要性。
导航 (navigation.md)：坚决推行类型安全路由（使用@Serializable），告别过时的字符串路由，并涵盖深层链接、共享元素转场等。

3. 设计、主题与动画：

主题与 Material 3 (theming-material3.md)：全面介绍MaterialTheme、动态配色、排版系统，以及如何构建一致的设计系统。
动画 (animation.md)：从基础的animate*AsState到复杂的updateTransition，还提供了 9 种常见动画（如 shimmer、swipe-to-dismiss）的“食谱”。
设计转代码 (design-to-compose.md)：这是一套算法，指导如何将设计稿中的图层智能地分解为语义化的 Compose 组件和正确的修饰符顺序，而非生硬的 1:1 映射。

4. 多平台与生产实践：

多平台开发 (multiplatform.md)：Compose Multiplatform 的架构思想、expect/actual的使用、Res.*资源管理，以及从单平台迁移的指南。
平台特定问题 (platform-specifics.md)：针对 Desktop、iOS、Web/WASM 平台的 API 差异和常见陷阱。
TV 开发 (tv-compose.md)：专门针对 Android TV 的大屏交互、焦点导航系统和 TV Material 3 组件。
生产崩溃手册 (production-crash-playbook.md)：来自真实应用的 6 大崩溃模式（如零尺寸DrawScope、重复key、陈旧的derivedStateOf）及其根因分析和修复方案，极具价值。

5. 高级与实验性主题：

原子化设计 (atomic-design.md)：如何将设计系统的 5 层结构（令牌、原子、分子、有机体、模板）映射到 Compose 的组件层次，建立可扩展的 UI 架构。
M3 动效 (theming-material3.md延伸)：详细解析 Material 3 的所有持续时间令牌、缓动曲线令牌以及MotionSchemeAPI，实现系统级的一致动效。
实验性样式 API (styles-experimental.md)：前瞻性地介绍Style {}API 的使用、陷阱以及与主题的集成方式。

这种全面的覆盖，确保了无论你是在处理基础的 UI 状态，还是在构建一个复杂的跨平台应用，或是优化一个 TV 应用的焦点流，AI 助手都能找到对应的专家级指导。

3. 集成与实操：让 AI 助手成为你的 Compose 专家

技能包本身是静态的 Markdown 文件，它的威力需要通过集成到具体的 AI 编码工具中才能发挥。官方文档提供了几乎所有主流工具的集成方案，其核心思想都是一致的：将技能包的路径告知你的 AI 助手，让它能在处理 Compose 相关问题时自动查阅。

3.1 通用集成原理与步骤

无论你使用哪种工具，集成的本质是修改该工具的“上下文”或“指令”文件。这个文件通常位于项目根目录或用户配置目录，AI 助手在分析你的代码和问题时，会读取这个文件中的指令。

通用步骤：

获取技能包：将aldefy/compose-skill仓库克隆到本地，或作为子模块添加到你的项目中。
定位技能包路径：技能包的核心文件位于skills/compose-expert/目录下。你需要记住这个目录在你本地或项目中的绝对或相对路径。
修改 AI 工具的指令文件：根据你使用的工具，找到对应的指令文件（如 Claude Code 的~/.claude/skills/， Cursor 的.cursor/rules/， Copilot 的.github/copilot-instructions.md等）。
添加引用指令：在指令文件中添加一条规则，大意是：“当遇到 Jetpack Compose 相关的问题时，请遵循[技能包路径]/SKILL.md中的工作流程，并参考references/目录下的相关指南和源码文件。”
验证集成：重启你的 AI 助手或编辑器，然后尝试问一个具体的 Compose 问题，观察其回答是否引用了技能包中的特定模式或建议。

3.2 不同工具的配置要点与避坑指南

虽然原理相同，但每个工具在配置细节上略有不同。以下是我在实际配置中总结的一些关键点和常见陷阱：

对于 Claude Code：Claude Code 的“技能”机制非常直接。你只需要将skills/compose-expert整个文件夹复制到指定的技能目录即可。

个人技能（推荐）：复制到~/.claude/skills/。这样在所有项目中都可以使用。
项目技能：复制到项目根目录的.claude/skills/下。
避坑点：确保复制的文件夹名称是compose-expert，并且内部包含SKILL.md文件。Claude Code 是通过识别这个文件来激活技能的。完成后，你不需要任何命令，在聊天中提及 Compose 相关关键词时，技能会自动生效。

对于 Cursor：Cursor 使用.mdc文件定义规则。你需要创建一个规则文件来指向技能包。

操作：在项目根目录创建.cursor/rules/compose-skill.mdc文件。

内容示例：

--- description: Jetpack Compose expert guidance globs: **/*.kt --- For all Compose-related code in Kotlin files, follow the expert workflow and consult the references defined in `[你的路径]/skills/compose-expert/SKILL.md`.

避坑点：globs: **/*.kt这行很重要，它限定了此规则仅作用于 Kotlin 文件，避免 AI 在处理其他文件时也误用 Compose 规则，造成干扰。确保路径[你的路径]是准确的相对路径或绝对路径。

对于 GitHub Copilot：Copilot 通过项目根目录的.github/copilot-instructions.md文件接收指令。

操作：在该文件中添加一个专门的章节。

内容示例：

## Jetpack Compose Expert Guidance When working on Jetpack Compose or Android UI code, you MUST adhere to the following: 1. First, read and follow the structured workflow in `[你的路径]/skills/compose-expert/SKILL.md`. 2. For any specific topic (e.g., state management, navigation, performance), consult the corresponding markdown file in the `[你的路径]/skills/compose-expert/references/` directory before generating code. 3. If unsure about API behavior, refer to the actual source code snippets in `[你的路径]/skills/compose-expert/references/source-code/`. Do not guess. Use the provided references as the single source of truth for Compose patterns and APIs.

避坑点：指令要写得清晰、强硬（使用“MUST”），并明确优先级（先读 SKILL.md，再查具体指南）。Copilot 有时会忽略较弱的建议。将技能包作为子模块 (git submodule) 添加到项目中，是管理路径和更新的好方法。

对于 Codex CLI / Gemini CLI 等：这类工具通常依赖于项目根目录的AGENTS.md或GEMINI.md文件。集成方式与 Copilot 类似，将技能包作为子模块引入，然后在对应的 Markdown 文件中添加详细的引用说明。

实操心得：我强烈建议将技能包设置为“个人全局技能”（如 Claude Code 的个人目录或 Antigravity 的全局目录）。这样，你无需在每个新项目都重复配置一次。对于团队项目，则推荐将技能包作为Git 子模块添加到仓库中，并在项目的 AI 指令文件里引用它，这样可以确保团队所有成员都使用同一套、最新版本的专家指导。

4. 实战效果对比：技能包安装前后的天壤之别

理论说得再多，不如看实际效果。安装compose-skill后，AI 助手生成的代码质量会有质的飞跃。我们可以通过几个典型场景来对比：

4.1 场景一：状态管理选择

问题：“我有一个计数器，当它大于10时，显示一个提示标签。”

安装前，AI 可能生成：

var count by remember { mutableStateOf(0) } val showHint = remember { count > 10 } // 错误！这不会响应 count 的变化 if (showHint) { Text("Count is over 10!") }

这里 AI 错误地在remember内部捕获了count的初始值，导致showHint永远不会更新。

安装后，AI 参考state-management.md，会生成：

var count by remember { mutableStateOf(0) } val showHint by remember { derivedStateOf { count > 10 } } // 正确！使用 derivedStateOf if (showHint) { Text("Count is over 10!") }

AI 现在知道，一个依赖于其他状态的计算值，应该使用derivedStateOf来创建，以确保其响应性。

4.2 场景二：列表性能优化

问题：“我的LazyColumn在快速滚动时卡顿。”

安装前，AI 可能只会建议：“检查你的item内容是否太重。” 这是一个正确但无用的泛泛之谈。

安装后，AI 会结合lists-scrolling.md和performance.md，提供一份详细的检查清单：

检查item的key参数：是否为每个项提供了唯一且稳定的key？没有key，Compose 无法有效复用项，导致大量不必要的重组和初始化。
```
// 差 items(users) { user -> ... } // 好 items(users, key = { it.id }) { user -> ... }
```
检查contentType：是否为不同类型的项设置了contentType？这有助于 Compose 更智能地复用相同类型的项。
```
LazyColumn { items(users, key = { it.id }, contentType = { it.type }) { user -> ... } }
```
检查项内容的稳定性：传递给item的 Lambda 内部，是否使用了不稳定的参数或捕获了不稳定的变量？这可能导致项本身的不稳定，阻碍重组跳过。AI 会建议使用@Stable注解数据类，或将 Lambda 提取为独立的、稳定的可组合函数。
建议使用derivedStateOf处理滚动偏移：如果项内容依赖于滚动位置进行计算，AI 会建议将计算包装在derivedStateOf中，避免在每一帧滚动时都触发重组。

4.3 场景三：导航模式

问题：“如何实现从主页到详情页的导航？”

安装前，AI 可能给出基于已废弃的compose-navigation字符串路由的代码，或者使用不安全的类型转换。

安装后，AI 严格遵循navigation.md中的类型安全路由指南：

// 1. 定义可序列化的路由类 @Serializable object Home @Serializable data class Details(val itemId: String) // 2. 使用类型安全的导航图 NavHost(navController, startDestination = Home) { composable<Home> { HomeScreen(onItemClick = { id -> navController.navigate(Details(id)) }) } composable<Details> { backStackEntry -> val details: Details = backStackEntry.toRoute() DetailsScreen(itemId = details.itemId) } }

AI 会强调使用@Serializable和类型安全的composable<T>DSL，彻底避免路由字符串的拼写错误和类型安全问题。

4.4 场景四：多平台资源访问

问题：“在 Compose Multiplatform 中，如何加载一张图片？”

安装前，AI 可能会直接使用androidx.compose.foundation.Image并传入一个本地资源 ID，这在 iOS 或 Desktop 上会失败。

安装后，AI 根据multiplatform.md和platform-specifics.md，会生成平台正确的代码：

// 在 commonMain 中 expect fun getImageResource(name: String): ImageBitmap // 在 androidMain 中 actual fun getImageResource(name: String): ImageBitmap { val context = LocalContext.current val resId = context.resources.getIdentifier(name, "drawable", context.packageName) return ImageBitmap.imageResource(id = resId) } // 在 desktopMain 中 (示例，实际可能从文件系统加载) actual fun getImageResource(name: String): ImageBitmap { // 使用 Compose for Desktop 的加载方式 return org.jetbrains.skiko.loadImageBitmap(File("path/to/$name.png").readBytes()) } // 在可组合函数中使用 @Composable fun MyImage() { Image(bitmap = getImageResource("my_icon"), contentDescription = null) }

AI 会解释expect/actual机制，并指导如何根据Res.*等共享资源模块来组织资源，实现真正的跨平台资源管理。

从以上对比可以看出，安装了技能包的 AI 助手，其输出从“可能正确”变成了“基于最佳实践的、可靠的”建议。它不仅能给出正确的代码，还能解释为什么这么做，以及不这么做的后果，真正扮演了专家级代码审查和指导的角色。

5. 高级应用与自定义扩展

compose-skill本身已经非常强大，但它的设计是开放和可扩展的。你可以根据自己团队或项目的特定需求，对其进行定制和增强。

5.1 集成团队内部规范

很多团队有自己的编码规范、自定义组件库或架构模式。你可以轻松地将这些内容整合进技能包。

操作：在references/目录下创建新的 Markdown 文件，例如my-company-design-system.md。
内容：详细描述你们团队的设计令牌系统、自定义主题扩展、基础组件（如MyButton、MyCard）的 API 契约和使用示例。
链接：在SKILL.md的工作流程或检查清单中，添加指向你这个新文件的链接。例如，在“设计系统”部分，可以加上：“对于我司自定义设计系统，请参考references/my-company-design-system.md。”
效果：此后，当 AI 助手被问及如何构建一个按钮时，它不仅会参考 Material 3 的标准，还会优先推荐并使用你们团队的MyButton组件及其属性。

5.2 添加特定领域知识

如果你的应用涉及地图、图表、音视频播放等特定领域，而这些领域的 Compose 集成有独特的最佳实践或坑点，你也可以为其创建指南。

示例：创建references/maps-compose.md，总结在使用 Google Maps Compose 库或 Mapbox 时，如何管理相机状态、处理标记点击、以及避免内存泄漏（如确保在DisposableEffect中清理监听器）。
示例：创建references/media-playback.md，指导如何使用androidx.media3与 Compose 集成，处理播放器状态与 UI 的同步、全屏切换的 CompositionLocal 使用等。

5.3 维护与更新策略

Compose 生态在快速发展。为了保持技能包的时效性，你需要一个更新策略。

关注上游：定期关注androidx/androidx和JetBrains/compose-multiplatform的发布日志和源码变动。
更新指南：当发现新的最佳实践、API 变更或废弃通知时，及时更新对应的参考文件。例如，当 Compose 编译器引入新的稳定性推断规则时，需要更新performance.md。
更新源码：对于source-code/目录下的文件，可以定期从官方仓库同步最新的相关代码片段，确保“事实核查”的准确性。
社区贡献：正如项目本身所鼓励的，你可以将你在生产环境中遇到的新“崩溃模式”或“优化技巧”总结成 PR，贡献回原项目，让更多人受益。

5.4 性能与成本考量

将大量 Markdown 文件作为上下文提供给 AI，可能会增加每次交互的令牌（Token）消耗和响应时间。在实际使用中，我观察到以下情况：

Claude Code/Cursor 等智能路由工具：它们通常具备良好的上下文管理能力，可能只在检测到 Compose 相关关键词时才动态加载部分技能内容，对性能影响较小。
Copilot 等自动补全工具：指令文件始终在上下文中，但通常只包含指向技能包的元指令，而非全部内容。实际的指南内容是在 AI 需要时，由底层模型根据文件路径去检索的（如果工具支持文件检索功能）。如果工具不支持，则需要将最关键的规则内联在指令文件中。
最佳实践：保持你的指令文件简洁，只包含最高层次的引导规则。确保技能包的文档结构清晰、关键词明确，方便 AI 快速定位。对于非常庞大的项目，可以考虑只集成最常用或最易出错的几个主题指南（如state-management.md,performance.md,production-crash-playbook.md）。

6. 常见问题与排查技巧实录

即使正确安装和配置了技能包，在实际使用中也可能遇到一些问题。以下是我在长期使用中总结的一些常见情况及解决方法。

6.1 AI 助手似乎没有引用技能包

症状：询问 Compose 问题，AI 的回答依然是通用、浅显的，没有体现出技能包中的深度建议或具体模式。

排查步骤：

检查安装路径：首先确认技能包文件夹是否被复制到了正确的位置。对于 Claude Code，检查~/.claude/skills/compose-expert/是否存在且包含SKILL.md。
检查指令文件语法：打开你为 AI 工具配置的指令文件（如.cursor/rules/compose-skill.mdc或.github/copilot-instructions.md），检查路径是否正确，指令是否清晰无歧义。确保没有语法错误（如 Markdown 格式错误）。
重启工具：许多 AI 集成工具（尤其是编辑器插件）需要在修改配置后完全重启才能生效。关闭并重新打开你的 IDE 或编辑器。
验证触发关键词：技能包的触发通常依赖于关键词。尝试在提问中明确使用技能包覆盖的核心术语，如“根据 Compose 最佳实践”、“参考状态管理指南”、“如何避免重组”等。
查看工具日志：一些工具（如 Cursor）可能有调试模式或日志输出，可以查看 AI 是否读取了你的规则文件。
简化测试：创建一个全新的、干净的项目，只集成技能包，然后问一个非常具体、技能包中明确有答案的问题（例如：“remember和rememberSaveable有什么区别？”），看 AI 的回答是否引用了技能包内容。

6.2 AI 给出的建议互相矛盾或过时

症状：AI 同时引用了技能包的建议和它自身训练数据中的旧知识，导致矛盾。

原因与解决：这通常是因为指令的优先级或强度不够。AI 的底层模型在训练时已经学习了大量 Compose 代码（其中包含过时或错误的模式）。如果你的指令只是“可以参考”，模型可能会将其与其他知识混合。

强化指令：在指令文件中使用更强制性的语言。例如，将“请参考”改为“你必须遵循”、“首要依据”、“禁止使用已废弃的模式，必须使用技能包中指定的类型安全路由”。
提供明确优先级：在指令中明确：“当技能包指南与你的其他知识冲突时，以技能包为准。”
检查技能包时效性：确保你使用的技能包版本与你的 Compose 版本相匹配。如果技能包版本较旧，它可能没有涵盖最新的 API（如新的ImmutableList注解）。考虑更新或自行补充。

6.3 技能包内容太多，影响响应速度

症状：集成后，AI 助手的响应速度明显变慢。

解决思路：

精简集成：不要一次性加载全部 20 个指南。分析你的项目最常涉及哪些领域（例如，主要是 UI 状态和列表），只将SKILL.md和那几个核心指南（如state-management.md,lists-scrolling.md,performance.md）的路径加入指令。其他指南可以按需手动引导 AI 查阅。
优化指令：在指令中让 AI 先尝试根据核心指南回答，如果不够，再按需查询其他特定文件。这需要更精细的指令设计。
工具选择：考虑换用上下文管理更智能的工具。一些较新的 AI 编码助手能更好地处理长上下文，并只提取相关片段。

6.4 如何处理技能包未覆盖的极端情况

症状：遇到了一个非常 niche 的问题，技能包的指南和源码中都没有直接答案。

正确做法：技能包不是万能的百科全书。在这种情况下，AI 助手会退回到其基础能力。此时，你可以：

引导 AI 进行推理：基于技能包中提供的原理（如重组机制、状态快照系统），让 AI 尝试推理可能的行为。你可以问：“基于runtime-source.md中描述的remember的存储机制，你认为在这个边缘情况下会发生什么？”
结合官方文档：明确要求 AI 同时参考 Android Developers 官方文档或 Kotlinlang 文档。
进行实证测试：对于编译器或运行时的具体行为，最可靠的方式是编写一个小型实验程序进行验证。你可以让 AI 帮你生成这个测试代码。
贡献社区：如果你最终找到了解决方案，并且认为这是一个具有普遍性的模式或坑点，非常欢迎你向aldefy/compose-skill项目提交 PR，补充相应的内容，帮助后来的开发者。

6.5 跨团队协作的一致性

挑战：如何在团队中确保每个人都使用相同版本和配置的技能包，以保证 AI 辅助代码风格的一致性？

解决方案：

将技能包作为子模块：这是最佳实践。在项目仓库中添加aldefy/compose-skill作为 Git 子模块，并将其放在一个固定的目录（如tools/ai-skills/compose-expert）。
标准化指令文件：在项目根目录放置团队统一的 AI 指令文件（如.cursor/rules/compose.mdc、.github/copilot-instructions.md），其中使用相对路径引用子模块中的技能包。
纳入开发环境配置：在团队的README.md或CONTRIBUTING.md中，明确说明初始化项目后需要运行git submodule update --init来拉取技能包。
定期更新子模块：指定专人或在团队周期会议中，定期更新子模块到官方仓库的最新版本，并同步更新团队内部的定制内容。