技能使用指南

android-architecture（Android架构设计）Skill 是什么？如何下载使用？

android-architecture（Android架构设计）Skill 专注 MVVM、清洁架构分层、Hilt 依赖注入与 Repository 模式，能一键输出 ViewModel、UseCase、Room 与数据映射代码并纠正反模式。本文讲清技能功能、安装验证步骤、使用流程、竞品对比与适用场景，帮 Android 开发者快速落地最佳实践。

Android架构设计Skillandroid-architecture
8 个章节 约 18 分钟阅读 AI 智能生成

android-architecture（Android架构设计）：把 MVVM 与清洁架构的最佳实践变成可落地的代码方案

  • 它是什么：一个面向现代 Android 架构的 AI 技能，专注 MVVM、清洁架构分层、Hilt 依赖注入、Repository 模式、Room 缓存与页面状态管理，技能 ID 为 14026。
  • 能做什么：不止给出概念解释，还能输出可直接参考的 Kotlin 代码骨架，包括 UI 状态、ViewModel、UseCase、Repository 接口与实现、Hilt Module、Entity/DAO 与数据映射器。
  • 怎么用：用自然语言描述你的模块与痛点，它按照 Google 推荐实践给出分层目录与代码；技能具备读取、写入、编辑、Bash、Grep、Glob 等工具权限，可在项目内检索与改动文件。
  • 和普通问答的差别：它内置了"反模式"清单（上帝 Activity、ViewModel 里直接发网络请求、暴露可变状态），会主动指出错误写法并给出正确写法。
  • 注意点：该技能在技能清单中标注为「用户可调用: false」，通常由 Agent 在识别到架构类任务时引用，具体调用入口与安装方式以官方说明为准。

1. 该技能叫什么？如何下载安装 AI 技能提升开发效率？

基本信息

项目 内容
技能中文名 Android架构设计Skill
技能英文名 android-architecture
技能ID 14026
技能定位 遵循 Google 推荐实践的现代 Android 架构模式参考与代码生成能力
可用工具权限 读取、写入、编辑、Bash、Grep、Glob
用户可调用 否（标注为 false，倾向由 Agent 在任务中自动引用）

它解决什么问题

Android 项目做久了，最常见的三个问题几乎人人都会遇到：

  1. 职责混乱：网络请求、数据库读写、UI 状态全塞在一个 Activity 或 Fragment 里，改一个功能要翻几百行代码。
  2. 分层缺失：没有 domain 层，业务逻辑散落在 ViewModel 和数据层之间，单元测试几乎无从下手。
  3. 依赖管理失控：Retrofit、Room、Repository 到处 new，换一个实现就要改十几个文件。

android-architecture 技能针对的正是这些问题：它把 MVVM 的写法、清洁架构的目录分层、Hilt 的模块定义、Repository 的接口与实现约定、Room 的 Entity/DAO 结构、DTO→Entity→Domain 的映射规则，以及"什么是反模式"整理成一套可以直接落地的参考答案。

一键安装 AI 技能提升开发效率的思路

AI 技能的安装通常遵循"找到技能 → 加入技能库 → 在会话中启用 → 验证生效"四步，具体命令、入口地址与账号体系以官方说明为准，本文不提供未经确认的具体命令行：

  1. 确认前提：你需要一个支持技能（Skill）扩展的 AI 客户端或 Agent 平台，并已登录可用账号；本地开发环境建议已具备 Kotlin / Gradle 基础工程，方便技能直接读取和改写代码。
  2. 找到技能：在技能市场或技能库中搜索技能英文名 android-architecture，或用技能 ID 14026 精确定位，核对描述是否为"在实现 MVVM、清洁架构、使用 Hilt 进行依赖注入或结构化 Android 应用层时使用"。
  3. 一键加入：点击安装/添加按钮把技能加入你的技能列表。若你的客户端支持工作流编排，可把它挂载到"Android 开发"或"代码重构"类工作流下。安装路径与按钮位置以官方说明为准。
  4. 验证是否生效：新建一个会话，输入一句最简单的测试指令，例如"用 MVVM 给出一个 UserViewModel 的最小骨架，状态用 StateFlow 暴露"，观察输出是否出现 private val _uiState = MutableStateFlow(...) 与 val uiState: StateFlow<...> = _uiState.asStateFlow() 这种"暴露不可变状态"的标准写法。出现即说明技能已生效。
  5. 提示词触发技巧：由于标注为「用户可调用: false」，你可能无法像普通命令那样直接点名调用它，更稳妥的做法是在需求里显式提到 “MVVM / 清洁架构 / Hilt / Repository / Room” 等关键词，让 Agent 判定需要引用该技能。

2. 该技能的主要功能和特点

  • MVVM 三层骨架生成：可输出 UI 状态数据类（如 UserUiState 含 user、isLoading、error）、继承 ViewModel 的视图模型、以及 hiltViewModel() 注入的 Composable，UI 与业务逻辑清晰分离。
  • 清洁架构目录规范：给出 data（local / remote / repository）、domain（model / repository / usecase）、presentation（ui / viewmodel）的标准分层，让团队对"代码该放哪"形成共识。
  • Repository 模式双端约定：domain 层只暴露接口（getUser 返回 Flow<User>、saveUser 返回 Result<Unit>），data 层提供实现，并示范"先发缓存、再拉网络"的写法。
  • Hilt 依赖注入模块化：提供 @Module + @InstallIn(SingletonComponent::class) 的 NetworkModule、RepositoryModule（用 @Binds 绑定接口与实现）、DatabaseModule，以及 @HiltViewModel + @Inject constructor 的注入示例。
  • UseCase 业务逻辑封装：把业务动作收敛成 GetUserUseCase 这类可调用对象，内部配合 Result.Loading / Success / Error 密封类，并可插入埋点与错误上报。
  • Room 数据库完整示例：@Entity 定义、@Dao 查询（含 Flow 观察式查询）、@Database 声明、依赖注入提供方式一应俱全。
  • DTO / Entity / Domain 三模型映射：明确数据传输对象、数据库实体、领域模型各司其职，并提供双向映射函数，避免网络字段名污染业务层。
  • 单一数据源（SSOT）模式：离线优先仓库示例，UI 只观察数据库 Flow，网络刷新在后台完成后写入数据库，天然支持断网可用。
  • 类型安全导航参数：用密封类定义路由，配合 NavHost 与 navArgument 传参，避免字符串拼接出错。
  • 统一错误处理与状态渲染：UiState 密封类配合通用 StateHandler，加载中、错误（带重试）、成功三种状态一处统一处理。
  • 反模式纠正能力：主动识别"上帝 Activity / Fragment"、“ViewModel 里直接 new OkHttpClient”、"把 MutableStateFlow 公开暴露"三类典型坏味道，并给出正确写法对照。

和普通工具比强在哪：普通脚手架模板只给你一份固定文件结构，改需求还得自己想；通用代码搜索给你的是一堆风格不一的博客片段。这个技能输出的是一整套内部自洽、彼此引用、按同一套约定组织的代码，且自带"什么不该做"的对照，对团队统一规范尤其有用。

3. 如何使用该技能？

由于该技能的元信息标注为「用户可调用: false」，实际使用方式更接近"在对话或 Agent 任务中被引用"，而不是敲一条命令。以下是通用使用流程：

步骤一：明确你要解决的架构问题

不要只说"帮我写个 Android 架构"，而是说清楚模块、现状和约束。示例输入：

我有一个 Kotlin 电商 App 的用户中心模块，现在所有网络请求、Room 读写和 loading 状态都写在 UserFragment 里，差不多 800 行。请用 MVVM + 清洁架构重构：domain 层出接口和 GetUserUseCase，data 层用 Retrofit + Room 实现 Repository，依赖注入用 Hilt，UI 用 Compose + StateFlow。

步骤二：让它先给分层方案，再给代码

推荐的追问顺序是"先结构、后细节"：先让它输出 data / domain / presentation 的目录树和每层职责，确认无误后再逐层生成代码。这样能避免一次性拿到一大坨代码却不知道从哪看起。

步骤三：逐层获取代码并核对关键点

  • 状态层：确认 UI 状态是单一数据类，字段含数据、加载中、错误三类。
  • ViewModel 层：确认可变状态是 private val _uiState，对外暴露 StateFlow 而非 MutableStateFlow；异步用 viewModelScope.launch。
  • 领域层：确认 Repository 只有接口，UseCase 通过构造函数注入 Repository。
  • 数据层：确认实现类同时持有 API 与 DAO，缓存优先、网络兜底。
  • 注入层：确认接口与实现通过 @Binds 绑定，Retrofit / Room 通过 @Provides 提供。

步骤四：借助工具权限直接落地到项目

该技能允许使用读取、写入、编辑、Grep、Glob、Bash 等工具，因此可以让它在你的工程里检索现有类名、创建新文件、修改引用，并用 Bash 执行 Gradle 构建来验证是否编译通过。首次让它改代码前，建议先提交一次 Git 快照，便于回滚。

步骤五：验证与回归

生成后重点验证三件事：能否编译通过、hiltViewModel() 注入是否正常解析、断网时是否仍能从 Room 读到缓存数据。这三条能过，说明分层基本立住了。

输出说明：典型输出是一份可直接参考的 Kotlin 代码集合，包含 UI 状态类、ViewModel、Repository 接口与实现、Hilt 模块、Room 实体与 DAO、映射器函数，以及一份"你原来写法的问题在哪"的对照说明。

4. 同类型竞品对比分析

方案名称 定位 核心功能 安装/使用门槛 适用场景 优势与不足
android-architecture 技能 AI 驱动的 Android 架构方案生成与重构助手 MVVM、清洁架构分层、Hilt 注入、Repository、Room、映射器、反模式纠正 需在支持技能的 AI 客户端中启用；具体安装入口以官方说明为准 老项目重构、新模块起底、团队规范对齐 优势：一次输出成套自洽代码，能直接在工程内读写文件、可执行构建验证；不足：生成结果仍需人工评审，UI 细节与业务规则需自行补齐
Google 官方架构指南与示例工程 权威文档与开源示例 架构原则说明、完整示例项目源码 免费公开，需自行阅读与移植 学习架构思想、对照最佳实践 优势：权威、更新及时、无版权顾虑；不足：示例是别人的业务，移植到自己项目需大量手工改造，不针对你的代码提问
通用大模型直接问答 聊天式代码问答 解释概念、生成片段代码 门槛低，打开即用 临时问一个写法、查 API 优势：灵活、可追问；不足：回答风格不稳定，容易混用 MVVM 与 MVI、漏掉分层约定，缺少工具权限无法直接改项目
Android Studio 工程模板 / 第三方脚手架 IDE 内置或社区模板 生成固定目录结构与样板文件 新建工程时选择即可 从零起新项目 优势：开箱即用、零成本；不足：模板僵化，不解释"为什么这样分层"，遇到已有代码的重构场景基本无能为力

选型建议：如果你要的是"把已有代码按最佳实践重新组织"，优先考虑 android-architecture 技能；如果你只是想快速起一个空工程，IDE 模板更省事；如果你需要权威依据对外做技术评审，官方架构指南仍是最佳背书。

5. 该技能的典型应用场景与实际体验情况

场景一：接手祖传代码的 Android 开发者

痛点：接手一个所有逻辑都在 Fragment 里的项目，首个需求就要改用户模块，不敢动、也不敢重构。 使用方式：把目标文件交给技能，要求"保持对外行为不变，仅做分层与依赖注入改造"，先出分层方案再逐层替换。 实际体验：上手难度低，因为技能自带反模式清单，能直接指出"这里在 ViewModel 里 new 了网络客户端"这类问题，说服力强。注意事项：大文件一次性改造风险高，建议按模块切分、每改一层跑一次构建。

场景二：需要从 0 搭新模块的团队

痛点：三个人三种写法，有人把 UseCase 写成静态工具类，有人直接在 Composable 里调 Retrofit。 使用方式：让技能输出目录规范与各层模板代码，作为团队基线，之后新代码照着填。 实际体验：效果最直接的是"约定统一"——Repository 接口放 domain、实现放 data、映射函数集中在 mapper，评审时争论明显减少。注意事项：团队需要就命名与包结构达成一致后再批量套用。

场景三：需要离线可用的内容型 App

痛点：断网就白屏，用户抱怨；加了缓存又出现"数据不一致"。 使用方式：要求技能按"单一数据源"给出离线优先仓库实现，UI 只观察数据库 Flow，网络刷新在后台写库。 实际体验：思路清晰，onStart 触发后台刷新的写法很好理解。注意事项：需要自行补充冲突解决策略与刷新频率控制，技能只给骨架。

场景四：Compose + 导航的页面状态治理

痛点：每个页面都自己写 loading 和错误提示，样式与逻辑重复，错误页还没有重试按钮。 使用方式：让技能给出统一 UiState 密封类与通用 StateHandler Composable，再配合密封类路由定义导航参数。 实际体验：改动量小、收益明显，页面代码量能显著下降。注意事项：泛型状态处理器要留意与各页面数据类型的匹配。

6. 该技能能为用户带来的价值

  • 效率提升：把"查文档 → 想结构 → 写样板 → 调注入"这条链路压缩成一次对话。分层目录、Hilt 模块、Room DAO 这些高度模板化的代码，原本要花数小时甚至半天，现在分钟级拿到初稿，人力集中在业务规则与边界处理上。
  • 门槛降低：对刚接触清洁架构的开发者，最大的障碍不是不会写 Kotlin，而是不知道"接口该放哪一层、映射该在哪做"。技能用可运行的具体代码回答这类"只可意会"的问题，比读十篇博客更有效。
  • 质量收益：内置反模式纠正，等于给代码评审配了一个随时在线的架构检查员，能减少"可变状态被暴露"“业务逻辑写进 UI”"直接依赖具体网络实现"这三类高频设计债。
  • 长期价值：分层规范一旦落地，后续换网络库、换数据库、加单元测试的成本都会显著下降；domain 层不依赖任何框架，测试写起来也最轻。
  • 可量化参考：以用户中心模块为例，从"800 行 Fragment"拆成 ViewModel + UseCase + Repository 接口/实现 + DAO + 映射器后，单文件职责下降、可测试点数量上升，后续同类模块可以按同一模板复制，边际成本持续走低。

7. 常见问题 FAQ

Q1：这个技能怎么安装？装了怎么确认生效？ 在支持技能的 AI 客户端技能库中搜索 android-architecture 或技能 ID 14026，核对描述为"在实现 MVVM、清洁架构、使用 Hilt 进行依赖注入或结构化 Android 应用层时使用"后加入技能列表，具体入口与安装命令以官方说明为准。验证方法是提一个"用 StateFlow 暴露 UI 状态"的小需求，看输出是否给出 private val _uiState + asStateFlow() 的标准写法。

Q2：这个技能收费吗？ 技能本身的定价与是否包含在订阅内，取决于你使用的平台与版本，以官方说明为准。需要说明的是，技能运行时会消耗你所使用 AI 服务的额度，这部分同样按平台规则计费。

Q3：适合谁用？初级开发者会不会被"带偏"？ 适合 Android 开发者、技术负责人、以及需要统一团队规范的架构评审者。初级开发者反而受益更大，因为技能会同时给出"坏写法"和"好写法"的对照，比如"直接暴露 MutableStateFlow"为什么会出问题，这比只看正确代码更容易建立判断力。但前提是不要无脑复制——务必先理解为什么这样分层。

Q4：它和直接问通用大模型有什么区别？ 通用大模型也能生成 MVVM 代码，但风格不稳定，容易混用 MVVM 与 MVI、忘记把可变状态私有化、把 Repository 实现写进 domain 层。该技能内置固定的分层约定与反模式清单，输出更一致；同时它具备读取、写入、编辑、Grep、Glob、Bash 等工具权限，可以在你的工程里检索类名、创建文件并执行构建验证，这是纯聊天式问答做不到的。

Q5：它会不会擅自改我的项目代码？ 技能具备写入与编辑权限，理论上可以直接改动文件。稳妥做法是：第一次使用时先要求"只输出方案与代码，不改文件"，确认无误后再允许落盘；同时在使用前提交 Git 快照，改完先跑一次构建与关键流程回归。该技能标注为「用户可调用: false」，通常由 Agent 在任务中引用，实际触发范围仍受你所使用客户端的工作流控制，具体行为以官方说明为准。