写在前面
最近我基于 Kotlin Multiplatform (KMP) 设计并实现了一个多应用的 Android 开发框架 —— Seraphim Framework。在这个过程中，我不仅运用了多年的模块化架构经验，还尝试与 Claude Opus 4.6 深度协作，让 AI 帮我生成大量样板代码、优化设计文档，甚至一起推敲技术选型。这篇文章记录了我的设计思路，以及 AI 是如何成为得力助手的。
为什么要做这样一个东西？
在日常开发中，我常常需要同时维护多个独立 App，它们共享一些基础能力（网络、存储、权限、工具类），但业务逻辑又完全隔离。如果每个 App 都从头搭建项目结构、重复配置 Gradle、复制粘贴工具类，不仅效率低下，还容易导致技术栈碎片化。
于是我想：能不能搭建一个多应用共享内核的模板项目？既能快速孵化新 App，又能保证底层统一、易于维护。而且，既然 Kotlin Multiplatform 已经成熟，为什么不把业务层也做成 KMP，为未来跨平台做准备？
这就是 Seraphim Framework 的初衷。
整体架构设计
我采用了清晰的分层结构，将项目拆分为四个主要层次：
┌─────────────────────────────────────┐
│ App Layer (Android) │
│ apps/delicacies, apps/pokemon, ... │
├─────────────────────────────────────┤
│ Shared Business Layer (KMP) │
│ shareds/delicacies, shareds/pokemon │
├─────────────────────────────────────┤
│ Core Layer (KMP) │
│ core/network, core/storage, etc. │
├─────────────────────────────────────┤
│ Utils (KMP) │
│ utils │
└─────────────────────────────────────┘
-
App Layer：只负责 UI（Compose）、导航、ViewModel 和 DI 组装，不包含业务逻辑。
-
Shared Layer：每个 App 对应的 KMP 模块，包含 UseCase、Repository、本地数据库（Room）、网络服务等。这一层可以在 Android 和 iOS 间复用。
-
Core Layer：基础设施封装，如网络请求（Ktor）、存储（Room + MMKV）、权限管理（Android 专用）等。
-
Utils：纯工具函数，多平台通用。
这样的分层让每个模块职责单一，依赖关系明确。同时，通过 约定插件（Convention Plugins） 统一管理所有模块的构建配置，彻底消灭了冗余的 build.gradle 代码。
技术选型与思考
在选型时，我优先考虑多平台支持、社区活跃度、与 Kotlin 的契合度。最终的技术栈如下：
类别
技术
理由
UI
Jetpack Compose
现代声明式 UI，与 Kotlin 无缝集成
DI
Koin (KSP)
轻量、简单，支持 KMP，配合 KSP 编译期检查
网络
Ktor + Kotlinx Serialization
官方出品，多平台一致性高
数据库
Room (KMP) + MMKV
Room 在 Android 上成熟稳定，KMP 支持日渐完善；MMKV 提供高性能 KV 存储
图片
Coil
Compose 友好，支持多种数据源
导航
Compose Destinations
类型安全、代码生成，避免手写 NavGraph
构建
19 个自定义约定插件
统一版本、简化模块配置
代码规范
Spotless + ktlint
保证代码风格一致
这些选型并不是一次定下的。在 AI 的帮助下，我对比了多种方案的优缺点，例如 Koin vs Koin Annotations vs Koin KSP，最终选择了 Koin KSP 以获得编译期安全性。
AI 如何辅助我完善框架？
在整个开发过程中，Claude Opus 4.6 扮演了多个角色：
1. 架构推演与设计建议
我进行了技术架构的选型和基础插件的设计搭建，AI帮我再开发过程中从AGP8升级到AGP9，快速生成基本的模块代码，AI 提供了多种多模块组织的参考案例，通过skills尽量的控制了幻觉的产生虽然过程中还是会产生不可预想的偏离。
2. 编写模块 README 和文档
项目中的 doc/ 文件夹存放了两个 App 的 PRD（产品需求文档）。这些文档最初是我口述功能点，AI 帮我润色成结构清晰、语言流畅的正式文档。后来我还让 AI 生成了模块的 README，确保每个模块都有独立的使用说明。
3. 代码补全与优化
在实现具体功能时（如 Ktor 的 receiveBffResult 扩展函数），AI 提供了完整的代码实现，并帮我处理了泛型、协程异常等细节。我只需要将其复制到项目中，稍作调整即可。
4. 生成测试用例和截图测试配置
为了确保代码质量，我引入了 Roborazzi 进行截图测试。AI 帮我编写了 jacoco 插件的配置，以及几个模块的单元测试模板，让我快速覆盖核心逻辑。
一些 AI 协作的心得
-
明确意图：向 AI 描述问题时，越具体越好。比如“我需要一个 Gradle 插件，作用是为 Android 模块统一设置 compileSdk = 36”，比“帮我写个插件”效果好得多。
-
迭代式对话：AI 生成的代码往往需要微调。我会把生成的代码放入项目，如果编译出错，直接把错误反馈给 AI，它能快速定位并修正。
-
利用 AI 做决策：遇到技术选型犹豫不决时，我会列出几个选项，让 AI 列出各自的优缺点，再结合我的场景做决定。比如 Room 与 SQLDelight 的对比，最终我选择了 Room 因为更熟悉且官方支持。
-
保持主导权：AI 是辅助，不能完全替代人的判断。架构的核心思想、模块划分的边界，还是需要自己把握。AI 的作用是加速实现、提供灵感。
结语
Seraphim Framework 是一个对本身多年APP开发的设计总结和对AI使用的初步验证，看到这里大家可能也发现了这篇文章本身99%也是通过Deepseek生成的，本来我想用豆包的在写文章吹牛这块感觉豆包比Deepseek厉害不过太烂了不想搞了。
欢迎到 GitHub 上看看源码（github.com/li-lance/an…），也欢迎与我交流。让我们一起，让开发更高效、更有趣。
