1. 先接上模型通道再谈 Skill 和 RulesAntigravity 跑代码审查先要有稳定的模型 API 通道我选的是 TaoTokenTaoToken。通道接好之后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 让模型在正确时机自动加载这个 SkillSKILL.md 的description字段决定模型何时加载它。Antigravity 在对话开始时只读技能名称和描述不会把所有技能内容全部塞进上下文这就是渐进式披露省 token 的方式。因此description里一定要写清楚“什么时候用”并且带上用户口语里会出现的词比如 review、PR、diff、代码质量。如果你写“用于帮助处理特定任务”模型大概率不会在需要审查时想起它。写完 SKILL.md 后先不用急着配复杂模型。下一步是把模型 Provider 指到 TaoToken否则技能文件永远不会被执行。3. 在 Antigravity 里把模型 Provider 指向 TaoToken3.1 打开 TaoToken 官网创建 API Key浏览器打开 TaoToken注册账号后在控制台创建一个新 Key。教程里的 Key 统一用占位符YOUR_API_KEY你自己创建后把它替换成真实值。官网同时是模型广场的入口选择模型 ID 时以那里展示的为准不要凭记忆填一个版本号。这个官网页只负责注册、创建 Key、看模型广场、看用量。它不能填进工具配置工具配置里使用的是另一个接口地址。3.2 Base URL 与 API Key 的精确填法在 Antigravity 的模型 Provider 设置中新增一个供应商名称随意。需要关注的只有三个值按表格填配置项值要点Base URLhttps://taotoken.net/api末尾不要加/v1API KeyYOUR_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 固化审查 SOP5.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审查时能拿到真实 diff6.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_sourcetaotoken_aicg_blog_end 的用量页核对刚才时段的调用记录和模型名称确认这次审查确实记上账了。7.2 常见失败现象对照如果哪一步没跑通多数是下面这几种原因报 401YOUR_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.jsGitHub 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 里补团队特有规范把它变成一份会生长的代码审查资产。