测评时间：2026-08-08 至 2026-08-09
测评对象：android/skills
许可证：Apache-2.0
快照数据：6,628 Stars、387 Forks，最近推送时间为 2026-08-07
测评结论：60% 来自本地实测，40% 来自可核查的仓库事实
先说结论
Google 的 Android Skills 不是一个“会写 Android 代码的万能助手”，而是一组面向 Android 长尾问题的官方技能包。它的强项不是让 Agent 突然具备全新的编程能力，而是让同一个问题在多次运行中更稳定，减少遗漏细节、架构漂移和错误触发。
本次测评给出 4.4 / 5：
- 全量静态检查覆盖 22 个 Skill；
- 22 个 Skill 的相对链接全部有效；
- 21/22 个 Skill 的 frontmatter 字段完整；
- 20 条触发测试达到 100% 整体判断一致率；
- 针对 edge-to-edge 的 A/B 实测中，无 Skill 组中位数为 9/12，有 Skill 组连续 3 次都是 12/12；
- 但本轮没有完成真实编译、安装到模拟器和截图验证，因此不能把“代码检查通过”写成“界面问题已经解决”。
最适合它的人，是需要处理 Compose、性能分析、系统栏、Play 政策、测试和新平台 API 的 Android 开发者。最不适合的场景，是把它当成日常业务开发的全能知识库，或者在没有核对版本的情况下直接照抄最新建议。
评分总表
| 维度 | 权重 | 得分 | 结论 |
|---|---|---|---|
| 产出增益 | 25% | 4.5 / 5 | A 组中位数 9/12，有 Skill 组 12/12，且重复运行方差归零 |
| 工程质量 | 20% | 4.5 / 5 | 22 个 Skill 零断链，21/22 frontmatter 满分，但有 3 个 Skill 没有分层参考目录 |
| 触发准确率 | 15% | 5.0 / 5 | 正例召回 10/10，误触发 0/10 |
| 覆盖度 | 15% | 3.0 / 5 | 更关注新 API 和边缘平台，普通业务的基础场景覆盖有限 |
| 权威性 | 10% | 5.0 / 5 | 内容由 Google 官方资料生成，来源边界清晰 |
| 可执行性 | 10% | 5.0 / 5 | 同时提供脚本和 CLI 方向，能把知识转成检查动作 |
| 维护活跃度 | 5% | 3.5 / 5 | 更新频繁，但不接受外部 PR，自动同步任务目前没有启用 |
加权总分：4.4 / 5。
这个分数代表“作为开发辅助工具的工程质量”，不代表所有项目都应该安装全部 Skill，也不代表生成的代码可以跳过编译和人工审核。
一、Google Android Skills 到底是什么
它不是一个单一的聊天机器人插件，而是 22 个按 Android 平台领域拆分的 Skill 集合，覆盖：
- 构建系统与 AGP 升级；
- CameraX、Media3 和设备能力；
- Jetpack Compose 自适应布局、主题和迁移；
- Navigation 3、系统栏和 edge-to-edge；
- R8、Perfetto SQL 和性能 Trace；
- Play Billing、Play 政策和 Engage；
- Wear OS、TV 和 XR；
- Android Intent 安全；
- 测试、截图测试和开发工具 CLI。
这个目录结构说明了它的产品定位：它不是把“Android 基础知识”重新包装一遍，而是优先覆盖 Agent 容易在细节上出错、但又很难只靠通用训练记忆稳定完成的任务。
官方安装入口的典型形态是：
android skills add --skill=<skill-id> --project=.实际参数仍需以当前版本的官方 CLI 文档为准。安装命令返回成功，并不等于 Skill 已经适合你的工程；还要检查版本、目录、依赖和权限。
二、我们怎么测
这次测评没有把“看过 README”当成实测，而是拆成三层。
L0：全量静态体检
对 22 个 Skill 的 SKILL.md 运行静态审计，检查：
- frontmatter 是否包含 name、description、license、author、last-updated 和 keywords；
- SKILL.md 的真实 token 数，而不是用磁盘字节数估算上下文成本；
- references 目录与入口文件的渐进披露比例；
- 所有相对 Markdown 链接是否能在本地找到；
- description 是否使用症状式触发词。
L1：触发准确率
只把每个 Skill 的名称和 description 交给一个干净 Agent，不允许读取正文，模拟真实的“应该选哪个 Skill”阶段。
测试包含：
- 10 条应该触发 edge-to-edge 的正例；
- 10 条语义相近但不应该触发 edge-to-edge 的负例；
- 例如“按钮被系统导航栏遮挡”和“按钮点击没反应”必须被区分。
L2：A/B 产出对照
使用同一个故意埋入缺陷的最小 Compose 工程和同一句用户请求，分别运行三次：
| 组别 | 条件 | 次数 |
|---|---|---|
| A 组 | 裸模型，不注入 Skill | 3 |
| B 组 | 注入 edge-to-edge 的 SKILL.md，并要求严格遵循 | 3 |
输出使用 12 项客观清单评分，其中包含双重 padding 的负向检查。每组取中位数，以降低单次生成波动。
L3：本轮没有做
本轮没有执行真实 Gradle 编译、安装到模拟器、运行截图和视觉回归。因此，本文可以评价“静态正确性和生成稳定性”，不能证明最终 APK 在真实设备上一定没有遮挡。
三、L0 静态体检：工程质量比磁盘大小更重要
静态检查得到三个重要结果。
1. 22 个 Skill，全部相对链接有效
这是本轮最硬的质量信号。整个 references 目录约 568,915 tokens，入口文件和参考文件数量都很大，但没有发现失效的相对链接。
这说明它的文档生成流水线至少能保证目录结构的一致性。对 Agent 来说，链接可用意味着它可以从入口说明继续加载所需 recipe，而不是走到一半才发现参考资料不存在。
2. 21/22 个 Skill 的 frontmatter 完整
唯一缺少 last-updated 字段的是 android-cli。其余条目都具备名称、描述、许可证、作者、更新时间和关键词。
这对自动触发很重要：没有描述和关键词，Agent 很难判断什么时候应该加载；没有更新时间，开发者也无法判断一条建议是否可能已经落后。
3. references 很大，不等于一次要读完
engage-sdk-integration 的 references 约 191,467 tokens，但入口 SKILL.md 只有 1,978 tokens，渐进披露比例达到 96.8。按磁盘大小看，它像是最臃肿的 Skill；按触发时真正进入上下文的 token 看，它反而是分层做得最好的条目之一。
真正需要警惕的是入口文件本身过大的情况：
| Skill | SKILL.md token | 主要问题 |
|---|---|---|
| wear-compose-m3 | 9,355 | 一次触发就会消耗接近一万 token |
| leanback-to-compose-tv-migration | 7,008 | 入口文件与参考资料拆分不够 |
| display-glasses-with-jetpack-compose-glimmer | 5,105 | 入口偏大，仍可继续压缩 |
相反，android-intent-security、edge-to-edge 和 play-policy-insights 没有 references 目录，所有内容都放在单个入口文件里。这种写法不一定错误，但与“渐进披露”的整体方向不一致。
4. 更新时间暴露了批量同步机制
18 个 Skill 的 last-updated 都是 2026-08-06，另外两个是 2026-05-14，一个是 2026-07-13，还有一个缺失。
这说明它更像是一次批量生成的官方文档投影，而不是 22 个条目分别由维护者持续编辑。批量生成的优点是来源统一，缺点是某个条目可能因为上游文档变化而突然发生结构或版本变化。
四、L1 触发测试：为什么 edge-to-edge 能做到零误触
L1 的结果是：
- 正例召回率：10/10，100%；
- 负例误触发：0/10，0%；
- 整体判断一致率：20/20，100%。
其中最值得学习的不是关键词数量，而是边界写得足够窄。
edge-to-edge 的 description 同时包含三种信息：
- 症状：按钮或列表被系统导航栏、状态栏遮挡或重叠；
- 子领域：IME insets 和 system bar legibility；
- 因果边界：只处理系统栏、键盘和 inset 导致的遮挡，不处理所有按钮故障。
因此，下面两句话会得到不同结果：
- “底部按钮被导航栏挡住了”——应该触发；
- “按钮点击没反应，onClick 不执行”——不应该触发。
这对所有 Skill 都有启发：description 不应该写成“修复按钮问题”，而应写成“当按钮因系统栏遮挡而不可见或不可点击时使用”。范围限定词比堆很多相关关键词更能降低误触发。
L1 也暴露了边界问题
这次测试并不是所有选择都同样可靠：
- perfetto-trace-analysis 对“列表很卡”和“启动很慢”有合理匹配，但 description 要求用户已经提供 trace 文件；现实中用户往往还没有 trace；
- adaptive 与 navigation-3 都涉及双栏、列表-详情和多面板，存在竞争触发；
- styles 提到主题、组件和自定义参数，容易被误认为是深色模式配色排错，但它实际更偏向 Styles API 的迁移和接入；
- P11 的交互事件问题和 P20 的深色模式配色问题，在现有 22 个 Skill 中都没有真正对应项。
覆盖空洞本身不是问题，但如果一个 description 写得过于宽泛，它就会变成这些问题的默认垃圾桶。
五、L2 A/B 实测：Skill 的价值是降低方差
测试任务是一个 Android App 的 edge-to-edge 修复请求，原始 fixture 故意包含：
- targetSdk 为 34；
- 没有调用 enableEdgeToEdge；
- 使用硬编码的 top padding；
- LazyColumn 没有 contentPadding；
- FAB 使用裸 padding，可能被系统栏遮挡；
- manifest 没有 windowSoftInputMode；
- 浅色背景配默认状态栏图标，存在可读性问题。
12 项检查结果如下：
| 检查项 | A1 | A2 | A3 | B1 | B2 | B3 |
|---|---|---|---|---|---|---|
| targetSdk 达到要求 | ❌ | ❌ | ❌ | ✅ | ✅ | ✅ |
| 调用 enableEdgeToEdge | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| 在 setContent 之前调用 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| 正确处理 resize | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| 使用 Scaffold | ✅ | ✅ | ❌ | ✅ | ✅ | ✅ |
| LazyColumn contentPadding | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ |
| consumeWindowInsets | ✅ | ❌ | ❌ | ✅ | ✅ | ✅ |
| FAB 不再使用裸 padding | ❌ | ✅ | ❌ | ✅ | ✅ | ✅ |
| 没有双重 padding | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| 没有幻觉 API | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| 处理 IME | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| import 正确 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
结果是：
| 组别 | 三次得分 | 中位数 | 极差 |
|---|---|---|---|
| A 组，无 Skill | 9、10、8 | 9/12 | 2 |
| B 组，有 Skill | 12、12、12 | 12/12 | 0 |
这说明 Skill 并没有把一个完全不会做的模型变成专家。裸模型最好的结果已经达到 10/12，三次也都正确调用了核心 API。
真正的增益在稳定性：
- consumeWindowInsets 由 1/3 提升到 3/3；
- FAB 的系统栏安全处理由 1/3 提升到 3/3；
- Scaffold 结构由 2/3 提升到 3/3；
- LazyColumn 的 contentPadding 由 2/3 提升到 3/3。
对单人开发来说，9/12 可能已经“能继续改”；对团队协作来说，同类问题每次生成不同架构，会增加评审、返工和维护成本。这里的 Skill 更像一条稳定器，而不是一台更强的代码生成器。
六、强约束的副作用：一致性不等于工程判断
有一个反向发现非常重要。
edge-to-edge Skill 要求项目 target SDK 至少达到 35。于是 B 组三次都自动把 targetSdk 从 34 升到了 35；A 组三次都没有主动做这个升级。
A 组的理由并不是“不知道这个要求”，而是认为：
- 修复遮挡问题不一定必须同时升级 targetSdk；
- targetSdk 升级可能改变权限、后台限制和前台服务等行为；
- 用户只请求修复 UI，不一定授权扩大升级范围。
这暴露了 Skill 的真实张力：
- MUST 能保证团队输出一致；
- 但过度使用 MUST，也会压制 Agent 对变更影响面的判断。
更好的写法是区分两类要求：
- “不这样做就无法完成修复”——使用 MUST；
- “这是推荐的长期升级方向”——使用 PREFERRED，并说明影响面和回滚成本。
七、另一个版本兼容性问题
B3 发现 Skill 推荐的 IME 首选方案，在 fixture 使用的 Compose BOM 2024.12.01 中并不存在，最后退回到 Skill 中列出的备用方案：
contentWindowInsets = WindowInsets.safeDrawing
这不是 Skill 完全失效，而是说明它的内容更靠近最新 SDK。对于仍然使用较旧但主流依赖的工程，Agent 必须自己核对 API 是否存在，不能只照抄首选方案。
因此，任何包含新 API 的 Skill 都应该明确写出：
- 最低 compileSdk；
- 最低 Compose 或 Gradle 版本；
- 实验 API 是否需要 opt-in；
- 旧版本应该使用哪条降级路径。
八、它做得好的地方
1. 选题由模型评测驱动
它没有把主要篇幅放在模型已经熟练的基础 Compose 教程，而是选择模型在性能、系统栏、R8、边缘设备和新 API 上容易出错的场景。
2. 指令像契约，而不是普通文档
MUST、PREFERRED、禁止项、输出格式和条件分支，使 Agent 更容易收敛到一致结果。L2 的方差归零，正是这种写法的实际体现。
3. 具备可执行工具链
部分 Skill 不止提供文字说明，还提供 Python 分析脚本和 android CLI 入口。它们能让 Agent 检查、转换、运行、截图和生成报告，而不是只输出一段建议。
4. 官方文档是单一事实来源
仓库通过流水线批量获取官方文档并重新生成内容，能减少手工复制造成的断链和版本漂移。
九、它的问题
覆盖面偏向新 API 和边缘平台
22 个 Skill 中，Wear、XR、TV、Play Engage、新版导航和性能分析占据很大比重。普通业务 App 真正高频使用的可能只有少数几个。
版本要求偏前沿
部分条目要求 AGP 9、compileSdk 37、实验性 Compose API 或 targetSdk 35。对锁版本的生产工程来说，它们可能更适合做迁移评估，而不是直接执行。
不接受外部贡献
仓库声明暂时不接受公开贡献，只能提 Issue。这意味着社区发现的描述边界或版本问题，不能直接通过 PR 修复。
自动同步没有真正启用
更新工作流中的 schedule 仍然被注释，实际依赖手动触发。last-updated 的批量相同日期也印证了这一点。
android-cli 尚未完成实测
它可能是最有价值的工具型 Skill，因为它给 Agent 提供 SDK、模拟器、运行、截图和文档检索能力。但本轮没有安装和运行它，所以这里只能列为高潜力项目，不能写成已验证推荐。
十、到底该不该安装
建议不要一次性安装全部 22 个 Skill，而是按工作流选择：
| 你的任务 | 优先考虑 |
|---|---|
| 系统栏、键盘和刘海屏遮挡 | edge-to-edge |
| R8、包体积和 keep rule | r8-analyzer |
| XML 迁移到 Compose | migrate-xml-views-to-jetpack-compose |
| 截图测试和测试基础设施 | testing-setup |
| 平板双栏和自适应布局 | adaptive |
| Wear OS、TV 或 XR | 对应平台 Skill |
| 性能 Trace 和卡顿分析 | perfetto-trace-analysis / perfetto-sql，先确认是否已有 trace |
| 需要 Agent 自动装 SDK、跑模拟器和截图 | android-cli，等待完整实测后再纳入生产流程 |
第一次使用时，建议在临时工程中完成：
- 固定 Skill、SDK、依赖和仓库提交版本；
- 跑一个十分钟内能完成的最小任务；
- 故意制造一次缺依赖或版本不兼容；
- 保存命令、日志、diff 和失败恢复步骤；
- 真实编译并在模拟器中截图；
- 确认它没有超出用户请求范围地升级工程。
最终结论
Google Android Skills 的工程质量确实很高：静态检查稳定、触发边界清晰，A/B 实测也证明它能把同类任务的产出方差压到零。
但它不是 Android 全能助手，更不是生产质量保证。它最适合用来处理“模型基本会，但细节经常不稳定”的长尾问题；不适合在没有版本核对、编译和设备验证的情况下直接照抄。
如果只选择一个方向开始，建议从 edge-to-edge、测试基础设施或性能分析中挑一个与当前项目最相关的 Skill，用最小工程做一轮可撤销实测。只有当它真的减少了返工，并且没有扩大权限和升级范围，才值得进入团队的默认工具链。
证据边界：本文的 L0、L1、L2 结果来自 2026-08-08 至 2026-08-09 的本地测试快照；L3 真编译、模拟器安装和截图回归尚未完成。所有“可用于生产”的判断都应在目标工程中重新验证。