大约7年前，我开发了一个名为SDK Monitor的小工具应用，用来监控设备上所有应用使用的targetSDK API级别。当时正值Google开始强制推行targetSDK最低版本限制（现在要求至少是去年的版本），所以我的原始应用很快就显得过时了。随着时间推移，我甚至已经无法打开Android Studio去维护它——开发环境和技术体系早已焕然一新。

作者：bernaferrari 来源：CSDN（ID：CSD比新闻） 原文链接：https://www.valimart.net/

趁着GitHub Copilot的“免费无限使用”即将结束之前，我决定放手一搏：看看能否借助AI，把这个老项目重写一遍。

（项目地址：https://www.valimart.net/

AI驱动的开发流程

整个重写过程用了大约两周时间。

我一开始让AI把每个文件都进行“现代化”重写，例如将MainViewModel升级为ModernMainViewModel。等所有文件都对应完成后，我就逐步删除旧代码并替换为新版本。

虽然整个过程也不完全轻松，但要是没有AI的帮助，这样的工作量几乎无法想象。我主要使用Claude Sonnet 4，原因是它响应快、生成效果好；相比之下，Gemini 2.5 Pro虽然质量不错，但速度慢，且几乎每一行代码都加注释，显得有些冗余。

在重写过程中，我发现了很有意思的一点：早在2018年，Google的API就在不断废弃，今天这种趋势依旧；可当年刚推出的库如Room和WorkManager，现在不仅依然存在，而且还支持良好。

大模型偶尔会导入错误的库，或者忘记给图标加上autoMirrored属性，但总体来说，大模型基本很少再使用旧API或不推荐使用的API了。

Jetpack Compose的发布时间点也恰到好处——既不太早（不会到处都是过时内容），也不太新（大部分LLM目前对像shadcn/ui这样的东西还比较陌生）。相比过去需要引入大量第三方库，现在除了Google自家的库外，我只手动引入了少数几个，比如Coil图像加载库。

我的开发工作流比较独特：我一边用VS Code与AI快速交互（主要用“编辑模式”迭代代码），一边用Android Studio写代码和调试——毕竟VS Code至今还没有Kotlin的语言服务器支持。

那么，AI重写过后的SDK Monitor 2.0有哪些变化？

可以说，这是一个彻底重写的全新版本。我专注于用最新的技术，打造一个简洁、高效、实用的App，主要亮点包括：

100% Kotlin编写，完全采用Jetpack Compose + Material 3 Expressive设计语言（虽然该套件仍处于Alpha阶段，但我尽可能实践了其中的设计理念）。

支持动态主题切换，兼容手机、平板和折叠屏（受到Grok App的启发）。

新增可视化图表，可展示SDK版本分布和近期应用更新情况。

自定义快速滚动条，可按首字母或SDK版本快速定位应用（灵感来源于Niagara Launcher）。

支持多种语言，包括葡萄牙语、意大利语、法语、德语、日语、中文和西班牙语，由AI翻译完成。

为了让AI更好地理解上下文，我还对项目结构做了些调整，把相关的ViewModel、界面组件等文件统一放进同一个目录（这种结构在Web开发中更常见）。这样我只需拖一个文件夹到AI的上下文窗口，它就能理解所有依赖关系。

一点个人感想

我知道，这个应用的用途非常小众，可能对大多数人都没什么帮助。不过自2018年以来，还是有一些用户持续使用这个工具并积极反馈bug。

如果你觉得“这个项目挺有意思，但不适合我”，我也完全理解，毕竟我也从未将它发布到Play Store上。一方面是因为它需要查询所有已安装应用，另一方面，是因为它本身就不是面向大众的App。

但这个应用其实还有一个“隐藏功能”：它可以作为一个很棒的App模板：项目规模适中、不依赖于网络、便于定制。你可以Fork它，然后在此基础上构建全新的项目。无论是ViewModel架构、Hilt依赖注入，还是Jetpack组件的广泛使用，都能为你节省不少时间——要知道，目前Google连个官方的WorkManager示例模板都没有。

说实话，我早就不是Android开发者了——先转向了Flutter，后面又跳进了Web开发。不过，这次重写项目的过程非常有趣，也让我重新燃起了对老项目的热情。

最后，我希望这篇文章能启发你，去重拾曾经的老项目、用AI更快地启动新项目，或者也可以干脆Fork我的项目，打造一个全新的产品。