1. 这玩意儿到底是个什么AI 编程助手的“技能弹药库”先说个我自己的真实场景。上个月我在做一个内部工具的重构代码库不大但接口调用关系绕得厉害。我的 AI 编程助手给我生成了一版重构建议方向是对的可它明显没搞懂这个项目里“配置中心”和“权限校验”之间的隐式依赖导致改出来的代码在边界情况下直接崩。当时我意识到一个问题不是 AI 能力不行而是它对我的项目上下文“一无所知”。后来我找到了 Antigravity Awesome Skills 这个技能库准确说是面向 Antigravity 这类 AI 编程助手的可安装技能集合。它里面收录了 1527 个 skill覆盖从需求拆解、代码生成、测试覆盖、安全审计到提交信息规范的各种场景。所谓“技能”你可以把它理解成给 AI 助手外挂的“专业手册”一个技能就是一套结构化的指令包、检查清单和示例集合装上之后助手在处理某类任务时会自动调用对应的知识和操作流程。这篇文章我打算讲透三件事Antigravity 的技能机制到底是什么和普通提示词有什么区别这 1527 个技能分布在哪些赛道哪些真正值得装哪些装了纯属浪费从安装到踩坑再到自己写一个技能塞进去的完整实操路径。如果你正在用 AI 编程助手且觉得它“好像会但总是差点意思”这篇应该对你有用。我自己是从“用完就忘”的提示词党变成了“把知识沉淀成技能”的配置党这个转变直接改变了我用 AI 的工作方式。2. 为什么 1527 个技能不是“多多益善”筛选比收藏重要得多2.1 技能库的本质把“优秀实践”变成可复用资产先说说“技能”这个东西在技术上的本质。大家平时给 AI 写提示词写的是“给我写一个 Python 函数实现 xxx”。这句话是一次性的离开当前对话就失效换一个任务又要重新写。而一个 skill 文件不是这样它通常包含三部分触发器描述什么时候该用这个技能。比如“当用户要求对代码做安全审计时”执行流程AI 拿到任务后应该按什么顺序做什么。比如先读配置文件、再定位敏感操作、最后按风险等级输出报告输出模板与质量标准结果应该长成什么样。比如必须包含“风险等级、受影响接口、修复建议”三栏缺一不可。这就像你给实习生长篇大论讲了一遍工作流程然后他每天都能按这个流程干活不用你每次重新说。Antigravity 的 skill 机制就是这个思路——把一次性的优秀实践固化成文件需要的时候自动触发。理解了这个本质你会发现技能库的价值不在数量而在于每个技能是否真的覆盖了一个你经常重复做的任务类型。1527 个听起来很唬人但其中真正和你日常工作重合的可能就几十个。装太多反而会让助手在选择技能时纠结甚至触发错误的技能。2.2 按工作流给技能分类比按“技术栈”分类更能提高选择效率我看了一下这个技能库的目录结构最开始的分类是按技术栈来的Python、Java、TypeScript、Rust……但实际用下来我强烈建议你别这么选。因为技术栈是“静态的”而你的工作是“动态的”。你写 Python 不代表你只干一个固定流程的活你可能今天写数据脚本明天做接口调试后天又去排查性能问题。如果只按语言装技能你会陷入两个困境要么每个语言都装一堆技能总数爆炸要么漏掉跨语言的通用环节比如需求拆解、测试设计这类和语言无关的底层能力。我自己的做法是按工作流分类挑出这几类优先级最高的技能类别解决的问题典型场景任务规划类把模糊需求拆成可执行步骤“帮我重构这个模块”代码审查类让 AI 按项目规范检查代码提交前 Code Review测试用例类按边界条件生成测试新接口上线前补测试文档生成类自动产出合规的说明文档README、接口文档更新提交规范类生成符合团队规范的 commit message每次提交代码安全审计类排查敏感信息和漏洞项目上线前检查按这个维度选装 20 个左右就能覆盖我 80% 的日常 AI 使用场景。这个结论不是我拍脑袋想的是我把过去一个月的 AI 使用记录翻出来统计的——和 AI 的对话里超过一半都落在这几类任务上。2.3 技能挑选的四个原则我反复踩坑后总结出来的第一看技能的描述是否“场景化”。好的技能描述会写“当你需要把用户故事拆成开发任务时”差的只会写“需求分析技能”。前者 AI 能准确匹配后者大概率触发不了。第二看技能的约束是否足够具体。比如一个好的测试生成技能会规定“必须覆盖空值、超长输入、并发调用三种边界”而不是笼统地说“生成全面测试”。约束越具体AI 的产出越稳定。第三看输出格式是否清晰。有些技能定义了精确的输出模板AI 生成的结果不需要二次整理有些技能只给了一堆建议AI 输出的东西还是要你重新加工。我反正优先选前者。第四起步求稳不追求覆盖全。新手期的价值点是确定性装了 10 个技能每个都能稳定生效这比装了 50 个技能、有一半在“间歇性生效”强得多。等你熟悉了 skill 的触发逻辑再逐步扩大技能面不迟。3. 动手装一次从克隆仓库到验证技能生效的完整流程3.1 环境准备和目录结构说明Antigravity 这个助手读取技能的方式和读取配置差不多它有自己的技能目录你只要把 skill 文件放进指定目录并确保文件名和后缀符合规定它就会在启动时自动扫描并加入可调用列表。我当时的操作路径大概是这样的# 1. 克隆技能库仓库如果只想挑着装也可以先下载到本地再手动拷贝 git clone https://github.com/example-org/antigravity-awesome-skills.git # 2. 确认 Antigravity 的技能目录路径 # 通常位于用户目录下的 .antigravity/skills cd ~/.antigravity/skills这里有个特别容易忽略的点目录路径因系统而异。我同事在 Windows 上装的时候目录路径就藏在用户目录的 AppData 下面和 macOS 完全不一样。建议你先在 Antigravity 的配置界面里看技能目录的实际地址别默认按文档里的路径来。3.2 推荐安装方式按需复制不要一口气全装1527 个技能如果全部复制进目录理论上 Antigravity 也能启动但实际体验会很差——启动扫描变慢不说AI 在选择技能时还会出现“选择困难”最典型的表现就是你让它写个排序算法它居然先触发了“系统架构设计”技能输出的内容直接跑偏。我推荐的做法是先筛选后复制分三步走# 1. 在技能库根目录搜索你工作流中需要用到的技能名 # 比如安全审计、测试生成、提交规范、文档生成… cd antigravity-awesome-skills ls skills | grep -i security ls skills | grep -i test ls skills | grep -i commit # 2. 把这些技能目录逐个复制到 Antigravity 的技能目录 cp -r skills/security-audit ~/.antigravity/skills/ cp -r skills/test-generator ~/.antigravity/skills/ cp -r skills/commit-standard ~/.antigravity/skills/ # 3. 重启 Antigravity让技能扫描逻辑重新加载有的小伙伴喜欢直接软链接过去好处是技能库更新的时候不用重新复制ln -s /path/to/antigravity-awesome-skills/skills/security-audit ~/.antigravity/skills/这个方式我后来也用了但它有个坑如果你在技能库里改文件名或者移动目录软链接会断掉Antigravity 会静默忽略失效的技能而且不报错你只会发现某个技能“不灵了”排查起来很费时间。3.3 怎么确认技能真的生效了装完之后最让人心虚的时刻就是“到底装没装上”。我自己的验证方法有两种。一种是直接看技能列表。在 Antigravity 的会话界面里输入斜杠命令查看已加载技能比如/skills list如果目录里的技能出现在列表中说明扫描成功。这里注意不是所有版本都有这个命令如果你用的版本没有这个命令跳过直接看下一条。另一种是行为验证法我更推荐这个。你故意触发一个技能对应的场景然后看 AI 的输出是否带有该技能定义的格式特征。比如我装完 commit 规范技能后让它为一个改动生成提交信息如果它输出的 commit message 严格带上了“类型、影响模块、关联需求”的结构大概率就是生效了。反之如果你试了两三次都还是它“自由发挥”的样式那不管列表里有没有都要查一下是不是没加载成功。4. 实测记录这几个技能让我从“能写”变成“写得对”4.1 代码审查技能从“看热闹”到“看门道”以前我让 AI 帮我 review 代码得到的反馈基本就是“这段代码逻辑清晰但可以增加异常处理”——正确的废话。装了代码审查技能之后它的输出完全变了一个层级。当时我拿一个同事写的支付回调接口做试验这个技能直接输出了三类问题表象问题参数校验不完整某个字段没有判断空值隐患问题回调幂等性只查了本地状态没有考虑并发下的重复回调规范问题错误码不符合项目里“前两位表示模块”的约定。说实话最后一条是我看完之后才发现项目里真有一份错误码规范文件只是我和同事都忘了。这就是技能的价值——它把“应该查什么”写成了检查清单AI 在触发时会按清单逐项过而不是凭语感给你泛泛而谈。这个技能给我最大的启发是审查类技能好不好取决于它的检查清单够不够细。你看技能内容的时候别只看开头几句好听话重点翻它的步骤列表和输出模板。4.2 测试用例生成技能边界条件不靠猜测试用例生成技能是我在技能库里最惊喜的一个发现。装的这个技能要求 AI 在生成用例时必须先列出“输入域分析”也就是把所有可能输入的类别分出来再针对每一类写用例。我拿一个日期格式化函数来试AI 在分析阶段就列出了有效日期、闰年 2 月 29 日、非闰年 2 月 29 日、月份 13 日、日期为 0、时间戳为 0、负数时间戳、超大时间戳。一共 8 类。其中“月份为 0”和“日期为 0”这两类是我自己在平时写用例时最容易漏掉的因为人下意识觉得“月份不都是 1 到 12 吗”。AI 在技能约束下会机械地执行“列全输入域”的步骤反而逼着它做了更完备的覆盖。装了这个技能之后我做了一个明显的改变让 AI 生成用例之后我不会直接复制而是先看它的“输入域分析”列表把我觉得还缺的类别补上再让它按补充之后的类别生成代码。AI 就从一个“写用例的”变成了“按我补充后的思路写用例的”效果完全不一样。4.3 文档生成技能README 终于不是摆设了项目文档是我最不愿意写的东西没有之一。但我也清楚文档缺失的后果是三个月后没人能看懂这个模块在干什么。这个技能库里的文档生成类技能触发时会先自动遍历项目的目录结构和关键文件然后把文档分成“项目简介、快速开始、配置说明、目录结构、常见问题”几个固定板块。最让我意外的是它会要求 AI 在“快速开始”部分把每个步骤对应的命令都写全而不是写“安装依赖然后启动”这种假大空。“常见问题”板块也很有意思技能要求 AI 根据代码里的 TODO、异常处理分支和注释中的疑点自动推断出用户可能会问的问题。当时它读到某个模块里有个“临时兼容逻辑”的注释就在文档里生成了一条“常见问题为什么这里需要临时兼容”——这一条比我自己写文档时会想到的还全。5. 踩坑记录技能装了没效果先别急着砸键盘5.1 技能未生效的排查链路我自己遇到过最无语的一次装完测试生成技能之后怎么触发都没反应。后来排查了一圈发现是技能描述里的触发关键词和我实际表达的场景不匹配。很多技能在描述里写的是“当用户要求生成单元测试时”但这个触发条件在 Antigravity 的技能选择器里通常是通过语义匹配来实现的不是简单的关键词命中。我当时让 AI “给这个函数写测试”语义上应该能匹配上但结果就是没触发。排查链路我是这么做的分享给大家先确认技能文件位置正确。我检查了目录发现文件确实放进了~/.antigravity/skills/下而且文件名后缀符合规范。重启确认扫描加载。重启后我重新检查/skills list如果在列表里就没加载问题。观察 AI 的输出是否带技能特征。如果完全不带说明 Meshidator 在选择技能时没把它选中。修改技能描述里的触发词。这个是需要你自己动手的地方把描述改成和你日常表达更接近的说法。比如原来写“当用户要求生成单元测试时”我改成“当用户要求给函数写测试、搞用例、覆盖测试时”改完之后触发率一下就上来了。这里多说一句触发词不是越多越好。有些人为了保险把能想到的词全塞进描述里结果语义匹配器反而因为选项太多而犹豫最终触发了一个不准确的技能。我的经验是描述保持在两三句话每句话对应一种常见的表达场景就够了。5.2 上下文膨胀装多了反而影响质量第二个坑是技能装多了AI 在输出时会把多个技能同时激活导致上下文膨胀质量问题就来了。我装完代码审查和测试生成技能后有一次让 AI 帮我 review 一段 Python 代码输出里居然同时出现了代码审查意见和测试用例设计看起来好像很全面但两边的深度都不够。后来去看了技能加载逻辑才发现技能系统是按“相关度”激活的两个技能的相关度都被判得比较高就同时拉进来了。解决方法是给技能配置“互斥提示”。在技能的描述或约束里写明“本技能只专注于代码审查不涉及测试用例生成如果用户同时要求测试请分两步执行”。加了这句话之后AI 的“串味”现象明显减少。5.3 同名覆盖你以为装了其实是白装还有一个特别隐蔽的坑同名覆盖。技能库里有不少跨语言、跨框架的同名技能比如都叫code-review的就有好几份。如果你先后把两个同名技能都复制进目录Antigravity 一般使用目录扫描机制后扫描到的同名技能会覆盖先扫描到的而且没有任何提示。我一开始完全没注意到这个问题后来发现审查风格时好时坏才意识到目录里有两个code-review文件夹。排查的时候你可以这样看# 搜索技能目录里的同名文件macOS/Linux find ~/.antigravity/skills -name *code-review* -type d # 如果出现两个目录保留你真正想要的那个另一个删掉或改名这是我实际踩过的坑属于那种“不让你报错、只会让你怀疑人生”的类型。6. 装得再多也是别人的自己动手写一个技能比想象中简单6.1 技能的最小文件结构用了一段时间之后我最大的一个感受是你真正用得顺手的技能往往是按自己的项目习惯调过的。与其等技能库里出一个完全合心意的版本不如自己做一个小小的。Antigravity 的技能文件格式不复杂一个 skill 通常就是一个目录下一份描述文件外加可选的规则文件。最小的完整技能结构大概是这样my-review-skill/ ├── SKILL.md # 技能描述包含触发条件和执行流程 └── rules.md # 详细规范和检查清单可选SKILL.md是灵魂。我自己写了一个针对“项目接口文档一致性”的审查技能内容大概是--- name: api-doc-consistency-review description: 当用户要求审查接口文档与代码实现的一致性时触发。 --- ## 执行步骤 1. 读取当前项目的接口定义文件如 OpenAPI 配置。 2. 扫描代码中对应的路由和控制器实现。 3. 逐项对比接口定义与代码实现找出不一致项。 4. 输出差异清单每项包含接口路径、文档定义、代码实现、差异说明、修改建议。 ## 输出格式 | 接口路径 | 文档定义 | 代码实现 | 差异说明 | 建议 | | --- | --- | --- | --- | --- |你编译完这个文件放进技能目录重启一下它就变成一个可以在需要时自动触发的技能了。第一次写的时候我有点忐忑结果跑通之后觉得比想象中简单太多。6.2 写技能时容易被忽略的三件事第一执行步骤要拆到“可机械执行”的粒度。不要说“分析接口一致性”要说“对比接口定义中的路径参数与代码路由中的路径参数是否一致”。前者需要 AI 自己判断怎么做后者是明确指令输出的稳定性完全不同。第二输出格式的约束一定要具体。我之前写过一个技能只写了“输出审查结果”结果 AI 输出的是大段散文根本没法直接用来提工单。后来我把输出格式强制改成表格AI 每次都会规规矩矩填表格虽然少了点自由发挥但实用性直接翻倍。第三要先小范围验证再推广。新技能写完先自己在几个典型场景下试确认输出符合要求后再考虑拷给别人。我之前写了个需求拆解技能自我感觉很好结果给同事用了一次他跑过来说“这个技能拆得太啰嗦了25 分钟的任务能拆成 8 个步骤我看着都累”。后来我把步骤合并成了 4 个才勉强能用。7. 最后再分享一点我自己的使用心得Antigravity Awesome Skills 这个技能库的价值不在于那 1527 这个数字而在于它给你提供了一套“把 AI 调教成团队老手”的范式。装技能不是目的筛选技能、调整技能、最终能自己写技能才是我觉得真正有意义的一条路径。我现在的工作流已经固定下来了用完一个任务凡是重复超过三次的我就考虑能不能把它写成一个技能写完先用一个月期间不断调整触发描述和执行步骤。到现在我的技能目录里大概常驻 30 个技能这 30 个是经历了“装了删、删了改、改了再装”之后留下来的。这篇文章写到这里我不是想说服你把这个技能库全装一遍恰恰相反我想说的是别管它有 1527 个还是 15270 个先挑 10 个能解决你当下最大痛点的装上、试用、调整然后再决定要不要继续加。工具是死的怎么让 AI 和你配合得越来越顺手这个探索的过程才是你真正会长期受益的东西。