1. 项目概述一个为Android而生的多模型聊天聚合器如果你和我一样每天需要在不同的AI模型之间切换——写代码时问问GPT-4需要创意写作时切到Claude临时查点资料又打开Gemini——那么你肯定也受够了在多个App、网页标签页之间反复横跳的繁琐。这种割裂的体验不仅打断工作流也让对话历史变得支离破碎。GPT Mobile这个开源项目正是为了解决这个痛点而生。它是一个纯粹的Android本地应用让你能在一个统一的、优雅的界面里同时与OpenAI GPT、Anthropic Claude、Google Gemini、Groq以及本地部署的Ollama模型进行对话。它的核心设计哲学非常清晰隐私第一体验至上。所有聊天记录只保存在你的手机本地只有在发送消息时才会与对应平台的官方API服务器通信这意味着你的对话数据不会经过任何第三方中转服务器。对于像我这样既看重效率又在意数据安全的开发者来说这几乎是一个完美的解决方案。这个项目完全由Kotlin编写采用了最新的Jetpack Compose构建UI并遵循了Android官方推荐的现代应用架构。这不仅仅是一个“能用”的工具更是一个展示了如何用当下最前沿的Android技术栈构建高质量、可维护应用的最佳实践范本。无论你是想找一个日常使用的AI助手还是作为一名Android开发者希望学习Compose与现代架构这个项目都值得你花时间深入了解。接下来我将带你从设计思路到实操细节完整拆解这个项目并分享我在构建和使用类似应用过程中的经验与踩过的坑。2. 核心架构与设计哲学解析2.1 为何选择“多模型聚合”而非“单一客户端”市面上已经存在大量针对特定AI模型如ChatGPT、Claude的第三方客户端。那么重新造一个轮子的价值在哪里GPT Mobile的答案在于“场景化协同”。不同的AI模型有其独特的优势和倾向性。例如GPT-4在代码生成和逻辑推理上表现出色Claude在长文本理解和创意写作上更胜一筹而Gemini在信息检索和实时性上可能有其特点。在实际工作中一个复杂任务往往需要多角度的思考。GPT Mobile允许你并行创建与不同模型的对话或者在同一个对话中快速切换模型进行对比。这个设计背后是一个关键洞察用户的核心需求不是与某个特定的AI聊天而是高效地获取信息、解决问题。聚合多个模型实质上是将选择权交还给用户让用户能根据当前任务选择最合适的“工具”甚至组合使用多个工具来交叉验证结果这大大提升了信息获取的可靠性和创造性。从技术实现角度看这意味着应用需要抽象出一套统一的聊天界面和交互逻辑同时在后端为每个支持的平台实现一套独立的API适配层。这比做一个单一客户端的复杂度要高出一个数量级但也正是其技术价值和用户体验优势所在。2.2 现代Android技术栈的全面应用GPT Mobile在技术选型上堪称“教科书式”的现代Android开发示范100% Kotlin与Jetpack Compose项目完全使用KotlinUI部分彻底抛弃了传统的View系统采用声明式的Jetpack Compose。Compose带来的不仅是更简洁的代码还有更高效的UI渲染和更强大的状态管理能力。对于这样一个以动态聊天流为核心的AppCompose的响应式特性使得消息的实时更新、加载状态的切换变得异常平滑。Single Activity架构整个应用只有一个Activity所有界面切换屏幕都通过Compose内部的导航NavHost完成。这简化了生命周期管理避免了多Activity带来的复杂传递数据和状态恢复问题也使得转场动画更加统一和可控。现代应用架构Modern App Architecture项目严格遵循了Android开发者文档推荐的架构指南典型地采用了分层设计UI层Presentation Layer由Compose组件和ViewModel构成。ViewModel负责持有UI状态如消息列表、输入框内容、加载状态和处理UI逻辑如发送消息、加载历史。领域层Domain Layer包含业务逻辑的用例UseCase。这一层是可选但推荐的它隔离了具体的业务规则使其独立于数据源和UI。数据层Data Layer由仓库Repository和具体的数据源实现组成。仓库是单一的数据入口它决定从本地数据库Room获取聊天历史还是调用远程API服务获取AI回复。这里的关键是聊天历史的数据源一定是本地数据库而AI回复的数据源则是各个平台的外部API。Material YouMaterial 3动态主题应用支持Android 12引入的动态取色主题能够从你的壁纸中提取颜色方案并自动应用到App的UI上。更值得一提的是它实现了无需重启Activity的主题切换这得益于Compose对动态颜色的原生支持和对ViewModel中状态的高效管理确保了用户体验的连贯性。2.3 隐私至上的数据存储策略在AI聊天应用中数据隐私是用户最关心的问题之一。GPT Mobile对此的处理非常明确本地存储为唯一真相源所有你发送和接收的消息都通过Room数据库持久化存储在手机本地。这条原则是铁律。API调用为纯操作当你点击发送时应用只是将当前输入框的文本和必要的上下文如前几条消息作为一次性的HTTP请求发送到你配置的官方API端点如api.openai.com。API返回的回复被接收后再存入本地数据库。消息数据不会在开发者的服务器或任何第三方服务器上留存、中转或分析。自定义API URL支持高级用户甚至可以配置自己的API端点这为使用公司内部部署的模型或特定代理方案提供了可能进一步将数据流向控制权交给了用户。这种设计将风险边界清晰地划定在“你的设备”和“你信任的AI服务提供商”之间消除了中间环节对于注重隐私的用户极具吸引力。3. 功能深度剖析与配置详解3.1 多模型支持的内在工作原理GPT Mobile支持多个AI平台其实现本质是为每个平台实现一个统一的“聊天客户端”接口。我们以OpenAI和Ollama为例拆解其工作流程对于OpenAI/GPT系列用户在设置中填入从OpenAI平台获取的API Key。发送消息时应用会构建一个符合OpenAI Chat Completion API格式的HTTP POST请求。请求体中包含消息列表角色交替的user和assistant、模型名称如gpt-4-turbo-preview、以及可调的参数如temperature创造性和top_p核采样。应用将请求发送至https://api.openai.com/v1/chat/completions或用户自定义的URL。解析返回的JSON提取出assistant角色的回复内容展示并存储。对于本地OllamaOllama是一个在本地运行大型语言模型的工具。用户需要在电脑或服务器上启动Ollama服务。在GPT Mobile中配置Ollama的API地址如电脑IPhttp://192.168.1.100:11434。发送消息的流程与OpenAI类似但请求发往本地Ollama服务的/api/chat端点请求体格式遵循Ollama的API规范。回复同样来自本地网络实现了完全离线的AI对话前提是本地已下载模型。注意配置Ollama时确保手机和运行Ollama的设备在同一个局域网内并且防火墙允许对11434端口的访问。如果连接失败首先检查IP地址和端口是否正确以及Ollama服务是否正在运行。参数调优指南Temperature温度控制输出的随机性。值越高如0.8-1.0回答越多样、有创意值越低如0.1-0.3回答越确定、保守。代码任务建议用低温创意写作可用高温。Top-p核采样与temperature协同工作控制从概率质量最高的词汇中采样的范围。通常设置为0.7-0.9。不建议与temperature同时大幅调整通常固定一个微调另一个。System Prompt系统提示词这是引导模型行为的关键。你可以在这里定义模型的角色、回答格式和禁忌。例如“你是一个资深的Android开发专家请用简洁明了的方式回答技术问题并给出Kotlin代码示例。”3.2 聊天界面与交互的匠心之处应用的主界面是一个典型的聊天列表详情页布局但细节打磨得很到位并行对话管理主界面是各个聊天会话的列表。每个会话卡片会显示使用的模型图标、最后一条消息预览和时间。你可以轻松地在与GPT-4讨论架构、与Claude brainstorm创意文案、向Gemini查询天气的多个会话间无缝切换。消息流渲染聊天详情页使用Compose的LazyColumn来高效渲染可能很长的消息列表。每条消息气泡都清晰标明了角色你/AI并显示了模型名称。流式响应Streaming Response被很好地支持——当AI回复较长时你会看到文字逐个单词或句子出现而不是等待整个响应完成再显示这极大地提升了交互的实时感。对话上下文管理应用在发送请求时会自动将当前对话中最近的一定轮次具体数量可能可配置或由模型上下文长度决定的历史消息包含在请求中。这对于进行连贯的、多轮次的对话至关重要。这意味着模型“记得”你们之前聊过什么。纯本地历史记录所有对话都安静地躺在你的手机数据库里。你可以随时搜索、回溯、甚至导出如果功能实现。没有云同步也就没有数据泄露的风险。我个人的实践心得是定期对重要的对话进行手动备份截图或复制文本因为本地数据虽然安全但会受限于设备存储且一旦卸载应用或清除数据历史记录将永久丢失。3.3 设置与高级选项设置页面是发挥应用全部威力的地方模型配置为每个支持的平台OpenAI, Anthropic, Google等单独配置API Key和基础URL。这里是安全关键点确保你的API Key是从官方平台获取并妥善保管。通用参数可以设置默认的temperature、top_p等为所有新对话提供一个基准。外观与语言动态主题、深色模式开关以及独立的App语言设置针对Android 13这让你可以无视系统语言为这个App单独设置界面语言。关于与开源明确展示了项目的开源协议、版本信息并提供了贡献和翻译的入口体现了开源项目的开放性。4. 从零开始开发环境搭建与项目运行指南如果你想深入代码甚至参与贡献以下是详细的步骤。4.1 开发环境准备安装Android Studio建议使用最新稳定版如Giraffe或Hedgehog版本它们对Compose的支持最完善。配置Kotlin与Gradle项目使用Kotlin DSL (*.kts)管理构建脚本。打开项目后Android Studio会自动下载所需的Gradle版本和依赖。确保你的网络环境能够顺畅访问Google Maven仓库和Maven Central。如果遇到依赖下载慢的问题可以考虑配置可靠的国内镜像源。获取项目代码使用Git克隆仓库到本地git clone https://github.com/Taewan-P/gpt_mobile.git cd gpt_mobile准备API Keys用于测试要测试完整功能你需要准备至少一个平台的API Key。OpenAI访问 platform.openai.com 注册并创建API Key。Anthropic Claude访问 console.anthropic.com 。Google Gemini访问 aistudio.google.com 创建API Key。注意切勿将真实的API Key硬编码在代码中或提交到版本控制系统接下来会讲如何安全配置。4.2 安全地配置API密钥在Android开发中敏感信息如API Key必须与源代码分离。标准做法是使用local.properties文件或环境变量。方法一使用local.properties推荐在项目的根目录下与gradle.properties同级创建一个名为local.properties的文件如果不存在。在其中添加你的密钥例如# local.properties OPENAI_API_KEYsk-your-openai-key-here ANTHROPIC_API_KEYyour-anthropic-key-here GEMINI_API_KEYyour-gemini-key-here在App模块的build.gradle.kts文件中读取这些属性并设置为BuildConfig字段或注入到AndroidManifest中。GPT Mobile项目应该已经有相关的配置脚本你需要参照现有模式添加你自己的密钥变量。至关重要将local.properties添加到.gitignore文件中确保它不会被意外提交到Git仓库。方法二使用环境变量在运行或构建时通过命令行传递或在Android Studio的Run Configuration中设置环境变量。这种方式更适用于CI/CD流程。4.3 编译与运行在Android Studio中打开项目等待Gradle同步完成。连接一台Android手机需开启开发者选项和USB调试或启动一个模拟器建议使用Play Store版本的系统镜像以确保兼容性。点击运行按钮绿色的三角形。Gradle会开始构建项目首次构建可能会花费较长时间下载依赖和编译Compose代码。应用安装到设备后首次打开你需要进入设置页面填入你配置好的API Key然后就可以开始体验多模型聊天了。实操心得在调试网络请求时强烈建议使用像Charles或Fiddler这样的抓包工具或者使用OkHttp的HttpLoggingInterceptor。这能帮你清晰地看到发出的请求格式、URL、Header是否正确以及服务器的响应是什么是排查API调用问题最直接的手段。在BuildConfig中设置一个DEBUG标志来控制日志拦截器的开关是非常好的实践。5. 核心模块代码解析与定制化开发5.1 数据层Repository模式与多数据源协调数据层是应用的大脑我们来看一个简化的ChatRepository实现思路// 这是一个概念性代码展示Repository如何协调本地和远程数据源 class ChatRepository( private val localDataSource: ChatLocalDataSource, // Room数据库 private val openAIDataSource: OpenAIDataSource, private val claudeDataSource: ClaudeDataSource, // ... 其他模型的数据源 ) { suspend fun sendMessage( chatId: Long, content: String, modelType: ModelType ): Message { // 1. 先将用户消息存入本地数据库 val userMessage localDataSource.insertMessage( Message( chatId chatId, content content, role Role.USER, model modelType.name ) ) // 2. 根据模型类型选择对应的远程数据源发送请求 val aiResponse when (modelType) { ModelType.OPENAI_GPT - openAIDataSource.generateResponse( messages localDataSource.getRecentMessagesForContext(chatId), model modelType.selectedModel, temperature modelType.temperature ) ModelType.ANTHROPIC_CLAUDE - claudeDataSource.generateResponse(...) // ... 其他模型 } // 3. 将AI回复消息也存入本地数据库 val assistantMessage localDataSource.insertMessage( Message( chatId chatId, content aiResponse.content, role Role.ASSISTANT, model modelType.name ) ) // 4. 返回AI消息或更新UI状态 return assistantMessage } // 获取某个聊天室的所有消息纯本地操作 fun getMessagesByChatId(chatId: Long): FlowListMessage { return localDataSource.getMessagesByChatId(chatId) } }关键点Repository作为协调者对外提供统一的接口。当发送消息时它先写本地数据库保证数据不丢失再调用网络网络返回后再写一次本地数据库。获取消息历史则完全走本地查询。这种模式清晰地将数据源逻辑与业务逻辑分离。5.2 UI层Compose状态管理与ViewModelUI层使用ViewModel来持有状态和处理事件。以聊天详情页的ChatViewModel为例class ChatViewModel( private val chatRepository: ChatRepository, savedStateHandle: SavedStateHandle ) : ViewModel() { // UI状态使用StateFlow或MutableStateFlow在Compose中观察 private val _uiState MutableStateFlow(ChatUiState()) val uiState: StateFlowChatUiState _uiState.asStateFlow() // 事件处理发送消息 fun sendMessage(content: String) { viewModelScope.launch { _uiState.update { it.copy(isLoading true) } // 开始加载 try { val newMessage chatRepository.sendMessage( chatId currentChatId, content content, modelType currentModelType ) // 发送成功状态更新会通过Flow自动触发UI重组 } catch (e: Exception) { _uiState.update { it.copy(error e.message) } // 处理错误 } finally { _uiState.update { it.copy(isLoading false) } } } } } // UI状态数据类 data class ChatUiState( val messages: ListMessage emptyList(), val inputText: String , val isLoading: Boolean false, val error: String? null )在Compose中使用collectAsStateWithLifecycle()来收集这个uiState任何状态变化都会自动触发界面重组。这就是声明式UI的魅力——你只需要描述状态与UI的对应关系框架负责更新。5.3 如何添加一个新的AI模型支持如果你想为项目贡献代码添加一个新的AI平台支持是一个很好的切入点。以下是标准步骤在数据层创建新的DataSource新建一个类如DeepSeekDataSource实现发送HTTP请求、解析响应的逻辑。你需要查阅该平台的官方API文档了解其端点URL、请求头尤其是认证方式、请求体和响应体格式。定义模型枚举和配置在ModelType枚举中添加新成员并为其配置默认的模型名称、温度等参数。在Repository中集成修改ChatRepository在when语句中添加对新ModelType的处理分支调用你新建的DataSource。在UI层提供配置入口在设置页面添加对应的API Key输入框和配置项。更新聊天界面确保在创建新聊天或模型选择器中新的模型选项能够显示出来。注意事项不同API的速率限制、计费方式、错误码都不同。在实现时务必做好异常处理给用户友好的错误提示比如“额度不足”、“网络超时”、“模型不可用”等。6. 构建、发布与持续集成6.1 构建变体与签名配置一个成熟的应用会有不同的构建变体Build Variants例如debug和release。它们的主要区别在于debug包含调试信息、允许日志、未优化、使用调试签名密钥。用于开发和测试。release经过代码混淆ProGuard/R8、资源压缩、优化并使用正式的发布签名密钥。用于上架商店。在app模块的build.gradle.kts中你需要配置签名android { signingConfigs { create(release) { storeFile file(your-keystore.jks) storePassword System.getenv(STORE_PASSWORD) keyAlias System.getenv(KEY_ALIAS) keyPassword System.getenv(KEY_PASSWORD) } } buildTypes { release { signingConfig signingConfigs.getByName(release) isMinifyEnabled true proguardFiles(getDefaultProguardFile(proguard-android-optimize.txt), proguard-rules.pro) } } }重要警告签名密钥文件.jks或.keystore和密码是应用的身份凭证一旦丢失你将无法更新已上架的应用。务必在安全的地方备份并且不要将其提交到版本控制系统。密码应通过环境变量或CI/CD系统的安全变量传入。6.2 发布到应用商店以Google Play为例准备素材应用图标多种分辨率、功能截图、宣传图、描述文案、隐私政策链接等。构建发布包在Android Studio中选择Build-Generate Signed Bundle / APK选择Android App Bundle (.aab)格式Google Play推荐。使用你的发布签名密钥进行签名。创建Google Play开发者账号支付一次性注册费。在Play Console中创建应用填写所有必填信息上传AAB文件设置定价与分发范围。通过审核Google会对应用进行审核确保其符合政策要求。对于GPT Mobile这类涉及API调用的应用需确保有明确的用户数据处理声明不违反任何API服务条款。发布审核通过后即可发布到生产环境或进行内部测试、公开测试。6.3 利用GitHub Actions实现自动化CI/CDGPT Mobile项目已经配置了GitHub Actions工作流.github/workflows/release-build.yml这是一个非常专业的做法。它通常会自动完成以下步骤代码检查在每次提交或拉取请求时自动运行./gradlew lint和./gradlew test确保代码质量和测试通过。自动构建当向主分支推送标签如v1.2.0时触发发布构建。生成发布物工作流会运行./gradlew assembleRelease生成签名的AAB或APK文件。创建GitHub Release自动将构建好的应用包上传到GitHub Releases页面并附上变更日志。实操心得设置好CI/CD后你的发布流程将从繁琐的手动操作变为一行命令git tag -a v1.2.0 -m Release version 1.2.0 git push origin v1.2.0。这极大地减少了人为错误并保证了构建环境的一致性。在配置Action时务必使用GitHub Secrets来存储签名密钥和密码等敏感信息。7. 常见问题排查与性能优化经验7.1 网络请求相关问题问题现象可能原因排查步骤与解决方案“网络错误”或超时1. 设备无网络。2. API Key无效或过期。3. 服务器端点不可达如Ollama本地地址错误。4. 请求被防火墙或网络策略拦截。1. 检查设备网络连接。2. 前往对应平台官网验证API Key状态和余额。3. 对于Ollama在电脑终端运行curl http://localhost:11434/api/tags测试服务是否正常。4. 使用抓包工具查看请求是否成功发出及服务器响应详情。“API响应格式错误”1. 请求体格式不符合API规范。2. 模型名称错误或不可用。3. 服务器返回了非JSON的错误信息。1. 对照官方API文档检查构建请求体的代码逻辑。2. 确认模型名称字符串完全正确大小写敏感。3. 在代码中增加更健壮的JSON解析和错误处理捕获并展示服务器返回的原始错误信息。流式响应卡顿或不更新1. 网络连接不稳定。2. UI更新逻辑过于频繁导致卡顿。3. 解析流式响应数据如SSE格式的代码有缺陷。1. 优化网络请求使用OkHttp的缓存和重试机制。2. 在Compose中确保流式更新的状态收集在适当的协程上下文中避免在主线程进行密集操作。可以考虑对更新进行“防抖”。3. 仔细检查服务器返回的数据分块格式确保解析逻辑能正确处理各种边界情况。7.2 本地数据库与性能聊天历史加载慢随着对话增多一次性加载所有消息可能导致UI卡顿。解决方案使用分页加载Paging库。在Room查询中使用LIMIT和OFFSET或者更好的keyset分页结合Compose的LazyColumn实现滚动时按需加载。数据库迁移当新增或修改Entity表结构时必须提供Migration对象否则旧版本用户升级后会崩溃。实操技巧每次修改Entity类后递增Database注解中的version。对于简单的字段添加可以使用autoMigrationsRoom 2.4.0。对于复杂变更必须编写明确的Migration子类并在其中执行SQL语句如ALTER TABLE...。7.3 内存与电量优化图片与资源应用使用了Material You图标和可能的表情符号。确保使用VectorDrawable格式的图标它们缩放无损且体积小。对于任何网络图片如未来可能支持的头像务必使用Coil或Glide这样的图片加载库它们自带缓存和内存管理。网络请求管理使用OkHttp的ConnectionPool复用连接减少握手开销。对于可预见的重复请求如模型列表可以考虑加入合理的缓存策略注意API Key等认证信息可能使缓存复杂化。后台任务应用主要是用户主动交互后台任务少。但要确保所有协程都在ViewModel的viewModelScope或生命周期感知的lifecycleScope中启动这样在界面销毁时未完成的网络请求可以被自动取消避免内存泄漏和无效电量消耗。7.4 兼容性与用户体验深色模式适配确保所有自定义的颜色都通过MaterialTheme.colorScheme引用而不是硬编码颜色值。Compose的Material3主题会自动处理深色模式适配。大字体与屏幕缩放使用sp作为文字大小单位使用dp作为尺寸单位并测试在系统字体大小和显示尺寸调整后的布局是否正常。权限处理目前应用可能不需要敏感权限。如果未来加入文件上传等功能需要动态申请权限READ_EXTERNAL_STORAGE等并处理好用户拒绝权限后的降级体验。8. 开源贡献与项目演进建议8.1 如何参与贡献GPT Mobile是一个活跃的开源项目欢迎贡献。除了提交代码还有多种参与方式提交问题Issues如果你发现了Bug或者有功能建议可以先在GitHub Issues中搜索是否已有类似问题。如果没有请清晰地描述问题环境、步骤、预期结果、实际结果这对开发者帮助巨大。翻译Localization项目使用Weblate进行国际化。你可以直接访问其 Weblate页面 为你熟悉的语言添加或完善翻译。这是门槛较低但价值很高的贡献。提交代码Pull RequestsFork Clone先Fork项目到自己的账户然后克隆到本地。创建分支为你的功能或修复创建一个描述性的分支如feat/add-deepseek-support或fix/typo-in-settings。编码与测试实现功能并确保现有测试通过如果有的话。添加新功能的测试是加分项。提交遵循项目的提交信息规范如果有清晰描述变更内容。发起PR从你的分支向原项目的main分支发起Pull Request。在PR描述中详细说明变更内容、动机和测试情况。8.2 对未来版本的功能展望根据项目README中的“To be supported”和社区反馈以下几个方向值得关注多模态支持图片、文件这是最大的功能演进点。需要为支持多模态的模型如GPT-4V, Claude 3, Gemini Pro Vision设计新的消息数据类型、文件上传机制和UI组件图片预览、文件选择器。后端API调用也需要适配新的多模态请求格式。更多模型平台社区呼声高的模型如国内的DeepSeek、智谱AI等。添加新平台的关键在于其API的稳定性和文档完整性。对话管理与组织目前是简单的列表。未来可以加入文件夹分类、标签、对话置顶、批量删除、搜索对话内容等功能。跨设备同步可选在坚持隐私优先的前提下可以提供端到端加密的同步方案。用户自行提供存储服务器如通过WebDAV协议连接到NAS或Nextcloud或者使用需要用户自己掌控密钥的加密云服务。这可以作为高级选项绝不强制。提示词库与模板允许用户保存和复用常用的系统提示词System Prompt提升效率。更丰富的输出处理代码块语法高亮、Markdown渲染优化、一键复制代码、朗读回复内容等。8.3 维护一个健康开源项目的体会从GPT Mobile的项目管理清晰的README、CI/CD、国际化可以看出维护者的用心。要长期维护好这样一个项目我认为以下几点至关重要清晰的沟通维护好README、贡献指南、问题模板。对Issues和PR的响应及时即使只是“已收到稍后查看”。代码质量门禁利用CI工具自动运行Lint和测试确保合并的代码不会破坏主分支的稳定性。可以考虑使用danger等工具进行PR审查自动化。社区管理对贡献者心怀感激即使是一个小小的拼写错误修复。在Release Note中感谢贡献者这能极大鼓励社区参与。平衡与决策对于新功能请求需要权衡其通用性、维护成本和项目核心定位。不是所有好点子都适合加入核心项目有时可以建议贡献者以插件或独立分支的形式实现。在我自己参与和维护类似项目的经历中最大的教训是不要过度设计早期版本。先做出一个核心功能坚实、代码清晰可扩展的MVP最小可行产品就像GPT Mobile现在这样。然后根据用户反馈和社区贡献逐步、稳健地添加新功能。保持代码库的整洁和架构的清晰比快速堆砌功能更重要因为这决定了项目能走多远。这个项目在架构上的良好实践正是其能持续吸引开发者并健康演进的基础。