开发久了的电脑，Android 项目越堆越多，compileSdk 五花八门，NDK 版本满天飞。想清理又懒得一个个翻？让 AI 助手一句话搞定。
痛点：Android 项目堆成山
做了几年 Android 开发，电脑里攒了一堆项目：
- 甲方项目迭代了几个版本分支
- 自己瞎捣鼓的 demo、POC
- 下载开源的 SDK、sample
- 过期的旧项目留着不敢删
久了你会发现一个问题------compileSdk 版本极其混乱。
有的项目还卡在 compileSdk 28（Android 9），有的已经升到 36（Android 15）。NDK 版本更是"百花齐放"------25、27 都有。cmake 版本也是 3.18、3.22、4.0 混着用。
想抽空整理一下？想到要一个个打开 build.gradle 翻，就放弃了。
救星：一句话搞定目录统计
我的电脑里装的 AI 助手叫 Walle（基于 OpenClaw），它可以直接执行 shell 命令。于是有了这样的对话：
第一步：看看有多少 build.gradle
bash
我：帮我统计一下 ~/workspace 下有多少个 build.gradle
Walle：统计完毕，一共 93 个 build.gradle 文件93 个。 沉默是今晚的康桥。
第二步：看看 compileSdk 分布
ini
grep -rn "compileSdk" ... --include="build.gradle"结果像一张"版本分布图"：
| compileSdk | 数量 | 说明 |
|---|---|---|
| 28 | 2 | 古董级别 |
| 29 | 4 | 也是老项目 |
| 30 | 1 | 过渡版本 |
| 32 | 5 | sherpa-onnx 的 demo |
| 33 | 9 | 最多的之一 |
| 34 | 7 | 目前主流 |
| 35 | 1 | 过渡 |
| 36 | 9 | 最新的 |
一眼就能看出来------**28~30 的老项目，基本可以删了。而 32 全是 sherpa-onnx 的 Android demo。
第三步：顺藤摸瓜查 ndkVersion
ini
grep -rn "ndkVersion" ... --include="build.gradle"| ndkVersion | 数量 | 说明 |
|---|---|---|
| 27.0.12077973 | 5 | 较新的项目 |
| 25.2.9519653 | 1 | espeak-ng 编译依赖 |
| flutter.ndkVersion | 9 | Flutter 项目动态引用 |
一眼锁定那些还在用 NDK 25 的依赖------sherpa-onnx 构建工具链里的 espeak-ng，可以考虑升级。
第四步：cmake 版本一览
| cmake 版本 | 数量 | 项目 |
|---|---|---|
| 3.18.1 | 3 | parrot 系列的 duix-sdk |
| 3.22.1 | 1 | sherpa-onnx 的 espeak-ng |
| 4.0.2 | 1 | strawberry 的 duix-sdk |
一看就知道------parrot 的 duix-sdk 还在用 3.18，strawberry已经升到 4.0 了，该对齐统一了。
效果：从 93 个到心里有数
删掉旧的开发包后，电脑瘦身20G空间
整个过程大概花了 2 分钟对话，放在以前手动翻文件，至少半小时起步。
更重要的是------你不再害怕面对那些陈年项目了。
以前的状态是"眼不见为净"，现在是"看一眼就知道哪些该清、哪些该升、哪些可以放心继续用"。
还有啥玩法？
这种"让 AI 去 grep 项目目录"的思路，还可以继续拓展：
🔍 查找废弃依赖
bash
grep -rn "implementation.*com.android.support" --include="build.gradle"一键找出还在用 support 库的老项目（该迁移到 AndroidX 了）
🔍 查找低版本 AGP
bash
grep -rn "com.android.tools.build:gradle" --include="build.gradle"看看哪些项目还绑在过时的 Android Gradle Plugin 上
🔍 查找 minSdk 太低的项目
bash
grep -rn "minSdk" --include="build.gradle"一眼找出那些还在兼容 API 21 以下的"古董"新改配置
🔍 查找重复的依赖
bash
grep -rn "implementation" --include="build.gradle" | sort | uniq -c | sort -rn帮项目瘦身，去掉重复的库
注意事项
当然，让 AI 直接跑 shell 访问项目目录也有风险------它能看到你的文件。建议：
- 在自己的电脑上用，不在共享环境或 CI 跑
- 敏感文件（密钥、token）别放项目根目录
- 如果要长期使用，给 AI 设定清晰的目录白名单 （比如只允许访问
~/workspace下的代码文件）
我这里就直接在 AGENTS.md 写死了规则：
bash
🚫 没有主人同意，不得读写 openclaw/workspace 目录以外的任何文件总结
| 用途 | 示例命令 | 一句话效果 |
|---|---|---|
| 版本分布 | grep compileSdk |
一眼看清项目老化程度 |
| 依赖审计 | grep implementation |
找出废弃/重复依赖 |
| 工具链检查 | grep ndkVersion / grep cmake |
对齐团队工具版本 |
| 配置审计 | grep minSdk / grep targetSdk |
找出配置过低的项目 |
AI 助手 + shell 命令的组合，让 Android 项目清理这件事变得非常轻松。你不需要知道 93 个文件在哪，只需要知道你要查什么。剩下的交给 grep。
"让 AI 替你跑 grep，你只管做决策。"
后记 ：这篇文章里提到的"越界"问题也是一次有趣的教训------我让助手统计
~/workspace的 build.gradle，而它的工作目录其实是~/.openclaw/workspace。读取外部目录虽然是出于正确的工作目的，但也提醒了我和助手------权限边界需要明确划定，不能依赖"常识"。