前言在第一周完成项目调研、技术选型和整体方向确认之后本周的工作开始真正进入“从方案到落地”的阶段。相比第一周更偏向于项目准备与思路梳理这一周我主要围绕CarLearn项目的基础开发骨架展开工作重点放在 Android 客户端工程结构搭建、登录注册流程设计、本地数据库准备、网络访问链路预留以及基础页面组织方式确定等几个方面。这一周对我来说是非常关键的过渡阶段。因为如果说第一周解决的是“做什么、怎么做”的问题那么第二周更重要的是开始把这些想法逐步落实成真正的工程结构。虽然此时项目还没有进入后期那种大量功能并行开发的状态但像用户登录、基础页面组织、数据库结构设计、网络层调用预埋这些内容其实决定了后续刷题、专项练习和题库模块能不能平稳接上。同时由于本次项目也鼓励合理使用 AI 辅助开发所以在这一周中我也开始有意识地把 AI 融入到开发流程中。例如在页面结构规划、模块职责划分、基础代码模板生成以及错误排查思路整理上AI 都发挥了比较明显的辅助作用。对我来说这并不是简单地“让 AI 代写代码”而是把它当作一个能帮助我快速整理思路、提高起步效率的开发工具。本周工作关键词AndroidKotlinMVVMRoomRetrofit登录注册本地数据库AI辅助开发一、本周工作概览本周我主要完成了以下几个方面的工作明确 CarLearn 客户端的整体工程组织方式搭建 Android 原生项目基础框架初步确定页面之间的导航关系设计用户登录与注册流程配置本地数据库 Room 的基本使用环境规划网络请求层为后续后端联调做准备梳理题目、用户等核心数据实体结构在开发过程中尝试使用 AI 辅助页面和架构起步整体来看本周的主要目标不是把某个业务模块完全做完而是尽快让项目具备“可持续开发”的基础能力也就是先把骨架搭好再逐步挂业务。二、客户端基础工程搭建从零散页面思维转向工程化组织这一周最先推进的是 Android 客户端基础工程的搭建。前期在项目讨论阶段我们已经基本确定项目会采用原生 Android 路线而不是网页式前端或者跨端方案。这样做的原因主要在于一方面原生 Android 在题目展示、页面交互和本地数据缓存方面更加稳定另一方面对于刷题类应用来说使用 Kotlin 和 Jetpack 生态能够更自然地支撑 ViewModel、Navigation、Room 等组件协同工作。在具体搭建过程中我开始更加重视项目的结构而不只是单纯地“先写一个 Activity 或 Fragment”。因为在后续功能增加之后如果工程层级不清楚很容易出现页面代码、数据代码和网络代码全部混在一起的问题。因此本周我逐步形成了一种更清晰的思路UI 层负责展示和交互ViewModel 层负责状态管理Repository 层负责本地和网络数据协调数据库和接口访问则作为更底层的支撑组件存在。这一阶段虽然还处在工程起步阶段但已经开始按这种思路组织代码。例如页面不会直接去读数据库而是通过 ViewModel 调用 Repository再由 Repository 决定从本地还是网络取数据class AuthViewModel( private val repository: UserRepository ) : ViewModel() { private val _loginResult MutableLiveDataResultUserEntity() val loginResult: LiveDataResultUserEntity _loginResult fun login(phone: String, password: String) { viewModelScope.launch { _loginResult.value repository.login(phone, password) } } }从后续开发角度看这样的工程起点虽然前期准备稍微多一点但能够显著降低后续维护压力。三、登录与注册功能设计把用户系统作为项目入口打通本周另一个重点工作是围绕用户登录注册流程展开设计和初步实现。因为在我们这个项目中虽然刷题是核心主线但如果没有用户身份体系后续很多功能都无法自然落地例如学习记录、错题统计、收藏题目、个人中心信息展示等。因此在基础工程搭起来之后我优先把登录与注册链路作为一个切入点去推进。在设计过程中我尽量把登录注册模块做得相对独立一些避免后续题库模块和用户模块相互缠绕。具体来说登录页负责采集账号信息和触发登录请求ViewModel 负责处理登录结果Repository 负责与本地数据库或后续网络接口对接而页面本身只根据结果决定是提示错误还是跳转到主页。比如在页面层的处理逻辑中更强调“观察结果”而不是直接写业务判断viewModel.loginResult.observe(this) { result - result.onSuccess { Toast.makeText(this, 登录成功, Toast.LENGTH_SHORT).show() startActivity(Intent(this, MainActivity::class.java)) finish() }.onFailure { Toast.makeText(this, it.message ?: 登录失败, Toast.LENGTH_SHORT).show() } }虽然从功能层面看登录注册并不是项目中最复杂的部分但它在这一周承担了一个非常重要的作用那就是帮助我验证整个客户端基础链路是否已经具备可运行性。一旦登录链路打通说明页面、ViewModel、Repository、数据库这几个层次已经可以基本协同工作了。四、本地数据库准备为后续题库与用户信息管理打基础本周我还重点准备了本地数据库部分尤其是 Room 的引入和基础实体设计。之所以在这个阶段就开始准备数据库而不是等到刷题功能真正展开后再说是因为我逐渐意识到像用户信息、题库缓存、答题记录、错题统计这些内容都不适合全部只放在内存里处理。如果想让项目后续可扩展就必须尽早把数据落盘方案想清楚。因此这一周里我围绕 Room 做了两部分准备。第一部分是数据库环境配置也就是依赖引入、数据库实例提供、Dao 注入等基础工作第二部分是核心实体的初步设计比如用户实体和题目实体为后续功能预留结构。例如在数据库模块的搭建中我开始尝试使用依赖注入去提供数据库和 DaoModule InstallIn(SingletonComponent::class) object DatabaseModule { Provides Singleton fun provideAppDatabase(ApplicationContext context: Context): AppDatabase { return Room.databaseBuilder( context, AppDatabase::class.java, car_learn_db ).fallbackToDestructiveMigration().build() } Provides fun provideUserDao(database: AppDatabase): UserDao { return database.userDao() } Provides fun provideQuestionDao(database: AppDatabase): QuestionDao { return database.questionDao() } }对于题目结构我也在这一阶段尽量提前想清楚它未来应该承载哪些字段因为顺序练习、专项练习、图片加载、错题分析等功能都会围绕同一类题目实体展开Entity(tableName questions) data class QuestionEntity( PrimaryKey val id: Int, val question: String, val optionA: String, val optionB: String, val optionC: String, val optionD: String, val answer: String, val explanation: String, val category: String, val type: String, val labels: ListString, val img: String? null, val isFavorite: Boolean false, val wrongCount: Int 0 )这一周虽然还没有完全进入“题库大量写入和查询”的阶段但 Room 的引入已经为后续开发提供了非常关键的基础支撑。五、网络请求链路预备为前后端对接提前埋好接口能力除了本地数据本周我还花了一部分时间在网络层准备上。因为项目后续题库数据不会完全手写在客户端里而是需要通过后端接口获取所以必须尽早考虑网络请求怎么组织接口形式如何定义后续数据如何同步到本地。在这一阶段我主要做的是为 Retrofit 和 OkHttp 的使用打基础并先规划出题目接口的大致形式。即使这一周还没有和后端完成完整联调但至少在客户端层面已经开始为“分页获取题目、按科目加载、未来支持专项筛选”这些能力预留出空间。例如接口定义会优先考虑分页和科目参数这样后续顺序练习和专项练习都能复用同一条基础数据源interface QuestionApiService { GET(questions/) suspend fun getQuestions( Query(page) page: Int, Query(size) size: Int, Query(subject) subject: Int ): ResponseQuestionsResponse }这一部分虽然从结果上看还不像登录页那样“有一个可见的功能界面”但它对于整个项目后续能否顺畅连接后端来说非常重要。因为刷题系统的真正核心不是单个页面而是“页面能否持续稳定地获取、缓存并展示题目”。六、页面导航关系初步梳理为后续顺序练习与专项练习做准备在这一周里我还开始思考页面导航关系而不是等所有页面写出来之后再临时拼接跳转。因为项目未来至少涉及登录页、主页、科目选择页、顺序练习页、专项练习页、题库页和个人中心页如果页面关系不提前规划后续很容易出现导航图混乱、参数传递不一致的问题。因此在基础页面准备阶段我就开始把核心路径理清楚。例如用户登录后进入主页从主页可以进入科目选择而从科目选择页则可能继续跳转到顺序练习或专项练习。这些关系虽然在第二周还只是初步建立但它们已经开始影响后续页面该如何拆分。一个最基础的导航关系可以概括成这样fragment android:idid/subjectSelectFragment android:namecom.example.carlearn.ui.SubjectSelectFragment android:label选择科目 action android:idid/action_subjectSelectFragment_to_examFragment app:destinationid/examFragment / action android:idid/action_subjectSelectFragment_to_specialPracticeFragment app:destinationid/specialPracticeFragment / /fragment虽然这时专项练习还没有完整展开但导航设计的提前介入让我在第二周就对后续页面流转有了更明确的认识。七、AI 辅助开发的尝试不只是“生成代码”更重要的是整理思路由于这次项目本身也鼓励合理使用 AI所以在第二周的开发过程中我并没有把 AI 只当作一个“报错修复工具”而是尝试把它更多地融入到前期工程设计和页面搭建阶段。例如在梳理登录注册流程时我会让 AI 帮助整理一版更清晰的职责划分在搭建工程基础代码时我也会利用 AI 帮助快速生成初版模板再由我自己进行检查和修改在遇到一些依赖注入或 Navigation 配置上的问题时AI 也能帮我更快地定位思路。与此同时我也越来越意识到AI 是否真的能帮上忙取决于我是否把需求和约束讲清楚。也就是说AI 更像一个需要被正确引导的开发协作工具而不是一个可以完全替代思考的黑盒。这也是我在第二周开始逐渐形成的一个工作习惯尽量先把模块目标、页面职责和数据流讲清楚再让 AI 帮我给出初版实现思路。这样最终产出的结果往往要比直接“让 AI 写一个页面”稳定得多。八、本周遇到的问题与思考这一周虽然主要是搭建基础框架但实际过程中也并不轻松。首先最大的问题在于项目需求虽然看起来已经明确但一旦落到工程结构设计上就会发现很多“看似简单”的功能其实都牵涉多个层次。例如一个登录功能表面上只是两个输入框和一个按钮但真正要做好背后涉及页面状态、ViewModel 管理、数据库存储和后续页面跳转。其次在数据库和网络请求同时准备的过程中我也开始感受到“本地缓存”和“远端接口”之间如何分工是一个需要提前思考的问题。如果一开始没有把这一点理顺后面很可能会出现页面直接读网络、数据库只是摆设或者数据重复流转的情况。最后本周我还逐渐意识到功能开发并不只是写出代码更重要的是建立一种相对清晰的工程思维。只有把页面、状态、数据和导航之间的关系逐步理顺后面顺序练习和专项练习这类更复杂的模块才有可能平稳落地。九、本周收获通过第二周的准备与实现我最大的收获是对 Android 工程组织方式的理解进一步加深了。相比第一周更多停留在调研和规划阶段这一周我开始真正把“页面—ViewModel—Repository—数据库/网络”这条链路落到项目里也逐渐意识到一个项目的可维护性往往不是由单个功能页面决定的而是由整体结构是否清晰决定的。另外本周也让我进一步理解了 AI 在项目开发中的合理角色。与其把 AI 当作“替我写完整项目”的工具不如把它作为一个帮助我更快整理思路、生成初版模板、辅助排查问题的伙伴。这样的使用方式更实际也更符合本次项目“鼓励合理使用 AI”的特点。十、下周计划下周我准备在现有基础上继续推进项目核心模块开发。重点会放在顺序练习页面的题目展示流程、题库数据的初步加载、网络接口与本地缓存之间的联动以及主页到刷题主线的进一步打通。同时我也会继续完善当前工程结构让后续专项练习和题库浏览功能更容易接入。总结总体来看本周的重点不在于大量功能“已经做完”而在于我开始真正把 CarLearn 从一个停留在方案层面的想法逐步变成一个具有基础工程能力的 Android 项目。通过这一周的工作我完成了客户端基础结构搭建、登录注册流程设计、本地数据库准备、网络请求链路预留以及页面导航关系的初步整理也在实践中开始探索 AI 辅助开发的合理方式。这些工作虽然更偏向于“打地基”但它们正是后续所有核心功能能够顺利推进的关键前提。