1. 先接上模型通道，再谈 Skill 和 Rules
Antigravity 跑代码审查，先要有稳定的模型 API 通道，我选的是 TaoToken（TaoToken）。通道接好之后，Skill 决定审查步骤，Rules 约束代码风格，MCP 拿 GitHub 上的真实 diff，三者组合起来才像真正的自动审查员。
第一次让 Antigravity 审 PR 时，我在对话框里顺手写了句“看看这个 PR 有没有问题”，它给了三条比较宽泛的建议。第二次我补了一句“注意边界条件”，它就盯着并发和空值。第三次我说“按团队风格检查”，重点又变了。问题不在模型，而在于临时 Prompt 没有把审查标准固定下来。真正能复用的做法，是把审查流程写进 SKILL.md，把团队硬性规范写进 Rules，再用 Workflow 把整件事固化成一条命令。但这些能力启动前，还得先有一个不发神经的模型通道——多 Key 来回切、长会话聊到一半断掉，都是 Skill 写得再漂亮也补不回来的。
1.1 三条临时 Prompt，换来三种审查结果
Skill 在 Antigravity 里是一个可复用的知识包，本质上是一个文件夹加一个 SKILL.md 文件。它解决的问题很直接：把“谁来审、按什么审、审完怎么反馈”固定成文件，而不是每次在输入框里现编。原文把这种机制叫渐进式披露——对话开始时，Antigravity 只看到技能名称和描述列表；如果描述和当前任务相关，它才读取完整 SKILL.md。换句话说，你不需要每次告诉它“去读技能”，只要描述写得够准，它自己会判断。
代码审查是最适合先做成 Skill 的场景，因为审查标准相对稳定：正确性、边界情况、风格、性能，这些不会一天一变。如果你手头有三个项目，每个项目的规范都不同，把它们分别固化成三个 SKILL.md，比每次复制粘贴一长段 Prompt 要省事得多。
1.2 Skill、Rules、Workflows、MCP 在审查链路里各自管什么
用一句话概括这几样东西的分工：Skill 是“要做哪些事”，Rules 是“绝对不能突破的边界”，Workflow 是“按什么顺序做”，MCP 是“从哪里拿到真实数据”。代码审查这个场景刚好把它们串起来：
- Skill 定义审查步骤：正确性、边界条件、风格、性能、安全。
- Rules 强制团队规范：命名、缩进、禁止循环内查询之类的硬约束。
- Workflow 把“取 diff → 逐条检查 → 汇总反馈”变成一条命令，比如
/review。 - MCP 把 GitHub 的 PR diff 和文件变更列表交给模型，让审查有据可依，不靠猜。
这四件套都就位后，Antigravity 才真正像一个审查员。不过原文主要在讲概念和配置，真正跑起来还需要一个稳定的模型请求通道。我把这个通道接到 TaoToken，后面会细说 Provider 的填法。
2. 创建 SKILL.md：把审查要求固化成技能包
2.1 审查技能放在 .agent/skills 还是全局目录
Antigravity 支持两种 Skill 位置：工作区级放在/.agent/skills/，全局放在~/.gemini/antigravity/skills/。团队仓库里的审查规范适合放工作区级，随仓库提交，每个成员拿到代码就自带审查标准；自己的通用审查习惯可以放全局，比如你无论写什么项目都想先过一遍安全 checklist。目录结构像这样：
.agent/skills/ └── code-review/ ├── SKILL.md ├── scripts/ └── resources/scripts/和resources/不是必需的，但可以放一些辅助脚本和模板。唯一必需的就是SKILL.md。
2.2 一份可执行的 code-review SKILL.md
下面是一份可以直接落地的 SKILL.md，比原文示例多加了决策树和输出规范，目的是让模型每次反馈颗粒度一致：
--- name: code-review description: 检查代码变更中的错误、风格偏离和最佳实践遗漏。当用户要求 review PR、检查 diff、评估代码质量时使用。 --- # 代码审查技能 按这里的步骤审查代码变更，不要跳过任何一项。 ## 适用范围 - Pull Request 或本地未提交的 diff。 - 单个文件或跨模块改动。 ## 审查清单 1. 正确性：代码是否实现预期功能？条件分支是否覆盖了 false、null、空集合？ 2. 边界情况：超时、并发、重试、溢出、格式非法时如何处理？ 3. 风格：是否遵守 .agent/rules 目录下的项目规范？ 4. 性能：是否存在循环内查询、重复请求、无必要的大对象拷贝？ 5. 安全：是否有注入、敏感信息硬编码、文件路径串联等风险？ ## 决策树 - diff 小于 20 行：按清单逐项快速过一遍。 - diff 涉及多个文件：先看接口签名与数据流，再查每个调用方。 - 出现空 catch 或 pass：提高严重程度，要求补上错误处理。 - 涉及数据库操作：确认是否在循环内，是否缺索引，是否可能全表扫描。 ## 输出格式 - 按严重程度分组：严重、建议、可选。 - 每条问题必须包含：文件位置、问题描述、修改建议。 - 没有问题时直接说“未发现明显问题”，不要堆套话。 ## 禁止事项 - 不修改任何文件，除非用户明确要求自动修复。 - 不只给结论不给依据。 - 不把 20 条小问题一股脑列出，只列优先级最高的 5 条。 ## 可选脚本 如果 scripts/ 目录下有辅助脚本，先用 --help 查看用法，不要通读源码。2.3 让模型在正确时机自动加载这个 Skill
SKILL.md 的description字段决定模型何时加载它。Antigravity 在对话开始时只读技能名称和描述，不会把所有技能内容全部塞进上下文，这就是渐进式披露省 token 的方式。因此description里一定要写清楚“什么时候用”，并且带上用户口语里会出现的词，比如 review、PR、diff、代码质量。如果你写“用于帮助处理特定任务”，模型大概率不会在需要审查时想起它。
写完 SKILL.md 后，先不用急着配复杂模型。下一步是把模型 Provider 指到 TaoToken，否则技能文件永远不会被执行。
3. 在 Antigravity 里把模型 Provider 指向 TaoToken
3.1 打开 TaoToken 官网创建 API Key
浏览器打开 TaoToken，注册账号后在控制台创建一个新 Key。教程里的 Key 统一用占位符YOUR_API_KEY，你自己创建后把它替换成真实值。官网同时是模型广场的入口，选择模型 ID 时以那里展示的为准，不要凭记忆填一个版本号。
这个官网页只负责注册、创建 Key、看模型广场、看用量。它不能填进工具配置，工具配置里使用的是另一个接口地址。
3.2 Base URL 与 API Key 的精确填法
在 Antigravity 的模型 Provider 设置中新增一个供应商，名称随意。需要关注的只有三个值，按表格填：
| 配置项 | 值 | 要点 |
|---|---|---|
| Base URL | https://taotoken.net/api | 末尾不要加/v1 |
| API Key | YOUR_API_KEY | 从 TaoToken 创建 |
| 模型 ID | 以官网模型广场展示为准 | 不要凭印象填版本号 |
注意：Base URL 填的是https://taotoken.net/api，不是官网链接，也不要加/v1。很多工具接入失败就是在这里多写了一段后缀。配好之后，长会话和切换模型就不再需要换 Key，换模型只改模型 ID 一个字段，这对反复试模型的场景很关键。
4. 用 Rules 约束代码风格
4.1 从 Customizations 打开 Rules 面板
Rules 是手动定义的 Markdown 约束文件。在 Antigravity 中，点击 Agent 面板底部的 Antigravity Settings，找到 Customizations，点 Manage，就能进入 Rules 面板。你可以创建 Global Rule 或 Workspace Rule：团队仓库的硬性规范放 Workspace，个人通用习惯放 Global。
4.2 代码审查 Rules 模板与激活方式
下面是一份审查场景的 Rules 模板，可以直接存到.agent/rules/下：
# 代码审查规则 1. 变量名使用小驼峰，常量使用全大写。 2. 函数体不超过 80 行，超过则拆分。 3. 禁止在循环里执行数据库查询。 4. 捕获异常后必须写日志，禁止空 catch。 5. 所有 SQL 语句必须带参数绑定，禁止字符串拼接。 6. 审查意见必须引用具体文件和行号。创建规则时可以在面板选择激活方式：Manual 通过@手动唤起；Always On 常驻所有对话；Glob 模式绑定文件路径，只有打开匹配文件时生效。审查场景最推荐 Glob，例如仓库主要是 TypeScript，可以给规则配src/**/*.ts，这样审查 TS 文件时强制挂载规则，查看文档时规则不占上下文。
Rule 和 Skill 的差别在这里很清晰：Rule 是在 System Prompt 层面的持久约束，定义“不能做什么”；Skill 是任务触发后加载的操作步骤，定义“要做什么”。一次代码审查里两者都会用到，Rule 负责风格底线，SKILL.md 负责流程和质量维度。
5. 用 Workflow 固化审查 SOP
5.1 创建 /review 工作流
如果每次审查都要重复“拿 diff、查规则、汇总问题”这一套，可以把它沉淀成 Workflow。在 Customizations 的 Workflows 面板里创建全局或工作区工作流，文件格式是 Markdown，包含名称、描述和步骤。一个代码审查 Workflow 的模板如下：
--- name: review description: 对当前分支的未提交改动执行一次完整代码审查，并输出结构化问题清单。 --- 1. 列出当前分支相对 main 的改动文件。 2. 对每个文件应用 .agent/rules 下的审查规则。 3. 加载 code-review Skill，按审查清单逐项检查。 4. 把问题按严重程度分组输出。 5. 询问是否生成修复补丁；未获确认前不要修改文件。保存后，在 Antigravity 对话框输入/review即可执行。Workflow 也可以嵌套，比如把风格检查、逻辑检查拆成原子工作流，再组合成/review，这样单独跑某一步时不用重复整个流程。
5.2 Workflow 与 Implementation Plan 的差异
Workflow 和 Antigravity 自动生成的implementation_plan.md不是一回事。Workflow 是长期流程模板，像工厂流水线，任何代码变更都可能经过它；Implementation Plan 是一次性施工图，只针对当前需求，任务合入后基本作废。如果你发现每次改完代码都要重复做一遍审查，那就把这段经验写成 Workflow，而不是让模型每次重新规划。
6. MCP 接通 GitHub：审查时能拿到真实 diff
6.1 用 npx 把 GitHub MCP Server 接进 MCP Store
代码审查如果只看模型上下文里的片段，很多问题发现不了。MCP 可以把 GitHub 的真实 diff、PR 变更列表、提交历史拉给模型。以 GitHub MCP Server 为例，编辑mcp_config.json，加入以下配置：
{ "mcpServers": { "github": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"], "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_YOUR_TOKEN" } } } }GITHUB_PERSONAL_ACCESS_TOKEN用你自己的 GitHub Token，权限只需要 repo 读写。保存后在 MCP Store 面板点击 Refresh，状态变成 Enabled 再继续。如果 GitHub 官方后续更新了推荐的 MCP 包名，以你当前环境的文档为准，这里沿用最常见的 npx 方案。Windows 下用 npx 比 Docker 省事不少，至少绕开了环境变量和镜像这一类报错。
6.2 从开放生态里安装现成 Skill
除了手写 SKILL.md，还可以用npx skills从开放生态里搜现成的审查技能。先运行：
npx skills find code-review从返回结果里挑一个，再按这个格式安装到当前项目：
npx skills add -y 作者名/技能仓库@技能名把“作者名/技能仓库@技能名”替换成实际搜索结果，不要照抄占位符。安装后它同样出现在.agent/skills下，Antigravity 会把它当普通 Skill 识别，触发方式与手写的一致。这适合不想从零写 skill 的开发者，装完先看内容再按团队规范改。
6.3 一次 PR 审查的执行轨迹
当 Skill、Rules、MCP 都接好后，一次 PR 审查会像下面这样跑：
| 阶段 | 输入/指令 | Antigravity 执行 |
|---|---|---|
| 启动 | 输入/review | 加载 code-review Skill，激活匹配的 Rules |
| 取 diff | 无 | 调用 GitHub MCP 读取 PR 的文件变更列表与完整 diff |
| 检查 | 无 | 按审查清单逐项检查，Rules 里的约束一并生效 |
| 反馈 | 无 | 输出按严重程度分组的问题清单，附文件位置和建议 |
| 提交评审 | “把意见发到这个 PR” | 调用 GitHub MCP 创建 PR Review，附上模型生成的总结 |
MCP 的价值在这一步完全体现出来：模型不再靠猜，而是直接读 GitHub 上真实 diff；审查结果也能以评论形式回流到 PR 页面，形成闭环。而整个闭环里的所有模型请求都走同一个 Key——经 TaoToken 的 Base URL 发出，任务里换来换去也不会锉断了。
7. 验证、排障与权限边界
7.1 完整调用验证
配完以后建议按这个顺序验证一次：
- 在仓库里随便改一行代码，保持未提交。
- 输入
/review，观察 Antigravity 是否先出现 MCP 工具调用，再进入分析。 - 对照输出是否出现 SKILL.md 里定义的严重程度分组和行号引用。
- 在对话中问一句“你使用了哪些规则”，如果模型能说出
.agent/rules下的具体条目，说明 Rules 已激活。 - 打开 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 的用量页，核对刚才时段的调用记录和模型名称，确认这次审查确实记上账了。
7.2 常见失败现象对照
如果哪一步没跑通，多数是下面这几种原因：
- 报 401：
YOUR_API_KEY没替换成真实 Key，或者复制时多了空格。到官网控制台重新复制。 - 报 404：八成是把官网链接当成了 Base URL，或者末尾多写了
/v1。Base URL 应该是精确的https://taotoken.net/api。 - Skill 不触发：检查
description是否包含review、PR、diff这些词。Antigravity 靠描述决定是否加载技能。 - GitHub MCP 显示红色：到 MCP Store 点 Refresh，确认本机装了 Node.js，GitHub Token 没有过期。
7.3 权限边界
MCP 接上 GitHub 后能读能写，但审查场景只需要“读 diff”和“创建 PR Review”两种能力。涉及批量修改文件、git push、合并分支时，让模型先输出方案，你审核后再执行。数据库和系统命令也一样：SQL 诊断、编译、运行必须由你在本地终端或 SQL*Plus 里执行，再把结果贴回对话，不要让 Agent 直接在生产库上跑命令。规则里写清楚“未获确认前不要修改文件”，能让模型在敏感操作前停下来等你。
7.4 拿上 Key，用 /review 跑一遍完整链路
把上面的 Provider 配好后，第一步不用急着写复杂规则。打开 TaoToken 创建 Key，回到 Antigravity 填好，跑一条最简单的指令：用 code-review Skill 检查当前分支的未提交改动。如果输出里出现了 SKILL.md 中定义的检查项和反馈格式，说明整条链路已经从“Skill 定义 → Rules 约束 → MCP 取 diff → Token 记账”闭环。后续再逐步往 SKILL.md 里补团队特有规范，把它变成一份会生长的代码审查资产。
