上周，谷歌Android团队的Chris Banes公开了一套Claude Code技能文件，专门针对Kotlin、Jetpack Compose和Android开发。我花了一个晚上研究这套配置，发现确实有不少值得聊的东西。
先声明，我没法保证测试过仓库里的每一个技能。但我自己用Claude Code技能做后端开发已经有几个月了，看到一个有深厚Android背景的人愿意公开自己的配置，这本身就是个值得拆解的信号。
Claude Code技能到底是什么？
简单回顾一下。技能是可复用的指令文件，放在.claude/skills/code>目录下，Claude会自动读取，并在描述匹配当前任务时调用相关技能。官方文档有更详细的格式说明。
一个典型的技能文件结构长这样：
前面是包含name和description的YAML frontmatter，后面是普通的Markdown指令。写起来简单，分享也方便。
为什么这比贴代码片段强
在用技能之前，我跟Claude同步"我们这里怎么做"的方式要么是CLAUDE.md文件，要么每次会话开头手动贴上下文。两种方法都能用，但都有代价。
CLAUDE.md每次都会加载，对于那些用不到这些规范的任务来说，上下文就臃肿了。手动贴上下文则意味着你总会忘一半。技能处在中间地带——它们随时可用，但只在相关时才被拉取。
对Android开发来说，这一点比想象中更重要。Compose处理状态至少有三种合理方式，具体用哪种取决于场景。没有明确指导的话，让Claude自己选对基本靠运气。
一个实际例子
假设我要搭建一个带列表和详情页的界面。没有指导的情况下，Claude可能返回一个在ViewModel里用MutableStateFlow的方案——代码完全正确，但我实际想要的是rememberSaveable，因为这种状态需要撑过配置变更，但不需要存到别的地方。
针对这种情况的技能文件可能是这样：
核心逻辑是：ephemeral状态用remember，要撑过配置变更的用rememberSaveable，跨页面共享或要撑过进程死亡的放ViewModel。屏幕级状态优先rememberSaveable而非ViewModel，除非别处需要观察这个状态。
这就是技能的价值所在。你不是在写代码，而是在编码判断标准，让Claude能在不同会话里一致地应用。
怎么用起来
第一步很明显，把仓库克隆到你项目的skills目录。Banes的仓库按功能分了类：有处理Kotlin惯用法的，有Compose UI模式的，还有Android架构决策的。结构很清晰，按需取用就行。
克隆之后，Claude会在相关任务时自动识别这些技能。不需要额外配置，不需要手动触发。这种"需要时才出现"的特性，正是技能比全局配置文件更轻量的原因。
这背后说明了什么
一个谷歌Android团队的工程师愿意花时间整理并公开自己的Claude配置，这件事本身比配置内容更有意思。
首先，这说明AI辅助编码在Android生态里已经不再是边缘实验，而是进入了"值得投入工程精力优化"的阶段。其次，技能文件这种形式确实解决了真实痛点——不然一个 busy 的工程师没动力做这件事。
更重要的是，这指向了一种新的协作模式：不是让AI从零学起每个项目的规范，而是把规范打包成可复用的模块。对于Android这种有强烈官方推荐范式、但实际项目总有自己变种的领域，这种模式尤其合适。
局限在哪
技能不是万能的。它们解决的是"给定场景下怎么选"的问题，但前提是Claude能正确识别当前场景。如果描述写得不够精准，或者任务边界模糊，技能可能不会被触发，或者被错误触发。
另外，技能文件里的判断标准需要维护。Compose的最佳实践在演变，Kotlin的新特性在加入，今天合理的决策逻辑明年可能就需要调整。这不是一次性配置，是需要持续投入的活文档。
值得跟进的信号
Banes这套配置的价值，很大程度上在于它提供了一个经过实战检验的起点。你不用从零摸索哪些场景需要明确指导，直接参考一个资深Android工程师的划分方式。
对于已经在用Claude Code的Android开发者，这省下了大量试错时间。对于还没开始用的，这是一个具体的切入点——不是抽象地讨论"AI能写代码了"，而是看一个真实项目里AI怎么被调教来配合特定技术栈。
我注意到这个仓库还在更新。技能文件的数量和覆盖范围比上周我看的时候又多了一些。这种持续维护本身也是个信号：作者自己在用，而且用出了新需求。
最后一点观察。技能文件的描述字段写得相当具体，不是笼统的"处理Compose状态"，而是精确到"搭建Compose UI状态时在rememberSaveable、ViewModel状态和remember之间做选择"。这种精确度直接决定了Claude能不能在正确的时候调用正确的东西。对于想自己写技能的人来说，这是值得学习的写法。
热门跟贴