过去半年我的 AI 编程助手使用习惯彻底变了从打开对话框问问题变成了先安装一个专用技能再开工。促成这种变化的是 Antigravity Awesome Skills 这套面向 AI 编程助手的可安装技能库目前收录了 1527 个技能包覆盖代码重构、测试生成、依赖升级、框架迁移、代码评审等常见工程场景。如果你也遇到过“助手说的东西没错但就是没法直接用进项目”的挫败感或者想把团队规范沉淀成可复用的能力这篇文章就是从认知到实操的完整梳理。我不打算只罗列命令我会把选型逻辑、排查过程、以及用了一个月后的真实体感都讲清楚。1. 为什么需要 1527 个“可安装技能”从通用问答到专用工作流1.1 通用助手的上限会写代码但不了解你的工程上下文很多人在最开始用 AI 编程助手时会觉得它“什么都会但什么都没那么会”。这里的原因其实不在模型本身而在任务描述方式。通用模型被训练成擅长回答宽泛问题可我们每天面对的工程任务往往是高度场景化的某个支付模块要按团队规范补测试某个老项目要从旧框架迁移到新技术栈某次改动需要同时更新接口文档和数据库迁移脚本。这些事情背后有一套隐性约定目录放在哪里、命名用什么风格、测试命令是什么、提交信息按什么模板写、错误码怎么统一。你当然可以每次都在对话框里把这些内容重新描述一遍但这是个非常糟糕的做法。一次对话塞两千字上下文模型确实能读懂可一旦任务稍微复杂一点关键约束就会被稀释输出质量立刻下降。我印象很深的一次经历是帮一个内部订单项目做配置迁移。当时我在对话里写清楚了“配置文件位置、迁移前后格式差异、必须保留的字段”前几个步骤还算顺利但到了校验阶段助手忽略了我最开始提到的“空值必须显式报错”这条规则直接生成了会吞掉异常的逻辑。问题就出在那些约定是我临时塞进上下文里的模型没有形成稳定的执行框架。技能库解决的就是这个问题。它把“项目背景 任务步骤 输出约束”打包成一个可安装、可复用的单元。安装之后助手在执行同类任务时不再是临场发挥而是按技能里写好的流程走。这个差别用一句话概括就是你从“每次喂模型吃上下文”变成了“让模型按一份成熟的作业指导书干活”。1.2 安装式技能与传统 Prompt 模板的本质区别很多人会问这不就是 Prompt 模板吗我自己以前也这么想直到我真正把一个技能包拆开看过才发现差别比想象中大。传统 Prompt 模板是一段静态文本。你把它存在备忘录里用的时候复制粘贴再手动修改里面的变量。这种方式有几个天然问题第一它没有结构全靠个人维护时间久了必然腐烂第二它没有“安装”和“卸载”的概念你没法知道当前会话里到底生效了多少套模板第三它很难被分发和版本化团队里每个人手里的模板可能都不一样。而 Antigravity 里的技能是一个结构化包至少包含三样东西元信息名称、描述、适用场景、依赖条件、指令体告诉模型在什么情况下做什么、按什么步骤做、输出什么格式、以及可选的资源文件示例、脚本、配置模板。这些内容被打包之后可以通过命令行安装、查询、更新、卸载就像一个应用商店里的 App 之于一段散落的网页脚本。1527 这个数字的意义也不在于数量本身而在于它代表了大量真实场景的沉淀。每个技能从一个具体痛点出发经过使用反馈迭代最后变成一套可以被其他人直接调用的流程。我个人的经验是直接使用社区里已经打磨过的技能比我自己从零写 Prompt 要稳定得多因为那些坑已经被前人踩过了。提示技能不是越复杂越好。好的技能通常只解决一个明确任务指令清晰、步骤有限不会试图覆盖所有情况。2. 技能库内容的组织方式如何在一千多个技能里快速定位2.1 一个技能包的真实结构要理解技能库怎么检索、怎么安装先得知道一个技能包内部长什么样。不同版本的格式可能有差异但常见的结构大概是这样django-migration-review/ ├── skills.yaml ├── prompt.md └── scripts/ └── parse_migrations.pyskills.yaml是元信息文件记录技能名称、描述、适用场景、作者、版本、依赖条件以及入口指令体的位置。prompt.md是核心指令体描述任务执行步骤、输入变量、输出格式和约束条件。scripts/目录放辅助脚本比如解析代码、扫描目录、生成报告这类需要确定性逻辑的部分。我最早以为只有prompt.md重要后来才发现skills.yaml里的描述字段才是决定检索命中率的关键。CLI 搜索技能时主要是靠这个描述字段做匹配描述写得越贴近实际任务语言越容易被搜索到。这也解释了为什么同样的关键词有些技能排在最前面有些则沉在下面——不是技能不好而是描述太泛了。2.2 技能库按哪些维度分类面对 1527 个技能最容易犯的错误是打开列表后不知道从哪看起。我自己的经验是先按这几个维度理解分类分类维度关注点典型例子语言/框架针对特定技术栈Django 迁移审查、TypeScript 类型修复、React 组件拆分任务类型解决某类工程动作补测试、生成提交信息、重构函数、排查崩溃日志工具链集成配合具体工具使用pytest 测试生成、git 提交信息、Dockerfile 优化团队流程规范某种工作方式代码评审、安全自查、发布前检查领域知识面向行业场景支付系统对账、数据迁移合规、权限模型设计这个分类并不在界面里直接显示但安装前你可以在技能的元信息里看到它属于哪个 category 字段。理解了分类搜索效率会明显提升。检索时我有一个很实用的组合技巧尽量用“任务动词 技术栈/工具名”来搜而不是只搜一个名词。比如搜“migration django”不要只搜“migration”搜“review typescript pr”不要只搜“review”。因为技能描述通常包含这些具体词汇组合搜索会同时命中描述字段和分类字段结果更准确。2.3 元信息里决定安装成败的三个字段在决定安装一个技能之前我会先看三个字段description、requires和engine。description决定了这个技能是不是真能解决我的问题。如果描述里写的是“帮助分析 Python 项目中的数据库迁移脚本”那它对 TypeScript 项目就没用没必要安装。requires列出的是该技能依赖的外部环境比如某个命令行工具、某个框架版本甚至某个模型能力等级。忽略这个字段很容易出现“装上了但跑不起来”的情况。engine则说明了这个技能是按哪种模式设计的不同模式对上下文处理和输出格式的要求不一样安装前看一眼能省很多时间。我一直建议别人养成一个习惯安装前先花十秒钟读这三个字段而不是看到名字就装。这一步能过滤掉至少三分之一看似有用、实际不适配的技能。3. 从安装到调用的完整实操链路3.1 前置准备与命令行安装在使用技能库之前需要先把 Antigravity 的 CLI 工具跑起来并确认它能连接到底层模型接口。这个步骤一般文档里都有但有个细节容易忽略CLI 需要在你的项目根目录下初始化否则技能执行时没法获取项目路径、文件列表这些上下文信息。有些技能安装成功但调用失败原因往往不是技能本身而是当前工作目录不在项目内。不同构建渠道的 CLI 命令首部可能略有差异下面以我常用的交互方式为例# 进入项目目录后先查看当前已安装技能 antigravity skills list # 搜索关键词组合 antigravity skills search migration review django # 安装指定技能 antigravity skills install django-migration-review # 再次确认安装状态 antigravity skills list --installed如果你的环境里需要批量安装也可以把技能名写进一个文件antigravity skills install --from-file skills.txt初次安装时CLI 通常会有一次确认提示列出技能涉及的操作范围和可能的副作用。我记得第一次安装一个会执行代码扫描脚本的技能时它明确提示了“该技能会读取项目中的迁移文件并生成分析报告不会修改任何文件”。这种透明提示很重要如果某个技能要求执行任意脚本、访问全局配置我会非常谨慎。3.2 三种调用方式自然语言、显式切换与命令行执行安装完成之后调用技能有几种不同路径我按使用频率排一下。最自然的是在对话里用自然语言触发。你可以直接说“用 django-migration-review 看一下这次迁移脚本有没有问题”助手会识别出技能名称并加载对应指令体。这种方式的优点是省事缺点是如果一句话里同时提到好几个技能可能触发混乱所以我只在调用高频技能时这么用。更可靠的是显式切换。在会话中输入斜杠命令/skills use django-migration-review这样会把当前会话的上下文切到这个技能下之后的对话都按这个技能的规则执行直到你切换或退出。我处理复杂任务时基本都走这条路因为它的行为最可预测。第三种是纯命令行执行适合在脚本或流水线里调用。例如antigravity skills run django-migration-review --target ./apps/orders/migrations这种模式会把技能当作一个小工具来跑输出通常是结构化的便于后续处理。无论哪种方式真正决定效果的是技能内部的“输入输出契约”。安装后我先看 prompt.md 里定义了哪些输入变量比如目标目录、文件列表、输出格式然后按它的预期提供信息。如果不提供助手就只能靠猜测效果自然不稳定。我用一个内部订单项目的实际经历来说明当时需要审查一批数据库迁移脚本。我没有直接让助手“帮我看看迁移脚本”而是先调用django-migration-review技能然后在对话里补充了“只需要关注索引和默认值变更不需要管字段重命名”。技能载入了预置的检查清单加上我补充的过滤条件最后生成的审查报告非常聚焦直接列出了三个值得注意的变更点。3.3 把技能接进日常工程流程而不仅是临时对话技能库另一个让我觉得值回票价的地方是它可以被接进工程流程而不是只存在于交互式对话里。比如可以在代码审查阶段加一步技能检查review-job: script: - antigravity skills run code-review-ts --diff origin/main..HEAD这样每次提交合并请求前CI 会自动调用技能对增量代码做一轮审查输出格式固定的结果。它不会取代人的审查但它能做一轮稳定、不疲倦的初筛。对我来说这是技能库从“玩具”变成“工具”的分水岭。4. 用了一个月后的真实复盘哪些技能值得装哪些是智商税4.1 我相对高频使用的几类技能使用一个月后我安装数量不算多真正留在常用列表里的就更少。先看结论技能类别典型场景我的评价测试生成类给现有函数补单元测试很值得装省下大量样板代码时间重构建议类拆分过长函数、消除重复代码有用但需要人工审查输出代码评审类增量代码检查相当稳定适合放进 CI提交信息生成类根据 git diff 写 commit message非常治愈每周省不少事儿大型迁移类配置文件迁移、依赖升级看情况技能只负责框架细节要盯装之前我最期待的是“自动生成完整测试”这类技能实际用下来它的效果反而不如“给既有函数补边界测试用例”这种窄技能。原因很简单完整测试涉及太多项目特有约束技能再强也覆盖不全而窄技能专注一个动作约束少输出就稳。4.2 效果差异背后的原因技能描述、指令颗粒度与模型能力为什么同样从技能库安装有的技能惊艳有的技能翻车我拆开看了好几个技能后总结出三个影响因素。第一技能描述是否可验证。好的技能会把“做得好”定义为可观察的标准比如“每个测试用例包含 Arrange-Act-Assert 三段结构”“所有新增代码必须通过静态检查”。差的技能只写“生成高质量测试”这种描述交给谁都没法稳定执行。第二指令体颗粒度是否合适。有些技能几乎没有具体步骤只有一段目标描述等于把问题又抛回给模型那我为什么不直接用通用对话呢另一些技能则过细要求模型执行十步操作中间一旦某一步出错就很难恢复。我比较喜欢“三步到五步”的技能明确输入、核心动作、输出格式再多就需要拆分成多个技能了。第三底层模型能力进入了一个关键区间。技能写得再好最终执行还是依赖模型对指令的遵循程度。在我自己配置的这套环境里同一个技能在不同模型版本上的表现差异很大升级后普遍更稳定。这也是一个容易踩的坑技能效果变差不一定是技能变了也可能是底层模型或接口参数变了。4.3 我的技能集管理习惯做减法安装技能这件事有一个隐蔽的成本叫“选择成本”。技能装得越多每次调用时越难决定用哪个甚至会出现多个技能争夺同一个任务的尴尬局面。我现在有两条原则。一是常驻技能控制在十个以内。日常高频任务就那么几类一个类别留一个技能就够。其余技能需要时再临时安装用完即卸减少干扰。二是定期做一次技能盘点。我会在每个迭代结束时执行一次列表清洗antigravity skills list --installed antigravity skills uninstall old-unused-skill别小看这一步。技能库本身是持续更新的今天装的一个技能两周后可能已经有大版本更新或兼容性问题留在那里只会成为隐患。保持一个精简、可信的技能集比拥有一个庞大但几乎不用的清单实用得多。5. 踩坑与排查安装不生效、版本不匹配、技能冲突5.1 技能装上后“没有生效”的完整排查链路技能使用不可能一帆风顺我第一个月就遇到了三次“装上但没反应”的情况。最开始我一头雾水后来总结了一条排查链路基本能覆盖大多数问题。第一步确认技能真的在已安装列表里。别看这步简单我就遇到过安装命令返回成功但因为网络问题实际没写完元信息的情况。antigravity skills list --installed如果列表里没有就重新安装并注意终端是否输出了 warning。第二步检查调用方式。如果你用的是自然语言触发但会话里同时存在多个技能助手很可能没有正确识别。这时切换成显式方式/skills use 技能名第三步查看详细日志。CLI 提供了 verbose 输出它会告诉你技能是否成功载入、指令体是否为空、是否有脚本执行失败。我觉得这步是排查效率最高的。antigravity skills run 技能名 --verbose第四步检查路径。技能执行时项目上下文由当前工作目录决定。如果你在项目根目录之外的地方调用技能很多步骤会因为文件找不到而静默失败。回到项目根目录再试一次能解决一部分“看起来没生效”的诡异问题。我把这几种情况整理成一张表方便对照症状可能原因排查动作安装命令报成功但列表没有元信息写入中断重新安装看 warning对话中触发没反应技能没有被识别改用显式/skills use执行后结果为空或报错指令体缺失或脚本失败跑--verbose看日志结果不稳定时好时坏工作目录不在项目内回到项目根目录再试5.2 版本不匹配技能按新版工具写了你的项目还停在旧版另一个比较隐蔽的问题是版本不匹配。技能作者通常在自己常用的环境里编写和测试技能如果技能里写的是新版本 CLI 才支持的命令而你的项目还在用旧版本执行时就会报错。我遇到过具体案例一个依赖升级技能默认使用lockfile新格式但我的项目还在使用旧的依赖锁定方式执行到中间步骤时直接失败。当时我没有先看技能的requires字段白白多花了一个小时。解决路径有三条。最优做法是先看requires在安装前就排除不兼容技能。其次是找一个版本相近的技能替代。如果只有这个技能符合需求我会把它复制到本地修改指令体里的命令和路径然后再安装本地副本antigravity skills install --local ./deps-upgrade-custom这个方式我非常推荐。你不需要成为技能开发专家只是把一个已有技能改成自己项目能用的样子成本很低效果却很贴合。5.3 多个技能同时加载导致的指令冲突还有一个真实存在的坑多个技能同时加载时输出格式要求互相打架。比如代码评审类技能要求输出 markdown 表格格式测试生成类技能又要求输出标准的测试文件结构。当你在同一个会话里先后调用这两个技能助手可能会把两种要求混淆生成的东西既不像审查报告也不像测试代码。我的处理方法是一个会话里只激活一个技能除非任务确实需要多阶段否则不在同一上下文里叠加。如果确实需要先审查再生成测试我会分两步执行中间重新打开一个会话避免指令残留。长期来看更好的方案是写一个组合技能。组合技能的指令体里明确定义阶段一调用哪个检查清单、阶段二调用哪个输出模板而不是在同一会话里把两个技能混在一起。这样行为可控也方便以后复用。6. 从使用者到维护者编写一个自己的技能并把团队经验打包6.1 技能的最小结构一个规范化审查技能的例子用了一段时间之后我很自然地就动了“自己写技能”的念头。原因很简单团队里的很多约定社区技能库里永远不会有现成版本因为它们太特异了。比如我们团队要求每次改动必须同步更新接口文档这个要求社区技能不可能替我写。动手之前我先参考了一个现有的简单技能然后从最小结构开始搭。下面是我的一个“TypeScript 代码变更规范审查”技能的雏形code-review-ts/ ├── skills.yaml ├── prompt.md └── scripts/ └── extract-diff-files.shskills.yaml里填的是技能的身份信息name: code-review-ts description: 审查 TypeScript 项目增量代码检查接口变更是否同步更新文档。 category: code-review requires: - git - typescript 5.0 engine: instructprompt.md里写的是给模型的指令你正在审查一个 TypeScript 项目的增量改动。 输入 - git diff 内容 - 变更文件列表 - 接口文档路径 执行步骤 1. 识别改动中涉及导出函数、类或类型定义的部分 2. 对比接口文档中对应的旧描述 3. 如果接口签名发生变化但文档未更新标注为问题 4. 输出表格文件 / 变更类型 / 是否有文档同步 / 建议 约束 - 只关注接口变更不评论代码风格 - 如果无法从 diff 中判断接口是否变化明确写“需要人工确认”这个技能没有特别复杂的脚本但它解决了我们团队一个真实、反复出现的问题接口文档和代码脱节。写出来之后我直接把它安装进常用列表每次提交前跑一遍至少能少几次被人提醒的尴尬。6.2 编写技能时的三个原则如果你也要自己写技能我建议先记住这三条原则。第一把边界定清楚。技能不是通用助手不需要覆盖所有场景。明确写出“本技能不做什么”有时候比写“做什么”更重要。像上面的例子“不评论代码风格”就是一条硬边界避免模型跑偏。第二把合格标准写进指令。与其写“高质量输出”不如写“输出必须包含一个表格列名分别是文件、变更类型、是否有文档同步、建议”。当我用“用户是否知道自己该拿着什么去执行下一步”来检验输出时技能质量明显上升。第三内置一个最小验证样例每次改完技能先拿一个很小的虚构代码片段测一遍不要在真实项目上边测边改。我吃过一次亏因为测试数据太大输出不稳定我很难判断是技能问题还是数据噪音。后来我用一段只有三个函数的小样本作为基准每次改完技能都先跑这个基准稳定了再上真实项目。6.3 本地验证、发布准备与我的维护习惯写完技能先做本地验证再决定是否放进团队或社区。我用过的最简单流程是antigravity skills test --skill ./code-review-ts这个命令会把技能在你指定的临时项目里跑一遍检查元信息是否合法、指令体是否能正常载入、脚本是否有语法错误。通过之后再拿一个真实任务测一下确认输出确实是你想要的格式。如果打算把技能分享回社区还有两件额外的事要做一是完整写明依赖条件比如需要什么版本的工具、什么能力的模型二是把示例中的敏感信息清理干净。我见过有技能示例里带着内网域名和密钥占位符虽然是假的但观感很差会直接影响别人对你的信任。现在我自己形成了一个比较稳定的维护习惯每次项目迭代结束花十分钟看看这周用过的技能哪些效果好就保留哪些总出问题就考虑替换或本地修改。个人判断标准很简单——如果一个技能让你在任务上多花的时间超过了它节省的时间那它就不值得存在。我对技能库后续演进的个人观察是这类社区技能很快会进入分层状态一部分会变成经过验证的基础技能被大量用户使用另一部分会变成垂直领域的专用技能由懂行的人维护。数字从 1527 继续往上长是必然的但真正考验一个使用者的能力不是收集了多少技能而是能不能在合适的场景里用合适的技能跑出稳定的结果。这也是我从“下载一堆技能”到“精简我的技能集”这段过程里最大的体会。