Google 的 Antigravity 正式宣布支持 Agent Skills 了。

好多人可能不知道 Antigravity，谷歌起名字还是一如既往的拉，英文名字是真难读，中文名字可以叫它反重力。

它是 Google 伴随 Gemini 3 Pro 推出的 AI IDE，定位是 agent-first IDE。

如果你还不知道 Skills 是什么，那可得恶补一下子了。

1. Skills，是你给 AI 配置的一份最佳实践手册。

就一个文件夹，一个 markdown 文件——SKILL.md。

SKILL.md 本质上是预先编写好的指导文档，告诉 Agent 如何高质量地完成特定类型的任务。

SKILL.md 文件开头是 YAML 元数据：

---
name: 这里写skill的名字
description: 这里写在什么场景下调用 skill，它可以做什么，什么时候能用
---

正文是具体指令：

# 怎么用
1. 第一步...（复习知识库...）
2. 第二步...（上网搜集资料...）
3. 第三步...（调研xxx代码...）
4. ......（包括但不限于以上，可以写任何你需要的流程）

还可以新建文件夹，放上他要用到的参考文献、脚本。就这么简单。

2. Antigravity 也一样，支持两种 skills：

2.1. 一是项目级 Skills，放在项目根目录：

/.agent/skills/<skill-name>/

比如你的项目叫 my-project，那就是：

my-project/
└── .agent/
    └── skills/
        └── my-skill/
            └── SKILL.md

你可以随时把它提交到 git，团队成员 clone 后就能自动获得。

2.2. 二是全局 Skills，配置后，你电脑上所有的项目都能用。

就放在下面这个路径里：

~/.gemini/antigravity/skills/<skill-name>/

当你开始对话时，Antigravity 就会：

• 扫描所有可用 skills
• 看你的任务和哪个 skill 匹配
• 自动加载并执行

当然，你也可以明确指定：

用 my-skill 帮我做这个任务

乍一听，也没什么啊，似乎只是写工作流？

但问题在于，过去这些东西几乎都是平台私有的，你换一个 IDE、换一个 CLI、换一个 Agent 框架，经验积累就要重来。现在不同了。

近两月，OpenAI、Anthropic、Gemini、国内各大平台正在纷纷下场支持 Skills，这阵仗，不亚于 2008 年的 App Store。

但问题又又来了，这么多平台都说支持 Skills，它们的支持程度一样吗？

3. 我们做了个测试

既然都说支持，那就测测呗。

我们设计了 4 个测试 Skills，在 Claude Code（Claude Opus 4.5）、Codex（GPT Codex 5.2）、Antigravity（Gemini 3 Pro）上分别跑了这四个 skills，用来检验各个平台对 Skills 的兼容性。

3.1. 第一个叫 hello-skill，用于检测 Agent 能否正确识别、触发 skill。

3.2. 第二个叫 format-boundary-trap，如果他正确地解析复杂的 YAML frontmatter（“标签，规则”），就没问题。

3.3. 第三个叫 strict-json-trap，主要看他能否输出纯 JSON（不能有 markdown 代码块、解释文字）。

3.4. 第四个叫 file-generation-trap，检验 skill 框架下，Agent 实际生成文件的能力。

4. 测试结果：全部满分？？？

出结果后，我反复确认了好几遍：

• ✅ 正确识别就不说，包成功的
• ✅ YAML 正确解析了，所有复杂的指令都可以正确显示
• ✅ JSON 输出成功，可以直接 JSON.parse() 调用
• ✅ 确实创建了文件，ls 能找到，cat 能打开

满分！ 至少，在"技能识别、格式解析、结构输出、真实落盘"这条基础链路上，它们的表现已经非常一致了。

似乎，Skills 标准，真的统一了？

5. 统一接口？很重要吗

昨天我遇到这样一个需求，用户上传了一批发票截图，但里面有重复的。我需要筛选出重复的发票。

好机械，给 AI 做得了。

我先直接让 Gemini CLI 做一部分，结果他直接搞了个视觉相似度算法，把画面相似的图片直接匹配。

我一看，全错了…… 即使最强多模态的谷歌也不要过度自信视觉匹配吧。

这些发票的交易号完全不同，根本不是重复的。要说重复，可能背景板是一样的吧……

没办法，考虑到这个场景会经常发生，与其每次临场纠正，不如把正确方法固化成 skill，我就手搓了一个 invoice-dedup skill：

name: invoice-dedup
description: 通过OCR提取交易号来识别重复发票
1. OCR识别发票文本
2. 正则提取交易号（20-30位数字）
3. 模糊匹配（处理OCR误差）
4. 分组输出重复发票

再做一些具体（几千字）的优化说明，终于可以了！

看完 skill，Gemini CLI 终于按正确标准工作，抓到了两组重复发票：

之后再处理这个需求，不发愁了！

这种"把正确路径写死、把错误路径封死"的效果，是 prompt 临场对话很难稳定做到的。

也正因为如此，Skills 真正让人兴奋的不是"又多了一个写法"，是三件事同时成立时带来的化学反应。

第一，一次编写，全平台通用正在变成现实。 以前你在某个平台里调顺的提示词、流程、规范，换个平台就得重来；现在，至少在基础标准上，Claude Code、Codex、Gemini、Cursor 等越来越多工具开始向同一个目录结构与 SKILL.md 收敛。

第二，创作门槛被压到地板。 写一个 skill 需要什么？一个文件夹，一个 SKILL.md。不需要懂训练，甚至不需要懂编程，你只需要能把经验写成"SOP 可执行的规范"。这会让大量"真正懂业务的人"有机会把自己的方法论产品化。甚至你可以让 AI 帮你写 skill。

第三，生态效应已经开始启动。 你看 SkillsMP 这种聚合站点上，skills 的数量增长非常快，粗制滥造、批量生成、质量参差。你会看到一些 skill 只是复制粘贴官方文档，description 写得模糊不清，甚至完全不可用。

这像不像早期 App Store 的榜单乱象？数量先爆，质量后补，优胜劣汰。

回头看，App Store 的爆发正是"统一入口 + 硬件成熟"同时成立。而今天的 Skills，正在满足同样的条件：模型足够强，Agent 足够通用，协议开始对齐。

从这个角度看，Skills 的故事，可能才刚刚开始。