Claude Code 如何帮我写 80% 的 Android 样板代码

痛点：你写了多少"不用动脑"的代码？

回想一下，你最近一周写的代码里，有多少是真正需要思考的？

我统计了自己上个月的提交记录，结果让我沉默：

• 70% 是 Room DAO、Entity、DTO、Repository 接口------这些代码的规律性极强，靠复制粘贴改个名字就能搞定
• 20% 是 ViewModel 的状态管理和事件分发------结构固定，变化的是业务字段名
• 只有不到 10% 才是真正需要动脑的：架构决策、复杂业务逻辑、性能优化

这意味着，我每天有 6 个小时在写"不用动脑"的代码。

直到我把 Claude Code 接入日常开发流程，这个比例被彻底翻转了。

---

Claude Code 是什么？为什么它不一样？

Claude Code 是 Anthropic 推出的命令行 AI 编程助手，和 Copilot 那种"行级补全"的思路完全不同。它的核心能力是：理解整个代码仓的上下文，然后批量生成、修改、重构代码。

几个关键区别：

特性	Copilot	Claude Code
工作方式	行级/块级补全	任务级指令执行
上下文	当前文件	整个 Git 仓库
交互方式	被动补全	主动对话
代码生成量	几行	几十到几百行

对我来说，最关键的是第三点：你可以像跟一个资深同事说话一样给它下指令，它理解项目结构后直接产出完整文件。

---

实战：四个场景，覆盖 80% 的样板代码

下面是我在实际项目中使用 Claude Code 的四个高频场景。都是在一个百万 DAU 的社交 App 中的真实实践。

场景一：一键生成 Data Layer（Entity + DAO + DTO + Mapper）

传统方式下，加一个新数据表需要写 4-5 个文件，来回切换、复制粘贴，光对齐字段名就要花 10 分钟。

现在我只需要一句指令：

/claude 在 data 层新增一个 UserProfile 表，字段包括：
userId(String, PK)、nickname(String)、avatar(String)、bio(String)、
level(Int, 默认 0)、createTime(Long)

使用 Room，遵循项目现有的 DataLayer 规范。
参考 @UserDao.kt 和 @UserEntity.kt 的风格。

Claude Code 会：

1. 自动读取 UserEntity.kt 和 UserDao.kt 了解项目规范
2. 生成 UserProfileEntity.kt（含 Room 注解、索引定义）
3. 生成 UserProfileDao.kt（含 CRUD + Flow 返回）
4. 生成 UserProfileDto.kt（网络层模型）
5. 生成 UserProfileMapper.kt（Entity ↔ DTO 转换）
6. 自动在 DI 模块中注册新的 DAO

耗时：从 30 分钟降到 2 分钟（含 review）。

生成出来的代码质量如何？举个例子，它自动生成的 DAO：

@Dao
interface UserProfileDao {
    @Query("SELECT * FROM user_profile WHERE userId = :userId")
    fun observeByUserId(userId: String): Flow<UserProfileEntity?>

    @Query("SELECT * FROM user_profile WHERE userId = :userId")
    suspend fun getByUserId(userId: String): UserProfileEntity?

    @Upsert
    suspend fun upsert(profile: UserProfileEntity)

    @Query("DELETE FROM user_profile WHERE userId = :userId")
    suspend fun deleteByUserId(userId: String)
}

不是我写的，但它非常清楚：查询方法用 Flow 返回做响应式观察、写操作用 suspend、使用 Room 2.5+ 的 @Upsert 注解。比很多两年经验的工程师写得都规范。

场景二：ViewModel 样板代码批量生成

Android 的 ViewModel 有固定的模式：State、Event、Effect 三件套 + stateIn() + onEvent() 分发。每个页面的 ViewModel 长得都差不多，业务逻辑才是差异点。

以前我最烦的就是在 ViewModel 里反复写这些结构。现在：

/claude 为 @UserProfileScreen.kt 生成对应的 ViewModel。
使用项目标准的 MVI 模式，参考 @ChatRoomViewModel.kt 的结构。
State 字段：isLoading, profile, errorMessage
Event：LoadProfile, EditBio, SaveProfile
Effect：ShowToast, NavigateBack

Claude Code 读完 ChatRoomViewModel.kt 之后，准确地复刻了项目的 MVI 模式：

@HiltViewModel
class UserProfileViewModel @Inject constructor(
    private val userProfileRepository: UserProfileRepository
) : ViewModel() {

    data class State(
        val isLoading: Boolean = true,
        val profile: UserProfileUiModel? = null,
        val errorMessage: String? = null
    )

    sealed interface Event {
        data object LoadProfile : Event
        data class EditBio(val newBio: String) : Event
        data object SaveProfile : Event
    }

    sealed interface Effect {
        data class ShowToast(val message: String) : Effect
        data object NavigateBack : Effect
    }

    private val _effect = Channel<Effect>(Channel.BUFFERED)
    val effect = _effect.receiveAsFlow()

    private val _event = MutableSharedFlow<Event>()
    private val state: StateFlow<State> = _event
        .onEach { event -> handleEvent(event) }
        .runningFold(State(), ::reduce)
        .stateIn(viewModelScope, SharingStarted.WhileSubscribed(5000), State())

    // ... 业务逻辑由我补充
}

样板部分 100% 自动生成，我只在 handleEvent() 里补充业务逻辑即可。

场景三：Retrofit API 接口 + 拦截器配置

新增 API 接口时，Claude Code 表现也相当稳定：

/claude 新增用户资料编辑的 API 接口：
PUT /api/v1/user/profile
请求体：{ "nickname": "", "bio": "", "avatar": "" }
响应体：{ "code": 0, "data": { "userId": "", "nickname": "", "bio": "", "avatar": "" } }

按照 @UserApiService.kt 的风格写，响应要统一用项目的 BaseResponse 包裹。
同时更新 @AuthInterceptor.kt，这个接口需要携带 token 但不需要签名。

它准确理解了项目的 Retrofit 配置规范：

interface UserApiService {
    @PUT("api/v1/user/profile")
    suspend fun updateProfile(
        @Body request: UpdateProfileRequest
    ): BaseResponse<ProfileResponse>
}

甚至连 @SerializedName 的命名策略都会跟项目保持一致（参考了已有的 DTO 文件）。减少了 API 对接中最常见的一类 bug：字段命名不一致导致的解析失败。

场景四：Compose UI 骨架搭建

Compose 的 UI 层也有很多套路代码：Scaffold + TopAppBar + LazyColumn + item。Claude Code 可以快速搭出骨架：

/claude 参考 @ChatRoomScreen.kt 的写法风格，为 UserProfileScreen 生成 Compose UI 骨架：
- 顶部标题栏："编辑资料"，左侧返回按钮
- 头像区域：圆形头像 + 相机图标覆盖
- 表单区域：昵称、简介输入框
- 底部：保存按钮
使用项目统一的 @TqTheme 主题色

生成的 UI 骨架约 150 行，布局结构、间距、颜色全部对齐项目规范。我只需要微调交互细节。

---

踩坑记录：这 5 件事你必须知道

用了三个月，踩了不少坑。先说最关键的 5 个：

坑1：不提供参考文件，生成风格会飘

Claude Code 的默认代码风格偏"教科书"，不一定匹配你的项目规范。每次指令都要用 @文件 引用参考代码。 这是我的指令模板：

请参考 @SimilarClass.kt 的风格，生成 XXX。

加不加这一句，输出质量差一个档次。

坑2：大文件一次性重写会丢逻辑

千万别让 Claude Code 一次性重写一个 500+ 行的文件。它会"重构"掉你没让它改的逻辑。正确做法是明确"新增方法"还是"替换某段" ：

# 好：精确指定修改范围
在 @UserRepository.kt 的第 45 行之后，新增一个 getUserWithProfile() 方法

# 差：范围太模糊
重构 @UserRepository.kt

坑3：Room 迁移脚本不可盲信

Claude Code 能生成 Migration，但数据库迁移涉及生产数据安全，必须人工 review 每一行 SQL 。我踩过的坑：它生成的 ALTER TABLE 缺少 NOT NULL 列的默认值，迁移会在有数据的设备上崩溃。

原则：AI 生成的 Migration → 本地跑一遍 → 三种 Android 版本实机验证 → 才能上线

坑4：DI（Hilt/Koin）绑定容易遗漏

新增了 Repository 或 DAO 之后，Claude Code 有时会忘记在 DI 模块中注册。我养成了习惯：每次让它生成新类之后，追问一句：

同时也更新 @AppModule.kt，注册新生成的依赖

坑5：生成代码我至少要 Review 两遍

第一遍看逻辑正确性，第二遍看是否符合项目规范（命名、包结构、错误处理方式、日志风格）。AI 写的代码在"可用"这个维度上接近 90 分，但在"可维护"这个维度上大概只有 70 分------你得补上最后那 20 分。

---

效率对比：真实数据

我统计了接入 Claude Code 前一个迭代和接入后一个迭代的代码产出：

指标	接入前	接入后	变化
日均提交文件数	8 个	14 个	+75%
样板代码占比（自评）	~70%	~15%	-79%
花在核心逻辑上的时间占比	~20%	~50%	+150%
bug 率（CR 阶段发现）	基本持平	基本持平	---

关键发现：代码量增加了，但 Bug 率没有上升。 AI 生成的标准化代码反而减少了手写时容易出的低级错误（拼写、空安全遗漏等）。

---

总结：我的工作流变成了这样

Step 1: 花 5 分钟思考 --- 我想实现什么？
Step 2: 花 2 分钟写 Claude Code 指令，@引用参考文件
Step 3: 花 2 分钟等它生成代码
Step 4: 花 5 分钟 Review + 微调
Step 5: 花 30 分钟写真正的业务逻辑

核心转变：我不再是一个"代码打字员"，而是一个"代码审查员 + 架构师"。

如果你也是 Android 开发者，建议你从下周一开始尝试：选取一个需要写样板代码最多的任务，交给 Claude Code，花 10 分钟 review 它的输出。我打赌你会跟我一样回不去。

---

One More Thing

本文提到的所有指令模板我整理成了一个 cheat sheet，可以直接在 Claude Code 里用。如果你有兴趣，评论告诉我，我下一篇写《Claude Code Android 开发指令模板大全》。

---

作者：一线 Android 开发者，专注 Kotlin + Jetpack + MVVM 技术栈，正在探索 AI 对移动端工作流的重塑。