魏金华最近不少朋友开始从“用 Google Antigravity 聊天”切换到“用 Google Antigravity 干活”，这两个状态之间的差距，大部分时候不是模型能力决定的，而是有没有把 Skills 玩明白。Google Antigravity 的 Skills 机制，简单说就是把一套可复用的能力模块塞给 AI Agent，让它在网页里写完代码之后还能自己跑测试、自己修前端样式、自己整理文献。对于写前端、做测试、搞研究和做内容创作的人来说，这个东西一旦用顺手，基本就回不去了。
这篇文章不讲基础操作，直接聊我实际跑过的玩法：Skills 怎么装、怎么定位、怎么写，以及把 Skills 用在测试、前端、研究和分镜里的具体踩坑记录。适合已经能跑通 Antigravity 基础流程、想再往上提一截的开发者。如果你连 Skills 是什么都还不太清楚，跟着下面的内容走一遍应该也能跑起来。
1. Antigravity 和 Skills 是什么关系
1.1 Antigravity 到底是什么
Google Antigravity 的核心并不是“又多了一个聊天窗口”，而是一个自带 Agent 运行时、能直接产出可运行 Web 应用的开发环境。它把模型能力塞进了编辑器、预览环境和部署流程里，你用自然语言描述需求，它负责拆任务、写代码、渲染预览、再根据反馈继续改。和传统 IDE 最大的差别是，这里的主角不是文件和光标，而是 Agent 的执行循环：理解任务、调用工具、观察结果、修正动作。
这也带来一个很明显的问题：默认情况下，Agent 每次接到任务都是从“通用知识”出发。它对你的项目结构、团队规范、测试习惯完全陌生，每次都要靠提示词交代一遍。我在实际使用中很快就发现，同样的需求，如果把上下文准备充分，产出质量和执行速度能差一个数量级。而“上下文准备”和“操作能力”的载体，就是这个项目标题里反复强调的 Skills。
1.2 Skills 到底在解决什么问题
Skills 本质上是一个“可复用的能力模块”。它把三样东西放在一起打包：一套给 Agent 看的操作规范，一般写在 SKILL.md 里，说明在什么场景下怎么做事；若干可执行的脚本或工具，用来调用外部 API、跑测试、解析文件；一份领域知识或模板，比如 API 文档摘要、代码风格约定、输出模板。
你可以把 Agent 理解成一位能力很强但经验不足的新员工，Skills 就是“新员工手册加检查清单加工具箱”。没有 Skills 的时候，你每次都要口头交代一遍；有 Skills 之后，你只要说“按前端开发流程处理”，Agent 自己会去加载对应 Skill，按既定步骤执行。
很多刚接触的人会把 Skills 和普通提示词混淆。区别在于提示词只是一次性文本，Skills 是带文件结构、可版本管理、可被条件触发、甚至能调用脚本的真正程序模块。它跟 Agent 的关系也不是绑定，而是按需加载：Agent 会根据当前任务目标去匹配 description，判断要不要调用这个能力。
1.3 这个设计和 Claude Code、Codex 的 Skills 有什么关系
提到 Skills，很多人第一时间想到的是 Claude Code 的 Skills、Codex Skills、OpenCode Skills。这批工具其实在把同一件事标准化：AI 编程 Agent 都需要一个可插拔的能力层。Antigravity 的做法在思路上高度一致，所以你之前如果已经会写 Claude Code Skills，迁移到 Antigravity 基本没有障碍。社区的很多经验也都是互相通用的，比如那些“好用的 claude code skills 安装”教程，里面的目录组织方式、提示词写法，在 Antigravity 里同样适用。
这也就解释了为什么现在各大平台都在强调 Agent Skills。从 AI Skills 到 Agent Skills 的演进，本质是从“会聊天”到“能干活”的演进。至于 AI Skills 和 Agent 的区别，我后面会专门说。总之，把 Antigravity 的 Skills 当作一个开放标准来学，而不是当作某个产品的私有功能，你的经验才不会白积累。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Skills 的获取与安装：别再手动复制粘贴了
2.1 先搞清楚 Skills 放在哪里
用 Skills 第一步是找到它的加载目录。Antigravity 沿用了主流 Agent 工具的惯例：既有用户级目录，也有项目级目录。用户级目录一般放在当前用户主目录下，比如在多数实现里是 ~/.antigravity/skills；项目级目录则放在 .antigravity/skills。两个目录的区别很简单：用户级的是“我在任何项目里都能用”，项目级的是“只有这个仓库能用”。
我个人的习惯是：通用能力，比如代码审查、commit message 生成、技术文档写作，放用户级；跟业务强相关的能力，比如某个后端服务的测试规范、特定组件库的使用约定，放项目级。这样既能随时复用，又不会让项目仓库变得臃肿。建议你装第一个 Skill 时，先用 Antigravity 自带的能力列一下当前配置，确认实际生效目录，而不是照着网上的旧教程一刀切。我见过不少朋友因为目录装错，界面里怎么都看不到技能，排错排了半天。
2.2 三种主流安装方式
我在实际使用中常用的安装方式有三种，按推荐程度排序。第一种是文件夹直接放入，把下载好的 Skill 目录整个放到 skills 目录下，这是最通用、最容易理解的方式，适合手动管理。第二种是社区脚本安装，现在很多开源 Skills 仓库自带安装脚本，自动化创建目录、下载文件、做基本校验。我自己用 superpower skills 和 mattpocock skills 这类大型技能包时，会直接用它们仓库里的安装命令，省事很多。
第三种是从 Skill Hub 拉取。Hermes Skills Hub 这类平台把多个开源 Skills 做了聚合，可以直接按名称搜索下载。这种方式适合“不知道用什么，想看看别人推荐什么”的场景，也方便做横向对比。
注意：无论用哪种方式，装完之后记得检查一下目录结构。最常见的问题是下载后整个仓库被套了一层外层文件夹，导致 Antigravity 找不到 SKILL.md。正确结构是“你的skills目录/某个技能名/SKILL.md”，不要多套一层。这个坑我至少踩过三次，每次都是装完看着没问题，一用就抓瞎。
2.3 值得留意的几个高质量 Skills 来源
这里分享几个我自己长期在用的，不含广告，纯属个人筛选结果。superpower skills 是 obra 维护的一套重量级技能集，覆盖面很广，包含任务拆解、代码审查、项目管理等，会把一个复杂工作流拆成多个可循环的子技能，对大型项目特别有用。mattpocock skills 是 Matt Pocock 出的 TypeScript 相关技能包，适合前端和全栈方向，里面很多提示词写法非常讲究。Hermes Skills Hub 则是聚合搜索平台，支持按标签筛选，适合做“skills 推荐”调研。
另外你也可以在 GitHub 上直接搜关键词。很多开源仓库把 Skills 做成独立目录，下载地址和安装说明都写在 README 里。搜索的时候建议用“find skills”“awesome ai skills”“开源skills 下载地址”这类组合词，比单搜一个词要准。很多作者会同时发布多平台版本，比如 Claude Code 桌面版和 Codex 都能用的通用技能包，所以看到“claude code skills 推荐”的帖子也不要直接略过。
关于“月老 skills 打分”这种社区行为，现在的生态里确实有不少开发者会给 Skills 做体验打分，主要关注点集中在三个维度：description 写得好不好、触发率高不高、会不会乱改代码。建议你选技能时也照着这个思路过滤，而不是只看 star 数量。
3. 手把手写一个能用的 Skill：从结构到细节
3.1 SKILL.md 的核心骨架
一个 Skill 能不能被 Agent 正确识别，第一步取决于 SKILL.md 的命名和位置。文件名建议叫 SKILL.md，内容放在技能目录的根目录下。它的核心结构是 YAML frontmatter 加正文，我拿一个前端审查技能的简化版举例：
code复制---
name: frontend-audit
description: 对前端页面做一轮结构化审查，检查布局、响应式、可访问性问题，并输出修复建议。当用户提到页面视觉、CSS 问题、布局错乱时使用。
---
# Frontend Audit
## 执行步骤
1. 先读取项目的页面结构文件，确认页面入口。
2. 使用浏览器工具打开页面，分别检查桌面端和移动端表现。
3. 逐项记录布局问题、样式覆盖问题、可访问性问题。
4. 输出 Markdown 格式的审查报告，按严重程度排序。
description 字段是 Agent 决定是否触发这个技能的关键。很多人的 Skills 不生效，就是 description 写得过于笼统，比如写成“执行前端审查”，Agent 压根不知道什么时候该调用。你要把适用场景、触发条件都写进去，甚至可以写上“当用户提到页面视觉、CSS 问题时使用”。这部分相当于给 Agent 的提示词广告位，写得好不好直接决定技能利用率。
3.2 一个真正好用的 Skill 应该满足哪三条标准
我写过不少 Skills，也删过不少。留下来的基本都满足三个标准。第一是单一职责，一个 Skill 只干一类事。前端审查就只做审查，不要把审查和自动修复混在一起，混在一起会导致技能体积大、触发判断难、执行过程容易出岔子。
第二是输入输出明确。在 SKILL.md 里写清楚接收哪些输入、产出什么格式的结果、输出到哪个文件。比如审查报告是输出到终端还是写入 docs/audit.md，要明确。含糊的 Skill 执行结果也一定含糊。第三是自带自检机制，好的 Skill 在最后一步会让 Agent 检查自己的输出是否符合格式要求，比如“如果发现报告缺少严重程度字段，请重新整理后再输出”。这个习惯能显著减少“看起来做了，其实没做完”的情况。
3.3 用脚本提升 Skill 的上限
Skill 不只是提示词。你可以在技能目录里放 scripts/ 子目录，写一些真正的代码供 Agent 调用。举例来说，我想做一个“批量优化图片元信息”的 Skill，就会写一个 Python 脚本处理 EXIF 读取和重命名，再在 SKILL.md 里告诉 Agent“当需要读取图片元信息时，运行 scripts/read_exif.py 并把输出作为分析依据”。
这里容易踩坑的一个细节是脚本路径问题。Agent 执行脚本时的当前工作目录不一定是技能目录，所以建议在 SKILL.md 里明确写清楚“脚本统一用绝对路径或基于项目根目录的路径调用”，或者让脚本内部先切换到自身所在目录，否则会出现“代码明明没问题，一跑就报找不到文件”的尴尬。脚本语言也不限 Python，Java、Node 写的命令行工具照样能被调用，只要标准输出是结构化文本就行。之前有人问 Ollama 怎么部署调用 Java 开发的 skills，本质上就是把 skill 脚本当作一个分发层，再通过 HTTP 或 CLI 调用后端服务，能力封装和语言没有必然关系。
3.4 把团队规范写进 Skills：给 Agent 一份“工作手册”
很多高级玩法是把团队规范固化到 Skills 里。前端团队的代码规范、组件库用法、状态管理约定，都可以拆成一个独立 Skill。这样 Agent 在改代码时会优先参考它，比自己临时搜项目文件快得多，也更能保持一致。
写这种规范型 Skill 时有一个诀窍：多用正面例子和负面例子。不要只写“代码要简洁”，要写“保持现有目录结构，不要新建 src 同名目录”“组件默认导出命名使用 camelCase，例如 userProfile”。Agent 对具体例子的理解远好于抽象表达。我甚至会在规范 Skill 里直接放一份“错误写法记录”，把过往几次 Agent 跑偏的情况整理进去，让模型从失败案例里学习，效果比我反复强调语气词好得多。
4. 实战场景：Skills 能帮你干什么活
4.1 前端开发：让 Agent 按照你的组件库风格干活
前端是 Skills 应用最密集的场景。你完全可以做一个 frontend-dev Skill，里面塞三部分内容：项目结构说明、组件规范、常见任务的执行顺序。比如当用户说“加一个筛选栏”时，Skill 会引导 Agent 先读现有组件，再判断是复用已有筛选组件还是新建，最后才动代码。如果没有这个 Skill，Agent 很可能会按自己习惯直接生成一个全新组件，导致项目里出现两套长得差不多的东西。
这里我想特别讲一下“结构图 skills”的用法。我在给复杂项目写 Skill 时会包含一个 prompts/ 目录，里面放若干结构图生成提示词，让 Agent 在改代码前先用文本形式输出目标页面的组件树和状态流，再开始改。这能让改动路径更清楚，也方便我审查：如果结构图有问题，代码大概率也有问题。这种“先画图再动手”的节奏，在大型前端项目里尤其值得推广。
4.2 测试：vscode + codebuddy + playwright 的组合玩法
不少人在问“vscode+codebuddy+playwright 测试 skills 在哪下载”。其实这类测试 Skill 的核心思路不是下载一个万能包，而是把测试流程标准化。我自己写了一个简单的 UI 测试 Skill，内容包括：启动本地开发服务、用 Playwright 打开页面、按关键路径执行点击、收集控制台错误、截图并生成测试报告。有了这个技能之后，我在测试上的重复劳动明显减少，只要告诉 Agent“跑一遍核心链路回归”就行。
在测试相关的 Skills 里，最大的坑是元素选择器写死。如果 Skill 里直接写 button:has-text("登录")，页面文案一变就挂。比较好的做法是引导 Agent 优先使用 data-testid 或稳定的位置关系；如果项目还没有打测试标识，Skill 可以先输出一个“建议为以下组件补充 data-testid”的清单，而不是直接硬等。
另外一个提醒：测试 Skill 的执行时间通常较长，建议在 SKILL.md 里设置明确的超时和失败重试规则。比如“页面元素 10 秒内未出现则截图并记录现状，而不是无限等待”。我看到不少测试任务的失败不是因为功能坏了，而是脚本一直等待一个永远不出现的元素，白白浪费长时间。
4.3 学术研究：从文献到论文草稿的辅助工作流
关于“academic research skills”和“agent skills 赋能人文社科混合研究方法论文写作”，我实际使用的心得是：Skills 不能替你做研究，但能把研究过程中的繁琐环节压缩到极致。我构建了一个简单的学术检索 Skill，内部包含文献检索关键词的生成规则、文献去重策略、引文格式检查，以及一段“混合研究方法论文结构模板”。当我对着一堆笔记说“整理成文献综述初稿”时，Agent 会先按 Skill 里的规则做去重和归类，再按模板组织成带引用标记的 Markdown 文件。这样我后续润色时只需要关注观点本身，不用在格式上耗时间。
有一点要特别声明：这类 Skill 的输出只能作为辅助材料，最终论文的思路、数据和结论必须你自己审核。我见过有人直接把 Agent 生成的句子放进正式论文，结果引用来源都编错了。这类工具是用来压缩查资料和排版时间的，不是用来替代学术判断的。
4.4 内容创作：分镜 Skill 是真的能出活
说到“分镜 skills 下载”，我在做视频脚本时真的被这种技能救过。一个设计良好的分镜 Skill 至少包含两部分：分镜表格模板和镜头语言规范。它会把“写一个 60 秒产品介绍视频的分镜”自动拆成：开场问题、痛点展示、方案引入、功能亮点、行动号召，每个分镜都带时长、画面、台词、字幕、转场方式。
这里的关键细节是：分镜 Skill 的输出必须是结构化表格，不要是自然语言段落。我在 SKILL.md 里会明确要求输出 Markdown 表格，并且规定每一列的字段名，比如编号、时间范围、画面描述、台词、字幕、备注。这样做的好处是后续可以直接粘贴到剪辑软件的分镜表里，不用再做一遍格式转换。如果你做的是视频号或短剧方向，可以再给 Skill 加一个“情绪曲线”字段，把每个分镜的情绪节奏也标注出来。
4.5 AI Skills 和 Agent 到底有什么区别
这个问题被问得很多。简单说：Agent 是会思考、会调用工具、会执行循环的执行体；Skills 是它大脑里的一部分“可装卸的知识和技能包”。你可以把 Agent 比作操作系统，Skills 比作安装在系统里的应用软件。没有 Skills 的 Agent 也能跑，但装上 Skills 才能干某个领域的专业活。
很多人问“OpenAI 怎么继承 skills”，其实各大平台之间已经在往统一格式上靠。你现在写的一个基于 SKILL.md 的技能，在 Antigravity、Claude Code、Codex、OpenCode 之间迁移时，主要改动只是目录命名和少量配置字段。真正需要重写的往往是内部调用的专用脚本。这也是我建议新手从一开始就保持“技能目录和脚本解耦”的原因，能让你的技能包在未来很长一段时间内保持可移植性。
5. 常见问题与排查技巧实录
5.1 VSCode 登录不上 Google Antigravity
这是一个被问崩的问题。我的排查顺序固定是：首先确认是否所有 Antigravity 相关窗口都已关闭，然后重新打开扩展，很多时候不是账号问题，是扩展的连接状态卡住了。其次是清理认证缓存，VSCode 的 OAuth 登录信息如果过期或损坏，会出现点击登录后一直转圈但不弹浏览器的情况，把本地存储里的认证信息清掉重来就好。
然后是检查系统时间，时间偏移会导致认证签名校验失败，这个问题比较隐蔽，正常人第一反应都不会想到。最后是查看 VSCode 输出日志里 Antigravity 相关的错误码，重点看是超时还是鉴权失败。如果上述都试过还不行，我会把扩展降级到能用的旧版本再试，开发工具的版本更新速度很快，偶尔出现兼容性回归是正常的。单独说明一下，登录问题里最常见的问题方向其实是本地认证状态和扩展版本不匹配，先清理状态、再做基础排查，往往五分钟内就能解决。
5.2 Skills 装了但 Agent 死活不调用
这个问题的头号原因是 description 写得太差。你可以把 description 理解成 Agent 挑选工具时的产品介绍，它必须写清楚“什么场景下值得使用”。实战经验是，description 里至少要包含任务对象、动作、输出物三个元素。比如“对前端页面做结构化审查，输出修复建议”就比“前端审查”好用得多。
第二个常见原因是 SKILL.md 放在错误目录层级下，装完技能后一定要确认没有多套一层文件夹。第三个原因是同名冲突，如果你在用户级目录和项目级目录放了两个同名 Skill，系统可能只会加载其中一个，而且不一定是你想要的那个。我还会做一次终极验证：在 Antigravity 对话里直接问“你的可调用技能列表里有哪些”，看这个 Skill 是否出现在列表中。如果出现了但不被主动调用，那就继续优化 description；如果根本没出现，就查目录和文件名。
5.3 脚本依赖与跨平台问题
如果你在 Skill 里放了脚本，最常出现的报错是路径错、依赖缺、编码不对。路径问题前面已经提过，统一用绝对路径或先切到脚本目录解决；依赖问题通过“自动检查加自动安装”解决；编码问题主要出现在 Windows 上，脚本里读文件时请显式指定 encoding='utf-8'。
另外建议大家给脚本加上“只读优先”的原则。很多 Skill 脚本的职责是读取分析类操作，不必要写文件的时候就不要提供写权限，这样能避免 Agent 在误判时对项目文件造成不可逆的改动。如果你确实要写文件，脚本内部先做一次备份再覆盖。这个习惯救过我至少三次，现在我把所有带写入功能的 Skill 都加了一层备份逻辑，成本极低，收益却很实在。
6. 踩了几轮坑之后，我对 Skills 的真实感受
第一次接触 Antigravity 的 Skills 时，我以为它只是把提示词做了个文件夹封装，没必要太当回事。后面真正把大型技能包和自定义脚本跑起来之后才发现，这套机制改变的其实是 Agent 的“可靠程度”。它让 Agent 不再每次都从零理解任务，而是有一整套可复用的工作流程可以照做，产出的稳定性也比靠“临场发挥”高出一截。
我自己的经验是，不要一上来就追求多。刚开始可以先收藏几个现成的高分 Skills，用几周时间观察哪些场景真的让你省事，哪些技能其实一直在吃灰；然后再针对吃灰的原因，自己动手写一个专属版本。自己写 Skill 的成就感远大于到处找下载，只有你最清楚自己每天在重复做什么工作。
另一个体会是，Skills 的价值会随着使用时间不断累积。你积累的每一个规范、每一段踩坑记录、每一条质量检查点，都会慢慢沉淀成可复用的能力。这可能是这类工具最被低估的地方：它不只是让 AI 更聪明，还在帮你把个人经验变成一种可以被重复执行的标准流程。这也是我愿意一直折腾下去的原因。